Vulnerabilities
GoAhead TLS flaws: revoked certificates still get in
Three TLS bugs in the GoAhead embedded web server weaken client certificate checks and DHE encryption. Which builds are hit, how to test, what to do.
FoxIO researcher Sébastien Féry has disclosed three TLS bugs in GoAhead, the small web server from EmbedThis that runs the management pages of routers, printers, industrial controllers and other embedded devices. The worst, CVE-2026-115881 (CVSS 9.1), means a GoAhead build that uses OpenSSL and checks client certificates against a certificate revocation list (CRL) still lets revoked certificates log in. The other two weaken TLS 1.2 encryption on Mbed TLS builds and let over-long certificate chains through on old LibreSSL builds.
EmbedThis fixed the OpenSSL and Mbed TLS bugs in GoAhead 6.1.1 on August 2 and published advisories for all three on October 12. FoxIO puts GoAhead on hundreds of millions of devices across IoT, operational technology (OT), firewall and military equipment. Whether a given device is exposed depends on which TLS library its maker compiled in and how they set up certificate checks, and a fix reaches you only when that maker ships new firmware. Nobody has reported exploitation, but FoxIO has published proof-of-concept code.
How it works
GoAhead's TLS options are compile-time settings, so the device maker decides them when building the firmware. Mutual TLS (mTLS), where the device asks the connecting client for its own certificate, is switched on with ME_GOAHEAD_SSL_VERIFY_PEER=1. ME_GOAHEAD_SSL_VERIFY_ISSUER=1 makes GoAhead check that the certificate was signed by the CA bundle in ME_GOAHEAD_SSL_AUTHORITY, and ME_GOAHEAD_SSL_REVOKE points at a CRL, the CA's list of certificates it has withdrawn before expiry.
Revoked certificates accepted (CVE-2026-115881). In sslOpen() in src/openssl.c, GoAhead loads the CRL into OpenSSL's certificate store with X509_STORE_load_locations(), but never sets the X509_V_FLAG_CRL_CHECK flag. Without that flag, OpenSSL's revocation step returns success without looking at the CRL. Nothing is logged, so the device looks correctly configured while a certificate from a lost laptop or a former contractor still completes the handshake. It affects GoAhead 3.4.5 to 6.1.0 built with OpenSSL or a compatible library, with peer verification, issuer verification, a CA bundle and a CRL all configured. The attacker needs a revoked certificate from that CA, so the risk is highest where revocation is how you cut off people and machines.
Weak DHE on Mbed TLS (no CVE, CVSS 5.9). In src/mbedtls.c, the call that loads the Diffie-Hellman (DHE) group passes the length of the 1-byte generator instead of the 256-byte RFC 3526 prime. The server therefore offers a 1-byte modulus in its TLS 1.2 DHE_RSA ServerKeyExchange message. FoxIO says that leaves eight possible shared secrets, so someone who records the traffic can decrypt it later. It needs a client that accepts the broken parameters; the OpenSSL client FoxIO tested refused them. TLS 1.3 and ECDHE (elliptic curve) suites are not affected. Affected range: GoAhead 4.0.2 to 6.1.0 built with Mbed TLS.
Chain-length cap skipped on LibreSSL (CVE-2026-115884, CVSS 7.4). GoAhead limits client certificate chains to 10 certificates (ME_GOAHEAD_SSL_VERIFY_DEPTH), but its verify callback only applies that limit when no other error is set. The legacy verifier in LibreSSL 3.2.x and 3.3.2 to 3.3.6 reports an over-long chain as "unable to get issuer certificate" instead, and GoAhead tolerates that error when ME_GOAHEAD_SSL_VERIFY_ISSUER=0. It only matters on servers that ask for a client certificate but accept one from any issuer, where the depth cap was the remaining check. OpenSSL, BoringSSL, AWS-LC, LibreSSL 4.x and Mbed TLS builds are not exposed. As Féry notes, none of the three bugs stops the handshake, so nothing breaks visibly.
What attackers are doing
There are no public reports of exploitation. FoxIO has released proof-of-concept code in its blog_poc repository and says its Mbed TLS secret recovery worked within five attempts and decrypted the captured HTTP exchange. It also published JA4 fingerprints that identify internet-facing GoAhead servers and the TLS library they use.
SecurityWeek reports that FoxIO founder John Althouse named vendors whose devices reportedly use GoAhead, among them Palo Alto Networks, D-Link, HP, Canon, Honeywell, Siemens and Rockwell. FoxIO has not said that any of their products use a vulnerable configuration.
What to do
Find GoAhead on your network
Current GoAhead releases send the HTTP header Server: GoAhead-http. Run nmap -p 80,443,8080,8443 --script http-headers 10.0.0.0/16 against your internal ranges and grep the output for GoAhead. Some vendors change or strip the header, so also match FoxIO's JA4 fingerprints against your TLS logs or scanner. They tell OpenSSL builds apart from LibreSSL 3.3.6 and Mbed TLS builds, which tells you which bug can apply.
Ask each vendor for build details
Device owners cannot rebuild GoAhead themselves. For every product found, ask the maker which GoAhead version and TLS library the current firmware uses, whether client certificates and a CRL are enabled, and when firmware with GoAhead 6.1.1 (or their backport) will ship. Get the answer in writing with a firmware version you can check.
Test revocation yourself
If a device uses client certificates, issue a test certificate from the same CA, confirm it can log in, revoke it, publish the updated CRL to the device, and try again with openssl s_client -connect <device>:443 -cert revoked.pem -key revoked.key, then send GET / HTTP/1.1. A device that enforces revocation drops the connection with a certificate revoked alert. An HTTP response means revocation is not working, whatever the configuration says.
For Mbed TLS builds, openssl s_client -connect <device>:443 -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384 shows whether the device offers DHE at all. A failure citing DH parameters or key size on a device that does offer DHE is a sign of the 1-byte modulus.
Mitigate by backend while you wait
- OpenSSL with a CRL: there is no configuration workaround in the advisory. Until firmware is fixed, treat revocation on these devices as absent: restrict who can reach them and replace the CA or the device certificates if a revoked certificate belongs to someone who must lose access now.
- Mbed TLS: disable finite-field DHE suites if the device lets you set ciphers, or prefer ECDHE and TLS 1.3 on the clients and proxies that talk to it.
- LibreSSL 3.2.x or 3.3.2 to 3.3.6: enable issuer verification with a trusted CA bundle, or ask the vendor to move to OpenSSL or LibreSSL 4.x. GitHub's advisory also lists 6.1.1 as patched for this bug.
Shrink who can reach the interface
Management interfaces should only be reachable from an admin network or jump host. Put an allowlist on the upstream firewall or switch for the device's HTTPS port, block it from user, guest and internet-facing segments, and remove any port forwards. If you depend on certificate login, a reverse proxy in front of the device that does its own CRL or OCSP check restores revocation until the firmware is fixed.
Check for misuse
Look for logins by certificates you have revoked. In TLS 1.2 the client certificate travels unencrypted, so network sensors such as Zeek record its subject and serial in x509.log; compare those serials against your CRL for every connection to a GoAhead device. On the device, review its access log or audit log, if it has one, for logins after the revocation date of each withdrawn certificate. If you find one, treat the device as compromised: review its configuration, reset local admin accounts and rotate any secrets it stores.
The wider lesson
CVE-2026-115881 sat in GoAhead since 3.4.5 because a CRL that loads cleanly looks the same as one that is enforced. Test revocation, issuer checks and cipher restrictions on embedded devices with a certificate or client that must fail, at installation and after each firmware update.
Our network penetration tests include embedded management interfaces and test certificate login with revoked and untrusted certificates, and our attack surface management work keeps the list of exposed device consoles current. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: SecurityWeek, FoxIO blog, GoAhead advisory GHSA-5m75-xq69-c3c5, GoAhead advisory GHSA-fmvx-2xfx-2gq4, GoAhead advisory GHSA-r392-vqwx-3r4g, GoAhead source.