pfSense CE EUVD-2026-102345

Exploitation requires the non-default 'Require Firewall Interface' option to be enabled on pfSense CE 2.7.1 through 2.9.0; without it the vulnerable code path in firewall_rules.php is not reachable. The attacker must also lure a user who already holds firewall-rules privileges into opening a crafted GET link (the unencoded 'if' parameter carries the payload), so success depends on social engineering of an authenticated privileged operator. Limiting factors: non-default configuration, required user interaction, a privileged (not anonymous) victim, and execution confined to that victim's WebGUI session privileges - there is no path to code execution against default installations.

This is a low-priority issue despite the existence of public exploit code. The vendor CVSS 4.0 base score is only 2.3 (Low), and the vector tells a consistent story: AV:N (reachable over the network) but AC:H and AT:P mean exploitation depends on a non-default configuration ('Require Firewall Interface' enabled), and UI:P means the attack cannot succeed without a privileged user being tricked into clicking a crafted link. Although PR:N indicates the attacker themselves needs no credentials, the payload only executes with the privileges of the lured victim, who must already hold firewall-rules privileges - so this is not a path to unauthenticated takeover. POC/exploit code is publicly available (GitHub + VulnCheck advisory), which raises reproducibility, but POC availability is NOT active exploitation: there is no CISA KEV listing and no EPSS score was provided in the input, so widespread opportunistic exploitation cannot be inferred. Impact is bounded (VC:L/VI:L, no availability impact). Net: a real, confirmed reflected XSS worth patching in routine cycles, but the stacked prerequisites (non-default option, privileged victim, user interaction) make it far lower real-world risk than its CWE class alone might suggest.

On a pfSense CE instance (2.7.1-2.9.0) with the non-default 'Require Firewall Interface' option enabled, an attacker crafts a GET URL to firewall_rules.php containing a malicious script in the unencoded 'if' parameter and sends it to an administrator with firewall-rules privileges. When that user opens the link while authenticated to the WebGUI, the reflected script runs in their session and can act with their privileges. Public exploit code for this specific parameter exists (VulnCheck advisory and a GitHub PoC repo), lowering the effort to reproduce it.