Skip to content
THREATWIRE

GoAhead 6.1.1 fixes TLS flaws that let revoked certificates back in

Three GoAhead TLS bugs can let revoked or untrusted client certificates in, or expose sessions, on opt-in setups. Fixed in 6.1.1. No known attacks; not in CISA KEV. Upgrade and ask device makers for firmware.

Critical

By ThreatWire Desk · Published 27 Oct 2026

PoC link

On this page
  • Affected: GoAhead 6.1.0 and earlier, only on builds that turn on mutual TLS or use the mbedtls backend with TLS 1.2 DHE. Default builds are not exposed.
  • Fixed in: GoAhead 6.1.1. Embedthis shipped it to device builders on 2 August 2026 and published the advisories on 12 October 2026.
  • Exploited? No. Neither CVE is in CISA KEV (checked 27 October 2026), and Embedthis reports no attacks.
  • Do this now: upgrade to 6.1.1, or ask your device maker for firmware built on it. Check whether your build uses a CRL or skips issuer checks.

What happened

Devices running GoAhead can accept a revoked client certificate, or let an outsider read some encrypted sessions. Three separate bugs sit where GoAhead connects to its TLS libraries.

GoAhead is a small web server from Embedthis. Device makers build it into routers, printers, gateways and industrial controllers. Embedthis published three advisories on 12 October 2026, all fixed in GoAhead 6.1.1.

The fix itself is older. The release notes say 6.1.1 reached device builders on 2 August 2026. Sébastien Féry of FoxIO, who found all three bugs, published his technical write-up on 26 October 2026.

The worst bug is CVE-2026-115881, rated Critical with a CVSS score of 9.1. The second is CVE-2026-115884, rated High at 7.4. The third, an mbedtls bug rated Medium at 5.9, has no CVE id.

Who is affected

Each bug needs a specific TLS library and build setting. The table below lists them from Embedthis's advisories.

BugTLS backendGoAhead versionsNeeded to be exposedSeverity
CVE-2026-115881, CRL never enforcedOpenSSL-compatible (the default)3.4.5 to 6.1.0Mutual TLS, a CA bundle, issuer checks and a CRL file all configuredCritical, 9.1
CVE-2026-115884, chain-depth bypassLibreSSL 3.2.x or 3.3.2 to 3.3.66.1.0 and earlierMutual TLS on, issuer checks offHigh, 7.4
GHSA-fmvx-2xfx-2gq4, 1-byte DH modulusmbedtls4.0.2 to 6.1.0TLS 1.2 DHE_RSA with a client that accepts the bad parametersMedium, 5.9
All threeAny6.1.1 and laterFixedNone

Mutual TLS means the client must also present a certificate. GoAhead sets it at build time, and default builds leave it off. So most GoAhead servers are not exposed to the two CVEs.

Am I affected? Ask your device maker three questions. Which GoAhead version and TLS library does the firmware use? Does it require client certificates? Does it use a revocation list or skip issuer checks?

What is confirmed

For CVE-2026-115881, the OpenSSL backend loads the revocation list but never enables checking. A client with a revoked certificate, such as a stolen device, still completes the handshake. It then keeps whatever access that identity had.

For CVE-2026-115884, old LibreSSL reports an over-long chain as an issuer error. GoAhead tolerates that error when issuer checks are off. An attacker with no trusted key can then pass as an authenticated client.

The mbedtls bug is a length typo. It shrinks a 2048-bit Diffie-Hellman value to one byte, leaving only eight possible shared secrets. A passive observer can decrypt the session if the client accepts those parameters.

FoxIO reported the three bugs between 22 April and 30 April 2026. Its researcher published reproduction files for each one. We read them without running them; they are a lab setup for testing, not an attack tool.

CISA's Known Exploited Vulnerabilities catalog lists neither CVE (checked 27 October 2026). The only GoAhead entry there is an older flaw from 2017.

What is not confirmed

No vendor or government source reports attacks on these bugs. NVD has no entry for either CVE yet, and CVE.org shows both ids as reserved. The scores above come from Embedthis.

Embedthis says GoAhead runs in hundreds of millions of devices. That is the size of its install base, not a count of exposed devices. The two CVEs only matter on builds with mutual TLS turned on.

We found no device maker advisory naming an affected product. Firms that use GoAhead each choose their own TLS library and settings. Until a maker publishes a list, its exposure is unknown.

The mbedtls bug may matter less in practice. The OpenSSL client FoxIO tested rejected the broken parameters. ECDHE suites and TLS 1.3 are not affected.

What to do

  1. Upgrade to GoAhead 6.1.1 or later and rebuild your firmware, if you ship GoAhead.
  2. Ask your device maker for firmware built on 6.1.1, if you run GoAhead-based equipment.
  3. Check builds that set a CRL. Treat revoked client certificates as still valid until you patch.
  4. Turn on issuer checks (ME_GOAHEAD_SSL_VERIFY_ISSUER=1) wherever mutual TLS guards access.
  5. Disable finite-field DHE suites on mbedtls builds, or move to ECDHE or TLS 1.3.
  6. Keep device management interfaces off the internet while you wait for firmware.

GoAhead 6.1.1 also fixes eight other bugs outside TLS. They include a password bypass for some stored hashes and CGI injection flaws. Read the release notes if your devices expose CGI.

Our take

These bugs fail silently. The server starts, the handshake completes, and nothing in the logs says that revocation or depth checks are off. Operators who chose mutual TLS did so to lock devices down.

The patch also took a long road to the public. Device makers had it in early August, but owners only learned of it in October. That gap is normal for embedded code, and it is why the firmware question matters most.

For another case where revoked trust kept working, see how eMudhra blames a script error for CA keys that anyone can recover.

Sources

Share on X@threatwire_https://www.threatwire.tech/news/goahead-6-1-1-fixes-tls-flaws-that-let-revoked-certificates-back-in

More articles