Packagist typosquatting report

San Francisco — July 6, 2026. Composer's package repository, Packagist, has become the latest battleground in open source supply chain security. Over the past eighteen months, security researchers have catalogued a steady drumbeat of typosquatting campaigns targeting PHP's default package manager — malicious packages published under names that are one keystroke, one hyphen, or one namespace away from legitimate, high-download libraries like guzzlehttp/guzzle, symfony/symfony, monolog/monolog, and laravel/framework. Packagist now indexes more than 480,000 packages and serves upwards of 3 billion downloads per month, according to Packagist's own public statistics — a footprint large enough, and a moderation model light enough, that attackers have consistently found it profitable to squat on developer typos rather than compromise upstream maintainers directly.

This report synthesizes public disclosures, takedown patterns, and Safeguard's own telemetry from scanning customer dependency trees to lay out how Packagist typosquatting campaigns are structured, why PHP's ecosystem is particularly exposed, and what detection and response should look like for teams still running Composer in production in 2026.

The Scale of the Problem

Typosquatting is not new to Packagist — Sonatype, Checkmarx, and independent researchers have flagged waves of lookalike PHP packages going back to at least 2021 — but the volume and sophistication have both increased. In campaigns tracked through late 2025 and into 2026, researchers identified clusters of packages published in rapid succession (sometimes dozens within a single 24-hour window) under near-identical vendor namespaces, a pattern consistent with automated tooling rather than one-off opportunism. Common techniques observed across these campaigns include:

• Character-level substitution — swapping visually similar characters (l for 1, o for 0) or adjacent-key typos (guzzlehttp/guzzel, symfony/symfon).
• Namespace impersonation — publishing under a vendor prefix that mimics a trusted organization (e.g., a package claiming to be laravel/* published by an unverified account, since Packagist namespace ownership is tied to the first publisher rather than a verified trademark holder).
• Dependency confusion via require statements — malicious packages that declare themselves as drop-in replacements and are pulled in transitively when a developer misspells a composer require command or copies a tutorial with a typo already baked in.
• Delayed payload activation — post-install scripts (composer.json scripts hooks) that fetch a second-stage payload only after a delay or on specific environment checks, a technique designed to slip past first-pass automated scanning.

Packagist's maintainers have historically responded to reports within days, and the platform does run automated abuse detection, but the reactive nature of takedown-after-report leaves a real window of exposure — public write-ups have documented individual malicious packages accumulating thousands of downloads before removal.

Anatomy of a Packagist Typosquat

The lifecycle of a typical campaign follows a recognizable pattern that defenders can use as a detection signature:

1. Reconnaissance — attackers identify high-traffic packages using Packagist's public download statistics and GitHub star counts, prioritizing libraries used in web-facing frameworks (HTTP clients, ORMs, logging libraries) where a compromised install script has the broadest blast radius.
2. Registration — one or several near-identical package names are registered, often reusing legitimate-looking README content scraped directly from the real project to pass a casual glance.
3. Seeding — some campaigns pair the malicious package with fake tutorial content, Stack Overflow answers, or SEO-optimized blog posts recommending the misspelled name, a tactic that inflates organic discovery beyond pure typo traffic.
4. Payload delivery — the actual malicious behavior is typically delivered via Composer's post-install-cmd or post-update-cmd hooks, which execute arbitrary PHP or shell commands automatically during composer install with no user interaction required. Observed payloads have ranged from credential harvesting (scraping .env files and cloud metadata endpoints) to establishing simple reverse shells and, in a smaller number of cases, deploying cryptomining scripts on CI runners.
5. Persistence and cleanup evasion — some packages have been observed removing their own entry from composer.lock change logs or obfuscating payload code with base64-wrapped eval() calls to reduce the chance of catching a reviewer's eye during a diff review.

Why PHP and Composer Are a Soft Target

Several structural factors make Packagist a comparatively attractive target relative to npm or PyPI, despite npm remaining the largest typosquatting target by absolute volume:

• Namespace trust is shallow. Packagist vendor names are claimed on a first-come basis; there is no equivalent of npm's org-verification badges or PyPI's trusted publisher attestation widely enforced across the ecosystem, so a convincing namespace is easy to obtain.
• Install-time code execution is the default, not the exception. Composer scripts execute automatically unless explicitly disabled, and a large share of PHP frameworks rely on post-install hooks for legitimate setup (cache warming, asset publishing), which normalizes the exact mechanism attackers abuse.
• Long-lived legacy deployments. PHP applications, particularly in the WordPress plugin and Laravel/Symfony agency ecosystem, tend to have long upgrade cycles and infrequent dependency audits, meaning a compromised package can sit in a composer.lock file for months before anyone re-resolves dependencies.
• Lower researcher density. Fewer security teams run continuous typosquatting monitors against Packagist compared to npm, meaning malicious packages statistically survive longer before a third party flags them.

Detection Challenges for Security Teams

The core difficulty for defenders is that typosquatting is a volume problem, not a signature problem — static malware scanning of any single package catches known payload families, but new campaigns rotate obfuscation techniques faster than public advisory databases can be updated. Teams relying solely on CVE-driven scanning (checking installed packages against the National Vulnerability Database or OSV) will systematically miss typosquats, because a malicious package with no legitimate predecessor has no CVE to match against — the vulnerability is the package's existence, not a flaw within otherwise-legitimate code.

This is compounded by dependency confusion at the CI/CD layer: private/internal package names referenced in a private Composer repository can be squatted on the public Packagist registry, causing build systems that fail to pin a repository source to silently resolve to the attacker's public package instead — a class of issue that has caused high-profile dependency confusion incidents across ecosystems since 2021 and remains under-mitigated in many PHP shops that have not adopted composer.json repository pinning or lockfile-based install-only enforcement (composer install --no-scripts in CI, where feasible).

How Safeguard Helps

Safeguard is built to close exactly this detection gap for teams that can't rely on CVE feeds alone. Safeguard continuously ingests and generates SBOMs across your Composer, npm, PyPI, and container dependency graph, then flags newly introduced packages with name-similarity scoring against your existing high-traffic dependencies — surfacing likely typosquats before they reach a production composer.lock. Reachability analysis then determines whether a suspicious or newly flagged package is actually invoked by your application code versus merely present in the dependency tree, letting teams triage the packages that matter first instead of drowning in transitive-dependency noise. Griffin, Safeguard's AI-powered detection engine, is trained to recognize the install-hook and obfuscation patterns common to Packagist and npm supply chain attacks — including suspicious post-install-cmd scripts and base64-wrapped payloads — and scores them independently of whether a public advisory yet exists. When a match is confirmed, Safeguard can open an auto-fix pull request that pins the correct package name and version, removing the manual remediation lag that lets these campaigns linger in production. Together, this gives security and platform teams a way to catch Packagist typosquatting at commit time rather than after a compromised install script has already run.