GoAhead's revocation check was never on. Revoked certs waltzed in.
Two separate flaws in the GoAhead embedded web server let revoked or forged client certificates pass mutual-TLS login, but only on specific builds.
Key points
- GoAhead's OpenSSL build loaded the revocation list but never flipped the switch that tells OpenSSL to actually check it, so revoked client certificates logged in cleanly.
- A separate flaw in GoAhead builds linked against LibreSSL 3.2.x or 3.3.2 to 3.3.6 let an attacker log in with a self-signed certificate chain and no trusted key at all.
- Builds using mbedtls are not affected by either flaw; builds using mainline OpenSSL are not affected by the LibreSSL bypass.
- Both issues require mutual-TLS to be enabled, a setup common in industrial gear, routers and medical devices rather than public websites.
- The vendor advisories are GHSA-5m75-xq69-c3c5 and GHSA-r392-vqwx-3r4g.
GoAhead is a small web server that ships inside a lot of hardware you never think about: routers, cameras, factory controllers, the odd medical device. Two advisories published this week show that its mutual-TLS login, the kind where both sides present a certificate before any traffic flows, was quietly broken on common builds.
The first flaw is almost comic. An operator switches on revocation, which is the mechanism for refusing certificates that have been reported stolen or decommissioned. GoAhead reads the revocation list into OpenSSL's certificate store. Startup looks clean. No warning, no error.
But GoAhead never calls the one OpenSSL function, X509_STORE_set_flags with the X509_V_FLAG_CRL_CHECK flag, that tells the library to consult the list. OpenSSL's internal check returns success without ever opening the file. A revoked client certificate, maybe one lifted from a device that was retired last year, completes the handshake as if nothing had changed.
If this reminds you of a web app that validates a password field by checking it exists rather than checking it matches, that is the right instinct. The configuration knob worked. The check behind it did not.
Which builds are actually at risk?
Only specific GoAhead builds. The revocation bug is in the OpenSSL TLS backend (src/openssl.c). Builds compiled against mbedtls use a different code path and are fine. The second flaw is the mirror image: it only bites builds linked against LibreSSL's legacy X.509 verifier, specifically LibreSSL 3.2.x and 3.3.2 through 3.3.6. Mainline OpenSSL, BoringSSL, AWS-LC and LibreSSL 4.x builds are not exposed.
| Build backend | Revocation bypass | LibreSSL chain bypass |
|---|---|---|
| OpenSSL | Affected | Not affected |
| LibreSSL 3.2.x, 3.3.2-3.3.6 | Not applicable | Affected |
| LibreSSL 4.x | Not applicable | Not affected |
| mbedtls | Not affected | Not affected |
| BoringSSL, AWS-LC | Not applicable | Not affected |
The LibreSSL case is nastier in theory. An attacker who can reach the mTLS endpoint presents a self-signed certificate chain longer than the server's configured depth of 10, and the legacy verifier waves it through. No stolen key required. The catch is the configuration: the deployment has to require client certificates but skip issuer-trust checking (ME_GOAHEAD_SSL_VERIFY_PEER=1, ME_GOAHEAD_SSL_VERIFY_ISSUER=0), which is an unusual, if not unheard of, choice.
What should operators actually do?
Find out which TLS backend your GoAhead build uses, then patch to the fixed release the vendor is shipping alongside the advisories. If you cannot patch today and you run the OpenSSL build with revocation configured, assume revocation is not being enforced and rotate or reissue any client certificates you believed were already blocked.
For ordinary people, there is nothing to click. These flaws live inside equipment managed by whoever installed your office network or your hospital's imaging kit. The practical pressure here is on vendors who redistribute GoAhead inside their firmware to cut new builds and push them out, which, as reported by The Hacker News, is now the open question.
My read: the LibreSSL chain bypass will get the louder headlines because "forge a cert, log in" sounds dramatic. The revocation bug is the one that will quietly matter more, because plenty of shops have been running with the switch they thought was on.
