The GoAhead embedded web server loaded a certificate revocation list into its default TLS backend but never turned revocation checking on, so a revoked client certificate could still pass login on affected setups.
The flaw is in builds that use the OpenSSL backend with mutual-TLS, where the server checks a client certificate and vice versa, and a revocation list is configured to block revoked certificates.
That is a setup an operator turns on deliberately; a default build does not. GoAhead 6.1.1, released to device makers on August 2, 2026, and publicly published on October 12, fixes it.
GoAhead is a small web server that device makers build into firmware to run management pages on routers, printers, gateways and industrial controllers. Its maker, EmbedThis, says it runs in hundreds of millions of devices.
The flaw was found by Sébastien Féry of FoxIO, who described it and two other TLS problems in a write-up on October 26.
On an affected build, the server loads the revocation list file at startup and reports no error, so an operator who configured it has every reason to think revocation is working. It is not. A client whose certificate was revoked, for example a stolen or retired device, completes the handshake as if the certificate were still valid and gets whatever access that identity allows.
In FoxIO’s test against GoAhead 6.1.0 with OpenSSL 3.6.2, a revoked certificate was accepted with issuer checking switched on.
The OpenSSL advisory describes revoked client certificates as silently accepted. To be exploited, the build must use the OpenSSL backend with client certificates required, a trusted certificate authority bundle and issuer checking enabled, and a revocation list configured; the attacker must hold a certificate signed by a trusted authority and listed as revoked. Builds that use the Mbed TLS backend are unaffected; that backend checks revocation via a separate code path.
The identifier on the advisory is CVE-2026-115881, rated 9.1 by EmbedThis. As of October 27, that identifier and the others below were not yet live in the public CVE and NVD databases; EmbedThis says it has requested them. The severity ratings are the vendor’s own.
Researchers cover two further problems, each tied to a specific TLS build. The versions and fixes differ, so the table below maps each by backend.
| TLS build | What goes wrong | Affected versions | Fix or interim option |
|---|---|---|---|
| OpenSSL (default) | Revocation list loaded but never enforced; revoked client certificates accepted. CVE-2026-115881, rated 9.1. | 3.4.5 through 6.1.0 | Upgrade to 6.1.1. No interim option in the advisory. |
| LibreSSL legacy verifier (3.2.x, 3.3.2–3.3.6) |
A client certificate chain longer than the limit is accepted when client certificates are required but issuer checking is off. CVE-2026-115884, rated 7.4. |
6.1.0 and earlier on those LibreSSL versions | Upgrade to 6.1.1, or turn issuer checking on with a trusted CA bundle, or use OpenSSL or LibreSSL 4.x. |
| Mbed TLS |
A length typo sends a 1-byte Diffie-Hellman value instead of the full 2048-bit one, so a passive observer can decrypt the session. Rated 5.9. No CVE assigned. |
4.0.2 through 6.1.0 | Upgrade to 6.1.1, turn off finite-field DHE suites, or use the OpenSSL backend. |
The Mbed TLS problem only reaches a session if the client accepts the broken setup. OpenSSL, current Go, current Java, and mainstream browsers refuse a value that small and fall back to a stronger key exchange, so the session never completes.
Clients without a minimum-size check, such as some embedded or custom ones, accept it, and then anyone who recorded the traffic can work out the key and read the session. TLS 1.3 and ECDHE sessions are unaffected, and Mbed TLS 4.x removed the key exchange they rely on.
The LibreSSL problem allows an attacker to present a certificate chain longer than GoAhead’s 10-certificate limit and still complete the handshake as an authenticated client, without any trusted key.
It appears only on builds linked against the older LibreSSL versions listed above and only where client certificates are required with issuer checking off. OpenSSL, BoringSSL, AWS-LC and LibreSSL 4.x reject the over-long chain.
Which backend and settings a build uses are chosen when the firmware is compiled, so a device owner cannot tell from the outside which apply. That is also why the fix is slow to arrive: GoAhead 6.1.1 is a drop-in replacement that device makers rebuild and ship as a firmware update, and an owner gets it only when their manufacturer does so. Whether any manufacturer has shipped it is not known.
As of October 27, no source reported any of these problems being used in attacks. EmbedThis’s policy is to end a disclosure embargo and publish early if a flaw is being exploited or disclosed by someone else, so the coordinated October 12 release is consistent with no known attacks.
However, it does not prove there are none. EmbedThis notifies customers of security updates through its Builder portal. FoxIO has published proof-of-concept code and offers fingerprints through its JA4Scan tool to find GoAhead servers by backend. The tool is free, but its source is available only on request, and a fingerprint identifies a build, not a confirmed-vulnerable server.
None of the device makers EmbedThis lists as GoAhead users, which include HP, Oracle, Siemens, Canon, Rockwell, D-Link and Comcast, has been shown to run an affected backend and setting. The affected population is not established.
The same 6.1.1 release closes 11 advisories in all, three of them rated critical. One is a login bypass: on a build using HTTP Basic or form login, an attacker who knows a valid username can sign in with any password if that user’s stored password is in the newer Blowfish format, which GoAhead added in version 6.1.0. EmbedThis says form login is the default for its built-in administration pages.
After upgrading, EmbedThis recommends ending active sessions, restarting the server, and changing Blowfish-stored passwords.
