EmbedThis says GoAhead runs in “hundreds of millions of devices,” and a mistake in how its TLS backend handled certificate revocation meant revoked client certificates could still log in on affected setups.
The immediate risk: revoked client certificates accepted
Researchers at FoxIO, led by Sébastien Féry, reported on October 26 that certain builds of the GoAhead embedded web server load a certificate revocation list (CRL) at startup but do not actually perform revocation checking. The behavior occurs in builds that use the OpenSSL backend with mutual-TLS (client certificates required), where a CRL is configured to block revoked certificates. On such builds, the server reports no error when it loads the CRL, creating a false sense of security: a client whose certificate has been revoked can complete the TLS handshake and obtain whatever access that identity provides.
Exactly which builds and settings are affected
The vulnerability applies only when several conditions are met at compile-time and runtime: the firmware must be built with the OpenSSL backend, client certificates must be required (mutual-TLS), a trusted certificate authority bundle and issuer checking must be enabled, and a revocation list must be configured. Builds that use the Mbed TLS backend are unaffected by this specific CRL error because Mbed TLS checks revocation through a different code path. The issue was demonstrated in tests against GoAhead 6.1.0 paired with OpenSSL 3.6.2; the vendor has assigned the identifier CVE-2026-115881 and given it a severity rating of 9.1.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleRelated TLS problems vary by backend
FoxIO’s write-up describes two additional, backend-specific TLS flaws. One affects Mbed TLS builds where a too-small key-exchange value can be accepted by clients without a minimum-size check; if such a client accepts the value, an eavesdropper who recorded the traffic can derive the key and decrypt the session. TLS 1.3 and ECDHE sessions are unaffected, and Mbed TLS 4.x removed the vulnerable key exchange. The other problem, seen on older LibreSSL-linked builds, 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 — but only where client certificates are required and issuer checking is turned off. OpenSSL, BoringSSL, AWS-LC and LibreSSL 4.x reject the over-long chain.
Patch, distribution, and practical constraints for device owners
EmbedThis released GoAhead 6.1.1 to device makers on August 2, 2026, and publicly published the release on October 12, 2026. That release is a drop-in replacement intended for firmware rebuild and redistribution by device manufacturers; owners receive the update only when their manufacturer issues a firmware update. Which TLS backend and settings a given firmware image uses are chosen at compile time, so an external observer cannot tell whether a deployed device is vulnerable without vendor disclosure or direct inspection. EmbedThis says it has requested public CVE and NVD entries for the advisory identifiers; as of October 27 those identifiers were not yet live in the public CVE and NVD databases.
Operational guidance and other fixes in 6.1.1
GoAhead 6.1.1 fixes the revocation-checking failure and closes 11 advisories in total, three of them rated critical by EmbedThis. One of the fixed issues is a login bypass: on builds using HTTP Basic or form login, an attacker who knows a valid username could sign in with any password if that user’s stored password is in the newer Blowfish format that GoAhead introduced in version 6.1.0. EmbedThis notes that 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.
What this means for device makers, security teams, and administrators
- Device makers and firmware teams: must rebuild firmware with GoAhead 6.1.1 and ship updates. Whether any manufacturer has shipped the fixed build is not known.
- Security teams and network operators: should treat published fingerprints and proof‑of‑concept code with caution. FoxIO published PoC 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.
- End users and administrators: if an approved update is available from a device maker, apply it; after upgrading, follow EmbedThis’s advice to terminate sessions, restart the server, and change Blowfish-stored passwords where used.
No source reported any of these problems being exploited in the wild as of October 27. EmbedThis’s disclosure policy is to publish early if a flaw is being actively exploited or disclosed by others, and the coordinated October 12 release is consistent with there being no confirmed in-the-wild attacks — though FoxIO’s public proof-of-concept code and scanning fingerprints make it easier for defenders and attackers alike to locate builds of interest.
For owners of routers, printers, gateways and controllers that embed GoAhead, the central unanswered operational fact is straightforward: a fix exists, but it must be repackaged and issued by the device maker. Whether and when that redistribution happens will determine whether the theoretical risk becomes a practical one.
