A Bad Week for the Web: PHP, Railway, and What to Do

I started looking into this after several hosting providers emailed me about PHP vulnerabilities on my VPS instances. Usually, I glance at those notices. This time, there were enough of them that I stopped and dug in.

It turned out to be one part of a rough week: critical PHP vulnerabilities, exposed customer secrets at Railway, and compromised certificate-signing keys at eMudhra. Node.js also shipped an important security update.

I covered the incidents in the video version of this article. Here, I want to separate what happened from what you actually need to do.

Checked October 23, 2026. Security investigations are ongoing; the linked advisories are the source for subsequent updates.

What needs your attention right now?

• Running PHP on a public server? Install the security fix for your PHP branch or your distribution's patched package, then restart the affected workers. Also check the October 23 session upload progress guidance below.
• Using Node.js? Update your deployed runtime to a release containing the October 21 security fixes.
• Storing secrets in Railway? Revoke and replace potentially exposed credentials at their issuing services, update your applications, and review usage.
• Just browsing the web? Keep your browser and operating system current. Chrome and Firefox already distributed emergency blocks for the affected certificate authorities.

These are different jobs. Patching a server does not invalidate a stolen API key, and changing a key does not repair the runtime.

PHP2Shell: your application can be clean and still be vulnerable

The two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, sit in the engine underneath your application. They concern memory handling and state left behind between requests. Updating WordPress or Laravel alone will not fix them.

Under exploitable conditions, an unauthenticated request can lead to remote code execution. With Apache's mod_php, researchers demonstrated an attack that starts before application code runs. PHP-FPM is also affected, although the exploit paths and demonstrated impact differ from mod_php. PHP advises all installations serving web requests to update. The PHP Foundation's explanation and the detailed OOM advisory describe those differences.

Think of it as a problem with the building's front door. A better lock on your apartment does not fix it.

The vulnerability is in PHP itself. The attack paths differ between mod_php and PHP-FPM, but both need the security update.

The first advisory describes corruption during out-of-memory handling. The second advisory covers stale internal state surviving after the memory behind it has been freed. Both received a critical CVSS v4.0 score of 9.2.

That is serious enough without rounding it up to 10. And a statistic about how many websites use PHP is not a count of exploitable sites, much less a count of hacked sites. Keep those claims separate.

Patch PHP, then verify the running service

The upstream fixes released on October 21 are:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Use the fixed release for your branch or a later release containing the fixes. Distribution packages may backport the patch while retaining an older upstream version number. Check your package vendor's advisory rather than judging the version string alone.

Restart the affected PHP workers or web-server processes after updating. For containers, rebuild with the patched runtime and replace the running instances. A patched package sitting on disk does not help a worker still running the old code.

Managed hosting changes who applies the fix. It does not remove the need to confirm that it happened.

PHP 8.1 and older are outside upstream support. The security team provided minimal source backports for 7.4, 8.0, and 8.1, but those are emergency source patches, not a return to regular support. Check your vendor or move to a supported branch. See PHP's release advisory.

An October 23 follow-up you should also check

PHP's October 23 follow-up concerns CVE-2026-115560, an unusual configuration-dependent path. It requires session upload progress to be enabled, with session.serialize_handler configured as php_binary or php_serialize and then switched to php at runtime before session_start(). PHP advises setting session.upload_progress.enabled=0 until the next regular bugfix release; applications that never change the serialization handler at runtime can keep the feature enabled.

Apply that setting in the active php.ini or the relevant server or PHP-FPM pool configuration, then restart the affected workers. Setting it inside your application with ini_set() will not work: the setting requires per-directory or server configuration.

This is additional guidance, not a replacement for patching. Check the October 23 session upload progress notice for the conditions and current recommendation.

Node.js needs an update too

On October 21, Node.js released fixes for ten vulnerabilities. One of the high-severity issues, CVE-2026-111497, affects its Brotli decoder: malformed compressed data can corrupt process memory and potentially lead to code execution.

Your application does not have to expose an obvious upload endpoint to process untrusted compressed data. Fetching a compressed response is another route by which external data can reach a decoder.

The security releases are 22.23.4, 24.22.1, and 26.12.1. Install the appropriate release or a later version containing the fixes, then redeploy or restart the application. These releases also include certificate changes responding to the eMudhra incident. The Node.js security announcement lists the affected components and downloads.

For a deployed application, check the runtime in the running environment. Updating Node on your laptop does not update the container or server serving your users.

