The GoAhead embedded web server loaded a certificate revocation list into its default TLS backend but never turned revocation checking on, so a revoked client certificate could still pass login on affected setups.

The flaw is in builds that use the OpenSSL backend with mutual-TLS, where the server checks a client certificate and vice versa, and a revocation list is configured to block revoked certificates.

That is a setup an operator turns on deliberately; a default build does not. GoAhead 6.1.1, released to device makers on August 2, 2026, and publicly published on October 12, fixes it.

GoAhead is a small web server that device makers build into firmware to run management pages on routers, printers, gateways and industrial controllers. Its maker, EmbedThis, says it runs in hundreds of millions of devices.

The flaw was found by Sébastien Féry of FoxIO, who described it and two other TLS problems in a write-up on October 26.

On an affected build, the server loads the revocation list file at startup and reports no error, so an operator who configured it has every reason to think revocation is working. It is not. A client whose certificate was revoked, for example a stolen or retired device, completes the handshake as if the certificate were still valid and gets whatever access that identity allows.

In FoxIO's test against GoAhead 6.1.0 with OpenSSL 3.6.2, a revoked certificate was accepted with issuer checking switched on.

The OpenSSL advisory describes revoked client certificates as silently accepted .

Source link