Maven Central has historically been the quietest major public registry from a malware-telemetry perspective. Sonatype's annual State of the Software Supply Chain reports have for years shown orders of magnitude fewer malicious components on Maven Central than on npm or PyPI, largely because the registry's publishing workflow requires namespace verification, PGP signing, and, since 2024, mandatory two-factor authentication for OSSRH and the newer Central Publishing Portal.
That relative calm started to shift in 2025. Multiple vendors, including Sonatype, JFrog, and ReversingLabs, published research during the year showing a measurable uptick in malicious Java artifacts, namespace abuse on the newer portal, and a handful of account-takeover incidents against established groupIds. This post consolidates what those vendors and the Central infrastructure team at the Apache Maven Project have publicly reported, and discusses what it means for Java and Kotlin teams.
Did Maven Central actually see more malware in 2025?
Maven Central actually did see more malware in 2025, according to public vendor counts, though the absolute numbers remain well below npm and PyPI. Sonatype's 2025 report and JFrog's security-research blog posts documented hundreds of malicious artifacts flagged and removed across the year, compared with the tens typically seen in earlier years. The increase was concentrated in a few themes: typosquats of popular Android and Kotlin libraries, packages claiming to be Log4j or SLF4J variants, and a handful of incidents where attackers attempted to resurrect abandoned or previously-taken-down groupIds.
The absolute counts are still small compared with the multi-thousand-per-year figures on npm, but the trend line matters. The registries that historically had stronger publishing controls are seeing attackers invest more effort to clear those controls, which suggests the controls are being treated as a filter rather than a wall.
What changed about the Central Publishing Portal?
The Central Publishing Portal, which replaced OSSRH as the default publish path for Maven Central, changed several things during its 2024 and 2025 rollout. Portal accounts require two-factor authentication, namespace claims are validated against DNS or source-host proof, and the portal collects provenance metadata that OSSRH did not always require. These changes closed the simplest attack paths that existed on OSSRH, where namespace ownership was sometimes verifiable only by email.
At the same time, the migration introduced a transition period in which new accounts could publish under newly-verified namespaces faster than the old manual review flow allowed. Researchers have publicly noted that some of the 2025 malicious-publishing incidents took advantage of the shorter onboarding window, especially when attackers could prove ownership of a domain they had registered specifically for the attack.
How did typosquatting evolve on Maven Central?
Typosquatting evolved on Maven Central by moving from groupId-level impersonation to artifactId-level confusion and version-pinning trickery. Classic groupId typosquats, for example registering a groupId that differs by one character from org.apache.logging.log4j, have become harder because the portal checks DNS ownership. What attackers did instead in 2025 was register a legitimate-looking groupId, then publish an artifactId whose name closely mirrored a popular component from a different groupId, betting that developers searching by artifactId alone would grab the wrong dependency.
A second pattern involved publishing a high-version-number package under a plausible groupId, hoping that version-range resolvers or opportunistic latest consumers would pick it up. This is the Java-ecosystem cousin of the dependency-confusion attacks that hit npm and private registries from 2021 onward.
Were any established Maven Central groupIds taken over in 2025?
A small number of established groupIds saw account-takeover attempts in 2025, and at least one incident was publicly documented by the affected maintainer. The common pattern was credential stuffing or phishing against the maintainer's Sonatype or GitHub account, followed by a publish of a malicious version to the existing groupId. Because Maven Central is immutable, the malicious version could not be removed without publishing a higher version and relying on downstream consumers to upgrade, though the Central team did work with affected maintainers to mark compromised versions.
These incidents are the Maven-ecosystem equivalent of npm's high-profile account takeovers from the 2018 event-stream era onward. They confirm that 2FA is necessary but not sufficient when attackers can compromise a maintainer's email recovery or session cookie.
What kind of payloads showed up in malicious Java artifacts?
The payloads in malicious Java artifacts during 2025 tended to fall into three categories: post-install stagers that fetched a second-stage JAR or native binary, build-time stagers that ran during Gradle or Maven plugin execution and dropped files onto the developer's machine, and trojanized library behavior where the legitimate API continued to work but added a hidden network callback. The third category is the hardest to detect, because a typical sanity test of the library will pass.
Several of the 2025 incidents specifically targeted the Android build toolchain, adding code that attempted to read signing-key material or CI secrets. Android's signing infrastructure has long been an attractive target because a compromised signing key grants indefinite impersonation of an app.
How should a Java shop respond in 2026?
A Java shop should respond in 2026 with a combination of build-level hygiene and registry-level policy. At the build level, pin dependency versions explicitly, avoid latest and open-ended ranges in production projects, verify PGP signatures or Sigstore attestations where available, and audit plugin definitions in pom.xml and build.gradle with the same rigor as library dependencies. Plugins run with the full permissions of the build and are often under-audited.
At the registry level, proxy Maven Central through a managed repository such as Artifactory, Nexus, or a policy-driven curation layer, so that new or unusual artifacts go through a review queue before they are available for developer use. Enforce 2FA on every account that can publish to your shared namespaces, and rotate credentials on any account that has not published in the last 12 months.
Is Maven Central still "safer" than npm?
Maven Central is still safer than npm in relative terms, because its publishing controls are stronger and its historical attacker volume is lower. The 2025 trend, however, is that the delta is narrowing. As attackers port successful playbooks from npm and PyPI to Maven Central, the stronger controls buy time rather than immunity. The practical implication for security teams is that Java projects should no longer be treated as a lower-risk lane; they should be covered by the same SBOM, reachability, and remediation tooling as JavaScript and Python projects.
This is particularly true for Android applications, for backend Java services in regulated industries, and for any project that ships customer-installed software. Each of those contexts amplifies the blast radius of a single compromised artifact.
How Safeguard.sh Helps
Safeguard.sh ingests Maven, Gradle, and Android build graphs and applies reachability analysis that reduces vulnerability noise by 60 to 80 percent, keeping alerts focused on code paths the application actually executes. Griffin AI autonomously remediates risky dependencies by opening pull requests that bump, replace, or exclude compromised artifacts across pom.xml and build.gradle. Eagle classifies Maven Central artifacts using behavioral and bytecode signals, identifying trojanized libraries and build-time stagers that name-matching misses. The Gold registry provides a curated Maven mirror, SBOMs track dependencies to 100 levels of depth across groupId hierarchies, and container self-healing rebuilds service images when a Maven dependency is pulled or reclassified.