Packagist shows its hand: Composer 2.10, stable version immutability and an MFA mandate in sight — what the roadmap means for TYPO3 and Sylius operators

What happened

Javier Eguiluz embedded it, but the lead is signed by Nils Adermann and Igor Benko: on 27 May 2026 the Packagist blog published a comprehensive stock-take of Composer and Packagist.org supply chain work. The trigger comes from two recent incidents in the PHP ecosystem: the laravel-lang tag injection attack of 22 May (draft 23.05.) and the intercom/intercom-php compromise of 30 April. Three axes become concrete: Aikido malware detection has been integrated into the Packagist metadata since March 2026; the public transparency log (funded by the Sovereign Tech Agency) captured the git tag modifications in the recent attacks in full; Composer 2.10 with the new dependency policy framework ships this week.

Context

Substantively, the step shifts three things at once. First: stable version immutability on Packagist.org closes precisely the gap the laravel-lang incident exploited; re-tagged versions are rejected server-side from the deploy point this week onwards, branch-based versions remain mutable. Second: the dependency policy framework in Composer 2.10 unifies vulnerability advisories, abandoned packages and malware flags in one configuration and is the structural prerequisite for the planned minimum release age policy, which puts a cooldown period on installed versions. Third: MFA events will move into the transparency log over the coming months and become visible on maintainer profiles, with the explicit aim of turning MFA status from a private hygiene question into a package property that consumers can read off. The longer-running direction is set as a heading, not a quarter plan: FIDO2-backed staged releases for packages with a large userbase, SLSA build provenance, Sigstore attestation, OpenSSF L3/L4.

What it means for the German Mittelstand

Three operational items fall straight out of the post: enable MFA today on every Packagist maintainer account, including and especially shared corporate accounts that are heading for Organizational Package Ownership over the next few months anyway. Plan Composer 2.10 with the self-update path into the CI/CD pipeline; review Renovate or Dependabot configuration in light of the source fallback deprecation (full removal in 2.11). And write down which dependency policies your platforms already enforce today — malware flag handling, vulnerability advisory response, abandoned package position.

On the compliance side, this is the direct duty track. NIS2UmsuCG § 30 requires a documented risk management of the ICT supply chain, and the Composer build pipeline is part of that supply chain. BSI baseline protection APP.6 and CON.8 address this exact stack. For regulated financial services providers DORA Art. 28 plus MaRisk AT 9 come on top — the mandatory entry in the ICT third-party register must now cover the build stack as well, not just the production platform, in the next audit cycle. The data protection position is the second layer: a compromised Composer pull can capture productive identities, which turns a build incident into a GDPR Article 33 reporting obligation.

What it means for the technical direction

Architecturally, the post shows the pattern emerging across ecosystems. PyPI has had 2FA mandatory since January 2024, npm shipped staged publishing on 22 May, Composer is closing the remaining gaps. The structural point sits in provenance binding: Composer has the advantage that packages are installed straight from the git tag, the artefact is therefore natively bound to its source — unlike npm or PyPI build artefacts. The step toward OpenSSF L3/L4 and SLSA dependency track L3/L4 still requires Packagist.org to host immutable build artefacts directly in future, with SLSA provenance and Sigstore attestation, verifiable on the Composer client side.

Operationally, this means two parallel tracks for the coming months. On the roadmap side, platform discipline (MFA, immutability, cooldown, trusted publishing). On the stack side, Composer 2.10 adoption with dependency policy configuration as a mandatory part of every new TYPO3 and Sylius pipeline. Anyone who does not plan that into the next twelve weeks will have no leverage when the next npm or Packagist wave arrives.

Concrete recommendation

Take three steps this week: first, enable MFA immediately on every Packagist maintainer account that publishes or consumes packages for your TYPO3 or Sylius platform. Move shared corporate accounts onto a transition plan toward Organizational Package Ownership now, without waiting for the final feature. Second, prepare Composer 2.10 in your CI/CD pipeline: schedule composer self-update, review source fallback behaviour, prepare dependency policy configuration in the composer.json of your own projects. Third, update the written supply chain security position together with your DPO, internal control system and (for regulated mandates) the MaRisk AT 9 owners — the next audit will question the Composer build pipeline just as it questions the production platform.

This article reflects our technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• Packagist blog — “An Update on Composer & Packagist Supply Chain Security”, Nils Adermann and Igor Benko (27 May 2026)
• Aikido — “Supply Chain Attack Targets Laravel-Lang Packages with Credential Stealer” (22 May 2026)
• Socket — “Mini Shai-Hulud: Packagist Malicious intercom-php Package Compromise” (30 April 2026)
• Packagist blog — “Composer 2.9.8 and 2.2.28 fix GitHub Actions token disclosure in error messages” (13 May 2026)
• GitHub changelog — “Staged publishing and new install-time controls for npm” (22 May 2026)
• OpenSSF — “Principles for Package Repository Security” (programme page, as of 27 May 2026)