Security: Docker image contains Go binary vulnerable to CVE-2025-68121 (crypto/tls, CVSS 10.0)

[jsell-rh]

DISCLAIMER: Created by Claude Sonnet 4.5

Summary

The apache/age Docker images (including release_PG18_1.7.0, the latest release) are being flagged by container scanners for CVE-2025-68121, a critical vulnerability (CVSS 10.0) in Go's crypto/tls standard library.

CVE Details

CVE-2025-68121 — Go crypto/tls session resumption auth bypass

During TLS session resumption, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial and resumed handshake, the resumed handshake may succeed when it should have failed. This can allow certificate validation to be bypassed.

• CVSS: 10.0 (Critical)
• Fixed in: Go 1.24.13, Go 1.25.7, Go 1.26.0+
• Published: 2026-02-05

Impact on apache/age Images

While Apache AGE is a C/SQL PostgreSQL extension, the Docker image ships with one or more Go-compiled binaries built against a vulnerable version of Go (< 1.24.13). Container scanners (Trivy, Docker Scout, etc.) detect the vulnerable Go build metadata embedded in the image and flag it.

Requested Fix

Please rebuild and publish updated Docker images compiled against Go ≥ 1.24.13 (or ≥ 1.25.7 if on the 1.25 series).

References

• NVD - CVE-2025-68121
• Go issue tracker
• Docker Scout advisory

[jrgemignani]

@jsell-rh

Analysis from Opus 4.6 -

Issue #2357 Analysis: CVE-2025-68121 in AGE Docker Images

Is it Valid?
Technically valid, but the issue significantly overstates the severity.

The CVE is real (CVE-2025-68121), but there are critical inaccuracies in the issue:

1. CVSS is NOT 10.0 — The GitHub Advisory Database rates it Moderate 4.8/10 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
2. The vulnerable binary is gosu — a privilege-dropping tool in the upstream postgres:18 base image, built with Go 1.24.6. The fix requires Go >= 1.24.13.
3. gosu never uses TLS — It's a simple setuid helper (gosu postgres command). Even though crypto/tls is statically linked in the Go binary (confirmed via strings), gosu's code path never invokes TLS. The CVE requires active TLS session resumption with mutated CA pools — something gosu categorically does not do.
4. This is NOT an AGE issue — AGE is a pure C PostgreSQL extension. The AGE Dockerfiles don't install Go or any Go tools. The vulnerability comes entirely from the upstream postgres:18 base image maintained by the Docker Library team.
   The CVE is real (CVE-2025-68121), but there are critical inaccuracies in the issue -

CVE-2025-68121 requires:

1. Active TLS session resumption
2. Mutation of ClientCAs or RootCAs between initial and resumed handshake
3. Use of Config.Clone or Config.GetConfigForClient

None of these conditions can occur in gosu. The binary drops privileges and execs — it performs no network operations whatsoever.

Summary

Factor	Assessment
CVE is real	✅ Yes
Actual CVSS	4.8 (Moderate), not 10.0
Vulnerable binary	gosu in upstream postgres:18 base image
Introduced by AGE	❌ No — upstream dependency
Exploitable in this context	❌ No — gosu does not use TLS
Scanner flagging	✅ Expected — scanners detect Go build metadata

Recommendation

This is an upstream base image issue. The fix will come when either:

1. The postgres:18 Docker image is rebuilt with an updated gosu (compiled against Go ≥ 1.24.13), or
2. The gosu project releases a new version built with a patched Go toolchain

No changes to the Apache AGE codebase or Dockerfiles are required. Rebuilding AGE Docker images against the latest postgres:18 base will pick up the fix once it's available upstream.

[jrgemignani]

@jsell-rh Opus did suggest another option. However, it is not without its own issues -

Option B (Proactive): Modify the AGE Dockerfile to rebuild gosu from source with Go 1.24.13 (available now). This silences scanners but adds build complexity for a non-exploitable issue.

Reasons NOT to Do This

1. The CVE is not exploitable here — gosu never performs TLS. This is purely cosmetic scanner appeasement. The actual risk is zero.
2. The issue itself is misleading — The CVSS is 4.8, not 10.0, and is unreviewed.
3. It's the upstream's responsibility — The postgres:18 image is maintained by the Docker Library team. Every project that uses postgres:18 as a base has this same "issue." The fix belongs upstream, not in every downstream consumer.
4. Maintenance burden — Someone has to remember to revert this once upstream catches up. In practice, these "temporary" workarounds tend to persist indefinitely.
5. Non-reproducible builds — The @latest tag means the same Dockerfile can produce different results on different days.