OPNsense 26.7.9 Fixes Four Authenticated Vulnerabilities, Including a Root-Level PPP Flaw

On November 11, 2026, the OPNsense project published four security advisories in its GitHub core repository. The most serious is rated High and can lead to command execution as root on the firewall. The other three are rated Moderate and cover a memory exhaustion denial of service in the captive portal, a privilege bypass in the Monit settings, and the ability of limited users to delete crash reports. Fixes shipped in OPNsense 26.7.9, followed by a 26.7.9_1 hotfix on November 12, according to a practitioner summary from tplfirewall.com.

All four issues require an authenticated user who already holds a specific privilege or group membership. That lowers the urgency compared to an unauthenticated remote flaw, but it does not make these safe to ignore. Delegated admin accounts, MSP logins, API keys used for automation, and reused or phished credentials are all realistic paths to an authenticated session on a firewall. If you have handed out limited OPNsense roles because they seemed harmless, this batch of advisories is a good reason to revisit that decision.

At a Glance

Affected: OPNsense Community Edition 26.7.8 and earlier; OPNsense Business Edition 26.10.

Fixed in: 26.7.9 (hotfix 26.7.9_1 released November 12) and Business Edition 26.10.0p1.

Exploitation: All four require authenticated access with specific privileges. No public reports of exploitation as of November 14, 2026.

What to do, in order:

Inventory every OPNsense instance and record its version.
Patch first any firewall with PPP, PPPoE, PPTP, or L2TP links, captive portal templates, Monit, or delegated user roles.
Verify PPP links, captive portal, Monit, and crash reporting after the upgrade.
Review who holds the privileges named in the advisories and remove what is not needed.

The Four Advisories

Advisory	Severity	Issue	Privilege needed
GHSA-f35q-c34m-pfw3	High	PPP password injection leading to root command execution	Interfaces: PPPs: Edit
GHSA-r23v-737v-6r5h	Moderate	Captive portal template ZIP causes memory exhaustion	Captive Portal template permission
GHSA-2f7g-25f3-55v7	Moderate	Monit settings changeable from disallowed source networks	page-services-monit plus a source-restricted page-all group
GHSA-2w8j-hpp2-8rfj	Moderate	Limited users can delete crash reports and possibly the PHP error log	System: Status, or read-only with Crash Reporter visibility

PPP Password Injection (High)

According to GHSA-f35q-c34m-pfw3, this is an incomplete fix for an earlier vulnerability, CVE-2026-57154. PPP passwords entered through the GUI are written unquoted into the mpd_*.conf configuration files used by mpd5, the daemon that runs PPP links. A password containing a line break can inject additional configuration directives, such as an up-script, into that file. When the link comes up, mpd5 runs the injected command as root.

Exploiting it requires the Interfaces: PPPs: Edit privilege, and it affects systems with PPP, PPPoE, PPTP, or L2TP links configured through the GUI. The practical concern is a user who was given that one privilege to manage a WAN circuit, or an attacker who has taken over such an account. Either one can turn narrow access into full control of the firewall. If any of your sites terminate a DSL or fiber circuit with PPPoE on the firewall itself, treat this firewall as a priority.

Captive Portal Template Memory Exhaustion (Moderate)

Captive portal templates can be uploaded as a base64-encoded ZIP file through the API. GHSA-r23v-737v-6r5h reports that OPNsense processed highly compressed archives without size limits. In the advisory's reproduction, a 1.4 MB upload expanded to roughly 2 GiB of resident memory and the process was terminated. The attacker needs captive portal template permission. In health care settings, the captive portal is often what sits in front of patient and visitor Wi-Fi, so the realistic impact is a disrupted guest network rather than a data breach.

Monit Privilege Bypass (Moderate)

OPNsense lets administrators restrict group privileges to specific source networks. GHSA-2f7g-25f3-55v7 describes a flaw in the hasPrivilege() check: membership in a source-restricted page-all group satisfied the full-admin check for Monit even when the request came from a network the restriction should have blocked. A user holding page-services-monit plus that group could change Monit settings from a disallowed network. If you rely on source-network restrictions as a control for admin access, this is a reminder to verify that the restriction actually holds rather than assuming it does.

Crash Report Deletion (Moderate)

