← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-0264 · CWE-122 · Disclosed 2026-05-13

A buffer overflow vulnerability in the DNS proxy and DNS Server features of Palo Alto Networks PAN-OS®…

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Pre-auth on a firewall is ugly, but this one is gated by feature exposure and only reaches RCE on PA hardware."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find PAN-OS targets and likely branches

An attacker starts with asset discovery using standard internet recon such as 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.
Conditions required:
  • Target runs affected PAN-OS branch
  • Attacker has internet visibility or internal network access to the device
Where this breaks in practice:
  • 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
Detection/coverage: External attack-surface tools can find PAN-OS appliances, but they generally cannot confirm the advisory's required DNS feature conditions.
STEP 02

Reach the DNS parsing path

The exploit chain only becomes real if the attacker can hit the DNS Proxy service on an attached interface or influence the firewall via a compromised upstream public DNS server. In the common case, that means the attacker needs UDP/TCP 53 reachability to the firewall interface bound to DNS Proxy, or control of a DNS server the firewall trusts enough to query.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Config audit is the best coverage here. Network scanners can identify open DNS on an interface, but they cannot reliably determine whether the upstream-DNS prerequisite exists.
STEP 03

Trigger the overflow with crafted DNS traffic

A weaponized harness would use a custom packet generator such as 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.
Conditions required:
  • Attacker can send or relay specially crafted DNS traffic to the vulnerable parser
  • Target build is still in an affected version window
Where this breaks in practice:
  • 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
Detection/coverage: Palo Alto says Threat Prevention can block known attack patterns with Threat ID 510027 in Applications and Threats content version 9100-10044+.
STEP 04

Land impact: crash broadly, RCE selectively

If exploitation succeeds, the baseline impact across affected PAN-OS platforms is denial of service. The more serious branch is potential arbitrary code execution on PA-Series hardware only, which is the main reason this stays high priority despite the gating conditions.
Conditions required:
  • Exploit succeeds against the parser
  • For RCE impact specifically, target is PA-Series hardware
Where this breaks in practice:
  • 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
Detection/coverage: Expect crash/restart symptoms, dataplane instability, or threat log hits if signatures fire. Pure pre-exploit detection is stronger in config review than in generic vulnerability scanning.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation in vendor reporting. Palo Alto states it is not aware of malicious exploitation; not listed in CISA KEV.
Proof-of-concept availabilityNo trusted public PoC or Metasploit module was located in routine searches. Public reporting also describes PoC availability as unverified.
EPSS0.00095 (user-supplied), which is extremely low. Percentile was not authoritatively verified from accessible FIRST output in this session.
KEV statusNot KEV-listed at time of assessment; there is no CISA due date driving emergency federal-style patching.
Vendor/CNA scoring signalAlthough 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 versionsPAN-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 requirementsApplies 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 versionsPatch 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 realityThere 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 / reportingDisclosed 2026-05-13. Palo Alto credits Liang Zhu and internal security research teams for discovery and reporting.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.8/10)

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.

HIGH Affected/fixed version ranges and exposure prerequisites from the vendor advisory
MEDIUM Real-world severity bucket after friction audit
LOW Internet-wide exposed population estimate for the DNS Proxy-enabled subset

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 Proxy enabled 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. Pin DNS to trusted resolvers only — Review Device > Setup > Services and 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.
  4. 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.
  5. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: identify every PAN-OS 10.2/11.1/11.2/12.1 firewall, then split the queue into PA-Series first and everything else second. For affected firewalls, validate whether 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

  1. Palo Alto advisory for CVE-2026-0264
  2. NVD record for CVE-2026-0264
  3. CISA Known Exploited Vulnerabilities catalog
  4. FIRST EPSS overview
  5. FIRST EPSS API documentation
  6. Palo Alto KB: Viewing the configuration in set and XML format
  7. Palo Alto KB: How to Configure DNS Proxy on a Palo Alto Networks Firewall
  8. PAN-OS CLI docs: View Settings and Statistics
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.