Packagist

About

Packagist is the main public repository for PHP packages, and Composer is the tool that installs them. Laravel apps are built largely from it, and many WordPress plugins bundle its packages inside them. Packagist lists each package, but the code itself is fetched from the project's own source repository.

While it installs, Composer runs your project's own scripts and any plugins you allow, with the rights of whoever runs it. Other packages run inside the app when PHP loads them, on every request.

If It Is Malicious

If a Composer package is malicious, it runs inside a PHP app with the app's rights, on every server and build that installs it.

Its code runs inside these technologies.

WordPressLaravelPHP

See It in the Stack

Examples

These are well-known names from Packagist, written as you would meet them in an inventory, an alert or a lockfile, the file that records every version a build installed.

laravel/framework

The Laravel framework itself.

guzzlehttp/guzzle

The HTTP client a great many PHP apps use.

monolog/monolog

Logging for PHP, used by Laravel and Symfony.

symfony/console

Command-line building blocks, used by Laravel and by Composer itself.

phpunit/phpunit

The standard test framework, installed for development.

How Bad Code Gets In

These are the ways bad code can reach your systems through Packagist. None of them needs a flaw in your own code, so outside code needs checking as much as your own.

• A maintainer's account is taken over and the package is pointed at a different source repository.
• A project's source repository is deleted or renamed, and its old address later serves someone else's code.
• A package named like a popular one catches careless installs.
• A Composer plugin runs code during install on every machine that allows it.

How to Check

These checks show what came from Packagist, whether a known bad version is in use, and how to keep one out next time.

• Commit composer.lock and install from it in every build.
• Run composer audit, which checks installed packages against known advisories.
• Keep allow-plugins to the plugins you trust, so no other package runs code at install.
• Serve the packages you use from a private repository, such as Private Packagist or Satis.

Well-Known Incidents

Each incident below is a real case, told at the level of its public advisory. The tag says how the bad code got in, and the link opens the primary source.

• Hijacked Account2023

  Packagist Account Takeover

  An attacker got into four inactive maintainer accounts, likely with passwords leaked on other sites, and pointed their packages at copies of the code under the attacker's control.

  Reach Fourteen packages were pointed elsewhere, Doctrine ones among them. The copies only changed a description, so no bad code went out.

  Affecteddoctrine/instantiatoracmephp/corejdorn/sql-formatter

  Source: blog.packagist.com (opens in a new tab)

In Common Stacks

These common stacks take code from Packagist. Open one to see where that code sits among its layers and who runs each one.

• WordPress on Linux, Apache, MySQL and PHP
• WordPress on nginx and PHP-FPM

Sources

• Composer: the audit command (opens in a new tab)
• Composer: allow-plugins (opens in a new tab)
• Packagist (opens in a new tab)