Why Exploited Admin-Only Bugs Demand a Firewall Admin Audit

A firewall admin audit is overdue the moment a vendor confirms exploitation of a bug that requires administrator access. An admin-only flaw can only be used by someone holding an admin session, so real-world exploitation tells you that, somewhere, attackers had one. PAN-OS CVE-2026-0322, added to CISA KEV on 14 October 2026, is that kind of flaw. Patching closes the bug. It does not tell you who else holds your admin credentials.

Why does an exploited admin-only bug point to credential problems?

Because the attacker had to authenticate as an administrator first. Exploitation of a privileges-required-High flaw means admin access was obtained, whether through stolen credentials, a chained bug or an insider.

Vendors rarely say which. Palo Alto Networks' advisory for the PAN-OS CVE-2026-0322 management interface RCE reports very limited exploitation and lists three attacker IP addresses, but does not explain how those attackers authenticated. Your organization may not be one of the victims. You still cannot rule out that your admin credentials are in the same state as theirs until you check. The scoring side of this is covered in what CVSS privileges required means for patch triage.

What makes firewall admin accounts a target?

They control the device that decides what traffic is allowed, and they are often managed more loosely than domain admin accounts.

Common weaknesses in firewall admin accounts:

• Local accounts outside the directory. They do not inherit password policy, MFA or leaver processes.
• Shared logins. One "admin" account used by the whole network team leaves no attribution and never gets rotated.
• Former staff and contractors. Accounts created for a project and never removed.
• Credentials in config backups. Exported configurations stored on file shares or in ticket attachments can contain account data.
• Service accounts with full rights. Monitoring or backup tools given superuser roles because a narrower role was harder to set up.

Any one of these turns PR:H into a formality.

What should a firewall admin audit cover?

Every account that can log in, every path it can log in from, and evidence of how each has been used. Run it per device, including central managers.

1. List accounts. Local accounts, directory-backed accounts and API keys, with their role on each device.
2. Match each to a named owner. Any account without a current owner is disabled pending review.
3. Check authentication. Confirm which accounts use MFA through the directory or a RADIUS/SAML source, and which rely on a local password alone. Palo Alto Networks' administrative access guidance calls for MFA through RADIUS or SAML for every administrator who can make changes.
4. Review recent logins. Pull admin login history for at least the past 90 days. Flag logins from unexpected source addresses, odd hours, or accounts that are normally idle.
5. Compare against advisory indicators. For CVE-2026-0322, search logs for the addresses Palo Alto Networks lists: 66.42.72.14, 208.83.239.114 and 149.248.47.234.
6. Review configuration changes. Look for new admin accounts, new management access entries, or policy changes no ticket explains.
7. Rotate. Change passwords and regenerate API keys for every account that remains, after you have preserved logs.

If step 4 or 6 turns up something unexplained, stop treating it as an audit and start incident response. Preserve evidence before upgrading, since CISA flagged CVE-2026-0322 for forensic triage.

Why not just patch and move on?

Because the patch removes one way to turn an admin session into root. It does nothing about the admin session itself.

An attacker who holds valid admin credentials can still change policy, add accounts, read configuration and open VPN access on a fully patched firewall. Admin access to a firewall is already enough to do serious damage. The code execution bug lets them go further and persist below the management layer. Fixing the bug while leaving stolen credentials valid closes the smaller door.

This is the same lesson as why patching your VPN gateway does not evict the attacker already inside: a fix stops new exploitation, not access that already exists.

How do you reduce admin exposure long term?

Fewer accounts, tied to the directory, reachable from fewer places. Each change makes the next admin-only bug less useful to an attacker.

• Directory-backed named accounts only, with MFA enforced at the identity provider.
• One local break-glass account per device, with a vaulted random password and an alert on every use.
• Role-based access. Read-only roles for monitoring and auditors; full admin only for the few who change policy. On PAN-OS this is done with admin role profiles.
• Management reachable only from a jump box or privileged access workstation, as described in how to restrict firewall management access to a jump box.
• Quarterly access review, with the account list signed off by the network lead.

Who should own the firewall admin audit?

The network or security engineering lead who owns the firewalls, with the identity team supplying directory and MFA data. The result should be a signed account list per device.

Budget a day for a small estate and a week for a large one. The first audit is the slow one. After that, the quarterly review is a comparison against the last signed list.