OPNsense flaw lets certificate users run root code

A critical vulnerability in OPNsense's ACME client plugin lets an authenticated user run commands as root on the firewall, turning a routine certificate job into a full takeover of the device.
The flaw, tracked as CVE-2026-123025, carries a CVSS score of 9.4 out of 10, putting it in the critical range. It sits in the Google Cloud DNS validation module of the os-acme-client plugin, versions 4.17 and earlier, which automates the issuing and renewal of Let's Encrypt certificates.
The problem is an operating system command injection, classified as CWE-78. The plugin's DnsGcloud::prepare() method decodes the stored Google Cloud key and then inserts the Google Cloud account and project fields directly into a shell command, which is passed to proc_open() through LeUtils::run_shell_command(). Neither field is validated or escaped before it reaches the shell.
That means a remote authenticated user who holds the privilege to issue or renew certificates through the web interface or the API can smuggle shell commands into those fields and have them executed as root. No further interaction is needed, and no administrative privilege is required beforehand.
The danger is the gap between the privilege needed and the privilege gained. Issuing a certificate is a narrow, everyday task that organisations often delegate to junior staff, contractors or automation accounts. This flaw lets anyone holding that narrow right take complete control of the firewall itself, including its rules, logs and stored secrets.
The advisory behind the flaw, GHSA-g9hg-38vq-jvh9, was published on 5 November 2026, and the CVE record was published the same day. OPNsense is an open-source firewall widely used by small and medium-sized organisations, schools and home-lab users as the perimeter device guarding their whole network.
Administrators should update the os-acme-client plugin as soon as the fixed release is available. Until then, the safest step is to move affected certificates to a different validation method, such as another DNS provider or HTTP validation, so that certificate issuing no longer passes through the Google Cloud module.
Access to certificate issuing should also be reviewed now. Every account entitled to issue or renew certificates on the web interface and the API should be checked, and stale accounts, including old contractor API keys, should be removed. Only the smallest possible number of accounts should hold the right.
Organisations should also rotate the Google Cloud service key tied to the ACME profile, along with any related API token, if there is any chance that an untrusted account could have edited the account or project fields. If those fields are found to have changed without explanation, the firewall should be treated as compromised, rebuilt cleanly, and every secret that passed through it should be rotated.
Deployments that do not use Google Cloud DNS validation, or that give no third-party account the right to handle certificates, are less exposed, because the attack needs an authenticated foothold first. But any OPNsense system running os-acme-client 4.17 or earlier with Google Cloud DNS validation configured should be treated as at risk until it is patched or the module is disabled.