GoAhead is a small embedded web server from Embedthis. You won't have installed it on purpose, but you've almost certainly used it: it powers the admin pages and APIs of routers, printers, cameras, network appliances, and industrial control equipment. Embedthis says it's deployed in hundreds of millions of devices.

On October 12, 2026, Embedthis published three security advisories for GoAhead, all found by Sébastien Féry of FoxIO. FoxIO followed with a detailed research write-up later in October. All three bugs are about TLS: how the server checks client certificates in mutual TLS (mTLS), and how it protects traffic on one older type of connection.

The fix is GoAhead 6.1.1. The catch is that GoAhead is a library that manufacturers compile into their firmware. A fixed GoAhead release doesn't fix the device on your network. That only happens when the manufacturer ships updated firmware.

🛑Editorial note: This write-up is for defenders. We don't publish proof-of-concept code, handshake details, or targeting information. Everything here is about working out whether you're exposed and reducing the risk until firmware arrives.

The short version

BugSeverityAffectsOnly matters if
Revoked client certificates still accepted (CVE-2026-115881)Critical, CVSS 9.1GoAhead 3.4.5–6.1.0, OpenSSL backendThe device uses mTLS and relies on a revocation list (CRL)
mTLS client certificate check bypass (CVE-2026-115884)High, CVSS 7.4GoAhead 6.1.0 and earlier, linked to LibreSSL 3.2.x or 3.3.2–3.3.6The device uses mTLS with issuer checking turned off
Broken Diffie-Hellman parameters (no CVE)Medium, CVSS 5.9GoAhead 4.0.2–6.1.0, Mbed TLS backendA TLS 1.2 DHE-RSA connection is made by a client that doesn't reject the bad parameters

Fixed in: GoAhead 6.1.1. Exploited? No exploitation had been reported as of October 27, 2026, but FoxIO has published research code, so expect that to change.

Why this got so much attention

The researchers' announcement listed a striking set of brand names, including Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin, and Boeing. Those names come from Embedthis's list of organizations that use GoAhead.

That's an important distinction. Using GoAhead isn't the same as being vulnerable. Each bug needs a specific TLS library and a specific configuration:

As of this writing, none of the named vendors has confirmed shipping an affected configuration or published an advisory referencing these bugs. That may change quickly. The right reaction isn't panic. It's an inventory, followed by pressure on your vendors.

That said, the stakes are real. Devices like these sit in water systems, power utilities, factories, and defense networks, and firmware updates for them are notoriously slow. Some will never be patched.

The three bugs, in plain English

1. Revoked client certificates still work (CVE-2026-115881)

The idea behind mTLS. With mutual TLS, a device doesn't just prove its identity to you. You prove yours to the device by presenting a client certificate. If a laptop is stolen or an operator leaves, you revoke that certificate and publish it on a certificate revocation list (CRL). The device is supposed to check the list and refuse revoked certificates.

What goes wrong. In GoAhead's OpenSSL backend, the server loads the CRL file but never turns on revocation checking. The load succeeds and nothing logs an error, so everything looks fine. Revoked certificates keep working anyway.

Who's exposed. GoAhead 3.4.5 through 6.1.0, built with OpenSSL, with mTLS enabled, issuer checking on, and a CRL configured. The attacker needs a certificate that was once legitimately issued and has since been revoked, such as one taken from a stolen or compromised device.

Why it's rated critical. Revocation is often the only way to cut off a lost credential. If your incident response plan says "revoke the certificate," that step does nothing on affected devices.

2. mTLS can be bypassed on some LibreSSL builds (CVE-2026-115884)

What goes wrong. GoAhead limits how long a client's certificate chain can be. On certain LibreSSL versions, a quirk in how errors are reported means GoAhead skips that check. In the vulnerable configuration, a client can get past mTLS without any trusted certificate at all.

Who's exposed. GoAhead 6.1.0 and earlier, linked against LibreSSL 3.2.x or 3.3.2 through 3.3.6, with mTLS enabled and issuer checking turned off. Builds that use OpenSSL, BoringSSL, AWS-LC, Mbed TLS, or LibreSSL 4.x aren't affected, and neither are builds with issuer checking on.

Why it matters. It's a narrow configuration, but it's a complete bypass. If a device in that configuration is reachable from the internet and you're counting on mTLS to keep strangers out, it isn't.

3. Weak Diffie-Hellman keys on Mbed TLS builds (no CVE)

The idea behind DHE. In a "DHE" TLS 1.2 connection, the client and server agree on a fresh secret key using Diffie-Hellman. That's what gives the connection forward secrecy: even someone recording all the traffic can't decrypt it later.

What goes wrong. A size typo in GoAhead's Mbed TLS code means the server sends a Diffie-Hellman group that's one byte long instead of the intended 2,048 bits. A key agreed on such a tiny group gives no real protection. Someone who can simply watch the network can recover the session key and read the traffic, including login credentials and session tokens.

