On 21 October 2026, five serious security problems went public on the same day. Two of them, in PHP and in GitLab, let a stranger run their own code on a server without logging in. If you run a WordPress site, a shop, a Node.js app or anything on Railway, this list applies to you. It cannot wait until next week.
First: who looks after your server
On ordinary shared hosting, the hosting company updates PHP. On a VPS, in containers, or on a server someone set up for you years ago, the update is on you or on whoever maintains that server. Send them three questions today:
- Which PHP and Node.js versions does my site run in production, not on your laptop?
- Since 21 October, have PHP and Node.js been updated to a fixed version and the server restarted?
- Do we have any server or secret on Railway or on a self-hosted GitLab?
PHP2Shell: a critical flaw in PHP itself
Two flaws (CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10) sit in PHP, in the part that reads the incoming request before your site’s code runs. So the security of WordPress, Drupal or Joomla has no say here. Apache with mod_php, PHP-FPM, CGI, FrankenPHP and LiteSpeed are all affected. Details leaked before the planned disclosure, and attack attempts are already being seen.
What to do:
- Upgrade PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. There is no official fix for 8.1 and older: move to a supported branch or install a patched package from your Linux distribution (Ubuntu and AlmaLinux have shipped them).
- Updating WordPress, plugins or Composer packages changes nothing. The bug is in PHP, not in your app.
- After upgrading, restart every PHP worker and rebuild and redeploy your containers. Check the version the web server runs, because the command-line version can differ.
- If you cannot patch today, take the server off the internet or restrict who can reach it. A WAF only helps if nobody can skip it and reach the server directly.
GitLab: 10 out of 10, if you host your own
CVE-2026-110264 lets an unauthenticated attacker run code on a GitLab server through a crafted regular expression. The code runs as the git user, which can reach every repository, CI variable and token. Versions back to 7.0 are affected. GitLab.com and GitLab Dedicated are already patched.
- Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, following the official upgrade path. There is no workaround.
- If the server was reachable from the internet, rotate its secrets and tokens. A patch closes the hole, but it does not take back what may already have leaked.
Node.js: ten fixes, four of them high
The most serious one (CVE-2026-111497) is a bug in Brotli decompression that can lead to code execution. The malicious data can arrive in a request to your server or in a response from a service your server fetches from, so a firewall in front covers only half of it. Three more weaken hostname and TLS certificate checks.
- Upgrade Node.js to 26.12.1, 24.22.1 or 22.23.4.
npm audit fixwill not help, because the bug is in Node.js itself, not in a package. - Node.js 20 and older get no fix. Move to 22 or 24.
- Rebuild your images, restart, and check the version in every running copy of the app.
eMudhra: weak certificate authority keys
The certificate authority eMudhra generated eight intermediate keys so badly that the secret part can be worked out from the public one almost instantly. Someone between you and a website, on public Wi-Fi for example, could present a fake certificate. No misuse has been seen so far, and Chrome, Apple and Microsoft already block these certificates.
Software with its own list of trusted certificates is the weak spot: Node.js (one more reason to upgrade), Python (update certifi, pip, uv), Go programs (rebuild with the new Go release), Firefox and NSS. Never switch off certificate checks to make an error go away.
Railway: rotate every secret
Railway disclosed that an attacker may have accessed customers’ encrypted environment variables and read some of them. The company believes only a subset of users is affected, but asks everyone to rotate their secrets. Those variables hold the keys to your database, cloud, Stripe, GitHub and AI APIs, and a stolen key works without ever touching your app.
- List every secret in every project and environment.
- Revoke each one where it was issued (Stripe, AWS, GitHub, OpenAI, Anthropic). Changing the variable in Railway alone does not stop a stolen key.
- Put the new key into Railway and redeploy every service. A running app keeps the old value until it is redeployed.
- Check each provider’s usage logs, especially AI spend, for anything you do not recognise.
Today’s order
| Order | What | Who it affects |
|---|---|---|
| 1 | PHP and GitLab | Any internet-facing server with PHP or a self-hosted GitLab |
| 2 | Secret rotation | Anyone using Railway |
| 3 | Node.js | Apps and tools running on Node.js |
| 4 | Certificate lists | Servers and scripts using Python, Go, Node.js |
For every fix the steps are the same: check what actually runs in production, install the fixed version, rebuild and restart, check the version in production. Whatever you cannot patch today, cut off or restrict.
Sources: Academind video, Help Net Security on PHP2Shell, The Hacker News on GitLab, The Hacker News on Node.js, BleepingComputer on eMudhra, The Hacker News on Railway. Status as of 22 October 2026.