CVE-2026-56127 in pfSense Plus
Summary
by MITRE • 09/03/2026
pfSense Plus before 26.07 and CE before 2.9.0 allow authenticated users with the Firewall: Rules: Edit privilege to inject arbitrary JavaScript via the descr parameter in /firewall_rules_edit.php. The firewall rule description is stored in the pfSense XML configuration with only backslash-escaping applied and no HTML sanitization, then rendered without encoding in the firewall log table in /status_logs_filter.php. The payload executes in the browser of any user with the Status: Logs: Firewall privilege who views the affected log entries.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified involves a stored cross-site scripting flaw within pfSense Plus versions prior to 26.07 and pfSense CE versions prior to 2.9.0, specifically affecting the firewall rule management interface. This security issue arises from an insufficient sanitization of user-supplied input when creating or editing firewall rules. An authenticated attacker possessing the Firewall: Rules: Edit privilege can manipulate the descr parameter in the /firewall_rules_edit.php endpoint by injecting arbitrary JavaScript code into the description field of a firewall rule. The system processes this input by applying only backslash-escaping, which is insufficient to prevent script injection when the data is later rendered in an HTML context without proper encoding or sanitization mechanisms such as those defined under CWE-79 for Improper Neutralization of Input During Web Page Generation.
The operational impact of this vulnerability extends beyond the initial point of entry due to how pfSense handles and displays log entries. The maliciously crafted description containing the JavaScript payload is stored in the pfSense XML configuration file with only basic escaping applied, leaving it vulnerable to interpretation as executable code during rendering. When any user with the Status: Logs: Firewall privilege accesses /status_logs_filter.php to view firewall logs, the system renders the affected log entries directly into the browser without encoding the special characters. Consequently, the injected script executes in the context of the victim's browser session every time they view these specific log entries. This behavior aligns with CWE-83 for Improper Neutralization of Script-Related HTML Tags in a Web Page and represents a classic stored XSS attack vector where persistence is achieved through database or configuration storage rather than transient request parameters.
From an adversary perspective, this vulnerability facilitates unauthorized access to sensitive information and potential control over the management interface if session cookies are accessible via script execution. The attacker can steal administrative credentials, perform actions on behalf of authenticated users, or deface the user interface by leveraging ATT&CK technique T1059 for Command and Scripting Interpreter within a web application context. Since the payload is stored server-side, it does not require social engineering to trigger beyond convincing an administrator with log-viewing privileges to load the affected page, making it particularly dangerous in environments where multiple users have access to monitoring dashboards. The lack of output encoding means that even if input validation exists for other fields, this specific path remains exploitable due to the direct reflection of unsanitized data into HTML content.
Mitigation strategies should prioritize immediate patching by upgrading pfSense Plus to version 26.07 or later and pfSense CE to version 2.9.0 or later, as these releases address the input validation and output encoding deficiencies. In scenarios where updating is not immediately feasible, administrators can implement compensating controls such as restricting access to /status_logs_filter.php exclusively to users with high-level privileges who are trusted and monitored closely. Additionally, deploying a Web Application Firewall capable of detecting and blocking XSS payloads in HTTP responses may provide temporary protection by filtering out malicious scripts before they reach the client browser. Long-term remediation requires enforcing strict output encoding practices for all dynamic content rendered from configuration data, ensuring that special characters like angle brackets and quotes are properly escaped according to HTML entity standards, thereby neutralizing any attempt at script injection regardless of input sanitization methods used during creation.