Check the PHP runtime serving your website after the October security update

Merradou Abderrahmane — Thu, 22 Oct 2026 18:00:07 +0000

PHP released fixes on October 21 for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can allow unauthenticated remote code execution. PHP-FPM users need to update too.

The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or vendor packages containing equivalent fixes.

I covered the advisories and the European response in my full article on Medium. Here are the deployment checks from it.

Check the version your website actually uses

First, verify the PHP runtime serving web requests. php -v checks your command-line installation; your website may use a different version.

Then check every deployed instance: containers, additional servers, staging environments exposed to the internet, and older applications still running quietly somewhere.

Install the update, restart the relevant services or replace the containers, and confirm the running workers use the patched build. Test the application's important flows after deployment.

A vendor may patch an older package without changing its upstream version number. Check its security notice before relying on the number alone.

Updating Composer or your project dependencies does not install these PHP runtime fixes.

If someone else manages your hosting

Send them the advisory and ask them to confirm which patch is running. If you manage the servers yourself, check the deployed environments before closing the ticket. It is easy to update one machine and leave another behind.

PHP's official announcement has the update instructions and the limits of temporary mitigations.

Have you received confirmation from your hosting provider, or are you still waiting for the patched packages?

Someone Poisoned Laravel's Most Trusted Packages — 233 Versions, 700 Repos

Merradou Abderrahmane — Mon, 25 May 2026 13:31:43 +0000

On May 22, 2026, an attacker spent exactly 15 minutes on a keyboard.

When they were done, 233 versions of widely-used PHP packages had been silently replaced with credential-stealing malware. 700 GitHub repositories were compromised. And every developer who ran a routine composer update that day potentially handed over their AWS keys, SSH keys, database passwords, and crypto wallet files to a stranger on the internet.

No alarm fired. No error was thrown. The official GitHub repositories looked completely clean.

TL;DR

What: Supply chain attack on the Laravel-Lang ecosystem — May 22, 2026
How: Attacker rewrote every version tag across 3 packages to point at a malicious fork — without touching the official repos' commit history
What it stole: Cloud credentials, SSH keys, browser passwords, crypto wallets, CI/CD secrets
Who's at risk: Anyone who installed or updated laravel-lang/http-statuses, laravel-lang/actions, or laravel-lang/attributes on or around May 22
Action needed: Rotate your credentials now

Are You Affected? Check This First

Run this in your project:

grep -E "laravel-lang/(http-statuses|actions|attributes)" composer.lock

If any of these three packages appear and your dependencies were updated around May 22, 2026 — treat your environment as compromised and rotate everything immediately.

What Happened — The 15-Minute Timeline

Three packages were hit in a coordinated attack:

Time (UTC)	Package
23:41	`laravel-lang/http-statuses`
23:45	`laravel-lang/actions`
23:56	`laravel-lang/attributes`

15 minutes. 3 packages. Every version tag. Rewritten.

The Clever Part — Why the Repo Looked Clean

This is what makes this attack different from a typical "bad package on Packagist" incident.

GitHub allows version tags to point to commits in a fork — not just the official repository. The attacker used this to:

Create a malicious fork with credential-stealing code
Rewrite every existing version tag in the official repo to point at their fork's commits
Let Packagist serve the malicious code to anyone running composer update

If you visited the official Laravel-Lang repos on GitHub that day — nothing looked suspicious. Clean commit history. Clean code. The poison was completely hidden inside a fork no one would think to check.

👉 The full breakdown is in the complete article:

Read the complete writeup on Medium →

It covers:

The exact mechanism of the autoload.files payload
The full list of credentials targeted (AWS, SSH, CI/CD, crypto wallets, browser passwords)
Step-by-step recovery instructions
The three rules that would have protected you

If this helped you or your team, share it. The faster this reaches the Laravel community, the faster affected developers can protect themselves.

DEV Community: Merradou Abderrahmane