This is a loaded nail gun left on the jobsite, but only if you actually plugged it in near the street
CVE-2026-0264 is a heap buffer overflow in the PAN-OS DNS Proxy and DNS Server handling path. An unauthenticated attacker who can reach the vulnerable path can send crafted DNS traffic and crash affected firewalls; on PA-Series hardware Palo Alto says the same bug can also *potentially* lead to arbitrary code execution. Affected branches are PAN-OS 10.2, 11.1, 11.2, and 12.1 before the fixed maintenance releases; Panorama, Cloud NGFW, and Prisma Access are not affected.
In practice, this is not a blanket 'every firewall on the internet is trivially RCEable' event. The real exposure is narrowed by Palo Alto's own gating conditions: the firewall must have DNS Proxy enabled with an interface attached, or it must be using a compromised public untrusted DNS server. That feature-specific reachability, plus the fact that RCE is only stated for PA hardware while VM-Series is DoS-only, keeps this out of CRITICAL even though the target class is high-value.
4 steps from start to impact.
Find PAN-OS targets and likely branches
Shodan, Censys, or internal inventory data to identify Palo Alto firewalls and likely PAN-OS branches. This is commodity work, but it does not prove the vulnerable DNS feature is reachable.- Target runs affected PAN-OS branch
- Attacker has internet visibility or internal network access to the device
- Simple PAN-OS fingerprinting does not reveal whether DNS Proxy is enabled
- Panorama, Cloud NGFW, and Prisma Access are unaffected and inflate false target counts
Reach the DNS parsing path
- DNS Proxy is enabled and attached to an interface, or the firewall uses a compromised public DNS server
- That interface or upstream path is reachable from the attacker position
- Many enterprises do not expose firewall DNS proxy to the public internet
- Internal-only DNS Proxy turns this into a post-initial-access or partner-network issue
- The 'compromised public DNS server' branch is a narrow prerequisite, not a default deployment state
Trigger the overflow with crafted DNS traffic
Scapy or a bespoke exploit to deliver malformed DNS requests or responses that exercise the overflow. Palo Alto rates attack complexity as high, which is consistent with a bug that likely needs protocol-shape precision rather than spray-and-pray traffic.- Attacker can send or relay specially crafted DNS traffic to the vulnerable parser
- Target build is still in an affected version window
- No broadly trusted public PoC or Metasploit module was located
- High attack complexity raises reliability problems across versions and hardware families
- Inline threat signatures can block known exploit patterns for subscribers
Land impact: crash broadly, RCE selectively
- Exploit succeeds against the parser
- For RCE impact specifically, target is PA-Series hardware
- VM-Series is described as DoS-only by the vendor
- The advisory says 'potentially execute arbitrary code,' which implies the RCE path is less established than the crash path
The supporting signals.
| In-the-wild status | No confirmed active exploitation in vendor reporting. Palo Alto states it is not aware of malicious exploitation; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No trusted public PoC or Metasploit module was located in routine searches. Public reporting also describes PoC availability as unverified. |
| EPSS | 0.00095 (user-supplied), which is extremely low. Percentile was not authoritatively verified from accessible FIRST output in this session. |
| KEV status | Not KEV-listed at time of assessment; there is no CISA due date driving emergency federal-style patching. |
| Vendor/CNA scoring signal | Although there is no NVD-enriched score, the CNA record from Palo Alto carries CVSS-BT 7.2 HIGH with vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N/E:U/AU:Y/R:U/V:C/RE:H/U:Red. |
| Affected versions | PAN-OS 12.1 < 12.1.4-h5 or < 12.1.7; 11.2 < 11.2.4-h17 / 11.2.7-h13 / 11.2.10-h6 / 11.2.12; 11.1 < 11.1.4-h33 / 11.1.6-h32 / 11.1.7-h6 / 11.1.10-h25 / 11.1.13-h5 / 11.1.15; 10.2 < 10.2.7-h34 / 10.2.10-h36 / 10.2.13-h21 / 10.2.16-h7 / 10.2.18-h6. |
| Exposure requirements | Applies only when DNS Proxy is enabled and attached to an interface, or when the firewall's configured DNS server is a compromised public untrusted IP. Risk increases if the bound interface is exposed to an untrusted network. |
| Fixed versions | Patch to the branch-specific maintenance release named in the advisory, including 12.1.4-h5 / 12.1.7, 11.2.4-h17 / 11.2.7-h13 / 11.2.10-h6 / 11.2.12, 11.1.4-h33 / 11.1.6-h32 / 11.1.7-h6 / 11.1.10-h25 / 11.1.13-h5 / 11.1.15, and 10.2.7-h34 / 10.2.10-h36 / 10.2.13-h21 / 10.2.16-h7 / 10.2.18-h6. |
| Scanning / exposure reality | There is no clean internet-wide census for this CVE because triggerability depends on configuration, not just appliance presence. A Shodan/Censys hit for PAN-OS is only a candidate target, not proof that the DNS Proxy path is reachable. |
| Disclosure / reporting | Disclosed 2026-05-13. Palo Alto credits Liang Zhu and internal security research teams for discovery and reporting. |
noisgate verdict.
The single biggest severity reducer is feature gating: this is only exploitable when DNS Proxy is actually enabled and attached to a reachable interface, or when the firewall depends on a compromised public DNS server. What keeps it in HIGH is that the target is still a pre-auth network bug on a perimeter firewall, and Palo Alto explicitly states there is a potential RCE outcome on PA-Series hardware.
Why this verdict
- Starts high because it is pre-auth network-reachable against a firewall parser: no credentials, no user interaction, and the vulnerable code sits on a security appliance that often faces hostile networks.
- Downward adjustment for exposure gating: the advisory narrows reachability to deployments with
DNS Proxyenabled and bound to an interface, or to a much narrower case involving a compromised public DNS server. That materially shrinks the attackable population. - Downward adjustment for platform split: the worst-case impact is not uniform. Palo Alto says all affected platforms can be crashed, but only PA-Series hardware has the potential RCE branch.
- Downward adjustment for exploitation signal: no KEV listing, no vendor-confirmed in-the-wild abuse, and the supplied EPSS 0.00095 does not support emergency internet-fire levels.
- Not lower because blast radius is still ugly when it lands: pre-auth code execution or control-plane failure on a firewall can turn one bug into network-wide visibility loss, traffic disruption, or a beachhead at the perimeter.
Why not higher?
This does not earn CRITICAL because the attacker cannot simply point at every PAN-OS box and win. The exploitability is constrained by specific DNS feature exposure, vendor-rated high attack complexity, and an impact split where the RCE branch is limited to PA hardware rather than the full affected estate. There is also no confirmed active exploitation pushing this into 'drop everything' territory.
Why not lower?
This is still a serious perimeter-device parser bug with no authentication required. Even with the gating conditions, many enterprises will have at least some PA-Series firewalls using DNS Proxy in branch, campus, or service-edge roles, and compromise or crash of a firewall is not a low-consequence event.
What to do — in priority order.
- Remove DNS Proxy from untrusted-facing interfaces — If you use DNS Proxy, disassociate it from externally accessible interfaces first. This directly cuts off the most important pre-auth path described by the vendor; for a HIGH verdict, deploy this compensating control within 30 days unless your exposure review shows internet reachability, in which case do it sooner.
- Disable unused DNS Proxy — If the feature is not required, turn it off instead of trying to protect it. Feature removal is the cleanest risk reduction here and should be completed within 30 days for affected vulnerable versions.
- Pin DNS to trusted resolvers only — Review
Device > Setup > Servicesand ensure the configured DNS servers are RFC1918/internal or otherwise trusted public resolvers, not arbitrary public IPs. This addresses the advisory's second exposure path and should be validated within 30 days. - Enable Threat ID 510027 — If you have a Threat Prevention subscription, enable Threat ID 510027 with Applications and Threats content version 9100-10044+. This is a useful shield while patching, but it is still a compensating control, so deploy it within 30 days and do not treat it as final remediation.
- Prioritize PA-Series over VM-Series — Patch sequencing should put PA-Series hardware first because that is where Palo Alto says arbitrary code execution is possible. VM-Series still matters, but the vendor-described impact is lower, so this is the obvious queue split inside the same 180-day remediation window.
- A generic WAF does not help; this is not an HTTP app-layer problem.
- Perimeter MFA is irrelevant because the path is unauthenticated network traffic, not a login flow.
- Assuming 'the firewall is internet-facing, therefore vulnerable' is also wrong; feature configuration, not appliance presence alone, determines exposure.
- Relying only on a version scanner is insufficient; many scanners will mark the version but miss whether DNS Proxy is actually enabled and attached to a reachable interface.
Crowdsourced verification payload.
Run this from an auditor workstation that can SSH to the firewall CLI, not on the firewall itself. Invoke it as python3 check_cve_2026_0264.py [email protected]; it needs an account that can run show system info and view the running config over SSH. It uses the local ssh client and returns VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_cve_2026_0264.py
# Determine likely exposure to CVE-2026-0264 on a PAN-OS firewall over SSH.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 3=UNKNOWN, 4=USAGE/SSH ERROR
import sys
import re
import subprocess
import ipaddress
SSH_TIMEOUT = 20
FIX_RULES = {
'12.1': [('12.1.2', '12.1.4-h4', '12.1.4-h5'), ('12.1.5', '12.1.6', '12.1.7')],
'11.2': [('11.2.0', '11.2.4-h16', '11.2.4-h17'), ('11.2.5', '11.2.7-h12', '11.2.7-h13'), ('11.2.8', '11.2.10-h5', '11.2.10-h6'), ('11.2.11', '11.2.11', '11.2.12')],
'11.1': [('11.1.0', '11.1.4-h32', '11.1.4-h33'), ('11.1.5', '11.1.6-h31', '11.1.6-h32'), ('11.1.7', '11.1.7-h5', '11.1.7-h6'), ('11.1.8', '11.1.10-h24', '11.1.10-h25'), ('11.1.11', '11.1.13-h4', '11.1.13-h5'), ('11.1.14', '11.1.14', '11.1.15')],
'10.2': [('10.2.0', '10.2.7-h33', '10.2.7-h34'), ('10.2.8', '10.2.10-h35', '10.2.10-h36'), ('10.2.11', '10.2.13-h20', '10.2.13-h21'), ('10.2.14', '10.2.16-h6', '10.2.16-h7'), ('10.2.17', '10.2.18-h5', '10.2.18-h6')],
}
PRIVATE_NETS = [
ipaddress.ip_network('10.0.0.0/8'),
ipaddress.ip_network('172.16.0.0/12'),
ipaddress.ip_network('192.168.0.0/16'),
ipaddress.ip_network('127.0.0.0/8'),
ipaddress.ip_network('169.254.0.0/16')
]
def parse_ver(v):
m = re.match(r'^(\d+)\.(\d+)\.(\d+)(?:-h(\d+))?$', v.strip())
if not m:
return None
return tuple(int(x) if x is not None else 0 for x in m.groups())
def cmp_ver(a, b):
pa, pb = parse_ver(a), parse_ver(b)
if pa is None or pb is None:
raise ValueError(f'Cannot compare versions: {a} vs {b}')
return (pa > pb) - (pa < pb)
def in_range(ver, start, end):
return cmp_ver(ver, start) >= 0 and cmp_ver(ver, end) <= 0
def is_affected(ver):
branch = '.'.join(ver.split('.')[:2])
rules = FIX_RULES.get(branch, [])
for start, end, fixed in rules:
if in_range(ver, start, end):
return True, fixed
return False, None
def run_ssh(target, commands):
joined = '\n'.join(commands) + '\n'
proc = subprocess.run(
['ssh', '-o', f'ConnectTimeout={SSH_TIMEOUT}', '-o', 'BatchMode=no', target],
input=joined,
text=True,
capture_output=True
)
if proc.returncode != 0:
print('UNKNOWN: SSH command failed')
if proc.stderr:
print(proc.stderr.strip())
sys.exit(4)
return proc.stdout
def is_private_ip(s):
try:
ip = ipaddress.ip_address(s)
return any(ip in net for net in PRIVATE_NETS)
except Exception:
return False
def main():
if len(sys.argv) != 2:
print('UNKNOWN: usage: python3 check_cve_2026_0264.py [email protected]')
sys.exit(4)
target = sys.argv[1]
sysinfo = run_ssh(target, ['set cli pager off', 'show system info', 'exit'])
version_m = re.search(r'^sw-version:\s*(\S+)', sysinfo, re.M)
model_m = re.search(r'^model:\s*(\S+)', sysinfo, re.M)
if not version_m:
print('UNKNOWN: could not determine PAN-OS version from show system info')
sys.exit(3)
version = version_m.group(1).strip()
model = model_m.group(1).strip() if model_m else 'unknown'
affected, fixed = is_affected(version)
if not affected:
print(f'PATCHED: version {version} is outside the documented vulnerable ranges for CVE-2026-0264')
sys.exit(0)
cfg = run_ssh(target, [
'set cli pager off',
'configure',
'set cli config-output-format set',
'show',
'exit',
'exit'
])
dns_proxy_lines = [line for line in cfg.splitlines() if 'set network dns-proxy ' in line]
iface_attach = [line for line in dns_proxy_lines if ' interface ' in line or re.search(r' ethernet\d+/\d+', line)]
mgmt_dns = re.findall(r'set deviceconfig system dns-setting servers (?:primary|secondary) ([0-9]{1,3}(?:\.[0-9]{1,3}){3})', cfg)
public_dns = [ip for ip in mgmt_dns if not is_private_ip(ip)]
pa_series = model.lower().startswith('pa-') and 'vm' not in model.lower()
impact = 'possible RCE on PA-Series hardware' if pa_series else 'documented DoS impact on non-PA platforms'
if dns_proxy_lines and iface_attach:
print(f'VULNERABLE: version {version} is affected, DNS Proxy is configured with interface attachment, model={model}, impact={impact}, fixed_version={fixed}')
sys.exit(1)
if dns_proxy_lines and not iface_attach:
print(f'UNKNOWN: version {version} is affected and DNS Proxy is configured, but interface attachment was not conclusively parsed; model={model}, fixed_version={fixed}')
sys.exit(3)
if public_dns:
print(f'UNKNOWN: version {version} is affected and management DNS uses public resolver IP(s) {public_dns}; advisory exposure depends on whether that upstream DNS is compromised/untrusted; fixed_version={fixed}')
sys.exit(3)
print(f'UNKNOWN: version {version} is affected but the script did not find clear DNS Proxy attachment or risky public DNS settings in the running config; manual review still required; model={model}, fixed_version={fixed}')
sys.exit(3)
if __name__ == '__main__':
main()
If you remember one thing.
DNS Proxy is enabled and bound to reachable interfaces, remove it from untrusted-facing interfaces or disable it if unused, pin DNS to trusted resolvers, and enable Threat ID 510027 where licensed within the noisgate mitigation SLA of 30 days; then complete the actual branch-specific PAN-OS upgrades within the noisgate remediation SLA of 180 days. If you discover any internet-reachable DNS Proxy exposure on PA-Series, treat that subset as the hot lane and remediate ahead of the generic HIGH clock.Sources
- Palo Alto advisory for CVE-2026-0264
- NVD record for CVE-2026-0264
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Palo Alto KB: Viewing the configuration in set and XML format
- Palo Alto KB: How to Configure DNS Proxy on a Palo Alto Networks Firewall
- PAN-OS CLI docs: View Settings and Statistics
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.