OPNsense CVE-2026-71490

Requires an authenticated OPNsense account that has been DIRECTLY assigned (not inherited through a group) both a component write privilege AND the user-config-readonly privilege; this combination is what triggers the exact-comparison parser flaw in ACL::hasPrivilege(). Limiting factors: exploitation is impossible for accounts whose privileges are assigned via groups (the group path splits comma-separated values correctly), requires a valid low-privileged account to already exist, and is confined to persisting configuration changes for components the account can write. Fixed in version 26.1.11, so unpatched installs prior to 26.1.11 are the exposed population. Impact is limited to configuration integrity for the affected component - no confidentiality disclosure.

The input provides a CVSS 3.1 base score of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L), indicating a network-reachable, low-complexity flaw requiring low privileges, with high integrity impact, no confidentiality impact, and low availability impact - consistent with CWE-863 (Incorrect Authorization). No EPSS score, no CISA KEV listing, and no public exploit code were supplied, so there is no public exploit identified at time of analysis and no SSVC decision data to corroborate exploitation likelihood. Critically, the network vector is gated by a non-default precondition: an administrator must have DIRECTLY assigned a single account BOTH a component write privilege AND user-config-readonly (group-assigned privileges are explicitly NOT vulnerable because the group path splits comma-separated values correctly). This makes the realistic risk narrower than the 7.1 score implies - it is an authenticated privilege-containment bypass affecting a specific, operator-created privilege configuration rather than a broadly exploitable remote flaw. Treat as a moderate, config-dependent integrity issue; prioritize patching where delegated/semi-trusted OPNsense accounts exist, but it is not a drop-everything internet-facing RCE.

An OPNsense account directly assigned both a component write privilege and the user-config-readonly restriction is intended to be read-only. Because ACL::hasPrivilege() concatenates the directly-assigned comma-separated privilege string and performs an exact match, the readonly check fails to match and the account is treated as not read-only, letting it call an MVC API guarded by throwReadOnly() to persist configuration changes for that component. No public exploit code is identified; exploitation requires the attacker to already hold such an account.