Problem Statement/Rationale

mongo-tools carries an indirect dependency on github.com/aws/aws-sdk-go v1 (currently pinned at v1.53.11). The AWS SDK for Go v1 reached end-of-life on July 31, 2025 and will no longer receive security patches.

This means two known CVEs will remain permanently unpatched in this dependency, and any future vulnerabilities discovered in v1 will also go unaddressed:

• CVE-2020-8911 - Padding oracle vulnerability in the AWS S3 Crypto SDK. Allows attackers with write access to an S3 bucket to exploit AES-CBC encryption when MAC validation is absent.
• CVE-2020-8912 - In-band key negotiation vulnerability in the S3 Crypto SDK. Enables encryption algorithm downgrade attacks (AES-GCM to AES-CTR) for attackers with bucket write access.

Because the v1 SDK is vendored into the mongo-tools repository and recorded in go.sum, every project that imports mongo-tools as a Go module inherits this transitive dependency. Security scanners (Trivy, Snyk, Dependabot, govulncheck, etc.) flag it, and there is nothing downstream consumers can do to resolve the finding - it must be fixed at the source.

How aws-sdk-go v1 ends up in the dependency tree

mongo-tools depends on the task runner github.com/craiggwilson/goke. Within that library, the file pkg/sh/net.go imports aws-sdk-go v1 to implement S3 helper functions.

The full dependency chain is:

github.com/mongodb/mongo-tools
  └─ github.com/craiggwilson/goke (direct, used in buildscript/)
       └─ goke/pkg/sh/net.go
            └─ github.com/aws/aws-sdk-go v1 (for S3 operations)

Critically, mongo-tools itself never calls any of the S3 functions from goke/pkg/sh. It only uses sh.Run, sh.RunOutput, and sh.RunCmd - simple command-execution helpers. The entire aws-sdk-go v1 tree is pulled in solely because Go's module system resolves dependencies at the package level, and goke/pkg/sh bundles S3 functionality alongside shell helpers in the same package.

Impact on downstream projects

Any Go project that depends on mongo-tools (directly or transitively) inherits this vulnerability finding. Known affected downstream consumers include, but are not limited to:

• github.com/percona/mongodb_exporter
• github.com/grafana/alloy

These projects have no way to suppress or override the transitive dependency - the fix must come from mongo-tools.

Why this matters even though mongo-tools doesn't use the vulnerable code

1. Security compliance. Many organizations enforce a zero-known-CVE policy on all dependencies in go.sum, regardless of whether the vulnerable code path is reachable. Vendored dependencies with known CVEs can block releases, fail audits, and require costly exception processes.

2. Transitive blast radius. mongo-tools is a widely-imported module. Every downstream consumer inherits this finding and cannot fix it independently.

3. Permanently unpatched. Unlike an active library where a fix might arrive eventually, v1 is EOL. These CVEs will remain flagged indefinitely until the dependency is removed.

Suggested resolution

Since mongo-tools does not use any S3 functionality from goke, the cleanest path is to eliminate the dependency chain that pulls in aws-sdk-go v1.

As goke appears to be a low-activity project maintained by a single author, and mongo-tools only uses a small subset of its functionality (sh.Run, sh.RunOutput, sh.RunCmd, and task.Context), it may be practical to fork goke with the S3 code removed, or to replace the dependency with a lightweight internal package.