Released binaries are built with Go 1.27.2, shipping CVE-2026-111943 (crypto/x509 distrusted intermediates) fixed in Go 1.27.3 #526

Summary

Both Go binaries shipped in the v1.5.29 .deb package (aikido-agent and aikido-request-processor.so) are compiled with Go 1.27.2. On 2026-10-20 the Go team shipped Go 1.27.3 and 1.26.10 on the URGENT security track to fix CVE-2026-111943 (GO-2026-6809, golang/go#82345): crypto/x509 now refuses chains that go through a small set of distrusted intermediate certificates. Go 1.27.2 is in the affected range.

No published release avoids it: v1.5.29 is the latest, and main still carries toolchain go1.27.2 in both go.mod files.

On timing, again nobody's oversight: v1.5.29 was cut from a commit made on 2026-10-15 at 15:08 UTC, Go 1.27.3 was tagged on 2026-10-20 at 01:26 UTC, and the advisory reached the Go vulnerability database on 2026-10-21 at 00:27 UTC. This is the situation of #450 and #519 one more time.

Evidence

Read from the shipped binaries, not from go.mod:

$ V=1.5.29
$ curl -sL -o zen.deb "https://github.com/AikidoSec/firewall-php/releases/download/v${V}/aikido-php-firewall.x86_64.deb"
$ ar x zen.deb && tar xzf data.tar.gz
$ for B in aikido-agent aikido-request-processor.so; do
    strings -a opt/aikido-${V}/$B | grep -oE '^go1\.[0-9]+\.[0-9]+$' | sort -u
    strings -a opt/aikido-${V}/$B | grep -oE 'golang.org/toolchain@v0.0.1-go[0-9.]+' | sort -u
  done

aikido-agent                : go1.27.2   golang.org/toolchain@v0.0.1-go1.27.2
aikido-request-processor.so : go1.27.2   golang.org/toolchain@v0.0.1-go1.27.2

An OSV query for the Go stdlib package returns GO-2026-6809 as the only entry at version 1.27.2, and nothing at 1.27.3. The golang.org/x/net v0.60.0 and google.golang.org/grpc v1.84.0 embedded in the agent have no open advisory.

Advisory

The RustSec aliases of the same advisory (RUSTSEC-2026-0381 to 0383) identify the intermediates as emSign ones whose private keys are now well known. Mozilla removed emSign ECC Root CA - G3 from its root store (bug 2083449).

Exposure

Unlike the advisories in #450 and #519, this one targets code that Zen actually runs:

• the agent's two outbound clients to the Aikido cloud (lib/agent/cloud/event.go, http.Client with default transport, and configStreamClient in lib/agent/cloud/sse.go) use no custom tls.Config, so server certificates are checked by (*Certificate).Verify against the host's system roots. These requests carry the AIKIDO_TOKEN in the Authorization header and bring back the blocking configuration
• crypto/x509.(*Certificate).Verify, crypto/tls.(*Conn).verifyServerCertificate and crypto/tls.(*Conn).clientHandshake are present in the agent's .gopclntab
• aikido-request-processor.so links Verify too, but has no TLS client handshake and no net/http.(*Transport): it only talks to the agent over the unix socket, so it does not look reachable there

To be fair on severity: exploiting this needs both a certificate for the Aikido endpoints issued under one of these intermediates and an on-path position between the agent and the Aikido cloud. Whether a given host trusts the chain also depends on its CA bundle: on our base image (Debian trixie, ca-certificates 20250419+deb13u1) emSign ECC Root CA - G3 is absent, while hosts whose bundle tracks recent Mozilla releases may still carry it. The point of the Go fix is to make Zen independent of the host bundle, which a firewall agent deployed on many different distributions probably wants.

The current endpoints (guard.aikido.dev, runtime.aikido.dev) chain to Amazon RSA 2048 M01 and Amazon Root CA 1, so moving to Go 1.27.3 should not change anything for legitimate connections.

Suggested fix

1. Set toolchain go1.27.3 in lib/agent/go.mod and lib/request-processor/go.mod.
2. Cut a release.

Since #489 the toolchain directive makes the release toolchain explicit, which is what makes this a two-line change, thank you for that. It also means a Go security release only reaches Zen when someone edits those lines. A scheduled govulncheck run in CI (source mode, with call graph analysis) would turn the next one into a failing check on your side before it turns into findings on your customers' side.

Context

We are Aikido customers. The Aikido dashboard raised this on v1.5.29 as one stdlib group, severity high, with a 14 day SLA, on both binaries of our API image. The finding has no remediation advice attached, and none is possible on our side: the Go version is baked into the binaries at compile time, and v1.5.29 is the latest release. A rebuild upstream is the only thing that closes it.

Happy to test a release candidate on PHP 8.4 / Debian trixie if that helps.