EmbedThis has disclosed that its GoAhead embedded web server, on OpenSSL builds, loads a certificate revocation list (CRL) but never enforces it, so revoked client certificates still complete mutual TLS. If you revoke certificates to cut off stolen or retired devices, affected builds won't honor that decision, and nothing at startup tells you.
What happened
EmbedThis published advisories on October 12, 2026 for three TLS flaws reported by Sébastien Féry of FoxIO, whose write-up followed on October 26. The fix, GoAhead 6.1.1, reached device builders on August 2 and closes 11 advisories in total.
In the headline bug, sslOpen() loads the CRL but never sets X509_V_FLAG_CRL_CHECK, so OpenSSL skips the revocation check. FoxIO reproduced it on GoAhead 6.1.0 with OpenSSL 3.6.2. Severity figures below are the vendor's. The Hacker News reported the CVE IDs weren't yet in public CVE or NVD databases as of October 27.
| Issue | Backend | Affected GoAhead | Severity |
|---|---|---|---|
| CVE-2026-115881: CRL not enforced | OpenSSL | 3.4.5 through 6.1.0 | Critical, 9.1 |
| CVE-2026-115884: chain depth limit bypass | LibreSSL 3.2.x, 3.3.2 through 3.3.6 | 6.1.0 and earlier | High, 7.4 |
| GHSA-fmvx-2xfx-2gq4: 1-byte DH modulus (no CVE) | Mbed TLS | 4.0.2 through 6.1.0 | Moderate, 5.9 |
CVE-2026-115881 needs a specific setup: OpenSSL backend, client certificates required, a CA bundle, issuer checking on, a CRL configured, and an attacker holding a revoked certificate from a trusted CA. An out-of-the-box build falls outside that setup, the advisory says, because mTLS and CRL loading are both off. It lists no workaround other than upgrading or using an Mbed TLS build.
On the LibreSSL builds, with issuer checking off, FoxIO completed a handshake using a 17-certificate chain from a self-signed CA it controlled. In the Mbed TLS case, a passive observer can read TLS 1.2 DHE-RSA traffic, though a client first has to tolerate the malformed DH values.
No source reports exploitation so far, though FoxIO has published proof-of-concept code.
Why it matters
Revocation is how you end a credential before it expires, and for device and machine identities it is often the main offboarding step. This bug breaks that step silently: the CRL loads, no warning appears, and a configuration review would pass. The required setup narrows exposure, but the deployments that meet it are the ones that deliberately chose client certificates and revocation, so they are relying on them.
The harder problem is who can act. GoAhead 6.1.1 must be rebuilt into firmware, and owners get it only when the manufacturer ships it. The Hacker News reports that HP and Siemens appear on EmbedThis's list of GoAhead users, but being on that list doesn't establish exposure. The same report says it remains unproven whether any listed manufacturer ships a vulnerable build.
One detail to watch: the advisory says the fix enables leaf-only checking and intentionally doesn't set X509_V_FLAG_CRL_CHECK_ALL, so don't assume 6.1.1 catches a revoked intermediate CA.
What to check in your environment
- Ask your vendors. For routers, printers, gateways and industrial controllers, ask whether firmware embeds GoAhead, which version and TLS backend, and when 6.1.1 ships. These are compile-time choices, so you may not be able to tell from outside.
- Test revocation directly. Where a device requires client certificates and has a CRL, issue a test certificate from the trusted CA, revoke it, update the CRL, and try to connect. A successful handshake means revocation isn't working there.
- Revisit past revocations. List unexpired certificates revoked for theft, compromise or decommissioning. On affected devices, treat them as live and review access logs for those identities where available.
- Add compensating controls. Until firmware arrives, restrict management interfaces to admin networks and don't let the client certificate be the only barrier.
- If you build firmware with GoAhead, check
ME_COM_OPENSSL,ME_GOAHEAD_SSL_VERIFY_PEER,ME_GOAHEAD_SSL_VERIFY_ISSUERandME_GOAHEAD_SSL_REVOKE, then rebuild on 6.1.1. FoxIO's interim options: for LibreSSL, issuer checking with a trusted CA bundle or moving to OpenSSL or LibreSSL 4.x; for Mbed TLS, disabling finite-field DHE suites or switching to OpenSSL. - Follow the post-upgrade steps. EmbedThis recommends invalidating active sessions or restarting the server, and rotating passwords stored as Blowfish (BF1) hashes, because the same release fixes a critical Basic-auth bypass for them. Windows
.batand.cmdCGI scripts now return 404. - Treat fingerprints as leads. FoxIO's JA4Scan fingerprints can locate GoAhead servers and their backend, but a hit only tells you which build is running. It doesn't prove that server is vulnerable.
References
- EmbedThis: GHSA-5m75-xq69-c3c5 (OpenSSL CRL)
- EmbedThis: GHSA-r392-vqwx-3r4g (LibreSSL chain depth)
- EmbedThis: GHSA-fmvx-2xfx-2gq4 (Mbed TLS DH)
- EmbedThis: GoAhead v6.1.1 release notes
- FoxIO: Choose Your Backend: Three TLS Bugs in GoAhead
- The Hacker News: GoAhead TLS flaws coverage
- SecurityWeek: TLS flaws found in GoAhead web server