Critical GoAhead Web Server Flaw Allows Attackers to Bypass Client Certificate Authentication

A critical flaw in the GoAhead embedded web server lets revoked client certificates pass authentication checks, potentially restoring access to identities administrators have blocked. Tracked as CVE-2026-115881, the vulnerability carries a CVSS score of 9.1 and affects GoAhead 3.4.5 through 6.1.0 when specific mutual TLS settings are enabled. GoAhead 6.1.1 fixes the issue.

The flaw is one of three TLS integration bugs detailed in FoxIO’s research. The other findings weaken certificate chain checks or, under specific conditions, allow captured encrypted traffic to be decrypted. Exposure depends on the TLS library, build options, and client behavior, not simply on whether a device uses GoAhead.

GoAhead Web Server Flaw

GoAhead provides web management interfaces for routers, printers, gateways, and industrial equipment. FoxIO says the software runs on hundreds of millions of devices. That deployment figure does not mean every device is vulnerable. GBHackers previously covered GoAhead server vulnerabilities affecting IoT devices, highlighting the wider importance of embedded web server security.

According to the Embedthis advisory, GoAhead’s OpenSSL backend loads a configured Certificate Revocation List, or CRL. However, it never enables the flag that makes OpenSSL check it. The missing X509_V_FLAG_CRL_CHECK flag causes verification to succeed without consulting the list. Loading the file succeeds, leaving administrators without a startup warning.

An attacker still needs a previously trusted, revoked client certificate and its matching private key. On affected deployments, that identity can complete the mutual TLS handshake and retain its original access. This is a revocation bypass, not a way to authenticate without any certificate. Default builds do not enable mutual TLS or load a CRL.

The second finding, GOAHEAD-SA-2026-0004, carries a CVSS score of 7.4. It affects GoAhead builds using LibreSSL’s legacy verifier in versions 3.2.x or 3.3.2 through 3.3.6 when client certificates are required but issuer checking is disabled. An overlong certificate chain produces an issuer error that GoAhead tolerates, bypassing its chain-depth limit. Ordinary self-signed certificates are already permitted under that configuration.

Certificate validation mistakes also feature in GBHackers’ coverage of Apache Tomcat certificate-checking flaws. However, those issues have separate causes and fixes.

The third flaw, GOAHEAD-SA-2026-0005, scores 5.9 and affects Mbed TLS builds of GoAhead 4.0.2 through 6.1.0. A buffer-length typo reduces a 2048-bit Diffie-Hellman modulus to one byte. A passive observer can decrypt completed TLS 1.2 DHE_RSA sessions if the client accepts those weak parameters. TLS 1.3 and ECDHE sessions are unaffected.

Device makers should rebuild and ship firmware with GoAhead 6.1.1 or later. Embed this date’s availability for device builders to August 2, 2026, with advisories published October 12.

Operators should confirm their firmware includes the fixes and review the actual TLS configuration. Temporary options include disabling finite-field DHE suites for Mbed TLS builds and enabling issuer verification with a trusted CA bundle for affected LibreSSL builds. These measures address different bugs and do not replace the CRL enforcement patch.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.