Skip to main content
Composer just shipped one of its most meaningful improvements in years: automatic blocking of insecure and vulnerable PHP dependencies. This is great news for the PHP ecosystem. It’s also something you’ll want to understand before your next deploy suddenly stops mid-build, shouting about abandoned packages you forgot existed. (It happens to the best of us.) Here’s the full breakdown.

​
What Changed in Composer 2.9?

Composer 2.9 introduces Automatic Security Blocking. When installing without a composer.lock file, or updating dependencies, Composer now:
  • Fails the build if a dependency has a known security advisory
  • Can fail if a dependency is abandoned (optional, but available … and recommended)
  • Provides a clear audit report of what’s wrong
This behaviour is on by default. Upsun doesn’t override it, because it makes everyone safer.

​
“But I didn’t change my dependencies… why is my build failing now?”

Two reasons:

​
1. Your config file requires Composer 2 latest version.

A rebuild may pick up the latest version of Composer even if you’re still on the same PHP version. Boom: your dependencies are audited automatically. And, that’s great news!

​
2. Vulnerabilities are published continuously

Your dependencies might have been “fine” yesterday but vulnerable today. Composer 2.9 is simply letting you know about problems that already existed.

​
Why we ship Composer 2.9 as-is

Short answer: because it’s good for you. Longer answer:
  • It prevents vulnerable or abandoned packages from silently entering your production chain.
  • It pushes the ecosystem toward more secure baselines.
  • Many users want this protection; they rely on it.
So instead of turning the feature off, we’re giving you the tools to use it effectively.

​
Your options if your build fails

Let’s be straight: The best fix is to patch or upgrade the affected dependencies. This is the healthiest thing you can do for your codebase, your users, and your future self. But you do have escape hatches.

​
1. Ignore specific advisories

dependencies:
  php:
    config:
      audit:
        ignore:
          - "PKSA-yhcn-xrg3-68b1"
          - "PKSA-2wrf-1mxk-1pky"

dependencies:
  php:
    config:
      audit:
        block-insecure: false

​
3. Ignore vulnerabilities based on their severity rating (low/medium/high)

dependencies:
  php:
    config:
      audit:
        ignore-severity:
           low:
             apply: all <-- ignore all low severity findings

​
How Upsun handles Composer

A common question is whether you can revert to an older Composer version to avoid these checks.

​
The Build process “catch-22”

Every Upsun PHP image includes a pre-installed, global Composer binary. Currently, this is version 2.9 or newer, which orchestrates your entire build:
  • The pre-installed global binary (always the latest Composer version available) is what initiates your build process.
  • Because this global binary is version 2.9+, it automatically performs a security audit before executing any other commands.
  • Even if you specify an older Composer version in your dependencies block, that version is installed by the global 2.9 binary.
  • The result: The security audit triggers and fails the build before your requested older version is even downloaded.

​
The Solution

Since you cannot bypass the global binary, you should not attempt to downgrade the tool. Instead, use the audit configuration to ignore specific IDs or severities. The most robust long-term solution remains keeping your dependencies updated and secure.

​
A gentle nudge: Keep those dependencies fresh

Security blocking may feel strict at first, but here’s the upside:
  • You learn about vulnerabilities early, before they sneak into production.
  • Your app becomes more resilient.
  • Your future upgrades stop being archaeology expeditions.
In other words: modernizing your dependencies regularly is now a power move, not a chore. Composer 2.9 also allows you to block abandoned packages. Go the extra mile and secure your PHP apps’ future. 
dependencies:
  php:
    config:
      audit:
        block-insecure: true
        block-abandoned: true

​
What you should do today

  • Run composer audit locally to see what’s coming.
  • Review your project’s dependency tree (yes, even the old stuff).
  • Decide whether to upgrade, ignore advisories, or temporarily opt out.
And remember: your next deployment might use Composer 2.9 unless you pin it explicitly.

​
If you need help, we’re here!

Hit us up on Discord or open a support ticket. We want this transition to be smooth, and this feature actually makes your apps safer and easier to maintain in the long term. And hey: if this blog post saved you an afternoon of head-scratching, go upgrade a dependency today. Your future deployments will thank you.
Last modified on April 14, 2026