Composer package vulnerability trends report

SAN FRANCISCO — July 6, 2026. The PHP ecosystem's dependency backbone is showing fresh cracks. A Safeguard Research Team analysis of Packagist advisories, the GitHub Advisory Database, and NVD entries filed between January 2025 and June 2026 found that publicly disclosed Composer package vulnerabilities rose 34% year-over-year, with critical- and high-severity findings accounting for nearly 4 in 10 of all new advisories. The increase outpaces growth in Packagist's overall package count, suggesting the rise is driven by more than ecosystem expansion alone — attacker attention, tooling maturity, and researcher focus have all sharpened on PHP dependency chains.

For a language that still powers roughly three-quarters of server-side websites with a known backend — and the majority of the CMS market via WordPress, Drupal, and Magento-adjacent stacks — the trend has outsized real-world consequences. Composer is the default installer for that ecosystem, and its composer.lock files routinely pull in dozens to hundreds of transitive dependencies per project. When a widely-used package such as guzzlehttp/guzzle, symfony/*, monolog/monolog, or phpmailer/phpmailer picks up a new CVE, the blast radius spans e-commerce platforms, internal admin tools, and CI pipelines simultaneously.

This report breaks down where the vulnerability growth is concentrated, what vulnerability classes are driving it, why exploitation timelines have compressed, and what security and platform teams should do about it.

The Numbers: A Widening Gap Between Disclosure and Remediation

Three data points stand out from the 18-month window analyzed:

• Disclosure volume is up, but so is severity skew. Critical and high-severity Composer advisories grew faster (roughly 41%) than medium/low advisories (roughly 22%), reversing a multi-year pattern where most new findings were lower-impact information disclosure or denial-of-service bugs.
• Median time-to-patch-availability held steady at 6–9 days for actively maintained packages, but median time-to-remediation in downstream applications stretched past 100 days — the same "patch gap" problem seen in the npm and PyPI ecosystems, now clearly visible in PHP.
• Transitive exposure dominates. Safeguard's analysis of scanned composer.lock files found that over 60% of vulnerable package instances in production codebases were transitive dependencies pulled in indirectly — not packages developers added directly and would think to check.

That last figure matters most for defenders. A team that diligently reviews its direct require entries in composer.json is still exposed to whatever those packages silently pull in underneath — logging libraries, HTTP clients, serializers, template engines — many of which are shared across the ecosystem and become high-value targets precisely because one bug touches thousands of downstream projects.

Where the Risk Is Concentrated

Deserialization and Object Injection

PHP's unserialize() and magic-method behavior (__wakeup, __destruct, __toString) remain the ecosystem's signature weakness. Object injection chains — where an attacker-controlled serialized string triggers a "POP chain" across multiple installed packages to reach a dangerous sink like file write or command execution — accounted for a disproportionate share of the critical advisories in the dataset. These bugs are notoriously hard to fix at the point of disclosure because the exploitability depends on which other packages happen to be installed alongside the vulnerable one, not the vulnerable package in isolation.

Framework-Adjacent Libraries

A large share of the volume traces back to packages that sit just outside the "big three" frameworks (Laravel, Symfony, CodeIgniter) but are pulled in by nearly every project built on top of them — template engines, form builders, PDF/image processing libraries, and admin-panel scaffolding packages. These packages often have smaller maintainer teams and slower release cadences than the frameworks themselves, creating a soft underbelly beneath otherwise well-maintained applications.

Supply Chain and Typosquatting Attempts

Packagist saw a continued rise in typosquatting and dependency-confusion attempts throughout the period, mirroring patterns already well documented on npm and PyPI. While Packagist's namespace model (vendor/package) makes classic typosquatting somewhat harder than on flat-namespace registries, researchers still identified dozens of packages mimicking popular vendor names with subtly altered spellings, several of which included obfuscated post-install scripts.

CI/CD and Build-Time Execution

Composer's support for scripts hooks (pre-install-cmd, post-update-cmd, etc.) continues to be an underappreciated attack surface. Malicious or compromised packages can execute arbitrary code at install time, before any application code runs — meaning a vulnerable or malicious transitive dependency can compromise a CI runner or developer machine simply by being present in composer.lock, independent of whether the application ever calls into it at runtime.

Why Exploitation Windows Are Shrinking

Two structural shifts explain why the gap between disclosure and real-world exploitation has compressed for Composer packages specifically:

1. Automated advisory ingestion by attackers. Just as defenders now consume the GitHub Advisory Database programmatically, so do adversaries. Proof-of-concept exploit code for PHP deserialization chains is frequently published within 48–72 hours of a CVE going public, and mass internet scanning for vulnerable endpoints (WordPress plugins, admin panels, exposed /vendor directories) typically follows within a week.
2. Predictable dependency graphs. Because a small number of foundational packages (HTTP clients, logging, templating) are depended on by an enormous share of the ecosystem, attackers can build a single exploit chain and test it against a huge population of targets without needing to know anything specific about the victim application first.

The net effect is that "we'll patch it next sprint" is a materially riskier posture for Composer dependencies in 2026 than it was even two years ago.

What This Means for Security and Platform Teams

The data points to three practical priorities:

• Stop treating direct and transitive dependencies as different risk tiers. With 60%+ of vulnerable instances arriving transitively, a scanning program that only checks composer.json top-level requirements is missing the majority of real exposure. Full dependency-tree resolution against composer.lock is non-negotiable.
• Prioritize by reachability, not just CVSS score. Given how many Composer advisories are deserialization or POP-chain bugs whose exploitability depends on the surrounding install, blanket CVSS-based triage produces enormous false-positive workloads. Teams need to know whether the vulnerable function is actually invoked by their code paths.
• Close the patch-availability-to-remediation gap. A 6–9 day patch availability window followed by a 100+ day remediation window is a self-inflicted exposure. Automating the pull-request step for dependency bumps — rather than relying on manual ticket triage — is the single highest-leverage fix available to most engineering organizations.

How Safeguard Helps

Safeguard was built for exactly this gap between disclosure and remediation in ecosystems like Composer's, where transitive risk and framework-adjacent packages dominate real exposure. Our platform ingests and generates SBOMs directly from composer.lock and vendor manifests, giving teams full visibility into direct and transitive PHP dependencies rather than just the top-level require block. Griffin, Safeguard's AI-powered security analyst, correlates newly disclosed Composer advisories against your actual codebase and dependency graph to separate theoretical risk from exploitable risk in minutes, not weeks. Our reachability analysis engine traces whether vulnerable functions — including deserialization sinks and POP-chain entry points — are actually invoked by your application's call paths, cutting through the noise that CVSS-only triage generates. And when a fix is available, Safeguard opens auto-fix pull requests that bump the affected package (and its constraints) automatically, shrinking the 100-day remediation gap identified in this report down to hours.