pfSense CE EUVD-2026-102342

Requires an authenticated pfSense CE account that has been granted the Dynamic DNS client privilege and access to services_dyndns_edit.php; the attacker must configure a custom DynDNS provider whose Update URL uses the file:// scheme (e.g. file:///conf/config.xml or file:///etc/master.passwd) and must supply a Result Match string that does NOT match the file contents, so that _checkStatus() logs the fetched data as root to the system log. Limiting factors: this privilege is not held by anonymous or default low-level users (PR:H), no victim interaction is needed (UI:N), and impact is confined to disclosure of files readable by root - there is no write/integrity or availability effect. It affects default-feature behavior of the DynDNS client, so no exotic non-default configuration beyond granting the privilege is required.

This is a credible but privilege-gated information-disclosure flaw, not a critical mass-exploitation threat. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H/UI:N, VC:H only) and the 6.9 (Medium) score are internally consistent with the description: exploitation is network-reachable and low-complexity, but requires a user already holding the Dynamic DNS client privilege (PR:H), which is a non-default, administratively granted permission. Public exploit code exists (abraxas/pfsense-dyndns-file), reported by VulnCheck, which raises practical risk, but the vulnerability is NOT in CISA KEV and no active exploitation is indicated - so this should be treated as 'publicly available exploit code exists,' distinct from in-the-wild use. No EPSS score was provided in the input, so exploitation probability cannot be quantified here. The dominant factor limiting real-world risk is the PR:H prerequisite: an attacker must already be a semi-trusted authenticated operator, making this primarily a privilege-escalation-of-data / insider or post-initial-access concern (reading /conf/config.xml and /etc/master.passwd as root) rather than a perimeter breach. No SSVC decision data was supplied. Overall: real and worth patching given public POC and the sensitivity of the files exposed, but the authentication barrier keeps it out of emergency-priority territory.

An authenticated pfSense operator (or an attacker who has compromised a limited account holding the Dynamic DNS client privilege) edits a DynDNS entry, selects a custom provider, and points the Update URL at file:///conf/config.xml with a deliberately non-matching Result Match string. When the client runs, _checkStatus() writes the fetched file contents to the system log as root, exposing the full configuration (including password hashes) or /etc/master.passwd. A public proof-of-concept for this technique is available on GitHub.