PHP gets less attention in supply chain security discussions than npm or PyPI, partly because the ecosystem is more concentrated and partly because the attacker ecosystem has historically focused on higher-volume targets. That doesn't mean Composer and Packagist are safe. Through 2025 we saw a steady cadence of incidents — namespace abuse, plugin-hook exploitation, abandoned-project takeovers, and credential-stealing payloads in otherwise-legitimate packages — that collectively raised the risk profile for PHP shops, especially those running large enterprise or CMS deployments.
This report consolidates what happened in 2025 and what the operational response looks like for PHP engineering teams. It's written for engineering leaders who want a clear-eyed view of the ecosystem rather than marketing material.
What makes the Composer ecosystem structurally different from npm or PyPI?
Composer has architectural choices that shape its threat profile. Packages are identified by a vendor/name format that ties publishing to a namespace (the vendor), which reduces some typosquatting attack surface but introduces different risks around namespace transfer and abandoned vendors. The default package source is Packagist, which fronts the actual code repositories (usually GitHub) rather than hosting artifacts directly. This means a Composer package's actual source of truth is a git repository, and compromises frequently target the repository rather than Packagist itself.
Composer plugins are the second structural consideration. Plugins execute code during composer install and composer update with the full privileges of the PHP interpreter. This is similar to npm's lifecycle scripts but with potentially broader capability, since PHP has rich file system and network access. A malicious Composer plugin can read credentials, modify other dependencies' files, or establish persistence — all during what appears to be a routine install.
The ecosystem has fewer packages than npm or PyPI but higher average concentration on specific projects. Symfony, Laravel, WordPress, Drupal, and Magento account for a disproportionate share of real-world PHP deployments, which means compromises targeting their plugin or dependency ecosystems have outsized impact. Attackers in 2025 increasingly targeted the long tail of packages that these major projects pull in transitively, rather than the major projects themselves.
What Composer-specific attack patterns emerged in 2025?
Four patterns stood out through the year. Abandoned-maintainer takeover remained the most common. An attacker identifies a package whose maintainer hasn't pushed in years, makes contact through whatever channels are available, and requests maintenance access — framed as a goodwill contribution. When granted, the attacker eventually publishes a malicious release. Several instances of this pattern hit packages that were transitively pulled in by popular frameworks, giving the attacker blast radius beyond the package's direct installs.
Namespace hijacking via expired vendor accounts also appeared. When a GitHub organization or a Packagist vendor account gets abandoned and its DNS or email records lapse, an attacker can re-register the associated email domain, trigger account recovery, and take control of the namespace. The first incident of this pattern in 2025 affected a small-but-critical package used by a major CMS's testing infrastructure.
Plugin-hook exploitation was the third pattern. Composer's scripts and plugin hooks allow package authors to run PHP during install, update, and various lifecycle events. Attackers leveraged these hooks to execute payloads during dependency resolution, often before the victim would have any reason to inspect the package's actual code. This was the most common vector for credential theft across the year, with .env files, AWS credentials, and WordPress admin sessions being the typical targets.
The fourth pattern was compromise of release tooling. Packages that use GitHub Actions or similar CI to publish releases got targeted through their workflow configuration, with attackers using pull requests from forks to inject malicious steps into the release workflow. The pattern worked best against projects that hadn't enabled branch protection on their CI configuration files, which in 2025 was still more projects than you'd hope.
What are the highest-value targets for attackers?
Attackers in 2025 consistently prioritized packages that met three criteria: high transitive install count, broad runtime permission surface, and low maintainer activity. Packages used by WordPress plugins are the canonical example — WordPress runs on a meaningful fraction of the internet, WordPress plugin developers pull from Composer liberally, and any malicious code that reaches a WordPress deployment has access to the admin session, database, and often the underlying host.
E-commerce platforms are the second cluster. Magento in particular has an expansive Composer-based extension ecosystem, and many of the extensions are maintained by small teams with weaker supply chain controls than the core platform. An attacker compromising a Magento extension can land payment card data harvesters on live storefronts. The 2025 incidents targeting this surface had real commercial impact.
Framework-level packages with broad access are the highest-value targets but also the hardest to compromise. Symfony and Laravel have mature security teams, high-visibility maintainership, and defensive CI. Attackers mostly avoid direct compromise of these projects and instead go after the dependencies they pull in — utility libraries, testing frameworks, and niche integration packages — because those targets have the same blast radius at a lower attacker cost.
How should PHP shops harden against these threats?
Start with dependency pinning. composer.lock should be committed, composer install --no-interaction --prefer-dist --no-scripts should be the default in CI, and --no-scripts should be overridden only for the specific packages whose scripts you trust. The pattern is the same as npm's --ignore-scripts: disable by default, enable explicitly.
Authenticity verification is underused in the PHP ecosystem. Composer supports package signatures via TUF-style mechanisms but adoption is spotty. At minimum, verify the commit hash of the package against what's expected for the version you're pulling. Tools exist to produce a dependency manifest with both version and commit SHA, and diffing that manifest across updates catches many of the namespace-hijack patterns.
Audit transitive dependencies for abandonment signals. A package whose upstream repository hasn't seen commits in 18+ months is a risk regardless of how stable its functionality seems. Either replace it, fork it internally and maintain it yourself, or accept the risk explicitly with a defined monitoring plan. Abandoned packages are a common supply chain pivot and the risk doesn't improve over time.
Private package registries deserve consideration for any PHP shop running at scale. Hosting your own Composer registry (Private Packagist, Satis, or a custom implementation) gives you control over which versions can be pulled, cache validation against upstream hashes, and a choke point for supply chain policy enforcement. The operational cost is modest compared to the visibility gain.
What about WordPress, Drupal, and the CMS ecosystems specifically?
CMS ecosystems need sharper controls because the attack surface extends beyond Composer into the CMS's own plugin marketplace. WordPress plugins installed through the WordPress admin don't flow through Composer at all, but many of them themselves depend on Composer packages that get bundled into the plugin distribution. The combined supply chain is deeper than either mechanism individually, and visibility requires scanning both.
For WordPress in 2025, plugin marketplace reviews got tighter but incidents continued. The core recommendation is to disable automatic plugin updates for any plugin that isn't from a vetted maintainer, maintain a shortlist of approved plugins by name and version, and scan plugin files for known-malicious patterns after each update. Tools that do file-integrity monitoring of the WordPress installation catch many compromise patterns after they land.
Drupal and Magento benefit from their more explicit Composer-native architecture. The same controls that apply to any Composer project apply here, with extra attention to extension marketplace sources. For Magento specifically, payment card data flows make PCI DSS obligations relevant, and the supply chain controls you implement need to be defensible under QSA review.
What does the attacker toolkit look like in 2026?
Looking forward, the attacker toolkit in 2026 is showing signs of better automation. Generative AI is being used to create plausible-looking maintainer profiles for social engineering, to generate polymorphic payloads that evade signature detection, and to craft contribution pull requests that pass surface-level code review. The defensive response needs to move from "can a human spot this" to "does the code behave as the package name suggests" — behavioral and reachability-driven analysis rather than syntactic review.
The 2026 attacker also has better operational security. Infrastructure rotates faster, payload domains are short-lived, and exfiltration paths increasingly use trusted services (GitHub, Discord webhooks, cloud storage) that blend into legitimate traffic. Defensive blocklisting is a losing game against this evolution; behavioral anomaly detection with a learned baseline is the posture that catches the tail.
How Safeguard.sh Helps
Safeguard.sh treats Composer, Packagist, and PHP projects as first-class ecosystems with dedicated parsers for composer.json, composer.lock, plugin configurations, and CMS-specific layouts including WordPress, Drupal, and Magento. Griffin AI applies reachability analysis at 100-level depth through PHP's autoloader and plugin systems, separating "present in vendor/" from "reachable at runtime" and sharpening remediation priority. Eagle watches Packagist, GitHub, and maintainer signals continuously, flagging abandonment indicators, maintainer transfers, and anomalous release patterns that map to the 2025 attack profile. The SBOM and TPRM integration extends to the long tail of Composer packages and their upstream repositories, producing evidence that survives PCI and enterprise audit review. Container self-healing rebuilds and redeploys affected PHP workloads — often the production-facing edge of a CMS — when a supply chain event requires remediation, keeping live deployments aligned with vetted package versions without manual intervention.