EmbedThis GoAhead is an embeddable web server available under GPL or commercial license (see https://github.com/embedthis/goahead ).

It can be compiled against a choice of TLS backends.

https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead discloses vulnerabilities in the GoAhead code for three of those backends: OpenSSL, LibreSSL, and Mbed TLS.

The TLDR section on that page says: GoAhead is used in hundreds of millions of IoT, Firewall, OT, and Military devices including those from Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin, Boeing, and more.

Three independent bugs in GoAhead's TLS integrations can leave revoked client certificates accepted, encrypted sessions recoverable to an observer or a configured chain-depth limit unenforced. Exposure depends on the TLS library and the verification settings built into the device:

OpenSSL-compatible backend - Critical, CVSS 9.1 - CRL loaded but not enforced, revoked client certificates are silently accepted. GOAHEAD-SA-2026-0006.

LibreSSL legacy verifier - High, CVSS 7.4 - An over-depth client chain is accepted when client certificates are required but issuer checking is disabled. This bypasses the chain-depth restriction. GOAHEAD-SA-2026-0004.

Mbed TLS - Medium, CVSS 5.9 - A buffer-length typo reduces a 2048-bit DH modulus to one byte. TLS 1.2 DHERSA sessions are decryptable when the client accepts the broken parameters. GOAHEAD-SA-2026-0005.

TLS build: OpenSSL-compatible backend GoAhead versions: >= 3.4.5, <= 6.1.0 Required configuration: mTLS enabled with a CRL configured. Revoked client certificates remain accepted even with issuer verification enabled. Fix or mitigation: Upgrade to 6.1.1 or later.

TLS build: Mbed TLS backend GoAhead versions: >= 4.0.2, <= 6.1.0 Required configuration: TLS 1.2 DHERSA negotiated with a client that accepts the broken DH parameters. Fix or mitigation: Upgrade to 6.1.1 or later, disable finite-field DHE suites, or use the OpenSSL backend.

TLS build: LibreSSL legacy verifier — 3.2.x or 3.3.2–3.3.6 GoAhead versions: <= 6.1.0 Required configuration: VERIFYPEER=1 and VERIFYISSUER=0. An over-depth client chain is accepted. Fix or mitigation: Enable VERIFYISSUER=1 with a trusted CA bundle, or use OpenSSL / LibreSSL 4.x. The web page then goes into much further detail I've not included here.

These seem to correspond to these GHSA advisories in their repo:

https://github.com/embedthis/goahead/security/advisories/GHSA-5m75-xq69-c3c5 OpenSSL CRL loaded but not enforced in GoAhead sslOpen() (src/openssl.c): revoked client certificates are silently accepted

https://github.com/embedthis/goahead/security/advisories/GHSA-fmvx-2xfx-2gq4 MbedTLS DH parameter truncation destroys forward secrecy: a length typo in sslOpen() (src/mbedtls.c) transmits a 1-byte DH modulus on TLS 1.2 DHE-RSA handshakes

https://github.com/embedthis/goahead/security/advisories/GHSA-r392-vqwx-3r4g mTLS client-certificate bypass: GoAhead's verifyClientCertificate() depth guard is skipped when the verifier reports a prior error, accepting an over-depth client chain on LibreSSL legacy-verifier builds

https://github.com/embedthis/goahead/security lists additional vulnerabilities fixed in their 6.1.1 release.

An issue was discovered in GoAhead 4.x and 5.x before 5.1.5. In the file upload filter, user form variables can be passed to CGI scripts without being prefixed with the CGI prefix. This permits tunneling untrusted environment variables into vulnerable CGI scripts.

An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. The server mishandles some HTTP request fields associated with time, which results in a NULL pointer dereference, as demonstrated by If-Modified-Since or If-Unmodified-Since with a month greater than 11.

EmbedThis GoAhead Webserver version 4.0.0 is vulnerable to a NULL pointer dereference in the CGI handler resulting in memory corruption or denial of service.

Embedthis GoAhead before 3.6.5 allows remote code execution if CGI is enabled and a CGI program is dynamically linked. This is a result of initializing the environment of forked CGI scripts using untrusted HTTP request parameters in the cgiHandler function in cgi.c. When combined with the glibc dynamic linker, this behaviour can be abused for remote code execution using special parameter names such as LDPRELOAD. An attacker can POST their shared object payload in the body of the request, and reference it using /proc/self/fd/0.

A vulnerability in a custom-built GoAhead web server used on Foscam, Vstarcam, and multiple white-label IP camera models allows an attacker to craft a malformed HTTP ("GET system.ini HTTP/1.1\n\n" - note the lack of "/" in the path field of the request) request that will disclose the configuration file with the login password.

A command-injection vulnerability exists in a web application on a custom-built GoAhead web server used on Foscam, Vstarcam, and multiple white-label IP camera models. The mail-sending form in the mail.htm page allows an attacker to inject a command into the receiver1 field in the form; it will be executed with root privileges.

EmbedThis GoAhead 3.0.0 through 3.4.1 does not properly handle path segments starting with a . (dot), which allows remote attackers to conduct directory traversal attacks, cause a denial of service (heap-based buffer overflow and crash), or possibly execute arbitrary code via a crafted URI.