CVE-2026-111230 in pfSense CE
Summary
by MITRE • 10/15/2026
Netgate pfSense CE through 2.9.0 contains a local file read vulnerability that allows users with the Dynamic DNS client privilege to read files as root by setting a file:// custom Update URL in services_dyndns_edit.php. Attackers can set a non-matching Result Match string so _checkStatus() logs file contents such as /conf/config.xml or /etc/master.passwd to the system log.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Netgate pfSense Community Edition versions through 2.9.0 represents a critical local file read flaw rooted in improper input validation within the Dynamic DNS client configuration interface. This security weakness specifically targets users who possess the privilege to manage or edit Dynamic DNS settings, which is often granted to administrative accounts for network maintenance purposes. The core technical failure occurs when an attacker interacts with the services_dyndns_edit.php script by manipulating the Update URL parameter. By injecting a file:// URI scheme into this field, the application fails to sanitize or restrict access to local filesystem resources, thereby allowing the underlying system processes to interpret and process these paths as valid update endpoints rather than rejecting them as malformed inputs.
The exploitation mechanism relies on a specific interaction between the configured Update URL and the Result Match string parameter. When an attacker sets a file:// path pointing to sensitive configuration files such as /conf/config.xml or /etc/master.passwd, they must also configure a non-matching Result Match string. This seemingly counterintuitive step is crucial because it forces the _checkStatus() function to fail its standard validation checks against the expected response from an external DNS provider. Instead of discarding the request due to this mismatch, the system proceeds to log the raw output or status information associated with the attempted connection attempt. Because the application runs these operations with elevated privileges, often effectively as root, it successfully reads the contents of the specified local files and writes them into the system logs for diagnostic purposes.
The operational impact of this vulnerability is severe due to the sensitivity of the data exposed through the logging mechanism. The /conf/config.xml file contains the entire configuration state of the pfSense firewall, including network interface definitions, NAT rules, VPN credentials, and potentially stored passwords or API keys in plaintext or weakly encrypted formats. Similarly, access to /etc/master.passwd provides direct insight into user account hashes and password policies on the underlying FreeBSD operating system. By exfiltrating these files through the log viewer accessible via the web GUI, an attacker can achieve significant information disclosure without needing remote code execution capabilities or elevated privileges beyond basic Dynamic DNS management rights. This effectively bypasses authentication controls for sensitive configuration data by leveraging legitimate administrative logging features.
From a classification perspective, this vulnerability aligns with CWE-200: Information Exposure and CWE-94: Improper Control of Generation of Code (Code Injection) in the context of log injection or misuse of system functions to read arbitrary files. It also maps to MITRE ATT&CK techniques related to Credential Access via Unsecured Credentials, as it facilitates the harvesting of sensitive authentication material stored within configuration files and password databases. The attack vector is classified as local because it requires initial access to the pfSense web interface with specific privileges, but its impact extends beyond simple privilege escalation into comprehensive system compromise through data theft.
Mitigation strategies for this vulnerability involve immediate patching to a version of pfSense CE that includes fixes for this input validation flaw in services_dyndns_edit.php and _checkStatus(). Administrators should ensure that the Dynamic DNS client configuration interface strictly validates URL schemes, rejecting any attempts to use file:// or other non-HTTP/HTTPS protocols. Additionally, implementing strict access controls on who can modify Dynamic DNS settings is essential; these privileges should be restricted only to users with a verified need for such functionality rather than being broadly available to all administrative accounts. Regular auditing of system logs and configuration files can also help detect any potential exploitation attempts or unauthorized changes resulting from this vulnerability before they lead to full system compromise.