Per GHSA-2w8j-hpp2-8rfj, users with System: Status access, or read-only users who can see the Crash Reporter, could call dismiss_status to delete files under /var/crash/ and potentially the PHP error log. On its own this does not grant access to anything. The problem is what it removes: diagnostic evidence you would want during troubleshooting or an incident investigation on an edge device.

Affected Versions and the Upgrade Path

The advisories list Community Edition 26.7.8 and earlier as affected, along with Business Edition 26.10. The fixes are in Community Edition 26.7.9 and Business Edition 26.10.0p1. The 26.7.9 release announcement on the OPNsense forum references the four advisories and lists the related changes, including a source_networks check in hasPrivilege(), limits on template parsing, and added validation for PPP fields. A 26.7.9_1 hotfix followed on November 12, so make sure you land on the latest build rather than stopping at 26.7.9.

At the time of writing, these four advisories do not appear to have CVE identifiers assigned, which matters if your vulnerability scanner or tracking process keys on CVE numbers. Track them by their GHSA identifiers instead. No public reports of active exploitation had surfaced as of November 14, 2026, and public discussion of the advisories was minimal.

Why This Matters in a Health Care Network

Many smaller health care organizations run open-source firewalls such as OPNsense for perimeter protection, site-to-site VPNs between clinics, guest Wi-Fi with a captive portal, and internal segmentation. These are the devices that sit between the internet and systems handling electronic protected health information (ePHI).

Consider a 25-bed Critical Access Hospital with a single IT staff member, two outlying clinics connected by VPN, and an MSP that holds a limited account for after-hours monitoring. Delegated access like that is normal and often necessary. These advisories show that some of those limited roles were less limited than they looked. An account meant only to manage a PPPoE circuit could have reached root, and an account meant only to view status could have erased crash evidence. None of this requires panic, but it does justify patching on a short timeline and a fresh look at who has what access on your firewalls.

What to Do Now

Inventory. List every OPNsense instance, including branch and clinic firewalls that do not get much attention, and record the installed version and edition.
Prioritize. Patch first any firewall with PPP-family links, captive portal templates, Monit, or user accounts other than the primary administrators.
Test where it counts. If you run complex PPP or captive portal configurations, test the update on a non-production unit or during a maintenance window with a rollback plan and a current configuration backup.
Upgrade. Move Community Edition systems to 26.7.9 with the 26.7.9_1 hotfix, and Business Edition systems to 26.10.0p1.
Verify. After the upgrade, confirm PPP links reconnect, the captive portal serves the correct template, Monit settings are as expected, and crash reporting works. Review PPP password fields for unexpected content, since the new validation may reject values the old version accepted.
Watch for follow-ups. Keep an eye on the advisory page and the release notes for any additional hotfixes.

Tighten Privileges While You Are in There

Patching closes these specific bugs. Reviewing privileges reduces the damage from the next one. Go through your users and groups and look specifically at who holds Interfaces: PPPs: Edit, Captive Portal template permissions, System: Status, page-services-monit, and any page-all group that relies on source-network restrictions. Remove privileges that are no longer needed, disable accounts belonging to former staff or former vendors, and confirm that API keys used for automation carry only the rights their scripts actually use. If an MSP holds access, ask them which privileges they need and document the answer.

Because one of these flaws allowed deletion of crash reports on the device itself, consider sending firewall logs to a remote syslog server or other central log store if you are not already doing so. Evidence that lives only on the appliance can be removed by anyone who gains enough access to it.

Regulatory Context

The HIPAA Security Rule does not mention firewalls by name, but these advisories map directly to several technical safeguard standards. The access control standard at 45 CFR 164.312(a)(1) requires technical policies and procedures that allow access to systems maintaining ePHI only to persons or software programs that have been granted access rights. A privilege escalation from a narrow role to root on a perimeter device undermines exactly that. The audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use ePHI, which is why the crash report deletion issue and off-device logging deserve attention. The integrity standard at 45 CFR 164.312(c)(1) and the transmission security standard at 45 CFR 164.312(e)(1) are also relevant when the compromised device is the one carrying site-to-site VPN traffic. These are standards, not optional guidance, and documenting your patch timeline and privilege review is a straightforward way to show you are meeting them.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.