GoAhead advisories say OpenSSL builds accepted revoked client certificates and mbedTLS builds sent a 1 byte DH prime

A 2048 bit group cut to one byte, and a revocation list that loaded but was never read

The prime in a 2048 bit Diffie Hellman group is 256 bytes long. According to Embedthis's own security advisory, GoAhead's mbedTLS builds up to version 6.1.0 sent one of them, the number 255, which is 1 of 256 bytes or 0.39 per cent of the prime (derived), and 255 is not even prime (3 x 5 x 17). The advisory says a passive observer who recorded such a handshake can recover the server's secret exponent in at most 254 tries and decrypt the session. A separate advisory says that in GoAhead's OpenSSL builds up to 6.1.0 a certificate revocation list was loaded without an error, and then never consulted, so revoked client certificates were accepted.

This briefing reads the primaries, not the press coverage. Read from 21:30 UTC on Tuesday 27 October 2026: the three GitHub advisories, the v6.1.1 release notes, the tagged source files for versions 6.1.0 and 6.1.1, Embedthis's GoAhead product page, the live CISA Known Exploited Vulnerabilities file, and the CVE.org and NVD records for the CVE numbers the advisories list. The Hacker News article of the same day that prompted the story returned a bot check to a script and was not read, so nothing here rests on it.

What the record does not establish is as important as what it does. Both flaws need settings that GoAhead does not enable by default. The decryption flaw also needs a client that accepts a one byte group, and the advisory says current OpenSSL, Go, Java and mainstream browsers refuse it. No advisory states that either flaw has been exploited, how many devices run an affected build, or which products embed it. None of the CVE numbers listed on the advisories resolved on CVE.org or NVD when checked. The sections below set out the conditions, the arithmetic, the gaps and what to do.

Three TLS advisories, three different builds

GoAhead is a compact embedded web server written in C. Version 6.1.1 was published on GitHub at 04:31 UTC on 12 October 2026 as a security patch release that resolves eleven advisories. Three concern TLS. Each affects a different backend, so the first job for a defender is to know which TLS library a device was built with. The release notes say GoAhead supports OpenSSL (preferred) or MbedTLS and does not pin a TLS library version: the integrator, meaning the device maker, selects and maintains it.

Zoom

Who computed the scores is not stated. The advisory pages show a CVSS 3.1 vector and score under the vendor's own publication, with no separate CNA or NVD score. None could be cross checked: CVE.org's record service returned no record for any of the five CVE numbers that appear across the eleven advisories, and NVD returned no results for the two numbers listed on the TLS advisories that carry one. The release notes say CVE identifiers "have been requested and will be added to the advisories as they are assigned", so the numbers on the pages are best read as provisional (inference). The disagreement over the decryption flaw's name is small but real: the release notes call it Medium and the GitHub page calls it Moderate, and it has no CVE number at all.

Flaw one: the revocation list that loaded, and was never consulted

The advisory says GoAhead's OpenSSL backend loaded a configured certificate revocation list into the certificate store but never called the OpenSSL function that turns checking on. Without that flag, the advisory says, OpenSSL's revocation check returns success at once on every TLS handshake without ever opening the list. The load call returned success, nothing was logged, and an operator who set the revocation file and saw no warning "has every reason to believe revocation is enforced", in the advisory's words. It was not.

Zoom

