Released binaries are built with Go 1.27.1 and x/net v0.59.0, shipping 13 known stdlib vulnerabilities fixed in Go 1.27.2 #519

Summary

Both Go binaries shipped in the v1.5.28 .deb package (aikido-agent and aikido-request-processor.so) are compiled with Go 1.27.1 and embed golang.org/x/net v0.59.0. The Go security release of 2026-10-08 published 13 stdlib advisories that affect Go 1.27.1, all fixed in Go 1.27.2. Five of them also affect golang.org/x/net below v0.60.0.

No published release avoids them: v1.5.26 is built with Go 1.26.8 (same advisories, fixed in 1.26.9), v1.5.27 and v1.5.28 are built with Go 1.27.1.

To be clear on timing, this is nobody's oversight: v1.5.28 was cut from a commit made on 2026-10-08 at 15:05 UTC, and the advisories landed in the Go vulnerability database the same day at 22:31 UTC. The release simply crossed the Go security release. This is the situation of #450 again, one toolchain later.

Evidence

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

$ for V in 1.5.26 1.5.27 1.5.28; do
    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 -E '^dep\s+golang\.org/x/net' | sort -u
    done
  done

v1.5.26  aikido-agent                : go1.26.8   golang.org/x/net v0.58.0
v1.5.26  aikido-request-processor.so : go1.26.8   golang.org/x/net v0.58.0
v1.5.27  aikido-agent                : go1.27.1   golang.org/x/net v0.59.0
v1.5.27  aikido-request-processor.so : go1.27.1   golang.org/x/net v0.59.0
v1.5.28  aikido-agent                : go1.27.1   golang.org/x/net v0.59.0
v1.5.28  aikido-request-processor.so : go1.27.1   golang.org/x/net v0.59.0

Advisories affecting Go 1.27.1

Source: an OSV query for the Go stdlib package returns these 13 entries at version 1.27.1 and none at 1.27.2. The same query for golang.org/x/net returns the 5 marked entries at v0.59.0 and none at v0.60.0.

To be fair on severity: we matched each advisory against the Zen sources and against the function names left in .gopclntab of the v1.5.26 and v1.5.28 binaries. None of them looks exploitable through Zen as it is written today:

• no net/http server and no TLS server are linked into either binary. The only listener is the gRPC unix socket, served by grpc-go's own transport
• the vulnerable x/net/http2 server and transport are not linked either, only Framer and hpack, which grpc-go pulls in
• CVE-2026-56857 is Windows only
• the outbound net/http client exists in the agent only, and talks to the Aikido endpoints over verified TLS
• mime/multipart.(*Reader).ReadForm and html/template are linked, apparently through the debug handlers that golang.org/x/net/trace registers on the default mux, but with no HTTP server nothing can call them

So this is not a live exploit report. It is still a supply chain problem: the vulnerable versions are present in binaries that sit inline on every request, and every customer scanner flags them, the Aikido dashboard included.

Where it comes from

Since v1.5.27 (#489), lib/agent/go.mod and lib/request-processor/go.mod both carry toolchain go1.27.1, so the release toolchain is now explicit: the binaries embed the path golang.org/toolchain@v0.0.1-go1.27.1.linux-amd64. That closed the silent drift described in #450, thank you for that.

The flip side is that the directive only moves when someone edits it. The two autofix PRs opened on 2026-10-10, #517 and #518, bump golang.org/x/net to v0.60.0 and leave the toolchain line untouched. A release cut from those two PRs alone would clear the x/net findings and still ship Go 1.27.1 with the 13 stdlib advisories.

Suggested fix

1. Set toolchain go1.27.2 in lib/agent/go.mod and lib/request-processor/go.mod.
2. Merge [Aikido] Fix security issue in x/net via minor version upgrade from 0.59.0 to 0.60.0 in lib #517 and [Aikido] Fix security issue in x/net via minor version upgrade from 0.59.0 to 0.60.0 in lib #518, or bump golang.org/x/net to v0.60.0 in the same change.
3. Cut a release.
4. Longer term, have the toolchain directive tracked the same way module versions are, or run govulncheck in CI as suggested in Released binaries are built with Go 1.26.5, shipping 8 known stdlib vulnerabilities (one critical) #450, so that a Go security release shows up as a failing check on your side before it shows up as findings on your customers' side.

Possibly related, not verified: .github/workflows/Dockerfile.build-libs-alpine declares its own ARG GO_VERSION=1.26.8, used to bootstrap the custom toolchain. We only run the .deb, so we have not analysed the Alpine packages.

Context

We are Aikido customers, and this was raised to us by the Aikido dashboard itself on v1.5.26: one group on stdlib (20 findings, 10 CVEs on 2 binaries) and one on golang.org/x/net (8 findings), both critical, with a 3 day SLA on CVE-2026-56857 and CVE-2026-78663. The remediation advice attached to the findings suggests rebuilding on a newer OS base image, which cannot help here, since the Go version is baked into a third party binary at compile time.

So on our side there is nothing to fix and no version to upgrade to: moving from v1.5.26 to v1.5.28 would keep both groups open. We are opening this here because 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.