OPNsense: root command injection in the ACME plugin
CVE-2026-123025: the Google Cloud DNS module of OPNsense's os-acme-client plugin, versions 4.17 and earlier, lets a certificate account run commands as root.
Who is affected
- os-acme-client plugin versions 4.17 and earlier with Google Cloud DNS validation configured
- OPNsense deployments where any account, even non-admin, holds the right to issue or renew certificates
How to fix
Update the os-acme-client plugin as soon as the fixed release ships; until then, switch certificate validation away from Google Cloud DNS; restrict to the bare minimum the accounts entitled to issue or renew certificates on the admin interface and API; rotate the Google Cloud service key and any API token if a doubtful account could have edited the account or project field.
What happened
Advisory GHSA-g9hg-38vq-jvh9, published November 5, 2026, describes an OS command injection in the Google Cloud DNS validation module of OPNsense's os-acme-client plugin, versions 4.17 and earlier (CVE-2026-123025, scored 9.4 in CVSS 4.0). The affected method decodes the key field and interpolates the Google Cloud account and project fields straight into a shell command passed to proc_open, with no validation or escaping. An authenticated user entitled to issue or renew a certificate through the admin interface or the API thereby gets code execution as root.
Why it matters for a hotel
OPNsense is the perimeter firewall of choice for smaller properties: it guards the network, quarantines guest Wi-Fi and signs portal and access-point certificates with Let's Encrypt. This plugin is exactly the renewal automation. The flaw enlarges what an apparently minor role can do: one maintenance account, one API key lent to a contractor, and the firewall itself falls from the inside, with root privileges.
Who is affected
OPNsense installations running os-acme-client 4.17 or earlier where any certificate uses Google Cloud DNS validation. Deployments without this module, or without third-party accounts entitled to handle certificates, are less exposed: the attack requires an authenticated foothold first.
How to fix
- Update the os-acme-client plugin through the plugin manager as soon as the fixed release lands; watch the security advisories of the opnsense/core repository.
- Until then, move the affected certificates to another validation method (a different DNS provider or HTTP mode) so issuance no longer transits the Google Cloud module.
- Inventory every account entitled to issue or renew certificates on the interface and the API; remove stale ones, including contractor API keys.
- Rotate the Google Cloud service key tied to the ACME profile and re-check the account and project fields stored in the plugin.
- If those fields changed without explanation: treat the firewall as compromised, reinstall cleanly and rotate every secret that passed through it.
Context
The advisory was published on the morning of November 5 (UTC), capping a year in which OPNsense hardening has already produced a series of vendor advisories. The mechanism, model fields copied into a shell command, is a classic of network consoles: the strength of the wall then rests on the list of accounts allowed to touch certificates.