CVE-2026-92182: Netgate pfSense CE XMLRPC Unauthenticated RCE — Detection and Remediation Guide

The Zero Day Initiative has published ZDI-26-960, disclosing an incorrect authorization vulnerability in the XMLRPC component of Netgate pfSense CE that allows remote attackers to execute arbitrary code without authentication. The flaw is tracked as CVE-2026-92182 and carries a CVSS score of 8.8.

Let me be blunt about why this one matters: pfSense sits at the network edge. It is the perimeter. A pre-authentication remote code execution flaw in the management plane of a firewall is a worst-case scenario — successful exploitation yields code execution on the device that terminates your VPNs, enforces your segmentation, and in many SMB and branch deployments is the entire security boundary. There is no "behind the firewall" for the firewall itself.

If you run pfSense CE — particularly with the webConfigurator or High Availability (CARP/XMLRPC) sync reachable from anything other than a locked-down management network — treat this as an emergency change window, not a routine patch cycle.

Technical Analysis

Affected Component

The vulnerability resides in the XMLRPC handler in pfSense CE — the PHP-based endpoint (/xmlrpc.php) primarily used by pfSense's High Availability configuration sync to replicate configuration, firewall rules, and state information between CARP cluster members. Because this handler processes serialized RPC requests over the web stack (nginx/PHP on modern pfSense builds), an authorization flaw here is reachable over HTTP(S) on the same listener as the webConfigurator.

