CVE-2026-111231 is a High severity (CVSS 7.2) authorization bypass in pfSense CE through 2.9.0. Read-only WebGUI users can still replace config.xml, because the config write deny privilege is ignored. We found no fixed version, so limit who can reach restore pages.
What's affected
The record says pfSense CE through 2.9.0 is affected. The researcher write-up says the review was of the public development tree for pfSense CE 2.9.0 at one commit, and notes that the PHP for the 2.9.0 release build was not on the public tree. We could not confirm whether shipped release builds contain the same code, and we found no Netgate advisory or fixed version, so check Netgate's channels.
The weakness is CWE-863, incorrect authorization. Per the record, the functions config_restore() and config_install() ignore the user privilege named Deny Config Write. A user who holds access to one of these pages can install a configuration file of their choice: services_acb.php, uploadconfig.php, diag_confbak.php or diag_backup.php.
The record says this can lead to root-level code execution after the configuration is reloaded or the system reboots. Severity differs by source. The record gives 7.2 (High). VulnCheck lists 8.6 on a CVSS 4.0 vector. Both are High.
How to check if you're exposed
Check your pfSense CE version.
cat /etc/version
Versions through 2.9.0 are in range per the record. Next, review user privileges. In the User Manager, find accounts and groups that have the Config Write deny privilege, and then check whether they also hold access to the backup, restore, configuration history or automatic backup pages. Those accounts are the ones the record describes.
Compare the configuration history under Diagnostics with what you expect. A change made by a read-only user, or a restore you did not request, is a warning sign. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Remove access to the backup, restore, configuration history and automatic backup pages from accounts that are meant to be read-only.
- Do not rely on the Config Write deny privilege alone until Netgate confirms a fix.
- Check the configuration history for changes you did not make, and restore a known good copy if needed.
- Limit the WebGUI to a management network or VPN.
- Install a fix from Netgate when it is confirmed.
Why it matters
A deny rule is only as good as the places that check it. Here the privilege existed and was shown in the interface, but the functions that write the configuration file did not look at it. The label promised more than the code delivered.
A configuration file on a firewall is a source of authority. Replacing it can change rules, users and services. Restricting who can restore is therefore a high value control, and it should be tested as part of every change to privilege handling. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
What does the Config Write deny privilege do?
It is meant to make a WebGUI user read-only. Per the record, the restore and install functions ignore it.
What is the impact?
The record says a chosen config.xml can be installed, which can lead to root-level code execution after a reload or reboot.
Sources
Last reviewed: 18 October 2026.
