Open an issue in the docker-library official-images GitHub repository, or check the image's own tracker if it has one. For a security update, the repository says to email the Docker Official Images team in advance and prefix the pull request title with the word security in square brackets. Gather evidence first.
Where to go
The official-images README says you can report issues by opening a GitHub issue in the repository, or by asking in the docker-library channel on Libera.Chat IRC. For security updates, it says to email doi@docker.com in advance and prefix the pull request title with [security].
Docker's page on becoming an official image adds that each image's documentation has a User Feedback section, and many images also have a GitHub issue tracker. General questions go to a channel in the Docker Community Slack.
Which one to use depends on what you found. A finding in a package the image includes is a different matter from a flaw in how the image is built.
Decide what kind of problem it is
| You found | Likely owner | Where to start |
|---|---|---|
| A vulnerable package in a base layer | The base image's maintainers and the upstream distribution | Check if a rebuild is pending, then raise on the image tracker |
| A flaw in the software the image packages | The upstream project | Report to the upstream project's security contact |
| A build or Dockerfile weakness | The image maintainers | Issue in the official-images repository or the image tracker |
| An image that seems tampered with or impersonated | Docker and the registry | Use Docker Hub reporting and stop using the image |
Take care not to publish exploit details in a public issue for something that is not yet fixed. If in doubt, contact the maintainers privately first.
What to include
- The full image reference and the digest you tested.
- Platform and architecture.
- The scanner name, version and the date of the scan, so others can reproduce.
- The advisory identifier and affected package with version.
- Whether the finding is reachable in normal use, if you know.
- What you already tried, such as pulling a newer tag.
A report with a digest and a reproducible scan is acted on faster than a screenshot.
Before you report
Check that the tag is still maintained. The repository says only tags in a library file are rebuilt, so a finding on an unlisted tag will not be fixed by a rebuild. The right answer there is to move to a listed tag.
Also check that a rebuild has not already arrived. Pull again and compare digests.
Your own response meanwhile
Reporting does not fix your exposure. While you wait, assess whether the vulnerable code is reachable in your use, apply a documented exception with an expiry date if you must keep running, and tighten runtime limits. Re-scan when a new digest appears.
Quick check
Do I report a vulnerable package to Docker or to the upstream project?
It depends on whether the flaw is in the packaged software or in how the image is built. Package flaws belong with the upstream project, and image issues with the image maintainers.
What should a security pull request title start with?
The official-images README says to prefix it with [security] and to email the team in advance.
Safeguard reachability analysis helps you judge whether a finding in an image matters for your use, and dependency scanning and SBOM supply the evidence for a report. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
