Three vulnerabilities in EmbedThis’s GoAhead web server can let revoked client certificates retain access, expose some encrypted sessions to eavesdroppers, or bypass a certificate-chain length limit. The affected configurations differ by TLS library and settings; EmbedThis’s advisories list GoAhead 6.1.1 as the fixed release for all three.
The advisories, published on October 12, 2026, credit FoxIO researcher Sébastien Féry. GoAhead powers management interfaces in networking equipment, printers and industrial systems. According to FoxIO, it runs on hundreds of millions of devices, but that footprint is not a count of vulnerable devices: each flaw requires a particular build and configuration.
Revoked certificates can retain access
The most severe flaw, CVE-2026-115881, carries a CVSS score of 9.1 and affects GoAhead 3.4.5 through 6.1.0 using its OpenSSL TLS backend, including libraries sharing the relevant OpenSSL API behavior.
According to EmbedThis, GoAhead loads a configured certificate revocation list but omits X509_V_FLAG_CRL_CHECK, the flag that tells the library to enforce it. Loading succeeds without a startup warning, leaving administrators with no indication that revoked certificates remain usable.
Exploitation requires mutual TLS, a configured certificate authority bundle, issuer trust checking enabled and a configured revocation list. The attacker must possess a client certificate signed by a trusted authority and listed as revoked in that deployment’s list. The certificate then grants whatever access its original identity authorizes—for example, allowing a compromised device to reconnect after its certificate was revoked.
Default GoAhead builds do not enable mutual TLS or load a revocation list. Mbed TLS builds are unaffected by this flaw. GoAhead 6.1.1 restores revocation checking for the client’s leaf certificate; the fix does not enable chain-wide revocation enforcement.
Eavesdropping requires a permissive client
A separate Mbed TLS backend flaw, rated 5.9 with no known CVE, affects GoAhead 4.0.2 through 6.1.0. A length error truncates a 256-byte Diffie-Hellman modulus to one byte, weakening the parameters used in TLS_DHE_RSA_* handshakes over TLS 1.2 or earlier.
EmbedThis’s advisory describes a reporter demonstration in which a passive observer could recover session keys and decrypt a captured HTTPS exchange. That outcome requires the client to accept the one-byte group and the observer to capture the handshake. No credentials or active interception are required.
Most modern clients—including OpenSSL 1.0.2 and later, current Go, Java and mainstream browsers—reject the weak group. Permissive embedded or legacy clients can accept it. TLS 1.3, ECDHE cipher suites and OpenSSL-backed GoAhead builds are unaffected.
GoAhead 6.1.1 corrects the parameter length. SecurityWeek reports that disabling finite-field DHE cipher suites or switching to the OpenSSL backend also protects Mbed TLS deployments.
Legacy LibreSSL builds have a chain-length bypass
CVE-2026-115884, rated 7.4, affects GoAhead through 6.1.0 when linked against LibreSSL 3.2.x or 3.3.2 through 3.3.6 and configured to require client certificates while disabling issuer trust checking.
An attacker able to reach that HTTPS endpoint can present a self-signed chain of more than 10 certificates and complete the handshake without trusted key material or prior authentication. A verifier error causes GoAhead’s callback to skip its depth guard, bypassing the chain-length limit.
Deployments with issuer verification enabled are unaffected, as are builds using OpenSSL, BoringSSL, AWS-LC, LibreSSL 4.x or Mbed TLS. Default builds do not enable client-certificate verification. EmbedThis lists GoAhead 6.1.1 as patched; FoxIO also recommends enabling issuer verification with a trusted CA bundle or switching to OpenSSL or LibreSSL 4.x.
For device owners, the upstream fix does not establish that updated firmware is available. FoxIO founder and CTO John Althouse cautioned, in comments reported by SecurityWeek, that device patches depend on manufacturers. FoxIO has not identified which products from the manufacturers it named use vulnerable configurations.
