A malicious Maven Central artifact usually looks like a normal library: valid coordinates, a signature, a POM and a plausible name. Publishing rules prove who uploaded a file, not that the code is safe. Spot it by name, ownership, build behavior and dependency changes, then pin, remove and rotate.
What do the publishing rules actually guarantee?
The Central publishing requirements say every deployed file needs a GPG or PGP signature in a matching .asc file. The POM must carry coordinates, name, description, URL, licenses, developers and SCM details. Checksum files are required for each file, and non pom packaging needs sources and Javadoc jars, though placeholder jars with a README are accepted when real ones are not available.
Two things follow. First, a signature shows the file was signed by a key, and a bad actor can sign with their own key. Second, the page says the SCM URL can be private or a placeholder, and the metadata fields are not verified for truth. A complete looking POM tells you little about intent. The page also does not describe how namespace ownership is verified, so do not assume more than the requirements state.
What are the warning signs?
None of these proves a problem alone. Together they should make you look closer.
- A name one character away from a popular library. Typosquats rely on a quick glance at a dependency list.
- A groupId that imitates a well known one, for example swapping a domain part or adding a suffix.
- A brand new artifact with very little history that a recent commit pulled into your build.
- A POM whose SCM URL points nowhere, or to an unrelated repository, with developers you cannot identify.
- Sources jars that are placeholders where you would expect real code from an active project.
- A patch release that suddenly adds a dependency, a plugin, or a build step, or a jump in jar size.
- Code that does work at class load time rather than when called: static initializers that touch the network, the file system or environment variables.
- Build plugins from the same publisher that execute during your build.
Constructed example: a team adds com.exmaple.http:fast-client because a blog snippet had that spelling. The correct organization is com.example. The artifact has one release and a placeholder sources jar. A reviewer who compares the groupId against the project's documentation sees the mismatch.
How do you check before you adopt?
- Compare the groupId and artifactId with the project's own documentation or repository, not a search result.
- Look at release history and the identity behind the developers entry.
- Open the sources jar. If it is a placeholder, treat the artifact with caution.
- Diff the dependency tree against the previous version.
- Verify the signature and the key you expect, where the project publishes its key.
What do you do if you have already used one?
- Stop builds that resolve it and block the coordinates in your repository manager.
- Find every project and image that contains the artifact, with a software bill of materials or a dependency search.
- Treat any machine that built with it as exposed. Rotate secrets that were available to those builds.
- Remove it, pin the known good version, rebuild and redeploy.
- Review logs for outbound connections from affected hosts.
- Report the artifact to the repository operators and record what you did.
Safeguard's dependency scanning and SBOM inventory can answer "where is this artifact used" in step 2. See the dependency inventory demo, and the free scan at gold.safeguard.sh/scan covers up to 100 dependencies in the browser.
What to do
- Route Maven resolution through a repository manager and allow only approved coordinates for new dependencies.
- Add a review step for any new groupId.
- Pin versions, and review upgrades that add dependencies.
- Keep an up to date SBOM for each release.
- Keep a written incident checklist like the one above.
Quick check
Does a valid signature mean a Maven Central artifact is safe?
No. Central requires signatures, but a signature shows which key signed the file, not that the code is benign.
What is the quickest check for a typosquatted artifact?
Compare the groupId and artifactId character by character with the project's own documentation or repository.
Sources
Last reviewed: 18 October 2026.
