pfSense-SA-26_03: stored XSS in the ARP table through a DHCP-supplied hostname

A DHCP lease in the ARP table

We walked through webConfigurator pages showing data learned from the network. On the ARP table, diag_arp.php printed dnsresolve without htmlspecialchars(), while the neighbouring NDP page escaped the same kind of value. We traced dnsresolve backwards: the hostname received in DHCP option 12 was stored in the ISC lease, read by system_get_dhcpleases() and matched to the MAC address by prepare_ARP_table(). Each link explained how a LAN client could write into an administrative page.

We tested the chain on pfSense CE 2.7.2 with ISC DHCP: a Linux client requested a lease carrying an HTML hostname, and the administrator’s browser executed the marker on opening Diagnostics > ARP Table. Our report of 26 March 2026 kept that scope precise; we had not tested Kea. We reported the flaw to Netgate, which integrated the fix on 27 March and published pfSense-SA-26_03.webgui on 1 April. The vendor advisory later clarified that Kea was unaffected and listed the fixed releases and System Patches.

Following option 12 into diag_arp.php

When the DHCP backend is ISC DHCP, a client announces a hostname in its DHCP request (option 12). The ISC DHCP daemon stores that hostname in its lease database as sent. diag_arp.php reads hostnames from the lease database to label the ARP entries, and it printed them into the HTML without encoding. A hostname is normally a short string of letters and digits, but nothing on this path forced it to be: a client could send a hostname made of HTML.

Root cause

The vulnerability is a stored cross-site scripting flaw (CWE-79). The DHCP-supplied hostname is persisted in the lease database by the ISC DHCP daemon, then rendered into diag_arp.php without HTML encoding, so markup in the hostname becomes part of the page rather than text:

DHCP client (network) → hostname option carrying HTML/JS
ISC DHCP daemon        → stores the hostname verbatim in the lease database
diag_arp.php           → prints the hostname into the ARP table, unencoded
admin browser          → parses the injected markup and runs the script

Netgate’s advisory is precise about the boundary between the two DHCP backends. The Kea DHCP backend is not affected, because it cleans the hostname of invalid characters before storing it, which renders the value inert. ISC DHCP stored it as received, so the missing output encoding in diag_arp.php became exploitable only on that backend.

Exploitation

An attacker needs only to be a DHCP client on a network served by a pfSense interface running ISC DHCP, with no account on the firewall. They request a lease with a crafted hostname:

# DHCP option 12 (host name) carrying markup instead of a name
<img src=x onerror=alert(document.cookie)>

The daemon records the hostname in its lease database. The payload runs the next time an administrator opens Diagnostics, ARP Table, which reads and prints that hostname. No interaction beyond viewing the page is required, which is why the vector carries UI:R (the admin loads the page) rather than no interaction at all.

The same class of DHCP-sourced display applies to other lease and mapping views, which is worth bearing in mind when hardening a build: any page that prints a client identifier, a DUID or a hostname learned from the network is on the same footing and must encode what it shows.

Impact

Netgate’s advisory does not publish a CVSS vector. Our assessment is AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (5.2): the attacker must reach an interface serving ISC DHCP on the local network. That is an adjacent-network precondition, not arbitrary access to the web interface. The administrator must then open the ARP page (UI:R).

The consequence is the usual stored XSS in an admin console, and on a firewall the console is a sensitive one. Script running in an administrator’s session can read what that session can read, act with its privileges and, on an appliance whose web interface configures the device, use that position as a step toward fuller control. The advisory notes the session cookie and other session information may be exposed.

The fix

Netgate corrected the master branches on 27 March 2026. Its 26.03.1 release notes also list this fix; later Plus 26.07 and CE 2.9.0 include it. For the affected supported releases (Plus 26.03 and 25.11.1, CE 2.8.1), the signed advisory lists a recommended System Patch. The correction encodes the hostname before display.

Detection and mitigation

1. Upgrade to pfSense CE 2.9.0 or Plus 26.03.1 or later, or apply the recommended System Patch on a supported affected release.
2. As the advisory suggests, switching the DHCP service to the Kea backend removes the exposure, because Kea sanitises hostnames before storing them. Kea is the default on current builds.
3. Follow the standard console hygiene the advisory recommends: do not administer the firewall from the same browser used for general web browsing, which limits what a stray script in the console can reach.
4. For detection, review DHCP lease hostnames for values containing HTML characters (<, >, ", =), which have no place in a legitimate hostname and indicate an attempt to plant a payload.

Timeline

Date	Event
2026-03	Reported privately to Netgate (security@netgate.com)
2026-03-27	Fix committed to the pfSense master branches
2026-04-01	Advisory pfSense-SA-26_03.webgui published, crediting our researcher
2026-05-27	pfSense Plus 26.03.1 released with this fix
2026-08	Fix included in pfSense CE 2.9.0 and Plus 26.07