CVE-2023-42325

What it actually does

CVE-2023-42325 is a reflected cross-site scripting vulnerability in Netgate pfSense 2.7.0 affecting the status_logs_filter_dynamic.php page. A user with access to the pfSense web interface can craft a URL containing script content that is rendered by another user’s browser without sufficient output encoding or input sanitization. If a privileged pfSense administrator opens the malicious URL while authenticated, the attacker-controlled JavaScript executes in the context of the pfSense management interface. This can allow theft of session-related data accessible to the browser, execution of unauthorized actions as the victim, manipulation of firewall configuration through the web UI, or privilege escalation depending on the victim’s permissions and session protections.

Why it matters to the business

Successful exploitation can let an attacker abuse a trusted administrator’s browser session to change firewall settings, create or modify users, weaken access controls, alter VPN or NAT rules, or disrupt network security controls. Because pfSense often sits at a network perimeter or critical segmentation point, even a moderate-severity web flaw can have outsized operational impact if an administrator is targeted. The vulnerability is not listed in CISA KEV and is not known from the provided data to be used in ransomware campaigns, but public exploit availability and a high EPSS score indicate elevated likelihood of opportunistic probing and exploitation attempts, especially against internet-accessible management interfaces.

How an attack unfolds

An attacker first obtains low-privileged access to the pfSense web interface or otherwise reaches a workflow where a crafted authenticated URL can be delivered to a pfSense user. The attacker constructs a malicious URL targeting status_logs_filter_dynamic.php with embedded JavaScript in a vulnerable parameter. The attacker then convinces a more privileged user, commonly a firewall administrator, to open the link through phishing, chat, ticketing systems, documentation, or another trusted communication channel. When the victim opens the URL while logged in, the pfSense interface reflects the attacker-supplied content and the browser executes it under the pfSense web application origin. The script can then issue same-origin requests, read page content available to the victim, attempt to capture tokens or sensitive UI data, and perform administrative actions permitted by the victim’s role. The attack is constrained by user interaction and browser/session protections, but it can still result in unauthorized configuration changes or account privilege abuse.

How to fix it

Upgrade pfSense to a version that includes the vendor fix for this issue. The provided advisory data does not include an exact fixed version, so security teams should consult Netgate pfSense release notes and apply the latest supported pfSense CE or pfSense Plus update available for the deployed branch. If immediate upgrade is not possible, restrict access to the pfSense web management interface to trusted administrative networks only, require VPN or bastion access for administration, disable internet exposure of the GUI, enforce MFA where supported, reduce privileges for non-administrative users, and remind administrators not to open unsolicited pfSense management URLs. As compensating controls, use reverse-proxy/WAF filtering where applicable to block obvious script injection payloads to status_logs_filter_dynamic.php, though this should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm the deployed pfSense version is no longer 2.7.0 and matches a vendor-supported release containing the fix. Verify the management interface is not exposed to untrusted networks by scanning externally and internally for reachable pfSense GUI services. Review access-control rules to ensure only approved administrative source ranges can reach the web interface. In a controlled test environment only, attempt to submit benign encoded HTML or script-like input to status_logs_filter_dynamic.php and confirm it is safely encoded rather than executed. Validate that browser-side protections such as secure cookies, SameSite attributes, MFA, and least-privilege administrative roles are in place where available. Review change logs and configuration history for unexpected user, firewall, NAT, VPN, DNS, or package modifications around suspected exposure windows.

Typical attack path

1. Identify a pfSense 2.7.0 management interface or a user with access to one.
2. Obtain low-privileged authenticated access or prepare a social-engineering path to deliver a crafted pfSense URL.
3. Create a malicious URL targeting /status_logs_filter_dynamic.php with encoded JavaScript payload content.
4. Send the crafted link to a privileged pfSense user and induce them to open it while authenticated.
5. Execute JavaScript in the victim’s browser under the pfSense web interface origin.
6. Use the victim’s privileges to read sensitive interface data or submit unauthorized configuration-changing requests.
7. Persist or expand access by modifying users, firewall rules, VPN settings, NAT rules, or other administrative configuration if permissions allow.

How to detect it

To determine whether exploitation has already occurred, review pfSense webConfigurator access logs, system logs, authentication logs, reverse-proxy logs, VPN/bastion logs, and any upstream web gateway logs for suspicious requests to status_logs_filter_dynamic.php. Focus on requests containing URL-encoded script tags, JavaScript protocol handlers, HTML event handlers, or browser-executed payload patterns. Correlate suspicious requests with administrator login sessions and subsequent configuration changes, especially changes made shortly after a request from an unusual source IP or user agent. Look for unexpected edits to firewall rules, NAT rules, VPN configuration, users, groups, certificates, DNS resolver settings, package installation, or backup/export activity. Because reflected XSS may not leave a server-side malware artifact, detection often depends on HTTP request logging, browser/proxy telemetry, and post-exploitation configuration auditing. If logs show a crafted request was opened by a privileged user, treat the session as potentially compromised and review all administrative actions from that session.

• /status_logs_filter_dynamic.php
• status_logs_filter_dynamic.php?
• %3Cscript
• <script
• %3C%2Fscript%3E
• </script>
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onclick=
• document.cookie
• XMLHttpRequest
• fetch(
• eval(
• atob(
• btoa(
• String.fromCharCode
• new Image()
• %3Cimg
• %3Csvg
• %3Ciframe

What your security team should do

• Prioritize upgrading pfSense 2.7.0 systems to the latest supported vendor release because public exploit code is available and EPSS indicates elevated exploitation likelihood.
• Immediately remove direct internet access to the pfSense web management interface; restrict it to trusted administrative networks, VPN, or a bastion host.
• Audit pfSense administrative users and remove unnecessary low-privileged accounts that could be used to stage or deliver authenticated attacks.
• Search web access logs, reverse-proxy logs, and firewall management logs for requests to /status_logs_filter_dynamic.php containing encoded script, HTML event handlers, or suspicious JavaScript keywords.
• Review pfSense configuration history for unexpected changes to users, groups, firewall rules, NAT, VPN, DNS resolver/forwarder, certificates, or installed packages.
• Educate administrators to avoid opening unsolicited pfSense management links, especially links received through email, chat, tickets, or documentation comments.
• If exploitation is suspected, invalidate active sessions, rotate administrator passwords, review MFA settings, and preserve logs before making major changes.