GoAhead 6.1.1 fixes three TLS bugs in web server embedded in hundreds of millions of devices

GoAhead, an embedded web server running inside hundreds of millions of devices, has received fixes for three separate TLS vulnerabilities in version 6.1.1. According to security firm FoxIO, which published the research, the affected equipment spans vendors including Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin and Boeing. Actual exposure varies by device, since it depends on which TLS library a vendor linked against and how the build was configured.

GoAhead typically serves device management interfaces on routers, switches, printers, gateways and industrial controllers. It supports two TLS backends, OpenSSL (the default) and Mbed TLS, and the OpenSSL backend also works with compatible libraries such as LibreSSL. Each of the three bugs hits a different corner of that matrix.

Revoked client certificates accepted on OpenSSL builds

The most severe issue, rated critical at CVSS 9.1 and tracked as GOAHEAD-SA-2026-0006, means a certificate revocation list configured by the operator is loaded but never enforced. FoxIO found that GoAhead places the CRL into the OpenSSL certificate store without setting the flag OpenSSL requires to activate revocation checking, so verification returns success without ever consulting the list. A revoked client certificate can therefore complete a mutual TLS handshake even when issuer verification is enabled.

FoxIO demonstrated this on GoAhead 6.1.0 with OpenSSL 3.6.2: a revoked, CA-signed client certificate passed the handshake while the verification callback reported no errors anywhere in the chain. Because loading the CRL file succeeds, startup logs give no warning that enforcement is inactive. Versions 3.4.5 through 6.1.0 are affected whenever a CRL is configured, and the practical result is that a deliberately withdrawn identity keeps its access.

Chain-depth limit bypassed with older LibreSSL

A second flaw, rated high at CVSS 7.4 and tracked as GOAHEAD-SA-2026-0004, defeats GoAhead's cap on certificate chain length, which is set to ten. It applies when the server is built against LibreSSL 3.2.x or 3.3.2 through 3.3.6 and run with issuer checking disabled. Those LibreSSL versions use a legacy X.509 verifier that reports an issuer error rather than a depth error when it stops building a chain, and GoAhead tolerates issuer errors whenever issuer verification is off. An oversized chain therefore slips past the depth restriction.

FoxIO tested a 17-certificate chain anchored to an attacker-controlled, self-signed CA against GoAhead 6.1.0 with LibreSSL 3.3.6: the handshake completed and a resource protected by client-certificate authentication returned HTTP 200. The same GoAhead source compiled against LibreSSL 4.3.1 produced the correct depth error and rejected the chain. Mitigations include enabling issuer verification with a trusted CA bundle, moving to LibreSSL 4.x or the OpenSSL backend, or upgrading.

One-byte Diffie-Hellman modulus in Mbed TLS builds

The third bug, rated medium at CVSS 5.9 and tracked as GOAHEAD-SA-2026-0005, is a buffer-length mistake with outsized consequences. While configuring the standard 2048-bit Diffie-Hellman group, the code passes the size of the one-byte generator buffer as the length for both parameters, so Mbed TLS reads only a single byte of the 256-byte modulus and discards the rest. A TLS 1.2 DHE_RSA handshake then offers that degenerate parameter to clients.

With the broken value in play, only eight shared secrets are possible, so a passive observer can test each candidate against captured traffic and decrypt the session offline. FoxIO's proof of concept recovered the shared secret after five attempts. The typo was introduced in 2018 during a migration to a binary-parameter API and survived a 2024 TLS refactor. There is a key constraint: the OpenSSL client FoxIO tested rejected the parameters as too small, so exploitation requires a client without minimum-size checks, a realistic scenario for custom or embedded TLS stacks. ECDHE suites and TLS 1.3 are unaffected. Versions 4.0.2 through 6.1.0 are exposed, and remedies are upgrading to 6.1.1, disabling finite-field DHE suites, or using the OpenSSL backend. FoxIO also suggests searching JA4S network telemetry for the affected cipher suites to locate exposed servers.

Why it matters

GoAhead sits on the management plane of routers, firewalls, industrial controls and military hardware, and rolling out 6.1.1 depends on dozens of individual vendors shipping firmware updates, so vulnerable builds are likely to persist in the field for a long time.

Two of the bugs silently weaken mutual TLS, which is frequently the only authentication boundary on a device management interface. A revoked credential that still authenticates, or a chain-depth limit that is not enforced, produces no error in the logs, so operators have no signal that their policy is being violated.

The Mbed TLS flaw is also a reminder of how fragile cryptographic plumbing can be: a single wrong sizeof reduced strong 2048-bit Diffie-Hellman to eight possible keys, and whether real deployments are decryptable comes down to whether client stacks validate parameter sizes. Defenders should inventory embedded devices for GoAhead, identify the TLS backend and verification flags in use, and hunt for the affected DHE suites in network logs.