A Vishing Attempt Turned Up a Real UniFi RBAC Bug

A social-engineering attempt that didn't work is still a good reason to go audit everything else. A precautionary sweep across a home network's infrastructure — triggered by an unrelated vishing call — turned up an automation API key with far more access than it needed, and a role downgrade that looked like a fix but wasn't a complete one.

Why an unrelated phone call led to auditing a router

The call itself never got anywhere — it targeted a Google account, not any self-hosted infrastructure. But a caller who's done real reconnaissance is worth taking seriously as a signal, not just a one-off. The reasonable response isn't "nothing happened, move on" — it's a precautionary pass across everything that account, or an account like it, could plausibly be used to pivot toward: source control, password managers, cloud accounts, and the network controller itself.

What the audit found

Buried in that sweep: a UniFi Network API key, created months earlier for a read-only documentation-sync job, was backed by an admin account still set to Super Admin. Nothing had ever actually needed that level of access — the automation only ever listed sites, devices, and clients. It had just never been revisited since the day it was created.

The obvious fix: drop that account down to a restricted role. UniFi supports exactly this — a custom viewer role, with both the network and admin permission scopes set to "View Only", already existed and was in use by a separate, correctly-scoped automation account on the same controller. Applying the same role to the over-privileged key looked like a clean, complete fix.

The part that didn't actually get fixed

This was confirmed directly: the same API key, using the same credential, hit that endpoint before and after the role downgrade and got byte-for-byte the same sensitive fields back both times. If your only verification step is "I changed the role, so it's fixed," you can walk away from an incident like this with a false sense of closure.

What to actually do about it

• Verify the fix, don't just apply it. After changing a permission or role, re-run the exact request that exposed the problem and confirm the response actually changed — not just that the settings page shows what you expect.
• Restrict at the network layer too, not just the application layer. A key or account scoped to local-network-only access can't be abused from outside your LAN even if its application-level permissions turn out to be broken — treat this as a second, independent control, not a substitute for correct RBAC.
• Rotate anything that was ever exposed in cleartext, on principle. Even with a mitigating control in place (a second factor gating the actual login, for example), a credential that a low-privilege key was able to read in plaintext should be treated as burned and replaced — it's cheap, and there's no good reason to leave a known-exposed value in place indefinitely.
• Audit automation credentials on a schedule, not just after an incident. The over-privileged key here wasn't the result of a mistake made under pressure — it was just never revisited after the day it was created. Every standing API key or service account is worth a periodic "does this still need what it currently has" pass, independent of whether anything has gone wrong recently.