pfSense-SA-26_03 : XSS stocké dans la table ARP via un nom d’hôte DHCP

Un bail DHCP dans la table ARP

Nous avons parcouru les pages du webConfigurator qui affichent des données apprises du réseau. Dans la table ARP, diag_arp.php imprimait dnsresolve sans htmlspecialchars(), alors que la page NDP voisine échappait le même type de valeur. Nous avons suivi dnsresolve en arrière : le nom d’hôte reçu par DHCP option 12 était enregistré dans le bail ISC, repris par system_get_dhcpleases(), puis associé à l’adresse MAC par prepare_ARP_table(). Chaque maillon expliquait comment un client du LAN pouvait écrire dans une page d’administration.

Nous avons testé la chaîne sur pfSense CE 2.7.2 avec le backend ISC DHCP : un client Linux a demandé un bail portant un nom d’hôte HTML, et le navigateur de l’administrateur a exécuté le marqueur à l’ouverture de Diagnostics > Table ARP. Notre rapport du 26 mars 2026 conservait cette portée précise ; nous n’avions pas testé Kea. Nous avons signalé la faille à Netgate, qui a intégré le correctif le 27 mars et publié pfSense-SA-26_03.webgui le 1er avril. L’avis éditeur a ensuite précisé que Kea n’était pas touché et indiqué les versions et System Patches disponibles.

Suivre l’option 12 jusqu’à diag_arp.php

Lorsque le backend DHCP est ISC DHCP, un client annonce un nom d’hôte dans sa requête DHCP (option 12). Le démon ISC DHCP enregistre ce nom d’hôte dans sa base de baux tel qu’il a été envoyé. diag_arp.php lit les noms d’hôte de la base de baux pour étiqueter les entrées ARP, et il les imprimait dans le HTML sans encodage. Un nom d’hôte est normalement une courte chaîne de lettres et de chiffres, mais rien sur ce chemin ne l’imposait : un client pouvait envoyer un nom d’hôte fait de HTML.

Cause racine

La vulnérabilité est un cross-site scripting stocké (CWE-79). Le nom d’hôte fourni par le DHCP est conservé dans la base de baux par le démon ISC DHCP, puis rendu dans diag_arp.php sans encodage HTML, de sorte que du balisage dans le nom d’hôte devient une partie de la page au lieu d’y être du texte :

client DHCP (réseau) → option nom d’hôte porteuse de HTML/JS
démon ISC DHCP       → stocke le nom d’hôte tel quel dans la base de baux
diag_arp.php         → imprime le nom d’hôte dans la table ARP, sans encodage
navigateur admin     → interprète le balisage injecté et exécute le script

L’avis de Netgate est précis sur la frontière entre les deux backends DHCP. Le backend Kea n’est pas affecté, car il nettoie le nom d’hôte de ses caractères invalides avant de le stocker, ce qui rend la valeur inerte. ISC DHCP le stockait tel quel, de sorte que l’absence d’encodage en sortie dans diag_arp.php n’est devenue exploitable que sur ce backend.

Exploitation

Il suffit à l’attaquant d’être un client DHCP sur un réseau servi par une interface pfSense utilisant ISC DHCP, sans aucun compte sur le pare-feu. Il demande un bail avec un nom d’hôte forgé :

# Option DHCP 12 (nom d’hôte) porteuse de balisage au lieu d’un nom
<img src=x onerror=alert(document.cookie)>

Le démon enregistre le nom d’hôte dans sa base de baux. Le payload s’exécute la fois suivante où un administrateur ouvre Diagnostics, Table ARP, qui lit et imprime ce nom d’hôte. Aucune action au-delà de l’affichage de la page n’est requise, ce qui explique le UI:R du vecteur (l’administrateur charge la page) plutôt qu’une absence totale d’interaction.

La même catégorie d’affichage de données issues du DHCP concerne d’autres vues de baux et de réservations, ce qui mérite d’être gardé en tête lors du durcissement d’une installation : toute page qui imprime un identifiant client, un DUID ou un nom d’hôte appris du réseau est sur le même plan et doit encoder ce qu’elle affiche.

Impact

L’avis Netgate ne publie pas de vecteur CVSS. Notre évaluation est AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (5,2) : l’attaquant doit joindre une interface qui sert ISC DHCP sur le réseau local. Il s’agit d’un prérequis de réseau adjacent, pas d’un accès quelconque à l’interface web. L’administrateur doit ensuite ouvrir la page ARP (UI:R).

La conséquence est le XSS stocké habituel dans une console d’administration, et sur un pare-feu cette console est sensible. Un script qui s’exécute dans la session d’un administrateur peut lire ce que cette session peut lire, agir avec ses privilèges et, sur un équipement dont l’interface web configure l’appareil, se servir de cette position comme d’une marche vers un contrôle plus large. L’avis note que le cookie de session et d’autres informations de session peuvent être exposés.

Correctif

Netgate a corrigé les branches master le 27 mars 2026. Les notes de version 26.03.1 mentionnent aussi ce correctif ; Plus 26.07 et CE 2.9.0 l’incluent ensuite. Pour les versions affectées encore supportées (Plus 26.03 et 25.11.1, CE 2.8.1), l’avis signé indique un correctif recommandé via System Patches. La correction encode le nom d’hôte avant affichage.

Détection et mitigation

1. Passer à pfSense CE 2.9.0 ou Plus 26.03.1 ou ultérieure, ou appliquer le correctif System Patches recommandé sur une version affectée supportée.
2. Comme le suggère l’avis, basculer le service DHCP sur le backend Kea supprime l’exposition, car Kea assainit les noms d’hôte avant de les stocker. Kea est le backend par défaut sur les versions récentes.
3. Suivre l’hygiène de console recommandée par l’avis : ne pas administrer le pare-feu depuis le navigateur utilisé pour la navigation web générale, ce qui limite ce qu’un script égaré dans la console peut atteindre.
4. Pour la détection, passer en revue les noms d’hôte des baux DHCP à la recherche de valeurs contenant des caractères HTML (<, >, ", =), qui n’ont pas leur place dans un nom d’hôte légitime et signalent une tentative de dépôt de payload.

Chronologie

Date	Événement
03/2026	Signalement privé à Netgate (security@netgate.com)
27/03/2026	Correctif intégré aux branches master de pfSense
01/04/2026	Publication de l’avis pfSense-SA-26_03.webgui, qui crédite notre chercheur
27/05/2026	Plus 26.03.1 publié avec ce correctif
08/2026	Correctif inclus dans CE 2.9.0 et Plus 26.07