Who's exposed. GoAhead 4.0.2 through 6.1.0, built with Mbed TLS, on TLS 1.2 connections that use a TLS_DHE_RSA_* cipher suite, where the client accepts the broken parameters. TLS 1.3 and ECDHE cipher suites aren't affected. Mainstream browsers and common TLS libraries reject the parameters and pick a different cipher, so the realistic risk is from embedded clients, legacy software, management tools, and custom scripts or collectors that don't check the group size. Machine-to-machine traffic in OT and IoT networks is exactly where those clients live.

Am I affected?

Work through these questions for each device type that has a web admin page or HTTPS API:

  1. Does it run GoAhead? Check the vendor's documentation, software bill of materials (SBOM), or open-source license notices, which often list bundled components. HTTP server headers sometimes say so too, but many vendors change or hide them.
  2. Which version and TLS library? Anything before 6.1.1 is in scope. The TLS library (OpenSSL, LibreSSL, or Mbed TLS) decides which bugs apply. Your vendor should be able to tell you.
  3. Do you use mTLS on it? If you don't use client certificates with the device, the two mTLS bugs don't apply.
  4. Do you rely on a CRL? If you revoke client certificates and expect the device to honor that, bug 1 is your priority.
  5. Which clients talk to it, and how? For Mbed TLS builds, look for older or embedded clients making TLS 1.2 connections. A TLS scanner or your network monitoring can show which cipher suites are actually negotiated with the device.
  6. Is it reachable from the internet? Exposure scanners and your own perimeter scans will show this. Internet-facing management interfaces are the highest priority.

What to do now

💡Priority order: internet-facing devices first, then devices protected by mTLS, then everything else on flat or shared networks.
  1. Ask your vendors directly. Ask whether their products embed GoAhead, which version and TLS library they use, and when firmware with GoAhead 6.1.1 will ship. Get the answer in writing. For critical infrastructure, use your support contract or account team, not a general inbox.
  2. Get management interfaces off the internet. No device's admin page should be reachable from the public internet. Put it behind a VPN, a jump host, or an authenticating gateway. This mitigates all three bugs for outside attackers, whatever the device's patch status.
  3. Segment the network. Put OT and IoT devices on their own network segments and allow only the hosts that need to manage them. The DHE bug needs someone who can watch traffic, and segmentation limits who that can be.
  4. Don't rely on mTLS alone. Until devices are patched, treat mTLS on affected builds as one layer, not the only one. Add network allow lists and, where the device supports it, a separate login.
  5. Treat revocation as broken on OpenSSL builds. If a client certificate is lost or compromised, revoking it isn't enough. Rotate the issuing CA or the device's trusted certificate store, or block the client at the network level.
  6. Turn off finite-field DHE cipher suites on Mbed TLS builds if the device lets you, so connections use ECDHE or TLS 1.3 instead. Prefer TLS 1.3 wherever both ends support it.
  7. Update your clients. Make sure the tools and scripts that connect to these devices use a current TLS library that rejects weak Diffie-Hellman groups.
  8. Rotate credentials if you suspect exposure. If admin traffic to an affected Mbed TLS device has crossed a network you don't fully trust, change the device's admin passwords and API tokens and end active sessions.
  9. Apply firmware as it arrives, and track vendor advisories. CISA and national CERTs often publish ICS advisories for affected industrial products.

If you build products with GoAhead

  1. Upgrade to GoAhead 6.1.1 and ship firmware updates to your customers.
  2. Publish an advisory even if you're not affected. A clear "not affected, here's why" saves your customers a lot of work.
  3. Check your build options. Note which TLS backend you use and whether you enable client verification, issuer checking, and CRLs, and document it in your SBOM.
  4. Avoid end-of-life TLS libraries. The LibreSSL versions involved are old. Prefer a current, maintained TLS library.

Why this one matters

None of these bugs is in the TLS libraries themselves. They're in the small amount of code that connects GoAhead to them: a missing flag, a mishandled error code, a wrong size argument. Code like that is easy to get wrong, hard to notice, and copied into a huge number of products.

The bigger lesson is about patch distance. The fix is already out, but the devices that matter most, in utilities, factories, and defense networks, depend on manufacturers to ship firmware and on operators to install it. Many of those devices will run vulnerable code for years. The defenses that work regardless (inventory, segmentation, and keeping management interfaces off the internet) are the ones to invest in now.

If you're building these skills, our TryHackMe SOC Level 1 review and the ISC2 Certified in Cybersecurity review cover the defensive fundamentals behind this kind of triage.

Sources

This write-up was compiled from Embedthis's GoAhead security advisories and FoxIO's research, published in October 2026. Where secondary coverage made broader claims than the advisories, we've followed the advisories.

This is a developing story. We'll update this page as device manufacturers publish advisories.

← All Write-ups