Security Tip: New Composer Cooldown Period!
[Tip #136] Composer 2.11 adds the long-awaited cooldown period option, designed to protect you from malicious version releases.
Let's take a step back from PHP2Shell this week, since if you're like me, you're probably sick of hearing about it everywhere. I promise I will come back to it, as there are some useful things we can, and should, be doing, but instead let's turn to an exciting new release from the Composer team!
Composer 2.11.0 was released today, which includes the new cooldown dependency policy! We talked about this way back in June, with the min-release-age feature in NPM and confirmation that it was coming to Composer too. A few months later, and it has arrived!
Composer introduced malware blocks back in 2.10, which blocked installation of package versions marked as malicious, however this requires malicious versions to be flagged after they are published - which introduces a window where a malicious version remains unflagged and installable.
The cooldown period is designed to narrow or close that window by delaying when your composer update will pull down a new version. This gives malware scanners a chance to identify and flag malicious versions before it is possible for them to reach you.
As per the release announcement, you can configure it through the config.policy within your composer.json file:
{
"config": {
"policy": {
"cooldown": {
"period": "1 day"
}
}
}
}and accepts a string like 1 day, 6 hours (supporting second, minute, hour, day, or week), or an integer number of seconds.
It works in either your project composer.json or global composer.json, or via the environment variable COMPOSER_POLICY_COOLDOWN_PERIOD.
Composer has no way to verify if a new version is a legitimate security fix or a malicious version, so everything is delayed. When you need to install a security fix quickly (such as when it's flagged by
composer audit), you can manually skip the cooldown with: composer update --no-cooldown vendor/package.So how long do I set it for?
That is a very good question.
A lot of malicious versions are detected within minutes, so an hour would protect against a lot. However that relies on automated scanning picking it up and correctly reporting it, while the more careful malicious versions are likely to take a few hours to be detected.
You could bump it to a week, but then that's an entire week where you won't receive security updates. That opens your app up to a very different risk.
My suggestion is to try with 1 day, and keep an eye out for security fixes via composer audit.
Wait, how do I update Composer?
composer self-update should do it in most environments. 🙂
Appendices
🎉 Laracon AU is NEXT WEEK! 🎉
Laracon AU is next week and it's going to be a lot of fun. Please come find me and say Hi if you're there. I'm not on the schedule, but that doesn't mean I don't have something planned. 🤐
🕵️ Pentesting & Security Audits 🕵️
PHP2Shell has raised the importance of security for a lot of folks, and now is a great time to get momentum and by-in from your boss to get a security audit of your app booked in. Reach out and I can give you all the details!
Found this security tip useful? 👍
Want to go deeper? 🤓
Upgrade to a Premium Subscription for exclusive monthly In Depth articles. Your support directly funds my security work in the Laravel community. 🥰
Need a second set of eyes on your code?
Book a Laravel Security Audit and Penetration Test - or, for something more focused, a lighter-weight Security Review.
Finally, connect with me on Twitter, Bluesky, phpc.social, and LinkedIn.
Keep reading
Subscription details
You are receiving this because you are a free subscriber to Securing Laravel.
Name: John Doe
Email: [subscriber]
Member since: 17 October 2026