Root Cause (Defender's View)

Per the ZDI classification, this is an incorrect authorization flaw. Practically, that means a code path in the XMLRPC request handler fails to properly verify that the caller is authenticated and authorized before reaching functionality that can be abused to execute code on the underlying FreeBSD operating system. Key characteristics from a defensive standpoint:

• Authentication required to exploit: No. The flaw is reachable pre-authentication, which is precisely what makes an 8.8 CVSS score on an edge device so dangerous.
• Attack vector: Network — crafted requests to the XMLRPC endpoint over the web management listener (default TCP 443, but commonly customized).
• Impact: Arbitrary code execution in the context of the web service — on pfSense, PHP runs with extremely elevated privilege (effectively root), so post-exploitation gives an attacker full control of the appliance: rule manipulation, traffic interception, credential harvesting from RADIUS/LDAP/IPsec configs, and a beachhead inside your network.

Exploitation Requirements

The attacker needs network reachability to the pfSense web/XMLRPC listener. In properly hardened environments that interface is bound to a management VLAN or localhost-tunneled only — but in our IR casework we routinely find pfSense webUIs exposed to WAN interfaces, exposed via NAT port-forwards, or reachable from broad internal segments. Assume yours is reachable until you verify otherwise.

Exploitation Status

At time of publication, ZDI has released the advisory per its coordinated disclosure timeline (typically ~120 days after vendor notification), which implies a patch window has elapsed or is imminent. Public proof-of-concept code and confirmed in-the-wild exploitation have not been confirmed in the advisory summary, and the CVE does not yet appear on the CISA Known Exploited Vulnerabilities catalog. Do not let that lull you. Edge-device RCEs are historically weaponized within days of public advisory — monitor the ZDI advisory page and CISA KEV continuously.

Detection & Response

The highest-fidelity signals for this vulnerability are: (1) HTTP requests to /xmlrpc.php from any source other than your known HA peer, and (2) the pfSense web stack (nginx/PHP) spawning child processes — which should essentially never happen on a healthy appliance. Forward pfSense logs (nginx access logs, system logs) to your SIEM via syslog now if you aren't already.

---
title: HTTP Request to pfSense XMLRPC Endpoint
description: Detects inbound HTTP POST requests to the pfSense XMLRPC handler (/xmlrpc.php). On pfSense CE this endpoint is used for HA/CARP configuration sync and should only ever be contacted by the designated HA peer. Requests from any other source may indicate exploitation of CVE-2026-92182.
id: 3b9f2c14-7a1e-4d58-9c42-8f6a2e1d5b77
status: experimental
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-960/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/06/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection:
    cs-uri|contains: '/xmlrpc.php'
    cs-method: 'POST'
falsepositives:
  - Legitimate CARP/HA configuration synchronization between pfSense cluster peers — tune by allowing only the known HA peer IP via a filter or threshold alert on source IP
level: high
---
title: pfSense Web Stack Spawning Shell or Interpreter
description: Detects the pfSense web server (nginx, lighttpd) or PHP-FPM spawning a shell, script interpreter, or system utility. The pfSense web stack does not spawn interactive shells under normal operation; this is a strong post-exploitation indicator for web-facing RCE such as CVE-2026-92182.
id: 8e1d4a92-3c6b-4f05-b218-6d9c7e3a1f44
status: experimental
references:
  - http://www.zerodayinitiative.com/advisories/ZDI-26-960/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/06/15
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: bsd
detection:
  selection_parent:
    ParentImage|endswith:
      - '/nginx'
      - '/php-fpm'
      - '/lighttpd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/csh'
      - '/tcsh'
      - '/perl'
      - '/python'
      - '/nc'
      - '/ncat'
      - '/curl'
      - '/fetch'
  condition: selection_parent and selection_child
falsepositives:
  - Rare — some pfSense packages (e.g., monitoring or backup plugins) may legitimately invoke utilities; baseline per environment and alert on first-seen parent/child pairs
level: critical

// Hunt 1: pfSense XMLRPC requests from unexpected sources (via syslog/CEF ingestion)
// Tune the allowed peer IP(s) for your HA pair; standalone appliances should have ZERO hits.
let HAPeers = dynamic(["10.0.99.2"]); // replace with your CARP peer address(es)
Syslog
| where TimeGenerated > ago(30d)
| where SyslogMessage contains "/xmlrpc.php"
| extend SrcIP = extract(@'(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})', 1, SyslogMessage)
| where SrcIP !in (HAPeers)
| summarize RequestCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SrcIP, Computer
| order by RequestCount desc;

// Hunt 2: Web server process anomalies forwarded from pfSense (auth/system log review)
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DeviceProduct has "pfSense" or SourceHostName has "pfsense"
| where Message has_any ("xmlrpc.php", "nginx", "php-fpm")
| where Message has_any (" sh ", "bash", "perl", "python", "fetch", "curl", "wget")
| project TimeGenerated, SourceHostName, SourceIP, DestinationPort, Message
| order by TimeGenerated desc;

// Hunt for evidence of XMLRPC probing/exploitation in pfSense nginx access logs
// Deployment note: run against a log collector holding forwarded pfSense access logs,
// or adapt the glob path to the log location on your syslog aggregation host.
LET logs = SELECT FullPath
FROM glob(globs='/var/log/remote/pfsense*/nginx-access.log*')

SELECT FullPath,
       Line,
       count() AS Hits
FROM foreach(row=logs,
query={
  SELECT FullPath, Line
  FROM parse_file(filename=FullPath, accessor='auto')
  WHERE Line =~ '/xmlrpc\.php'
})
GROUP BY FullPath, Line

#!/bin/sh
# CVE-2026-92182 pfSense CE triage & hardening script
# Run from pfSense shell (Diagnostics > Command Prompt, or SSH option 8)

echo "=== [1] pfSense version ==="
cat /etc/version
grep -E '"product_version"|built' /etc/inc/globals.inc 2>/dev/null | head -5

echo "=== [2] XMLRPC / HA sync configuration review ==="
grep -i -A3 -B1 'synchronizetoip\|xmlrpc' /conf/config.xml | head -40

echo "=== [3] Web listener bindings — confirm webConfigurator is NOT on WAN ==="
sockstat -4l | grep -E 'nginx|lighttpd|:443|:80'

echo "=== [4] Historical access to /xmlrpc.php (who has touched the endpoint) ==="
zcat /var/log/nginx-access.log*.gz 2>/dev/null | grep 'xmlrpc.php' | awk '{print $1}' | sort | uniq -c | sort -rn
cat /var/log/nginx-access.log 2>/dev/null | grep 'xmlrpc.php' | awk '{print $1}' | sort | uniq -c | sort -rn

echo "=== [5] Suspicious child processes of the web stack (live check) ==="
ps auxww | grep -E '(nginx|php-fpm|lighttpd)' | grep -v grep
ps auxww | grep -E ' (sh|bash|perl|python|nc |fetch|curl) ' | grep -v grep

echo "=== [6] Unexpected outbound connections from the firewall ==="
netstat -an | grep ESTABLISHED | grep -v -E '127\.0\.0\.1|:53 |:123 '

echo "=== [7] Harden: restrict management + XMLRPC to the HA peer only ==="
echo "Add pf rules (System > Advanced > Firewall & NAT or /tmp/rules.debug) limiting"
echo "TCP 443 on sync/mgmt interfaces to the CARP peer IP, e.g.:"
echo "  pass in quick on <SYNC_IF> proto tcp from <HA_PEER_IP> to any port 443 keep state"
echo "  block in quick on <SYNC_IF> proto tcp from any to any port 443"

echo "=== [8] If HA sync is unused, disable it: System > High Availability Sync ==="
echo "Remove 'Synchronize States'/'Synchronize Config to IP' entries and save."

Remediation

1. Patch immediately. Apply the fixed pfSense CE release from Netgate as soon as it is published. Track the fix through the ZDI advisory (http://www.zerodayinitiative.com/advisories/ZDI-26-960/) and Netgate's security advisories/release notes. Verify your installed version via cat /etc/version against the patched build.
2. Eliminate exposure of the XMLRPC endpoint. The only host that should ever reach /xmlrpc.php is your designated HA peer. Enforce this with firewall rules on the sync/management interface (see script step 7). On standalone appliances with no HA pair, disable XMLRPC/HA sync entirely under System > High Availability Sync.
3. Remove the webConfigurator from the WAN. Audit interface bindings (sockstat -4l). Management should live on a dedicated management VLAN with ACLs, or behind an administrative VPN. If you discover WAN exposure, treat the device as potentially compromised — do not just patch and move on.
4. Rotate credentials and review configuration integrity. Because exploitation is pre-auth with code execution, any device with a reachable endpoint should have admin credentials, API keys, IPsec pre-shared keys, and LDAP/RADIUS bind passwords rotated, and the running config diffed against a known-good backup.
5. Enable and centralize logging. Forward nginx access logs and system logs to your SIEM via syslog with TLS. Without historical /xmlrpc.php request data, you cannot scope whether you were probed or breached before patching.
6. Hunt retroactively. Run the KQL queries above across at least 30–90 days of retained logs. Any non-peer source touching the XMLRPC endpoint warrants a forensic review of the appliance (unexpected users in /etc/passwd via config, cron entries, modified PHP files under /usr/local/www/).
7. Monitor KEV. If CISA adds CVE-2026-92182 to the Known Exploited Vulnerabilities catalog, federal remediation deadlines will apply — and more importantly, it confirms active exploitation, elevating this from urgent patch to incident response for any unpatched exposure window.

The defensive lesson here extends beyond this CVE: firewall management planes are crown-jewel attack surfaces. Pre-auth flaws in edge management interfaces are the single most reliable initial-access vector we see in edge-device IR engagements. Minimum exposure, strict source allowlisting, and centralized logging would each independently blunt this vulnerability — defense in depth isn't a platitude when the target is the perimeter itself.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub