Skip to content

Back to the catalog

Packagist is now protected by Aikido Intel and other updates to the PHP registry
aikido.devarticle

Packagist is now protected by Aikido Intel and other updates to the PHP registry

Aikido describes how its CC-BY-licensed Intel malware feed now powers default-on malicious-package blocking in Composer 2.10+ for Packagist, using Composer's dependency policy framework to strip flagged versions from resolution at update/require/create-project/install time. It also covers Packagist's newly mandatory stable version immutability (preventing git re-tagging attacks like the recent Laravel-Lang compromise), Private Packagist's enforcement of current Composer clients, and planned features (minimum release age, organizational ownership with mandatory MFA, staged releases), framed alongside similar moves by npm, PyPI, crates.io and RubyGems.

TL;DR Aikido's malware-detection feed now blocks flagged packages by default in Composer 2.10+, and Packagist made stable release tags immutable to kill re-tagging attacks.
Document

What it is

Aikido's blog on Packagist/Composer security hardening. The one action item for an engineer: Composer clients older than 2.10 get none of this protection. The Aikido Intel malware-blocking feed is on by default only in Composer 2.10+.

How it works

When Aikido flags a malicious version, the flag ships inside the package metadata Composer downloads. Composer 2.10's dependency policy framework pulls the flagged version out of the resolution pool, so composer update, composer require, and composer create-project won't select it. The page stresses that the check on composer install is the important one: a version flagged after your lockfile was written will fail on the next install, catching cases where a pinned dependency turns malicious. A user who still wants a blocked package can manually override the block.

Preconditions / Affected

  • Composer 2.10 or higher — older clients (common in CI images and long-lived AI-agent environments) have no malware blocking.
  • For those who can't upgrade the client, Private Packagist can require a current Composer to connect and will refuse to serve a flagged version's files to any client, old or new.

What to do

  • Upgrade Composer to 2.10+ if you're behind; the block is a default that only helps current clients.
  • The planned minimum release age (blunting attacks that rely on the short window before detection) isn't shipped yet. In the interim, the page points to Aikido Safe Chain (free, open source) for similar protection, and as the non-PHP option that blocks new/malicious packages before install.
  • Inspect what the feed flags at the public, free endpoint intel.aikido.dev.

Caveats

  • The block only fires once something is detected — it protects the window between detection and takedown, not zero-day-fresh uploads. This is precisely the gap the not-yet-shipped minimum-release-age feature is meant to cover.
  • Blocks are overridable by the installing user, so this is a guardrail, not an enforcement boundary.
  • Organizational ownership, mandatory MFA, and staged releases are described as planned/coming, not available.

The immutability, Private Packagist, and planned-feature details are already in the catalog summary; the reader-facing delta here is the version gate (2.10), the composer install-on-existing-lockfile behavior, the manual override, and Safe Chain as the interim/non-PHP fallback.

Techniques named here

Threat actors named here

  • Laravel-Lang attacker