Railway: secrets were the problem, and deployments were paused

I have several Railway projects, so this one got my attention immediately.

In its October 21 disclosure, Railway said an unauthorized party may have accessed encrypted customer environment variables and obtained the decrypted contents of some of them. It recommended that all users rotate stored secrets and private registry credentials, even though its initial assessment suggested only a subset of users might be affected.

Those variables can hold database passwords, cloud credentials, and API keys. Encryption at rest does not protect a secret once someone has obtained its readable value.

Railway paused deployments during the investigation. That made the usual response painful: customers could revoke a key, but could not immediately deploy its replacement. Keeping an application available and stopping unauthorized credential use became competing priorities.

By the October 23 status updates, builds and deployments were proceeding normally across all plans. Railway was still investigating and notifying customers. That distinction matters: restored deployments do not mean old secrets are safe. Check the incident timeline for the latest state.

Rotate credentials at the source

Do this for every Railway project storing credentials. Railway recommended rotation for all users while its investigation continued, so do not wait for confirmation that your account was affected. Work through the actual secrets and the services that issued them:

1. Identify credentials stored in Railway. Include database access, cloud services, AI providers, private registries, and other integrations.
2. Invalidate the old credentials with each issuer. Deleting a value from a hosting dashboard does not stop the original key working elsewhere.
3. Create replacements and update every consumer. Follow the provider's rotation procedure, redeploy as needed, and verify the application connects successfully.
4. Review access, usage, and billing history. Look for unfamiliar activity and preserve relevant logs.

If you suspect active misuse, do not leave a credential usable just to avoid downtime. For database credentials and other shared access, account for every service using them so you can restore those connections deliberately. Railway's PostgreSQL rotation guide is one example of the provider-specific steps involved.

The issuer must stop accepting the old credential. Removing it from Railway alone does not revoke it.

AI keys are credit cards for compute

Railway believes the incident was part of attacks on platform companies aimed at compromising AI inference providers. That is still its assessment, rather than confirmed attacker attribution.

The incentive is easy to understand: a stolen API key can let someone run models on your account. It turns access to a configuration system into access to something they can spend.

Give each application separate credentials wherever possible. Scope their permissions, use provider spending controls where available, and enable usage alerts. An alert helps you notice a problem; it does not necessarily stop charges.

Check model usage as well as the total bill. A sudden spike is obvious. A model or workload your application never uses may be a useful clue too. Railway published OpenAI usage guidance and Anthropic usage guidance for that review.

eMudhra: the keys were weak enough to recover

The third incident affected the trust behind HTTPS.

A certificate authority helps a client decide whether a certificate belongs to the site it is connecting to. A trusted root can certify an intermediate authority, which can then issue website certificates.

Eight eMudhra intermediate keys were compromised: six associated with TLS and two with code signing. The issue was not simply that someone copied a securely generated private key. Mozilla's investigation found the affected P-384 private values were integers smaller than 256, making them trivial to recover. That leaves fewer than 256 possible private values to try. eMudhra described errors in its key-generation process. See the public incident report.

A compromised intermediate can enable forged certificates. An attacker would still need a client that trusts the chain and a way to direct or intercept its connection. Possessing the key does not automatically reveal every encrypted session on the internet.

Certificate impersonation also requires a client that still trusts the chain and a way to intercept or redirect its connection.

Chrome and Firefox distributed emergency blocks on October 17. Chrome also reported that no TLS certificates chaining to the six affected intermediates had been logged to Certificate Transparency before its block, limiting what could have been accepted under its default checks. The browser vendors' response thread documents the protections.

For ordinary browser users, keep updates enabled. For developers maintaining custom trust stores or older clients, verify how those clients receive revocation and trust changes. Do not assume a browser's automatic protection applies to every runtime.

AI makes the time between discovery and action matter more

There is an AI connection here, but the failure modes themselves are familiar.

The PHP Foundation describes AI-assisted research by Calif, OpenAI, and Wiz in its account of finding and fixing the vulnerabilities. In Railway's case, valuable AI credentials appear to be part of the incentive. The certificate incident is a failure in key generation and the controls around it.

Memory corruption, stolen credentials, and broken cryptographic processes all predate today's models. AI can accelerate work on those problems for defenders and attackers alike.

My takeaway is practical: verify that the patched worker is serving requests, the old key no longer authenticates, and the application still works after the change.

AI can make us more productive. It gives attackers that same advantage. The response starts with taking the patch email seriously.