Daily/weekly images for closing CVEs

[Ninos]

Current mongo:latest (1 months old) has some critical CVE's which should be fixed upstream:
https://hub.docker.com/layers/library/mongo/latest/images/sha256-3f04076470ff9110ce77473afe54c549feaca994a29bc5ff01a549bf340acf8c

Re-building mongo:latest every day/week should fix most of CVE's. In gitlab you can define scheduled pipelines, may you can use something like that also in github.

PS: If possible, please update also the go-packages, especially golang.org/x/crypto 0.25.0 (has also a critical cve). Tried to update with poetry & bazel for a MR to main repo, but seems not so easy (some dependency conflict)...

[LaurentGoderre]

Those are false positive. See https://github.com/tianon/gosu/blob/master/SECURITY.md

[yosifkit]

If there are any other updates from OS packages, they will be address at the next Dockerfile change (like version bump) or base image update.

Edit: for example, the CVE's existing in the base ubuntu:24.04 image would need to be addressed by a new, updated Ubuntu 24.04 image. Just rebuilding from the mongo Dockerfiles would be unlikely to affect any of them. It has been a month since the last Ubuntu image update, so I expect one very soon.

Background:

Tags in the [official-images] library file[s] are only built through an update to that library file or as a result of its base image being updated (ie, an image FROM debian:bullseye would be rebuilt when debian:bullseye is built).

-https://github.com/docker-library/official-images/tree/2f086314307c04e1de77f0a515f20671e60d40bb#library-definition-files

Official Images FAQ:

Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame

- https://github.com/docker-library/faq/tree/0ad5fd60288109c875a54a37f6581b2deaa836db#why-does-my-security-scanner-show-that-an-image-has-cves

To ensure that we don't push contentless image changes, we rely on periodic base image updates.

We strive to publish updated images at least monthly for Debian. We also rebuild earlier if there is a critical security need. Many Official Images are maintained by the community or their respective upstream projects, like Ubuntu, Alpine, and Oracle Linux, and are subject to their own maintenance schedule.

- from the same FAQ link

[bgehman]

Hi @yosifkit (or package maintainers) -- based on my analysis of the Crit/High CVEs found across all the (non-windows) Mongo official dockerhub images, practically all of the CVEs are coming from gosu, which is not a "base OS" package, but something being brought in by the mongo Dockerfiles directly. See: https://github.com/docker-library/mongo/blob/master/8.0/Dockerfile#L27

Related gosu tracking for the similar (from 2023): tianon/gosu#136

This can be fixed by Docker getting off any unsupported 3rd party tooling used during their image build processes..

latest CVE report for mongo:latest: https://hub.docker.com/layers/library/mongo/latest/images/sha256-0fbe569f105156a412dd7383afdc9d6a784c9acea1367663c384e5e98b2ecc2a

[tianon]

As soon as we finish playing whack-a-mole with gosu, we'll hit /usr/bin/bsondump (CVE-2025-30204, CVE-2025-22870, CVE-2025-22869, CVE-2025-22866), which exhibits the exact same problem (Go binary with "vulnerable" libraries that probably doesn't even use the vulnerable functions).

If you run govulncheck against /usr/local/bin/gosu in the current mongo:latest image, it'll come back with only GO-2023-1840 (aka CVE-2023-29403, https://github.com/tianon/gosu/blob/9dc5d8d7556e44d382b9f71734197b5071682c31/govulncheck-with-excludes.sh#L9-L13).

If you do the same with /usr/bin/bsondump, it narrows the list there to only two: GO-2025-3503 (aka CVE-2025-22870) and GO-2025-3487 (aka CVE-2025-22869) -- I cannot comment on whether either of those are particularly relevant for bsondump, but I would be surprised if they are, especially if they're relevant in any of the ways bsondump gets invoked.

Here's a simple Dockerfile for reproducing that result:

FROM golang
RUN --mount=type=bind,from=mongo,src=/usr/local/bin/gosu,dst=/tmp/gosu \
	go run golang.org/x/vuln/cmd/govulncheck@latest -mode=binary /tmp/gosu

[bgehman]

Hi @tianon I see you are the author of gosu, as well as actively contribute to these Docker Hub base images, so appreciate the years of dedication to these projects. I've now read your SECURITY.md and understand the point you are making, which ultimately boils down to (I'm going to paraphrase):

I know my (golang) compiler version is long out of support, and the upstream (golang) source libraries have known (and long since fixed) crit/high vulnerabilities -- but the resulting generated executable does not contain those exploits.

I need to ask: Is this a hill that Docker is planning to die on?