The conditions are narrow and the advisory lists all of them: an OpenSSL build, mutual TLS on, a CA bundle set, issuer trust on, a CRL file set, and an attacker who holds a client certificate that the CA signed and the CRL lists. That is six conditions (counted from the advisory's list). The advisory says the default build does not enable mutual TLS or load a CRL, and adds that deployments with a CRL set are the explicit target, because those operators chose revocation for a reason. The example it gives is "a stolen, decommissioned, or otherwise compromised device": a certificate the operator has already revoked.

What "accepted" means: the TLS handshake completes and the client is treated as authenticated by its certificate identity, with "whatever access the original certificate's identity authorises". The advisory scores it 9.1, with no privileges and no user interaction needed, high confidentiality and integrity impact and no availability impact. What the access is depends on the device: a management interface, a data feed or an operator screen. The advisory does not say, and this site does not guess. One consequence follows from the arithmetic of revocation and is inference: with checking off, the only limit on a revoked certificate was its own expiry date, so every unexpired entry on a deployment's CRL was a working credential.

The fix is one call added after the load, and the tagged v6.1.1 source contains it, as the Technical details section shows. The advisory says it deliberately does not enable chain wide checking, because that needs a revocation list for every issuer in the chain, which most deployments do not ship. So 6.1.1 restores revocation checks for the client's own certificate only. A deployment that relies on a CRL for an intermediate certificate is not covered by this fix.

Flaw two: what "session decryption" means, and what it needs

This is the flaw behind the phrase "sessions decryptable", and the primary is specific about its limits. The weakness is a one token error in the mbedTLS backend: the length passed for the prime was the size of the generator, 1 byte, rather than the size of the prime, 256 bytes. mbedTLS does not check the bit length, so a 2048 bit group declared in the code reached the wire as a prime of 255 and a generator of 2. The advisory classes it as use of a broken or risky cryptographic algorithm (CWE 327), incorrect calculation (CWE 682) and a risky cryptographic implementation (CWE 1240).

In a DHE key exchange the two sides agree a shared secret from a public group and a private exponent each. With a prime of 255 the advisory says the server's exponent "can be recovered in at most 254 iterations". From that exponent an observer computes the shared secret, derives the session keys and decrypts the recorded request and response. It calls this the destruction of forward secrecy for the affected session. The property that is lost is the promise that a recorded session stays private even if something is learned later: here the recording alone is enough, with no key and no man in the middle.

Zoom

The primary lists four conditions, and the third is the one that limits the damage. The server is an mbedTLS build. The handshake is TLS 1.2 or earlier with a DHE RSA suite. The client accepts a one byte group. And the attacker can observe the handshake, which the advisory says needs no man in the middle position, no credentials and no prior authentication. It says "most modern stacks" refuse a group under 768 bits and fall back to ECDHE, and that TLS 1.3 and ECDHE suites are not affected. It names the clients that accept: embedded clients that do not enforce a minimum group size, legacy stacks and custom telemetry collectors.

That last list is where the severity argument sits. The score of 5.9 carries a high attack complexity, which reflects the need for a permissive client. For a fleet of old sensors that talk only to a GoAhead gateway, that need may be met by default (inference): the vendor's rating describes the typical case, not a specific estate. How many such clients exist is not stated. The advisory says the reporter needed five iterations. The tagged source confirms the one token fix, but this site ran no capture and no decryption.

The third advisory, on a chain depth guard in LibreSSL 3.2.x and 3.3.2 to 3.3.6 builds, is narrower still. It needs issuer trust off and mutual TLS on, and it lets an attacker present a self signed chain of more than ten certificates as an authenticated client. The advisory says OpenSSL, BoringSSL, AWS-LC and LibreSSL 4.x builds, and the mbedTLS backend, are not exposed. It is noted here for completeness because it is a TLS flaw in the same release, rated High, 7.4.

Stated and not stated: where GoAhead sits and what the record leaves out

Embedthis's product page says GoAhead is "deployed in hundreds of millions of devices" and lists printers, routers, switches, IP phones, data acquisition, military applications and WIFI gateways as examples. That is a vendor's own marketing claim, not a count of affected devices. Embedthis sells commercial licences and a subscription for updates, and its 6.1.0 release notes say GoAhead is in maintenance mode and point new projects to its newer Ioto agent, which it also offers. It wrote, scored, rated and published its own advisories, and the release notes say the findings come from an in house audit and from outside researchers, who are thanked by name there.

The older KEV entry matters as context, not as evidence: CISA lists a 2017 remote code execution flaw in GoAhead before 3.6.5 as exploited. That shows the product class has been attacked before. It does not show that these 2026 flaws are being used, and nothing in the record does.

Fix dates against disclosure dates

The release notes give the date as "August 2, 2026 (device builders); advisories published October 12, 2026". The GitHub tag for 6.1.1 carries a timestamp of 12 October 2026 at 04:31:02 UTC. From 2 August to 12 October is 71 days (derived). The notes do not say what device builders were told in August, or whether the advisories existed then, so the 71 days is a gap between two dated statements, not a measured exposure window.

Two readings are inference. First, the earlier notes did not mention either TLS flaw, and the CRL advisory's version range, 3.4.5 to 6.1.0, includes the 6.0.5 and 6.1.0 releases whose notes describe security audits: an audit is not a guarantee, and a silent success is the kind of defect an audit may pass. Second, for a device maker the fix has been available for 86 days (2 August to 27 October, derived), so an unpatched device on the market now may reflect a supply chain delay rather than a missing patch (inference). The advisories do not say which device makers have shipped it.

Friendly names: when a label does the work of a control

A setting, a score or a protocol name is not the same as the control it suggests. Five labels appear in this story.

Method is separate from accusation. Embedthis found and disclosed its own bugs, published code level detail and fixed them, which is what a maintainer should do. The gap is in what an operator can know: a device with a configured CRL gave no sign that it was not enforcing it. A control that cannot show it is working is a label.

Technical details

Every block below is copied by program from a page or source file saved on 27 October 2026, and each caption names the source. The vendor's advisories print no indicators, hashes or domains and no detection rules, so there are none here. Two blocks at the end are commands this site derived, labelled as such. No exploit or proof of concept code is published here or was downloaded.

Settings first. These are the build settings the advisories list as conditions. They are compile time settings, so a defender reads them from the device vendor's build configuration, not from a running service.

The server is built against the OpenSSL TLS backend (ME_COM_OPENSSL=1, the project's preferred and default TLS backend). mbedtls builds are not affected.
Mutual TLS is enabled: ME_GOAHEAD_SSL_VERIFY_PEER=1.
A CA bundle is configured: ME_GOAHEAD_SSL_AUTHORITY non-empty.
Issuer trust is enabled: ME_GOAHEAD_SSL_VERIFY_ISSUER=1.
A CRL is configured: ME_GOAHEAD_SSL_REVOKE non-empty, pointing at a CRL file.

The server is built with the mbedtls TLS backend (ME_COM_MBEDTLS=1 ME_COM_OPENSSL=0). Builds linked against OpenSSL are not affected.
The TLS handshake is TLS 1.2 (or earlier) and uses a DHE_RSA cipher suite (TLS_DHE_RSA_*). TLS 1.3 and ECDHE handshakes are not affected.
The client accepts a 1-byte (8-bit) DH group. OpenSSL >= 1.0.2, current Go, current Java, and current mainstream browsers refuse it; permissive embedded or legacy clients accept it.
The attacker can observe the handshake on the network.

The deployment enables mutual TLS with ME_GOAHEAD_SSL_VERIFY_PEER=1.
The deployment disables issuer trust checking with ME_GOAHEAD_SSL_VERIFY_ISSUER=0. Deployments that set ME_GOAHEAD_SSL_VERIFY_ISSUER=1 are not affected.
GoAhead is linked against LibreSSL 3.2.x or 3.3.2-3.3.6.

The revocation code. The first block is src/openssl.c in the v6.1.0 tag, the last version the advisory lists as affected: the list is loaded and nothing turns checking on. The second is the same function in the v6.1.1 tag, which adds the flag call. A defender with source can search a build for the call.

    if (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {
        store = SSL_CTX_get_cert_store(sslctx);
        if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {
            error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);
            sslClose();
            return -1;
        }
    }

    if (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {
        store = SSL_CTX_get_cert_store(sslctx);
        if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {
            error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);
            sslClose();
            return -1;
        }
        /*
            Enable CRL checking on the leaf certificate. Without this flag OpenSSL loads the CRL but
            never consults it, silently accepting revoked client certificates.
         */
        X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);
    }

The advisory prints what a reporter's verify callback logged for a revoked certificate against a vulnerable build. The revoked error never appears, which is the sign of the flaw.

VERIFY_CB: preverify_ok=1 error=0(ok) depth=1
VERIFY_CB: preverify_ok=1 error=0(ok) depth=0
X509_V_ERR_CERT_REVOKED never fires.

The decryption code. The first line is the mbedTLS call in v6.1.0, with the generator's size passed as the prime's length. The second is the v6.1.1 line. Below them is what the advisory says goes on the wire.

    if ((rc = mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))) < 0) {

    if ((rc = mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))) < 0) {

ServerKeyExchange.params:
    P_len = 1
    P     = 0xFF
    G_len = 1
    G     = 0x02
    Y_len = 1
    Y     = g^x mod P, where x is the server's per-handshake DH exponent

The chain depth guard, v6.1.0 and v6.1.1. The old guard only applied when no earlier error was recorded. The fix rejects an over deep chain unconditionally.

    if (ok && VERIFY_DEPTH < depth) {
        if (error == 0) {
            error = X509_V_ERR_CERT_CHAIN_TOO_LONG;
        }
    }

    if (VERIFY_DEPTH < depth) {
        logmsg(3, "Certificate chain too long (depth %d exceeds limit %d)", depth, VERIFY_DEPTH);
        trace(4, "OpenSSL: Issuer: %s", issuer);
        trace(4, "OpenSSL: Peer: %s", peer);
        return 0;
    }

The scores as printed on the advisory pages, so a defender can feed the same vectors to a scoring tool. They are the vendor's, not NVD's.

GHSA-5m75-xq69-c3c5  9.1  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N  CVE-2026-115881
GHSA-fmvx-2xfx-2gq4  5.9  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N  No known CVE
GHSA-r392-vqwx-3r4g  7.4  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N  CVE-2026-115884

Two checks for a defender, both derived by this site and neither published by Embedthis. The first lists the entries in a deployment's own CRL, with dates, so the revoked and unexpired certificates can be identified. The second is a client test of the server's offered group against your own device only: the advisory says OpenSSL's s_client "rejects the truncated group with DH_check_params_ex: modulus too small", so a refusal with that text would point at an affected build. This site did not run either command, and the advisory does not say they are a reliable detector.

openssl crl -in YOUR_CRL.pem -noout -text
openssl s_client -connect YOUR_DEVICE:443 -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384

What to do, in the order worth doing

Where GoAhead is embedded, the operator rarely compiled it. These steps start with finding it, because the advisories name only the software, not the devices.

What could not be verified

• The Hacker News article. It returned a bot check to a script, so it was not read. The briefing rests on the vendor's advisories and release notes instead.
• CVE records. CVE.org's record service returned no record for CVE-2026-115880, 115881, 115882, 115884 or 115888, and NVD returned no results for 115881 and 115884. NVD was not queried for the other three.
• The fix commit. The DH advisory cites commit 4421c113. That address returned a not found response on GitHub, and the v6.1.1 tag points to a commit titled "remove internal references from the published tree". The fix was confirmed by reading the tagged source files instead.
• Exploitation, exposure and embedding vendors. None is stated in any primary read.
• Whether the earlier lines are fixed. Not stated for versions before 6.1.1 other than 6.1.0.
• The advisory's capture claim. The five iterations the reporter needed are the advisory's statement. No capture or decryption was run here.
• Time stamped. Sources were read between 21:30 and 21:47 UTC on 27 October 2026. A CVE record, a KEV entry or a supplier statement could appear within hours.

The question that exposes the gap

When you revoked a device's certificate, did you ever try to connect with it afterwards, or did you take the loaded revocation list as proof that it was refused?

Key facts