UniFi RBAC Gap: a Limited Admin Can Still Read Full Site Settings

A social-engineering attempt that did not work is still a good reason to audit everything else. An unrelated vishing call triggered a precautionary sweep across a home network's infrastructure. It turned up an automation API key with far more access than it needed, and a role downgrade that looked like a fix and was not 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 self-hosted infrastructure. But a caller who has done real reconnaissance is a signal worth taking seriously, not a one-off. The reasonable response is not "nothing happened, move on". It is a precautionary pass across everything that account, or an account like it, could plausibly pivot toward. Source control, password managers, cloud accounts, and the network controller itself.

What the audit found

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

The obvious fix is dropping that account to a restricted role, and UniFi supports exactly that. 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

I confirmed that directly. The same API key, on 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 is fixed", you walk away from an incident like this with a false sense of closure.

What to actually do about it

• Verify the fix, do not just apply it. After you change a permission or role, re-run the exact request that exposed the problem and confirm the response changed. Not that the settings page shows what you expect.
• Restrict at the network layer too, not only the application layer. A key or account scoped to local-network-only access cannot be abused from outside your LAN, even when its application-level permissions turn out to be broken. Treat that as a second independent control, not a substitute for correct RBAC.
• Rotate anything ever exposed in cleartext, on principle. Even with a mitigating control in place, like a second factor gating the login, treat a credential a low-privilege key could read in plaintext as burned and replace it. It is cheap, and there is no good reason to leave a known-exposed value in place.
• Audit automation credentials on a schedule, not after an incident. The over-privileged key here was not a mistake made under pressure. It was never revisited after the day it was created. Every standing API key or service account deserves a periodic "does this still need what it has" pass, whether or not anything has gone wrong recently.