GoAhead Web Server Flaws Put Smart City Devices at Risk
A hidden web server inside city cameras, switches, gateways and building controllers has new security flaws, and most smart city control rooms and SPVs cannot tell which of their devices carry it until each vendor answers
This post argues that the GoAhead flaws disclosed this week are a smart city problem first: they test whether an ICCC, an SPV or a building owner knows what software runs inside the cameras, network switches, gateways and controllers it already operates, not how fast it patches. GoAhead is a small web server that device makers compile into the management pages of routers, switches, gateways, printers and industrial controls, and it is deployed in what its maker calls “hundreds of millions of devices”.[7] Its latest release fixes a critical bug that lets revoked client certificates back in.[1][5] An ICCC or a building’s asset list names the camera, switch or controller by brand and model. It does not name the web server inside the firmware, so no owner can tell whether a site is exposed until each vendor answers. CERT-In has already asked smart cities to make a software bill of materials (SBOM) part of procurement.[13] GoAhead shows why that request needs a deadline and a named format in the contract.
We make no claim that any Indian city, building or vendor runs an affected GoAhead build. The researchers have not said which products are affected, and neither have the device makers.[2][3]
The worst of three bugs lets a lost or retired device’s certificate keep working
Sébastien Féry of FoxIO published the details on 26 October. Each bug sits in the way GoAhead connects to a different TLS library, so which devices are exposed depends on the library the manufacturer compiled in and how it set up certificate checks.[1][2]
| TLS library compiled in | GoAhead versions | When it bites | Rating | Fix or interim step |
|---|---|---|---|---|
| OpenSSL or compatible (the default) | 3.4.5 to 6.1.0 | Mutual TLS on, with a revocation list configured: revoked client certificates are still accepted | Critical, 9.1 (CVE-2026-115881) | Upgrade to 6.1.1 [1][5] |
| LibreSSL legacy verifier (3.2.x, 3.3.2 to 3.3.6) | Up to 6.1.0 | Client certificates required but issuer checking off: an over-long certificate chain is accepted | High, 7.4 (CVE-2026-115884) | Turn on issuer checking with a trusted CA bundle, or move to OpenSSL or LibreSSL 4.x [1] |
| Mbed TLS | 4.0.2 to 6.1.0 | TLS 1.2 DHE_RSA with a client that accepts a one-byte Diffie-Hellman value: recorded sessions can be decrypted | Medium, 5.9 (no CVE) | Upgrade to 6.1.1, or disable finite-field DHE suites [1][6] |
The critical one matters most for systems that authenticate devices or users with client certificates, an approach some IoT gateways and device-to-device links use. GoAhead’s advisory says the OpenSSL backend loads the configured certificate revocation list but never sets the flag that tells OpenSSL to consult it, so a stolen or decommissioned device’s certificate “completes the mutual-TLS handshake exactly as if it had never been revoked”. Startup shows no warning.[5] The default build does not enable mutual TLS, so only deployments that deliberately turned it on are affected, but those are precisely the operators who expected revocation to work.[5]
Readers of our eMudhra certificate report will recognise the pattern. There, revoked certificates kept working because common clients do not check revocation by default. Here, the check was configured and still never ran.
A city cannot install the fix itself; it arrives only in each vendor’s firmware
EmbedThis released GoAhead 6.1.1 to device builders on 2 August 2026 and published the advisories on 12 October.[4][2] The release notes list eleven advisory fixes in all, including a critical password bypass for users whose passwords are stored as Blowfish hashes, CGI injection and several HTTP request-smuggling defects.[4] The Hacker News reported that EmbedThis notifies customers through its Builder portal, and that as of 27 October no source had reported the flaws being used in attacks.[3]
A city cannot install 6.1.1 itself. FoxIO’s John Althouse put it plainly: an upstream fix “doesn’t mean there’s a patch available for the devices yet — that’s up to the manufacturer”.[2] FoxIO named Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin and Boeing among companies whose devices use GoAhead, without saying which products, if any, use a vulnerable configuration.[1][2]
Earlier GoAhead bugs took more than three years to reach industrial vendors’ advisories
GoAhead has been here before. The table below sets the upstream fix against the dates when two industrial vendors’ advisories appeared on CISA’s site. It shows how long a device can carry a known web-server flaw, not how fast any particular vendor patches today.
| GoAhead flaw | Fixed upstream | Made public | Later vendor advisory on CISA’s site |
|---|---|---|---|
| CVE-2017-17562: remote code execution through CGI | GoAhead 3.6.5 [8] | December 2017 [8] | GE MDS industrial radios, ICSA-22-090-06, 2022 [9]. CISA had added the flaw to its Known Exploited Vulnerabilities catalogue on 10 December 2021 [8] |
| CVE-2019-5096: use-after-free, code execution, CVSS 9.8 | Vendor patched 21 November 2019 [10] | 2 December 2019 [10] | Rockwell Automation network and controller modules, ICSA-23-026-06, 26 January 2023 [11] |
| CVE-2026-115881 and two related TLS bugs | GoAhead 6.1.1, 2 August 2026 [4] | Advisories 12 October 2026; write-up 26 October 2026 [1][4] | None identified for a named vendor in the sources we read, as of 29 October 2026 [2][3] |
In the Rockwell case, the company told CISA that the listed devices “may use a version of GoAhead web server with publicly known vulnerabilities”.[11] That “may” is the point: three years after the fix, even the manufacturer was describing its exposure in conditional terms. A city that relies on brand-level asset lists inherits that uncertainty, and has no way to judge it.
CERT-In already asks smart cities for SBOMs; GoAhead shows which fields they must include
CERT-In’s Cyber Security Guidelines for Smart City Infrastructure (February 2025) encourage departments and organisations in smart cities “to make the creation and provision of SBOM a mandatory standard practice as part of software procurement”.[13] CERT-In’s SBOM technical guidelines (version 2.0) go further: government, public sector and essential services organisations should include SBOM requirements in all software and solutions procurement, and security teams should put the SBOM inventory into their vulnerability-management workflow.[12]
The same guidelines recommend requiring SBOMs “in purchase orders or contracts, specifying SBOM elements, delivery timeframe, and delivery method”.[12] Their minimum data fields include component name, version, supplier, dependencies, patch status and end-of-life date.[12] For GoAhead, the dependency field is the one that matters: the useful answer is not just “GoAhead 6.1.0” but which TLS library it is built against, because that decides which of the three bugs apply.[1] The guidelines also describe a Vulnerability Exploitability eXchange (VEX) statement, in which the supplier says whether a product is not affected, affected, fixed or under investigation.[12] That four-way answer is exactly what an SPV needs from each vendor this week.
Four questions every SPV should send the vendors behind its control room and building network
Send these to each OEM and system integrator whose equipment has a web management page: network switches, IoT and BMS gateways, NVRs and cameras, UPS and power monitoring cards, access-control panels and video-wall controllers. Write the answers into the asset register, against each model and firmware version.
- Does this firmware include GoAhead, and which version? Ask for the answer in writing, per model, and for the SBOM itself if the vendor has one.[12]
- Which TLS library is it built with, and is mutual TLS or a revocation list configured? The answer decides whether the 9.1, 7.4 or 5.9 rated bug applies, or none.[1]
- What is the status: not affected, affected, fixed or under investigation? These are the VEX categories in CERT-In’s guidelines; ask for a date for anything “under investigation”.[12]
- When will firmware built on GoAhead 6.1.1 be released, and who installs it? Until then, keep management pages off the internet and the business network, allow access only from a jump host, and where a device relies on client certificates, remove a lost device’s access on the device itself rather than relying on revocation alone.
For new tenders, turn the same questions into a clause: the SBOM at handover and with each firmware release, a VEX statement within a fixed number of days of a public advisory, and both treated as O&M deliverables. Our guide to cyber security OEMs matched to the layer covers which vendors serve devices and networks, and how to design a BMS for a control room shows where these management interfaces sit. The control rooms guide explains how ICCC feeds are integrated.
Planning a command and control centre? Talk to Trisim Global Solutions.
Trisim’s view: smart city handover files need a component list, not just brand names
A device register that stops at the brand name can only wait for vendors to speak. Asking for the SBOM at handover, and a VEX answer within days of each advisory, turns this week’s round of vendor emails into a simple lookup.
Sources
- FoxIO (Sébastien Féry), Choose Your Backend: Three TLS Bugs in GoAhead, 26 October 2026
- SecurityWeek (Eduard Kovacs), TLS Flaws Found in GoAhead Web Server Used in Hundreds of Millions of Devices, 28 October 2026
- The Hacker News, GoAhead TLS Flaws Allow Revoked Client Certificates and Enable Session Decryption, October 2026
- EmbedThis (GitHub), GoAhead v6.1.1 Release Notes, released 2 August 2026, advisories published 12 October 2026
- EmbedThis (GitHub advisory GHSA-5m75-xq69-c3c5), OpenSSL CRL loaded but not enforced in GoAhead sslOpen(): revoked client certificates are silently accepted, 12 October 2026
- oss-security mailing list (Alan Coopersmith), Three TLS Bugs in GoAhead web server prior to 6.1.1, 27 October 2026
- EmbedThis, GoAhead Embedded Web Server, accessed 29 October 2026
- NIST National Vulnerability Database, CVE-2017-17562 Detail, published 12 December 2017
- CISA, ICSA-22-090-06: General Electric Renewable Energy MDS Radios, 2022, last revised 27 May 2022
- Cisco Talos, TALOS-2019-0888: EmbedThis GoAhead web server code execution vulnerability, 2 December 2019
- CISA, ICSA-23-026-06: Rockwell Automation products using GoAhead Web Server, 26 January 2023
- CERT-In, Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (CISG-2024-02), version dated 9 July 2025
- CERT-In, Cyber Security Guidelines for Smart City Infrastructure, February 2025