Node.js and PHP security releases: already rolled out on velixir

Yesterday was a big day for internet security. Node.js and PHP both published security releases on the same afternoon, and PHP's was the kind nobody wants to read: two critical bugs that can let someone run code on a server without logging in.

If your Node.js or PHP app runs on velixir, you don't need to do anything. We've already rebuilt it.

What was fixed?

Node.js 22.23.4 and 24.22.1 fix ten issues across the release lines, four of them rated high. They include a remote code execution bug in the Brotli decoder and a few ways around TLS certificate hostname checks.

PHP 8.3.36, 8.4.27 and 8.5.12 fix CVE-2026-109618 and CVE-2026-109619. Both can lead to remote code execution with no login, and the PHP team asks everyone to update immediately.

What did velixir do?

Two things.

First, every new build now ships the patched versions. For Node.js that's the official release binary, checked against its published checksum. For PHP it's the lowest patched version your composer.json allows, so a Laravel app asking for "php": "^8.2" builds on 8.3.36 rather than jumping straight to 8.5.

Second, the apps that were already running. Most apps aren't redeployed for weeks, and an app's runtime is whatever was current on the day of its last deploy. A fix that only reaches new builds doesn't protect much. So we rebuilt each running Node.js and PHP app from the exact source it was serving, with the same build variables, and rolled it out. PHP apps went first.

How do I check my app?

Open your app's releases. You'll see a new one, labelled as a rebuild with the runtime security updates. Its build log names the versions inside, for example "Node.js 24.10.0 replaced with the security release 24.22.1."

Is anything not covered?

A few cases, and the build log warns about each one:

• Node.js 20 and older, and 23. These are end of life, so there's no fix to ship. Set "engines": { "node": "22" } (or "24") in package.json and deploy.
• PHP pinned exactly to 8.2 or 8.1. A constraint like ~8.2.0 rules out every patched version we can build. Allow "php": "^8.3" and deploy.
• PHP projects with their own nixpacks.toml. We leave your file alone. The build log says the one line to add.

If your app's source is too old for us to rebuild, deploying it again does the same job.

Will this happen next time?

Yes. Next time Node.js or PHP ships a security release, it's the same routine: new builds get it straight away, and running apps are rebuilt and rolled out for you. Keeping your runtime patched shouldn't depend on someone remembering to press deploy.

New to velixir? Start here.