Docker Scout continues to detect the CVEs (docker/roadmap#749), as well as my corporation's internally used scan tool of choice (Xray). If you/Docker believe govulncheck is the solution here (instead of simply upgrading dependencies and rebuilding), then the community must rely on you/Docker to drive the change in across the security scanning industry.

Is there any Docker image security scanning software that implements govulncheck as you described?

My options:

1. track all these CVEs in "false positive" exemptions files -- even though the scanner is accurately reporting the binaries are compiled with known vulnerable compiler versions and source libraries versions containing known/fixed CVEs -- and work with my internal security teams and executives to try to convince them that everything is really "ok" (trust me bro).
2. or I simply move to the competition (0 CVEs)

[madduci]

there are new Issues with the version 8.0.9 released 4 days ago, mostly come from stdlib, which happens to be a very old version

[yosifkit]

@madduci,

All of the IDs shown in your screenshot are from gosu and thus are false positives; see the previous discussion and SECURITY.md in the gosu repo.

[BenNolanGartner]

The reasoning behind the notes in the security document is sound and clearly explained, however considering this is being flagged as a critical vulnerability—which is an instant disqualification for use in a lot of organizations—is it worth not changing the version to one which doesn't flag the CVE, even if it is a misidentification?

It's also worth considering that this will likely continue to be reported as an issue, so whether the time that will be dedicated to responding to the reports is less than the time needed to do the update and push out a 'fixed' version, etc.

[TomChatt2]

Having chased this rabbit trail far deeper than one should have to, I have an appreciation for the attention that developers like @tianon are giving to assessing the CVEs. That being said, I don't think that you all are appreciating the position that MongoDB users are in with regard to having to provide extraordinary justifications to our IT organizations because of the critical and high CVEs flagged against MongoDB. Computer security is a growing concern, and IT orgs are paying increasing attention to this.

It is not sufficient for me as a MongoDB user to do due diligence against each CVE simply by being pointed to a general security statement in the gosu project (as per @yosifkit 5/21 comment above). While some of the CVEs against MongoDB may be due to its inclusion of gosu, I’m not in any good position to assess whether those CVEs are due only to gosu, or whether there are other places in the overall Mongo codebase where go is also used (and where gosu’s project-specific CVE assessments may or may not apply). For example, the use of bsondump, which also has CVEs, has been pointed to above. Are there other go components in Mongo? How would I know? Has anyone run “govulncheck” against the whole Mongo codebase? I’ve seen no evidence of that.

What would be helpful would be for Mongo to maintain a Security posture statement that identifies the known CVEs (at least the critical and high ones) that are being flagged against it, and Mongo’s assessment of each. When I look at the CVEs flagged against Mongo in, for example, Docker Hub, I should be able to readily assess whether Mongo:

• plans to fix it
• has already taken steps to mitigate it in version xxx
• don’t believe it applies because {insert reasons here}
• hasn’t yet assessed it.

Something similar to the Security.md in the gosu project, but for the whole Mongo project and with assessments of each specific CVE.

[grooverdan]

Docker Scout hasn't received enough motivation to implement the obvious: docker/roadmap#749

User supplied check:

$ go install golang.org/x/vuln/cmd/govulncheck@latest

$ go/bin/govulncheck --version
Go: go1.23.2
Scanner: govulncheck@v1.1.4
DB: https://vuln.go.dev
DB updated: 2025-08-29 15:42:26 +0000 UTC

No vulnerabilities found.

$ podman run -v ~/go/bin/:/exec:z --rm mongo:latest /exec/govulncheck -mode=binary  /usr/local/bin/gosu
=== Symbol Results ===

Vulnerability #1: GO-2023-1840
    Unsafe behavior in setuid/setgid binaries in runtime
  More info: https://pkg.go.dev/vuln/GO-2023-1840
  Standard library
    Found in: runtime@go1.18.2
    Fixed in: runtime@go1.19.10
    Vulnerable symbols found:
      #1: runtime.Caller
      #2: runtime.CallersFrames
      #3: runtime.Frames.Next
      #4: runtime.Func.Entry
      #5: runtime.Func.Name
      Use '-show traces' to see the other 20 found symbols

Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 3 vulnerabilities in packages you import and 49
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.


$ podman run -v ~/go/bin/:/exec:z --rm mongo:latest /exec/govulncheck -mode=binary -show verbose  /usr/bin/mongodump
Scanning your binary for known vulnerabilities...

Fetching vulnerabilities from the database...

Checking the binary against the vulnerabilities...

Govulncheck scanned the following 29 modules and the go1.23.11 standard library:
...

=== Symbol Results ===

Vulnerability #1: GO-2025-3849
    Incorrect results returned from Rows.Scan in database/sql
  More info: https://pkg.go.dev/vuln/GO-2025-3849
  Standard library
    Found in: database/sql@go1.23.11
    Fixed in: database/sql@go1.23.12
    Vulnerable symbols found:
      #1: sql.Row.Scan
      #2: sql.Rows.Scan


$ podman run -v ~/go/bin/:/exec:z --rm mongo:latest find /usr/bin/ -name mongo\* -print -exec /exec/govulncheck -mode=binary -show verbose {} \;

(results not included - mostly same as above]