October 2026 Breaches Explained: PHP2Shell, Railway, LiteLLM, Onamae and Saudi Arabia.

In the week of 17 to 23 October 2026, attackers hit the layers that most websites and AI products are built on. Two critical flaws in PHP, the language behind 69.3% of websites with a known server-side language, pushed governments to take their own sites offline while they patched. A poisoned release of LiteLLM, a popular AI gateway, sat on the official package index for under two hours with a credential stealer inside. Railway, a cloud hosting platform, said an intruder may have read customers' secret keys, and crypto wallets were drained before the public notice went out. In Japan, a provider found malicious programs on servers it hosts for customers, suspended every plan and said 26,739 servers are potentially affected. In Saudi Arabia, criminal groups claimed breaches of a World Cup stadium contractor and a cloud ERP provider. This article explains each incident: how the attackers got in, when, what was exposed and what you should do today. The common lesson is simple: your data is only as safe as the keys that open it, AI now speeds up both attackers and defenders, and a human has to make the hard decisions within hours.

What happened in October 2026, in one table?

What is PHP2Shell and why did governments take websites offline?

PHP2Shell is the name given to two flaws, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. They sit in PHP itself, not in a plugin or a theme, so a site can be exposed even if its own code is perfectly written. That includes WordPress and Laravel sites, because both run on PHP. According to The Hacker News, nearly every PHP version back to 5.4 is affected, and the setup called Apache mod_php carries the highest risk because a single request without a login can trigger the attack before any application code runs. The flaws can also leak memory from the PHP process, which can expose passwords, tokens, API keys and certificates belonging to other visitors' requests.

The scale explains the panic. W3Techs measures PHP on 69.3% of all websites whose server-side language is known, as of 24 October 2026. When a flaw of this severity hits a language that common, there is no small target list.

The timeline shows how little time defenders had:

• 17 October: Amazon's honeypot network recorded an exploitation attempt four days before public disclosure. Amazon says it is unclear how the attacker had the details that early.
• 20 October: the CVE numbers leaked online, so PHP moved its security release forward by a day. That evening, one of the research firms mistakenly posted a video of its working exploit.
• 21 October, early hours: Cloudflare switched on firewall rules at 03:02 UTC and attackers changed their payloads to get around them.
• 21 October, afternoon: fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were released. At 14:19 UTC watchTowr reported active exploitation attempts against both flaws.

Some organisations decided the safest move was to switch off. In the Netherlands, the government's DigiD and MijnOverheid services, the website of the lower house of parliament and several education systems went offline as a precaution, and the HR software company BambooHR took its service down in the US, Canada and Ireland, The Hacker News reported. That was a human decision: accept a few hours of downtime rather than risk a breach.

There is also an AI story inside this one. The flaws were found by Wiz Research, the security firm Calif and OpenAI's Codex Security team, and the researchers said AI models helped them turn the bugs into working exploits. The same tools that help defenders find a decade-old bug can help attackers weaponise it within hours of a leak.

What should you do about PHP right now?

1. Find out which PHP version each server runs. Your hosting panel shows it, or a developer can run php -v. Many companies discover forgotten sites at this step: an old campaign page, a staging copy, a WordPress blog nobody updates.
2. Update to a fixed version. That means 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. Linux distributions sometimes ship the fix under an older looking version number, so check the package notes for the CVE numbers. For PHP 7.4, 8.0 and 8.1, PHP published source patches only, and PHP 8.2 reaches end of life on 31 December 2026, so plan the upgrade now.
3. If you cannot update today, reduce the risk or go offline. PHP lists partial measures such as disabling session upload progress (session.upload_progress.enabled=0) and enforcing request size limits. They do not close both flaws. Rapid7 advises updating on an emergency basis, outside normal patch cycles.
4. Check your logs back to 17 October, not just since the patch. Warning signs include unusual multipart requests followed by memory errors or repeated HTTP 500 responses, oddly large PHPSESSID cookies, unexplained PHP worker restarts and POST requests containing PHP_SESSION_UPLOAD_PROGRESS.
5. If anything looks wrong, change the secrets the site holds. Database passwords, payment gateway keys, email credentials and API keys stored in configuration files should be replaced, because the memory leak alone can expose them.

How did attackers poison LiteLLM, and who was affected?

LiteLLM is a widely used open-source gateway that lets companies route requests to different AI models through one interface, which means it often holds the keys to every AI provider a company uses. On 21 October, version 1.107.0 was published with a credential stealer inside it. StepSecurity's analysis gives the window: the malicious packages were uploaded to PyPI between 11:39 and 11:40 UTC and removed by 13:23 UTC, and the Docker tags pointed to infected images until 14:20 UTC.

The way in matters more than the malware. LiteLLM's maker says an internal deployment was exposed to the public internet, and its logs contained GitHub login tokens for three developers, one of them an organisation owner. The attacker used the owner's token to override branch protection and point the release process at a lookalike repository. According to The Hacker News, one account triggered the release and another approved it, so the usual two-person check passed with stolen identities. It was the project's second compromise this year, after an earlier one in March.

The payload ran whenever Python started on the machine, even if LiteLLM was never imported. It collected cloud credentials for AWS, Azure and Google Cloud, SSH and TLS private keys, browser passwords and cookies, credentials for more than 20 AI coding tools and, on LiteLLM proxy servers, the stored provider API keys. A background process then checked in every hour for new code to run.

If any machine or container installed 1.107.0 or pulled an affected image, treat it as fully compromised: rebuild it, pin version 1.106.2, and rotate every credential that machine could reach, from a clean device.

What happened at Railway, and why were AI keys the target?

Railway hosts applications for developers and startups, and stores their environment variables: the API keys, database passwords and tokens an application needs to run. On 21 October Railway disclosed that an unauthorised party may have accessed encrypted environment variables, and in some cases obtained their decrypted contents. It has not said how the attacker got in.

The timing is the painful part. Crypto.news lays it out: Railway paused builds at 07:24 UTC, the first known theft from a wallet whose private key was stored on Railway happened at 19:36 UTC, and the public disclosure followed at about 21:51 UTC. The researcher Taylor Monahan estimated losses at about $371,000 across at least 19 blockchain networks, an external figure Railway has not confirmed.

Railway said it believes the attack is part of a series targeting platform companies with the aim of compromising AI inference providers. In plain terms, AI API keys have become a prize: a stolen key lets someone run expensive AI workloads on your bill or reach whatever data your AI integration can see. Railway told customers to rotate their variables and private registry credentials, review logs, redeploy with new storage credentials and reconnect GitHub.

A smaller platform shows what happens when the cleanup is incomplete. Zeabur, a hosting platform, was breached in August, then again on 14 and 15 October with admin credentials that had been missed in the August rotation. BleepingComputer reports that the admin tokens had no expiry and had not been rotated since they were created in January 2024. The second breach exposed information on 321,810 accounts and over 3.2 million environment variable records, and the company announced it is shutting down by 31 December 2026.

What happened to Onamae Desktop Cloud in Japan?

Onamae Desktop Cloud is a virtual server service run by GMO Internet, marketed to people who run automated currency trading software around the clock. In its second report, GMO says an investigation began on 19 October after a customer inquiry, and on 20 October it confirmed that a malicious program had been installed in the server environments of some customers. It suspended the control panel and new sign-ups, then from 04:00 Japan time on 21 October began shutting down servers on all plans. In total 26,739 servers are potentially affected.

GMO warns that information stored on the servers, including passwords for trading tools and trading accounts, may have been viewed by a third party, and it says customers reported unauthorised operations on trading accounts. It consulted the police on 22 October. The intrusion route is still under investigation. Customers were told to change their trading passwords from a different device, check balances and transaction history, turn on two-factor authentication and change any password they reuse elsewhere.

The lesson for any company that rents servers: when the provider's infrastructure is breached, everything stored on your server is exposed, even if you did nothing wrong. Passwords saved on a server should be treated as if they could be read by someone else one day.

What happened in Saudi Arabia?

Two claims made headlines this month. Both come from the attackers and neither has been confirmed by the companies named.

• The Jeddah stadium contractor. A group known as WallStreet claimed it compromised the Sama Construction consortium, which includes China Railway Construction Corporation, on 3 October. The UAE-based analysis firm Hackmanac described the consortium as the main contractor for Jeddah Central Stadium, a planned 2034 FIFA World Cup venue. The claim covers more than 1.5 million files, about 17 terabytes, including contracts, payment information, stadium designs and personal data of 150,000 employees. The company had not responded to The National's request for comment.
• A Saudi cloud ERP provider. On 13 October the ransomware group HYFLOCK publicly claimed an attack on Nodhom, a Saudi cloud ERP provider, and threatened to publish data unless the company contacted it. The type and volume of data were not stated, and there is no independent confirmation.

Even as claims, both carry a clear message for companies in Saudi Arabia and the Gulf. Your data does not live only in your own systems. It sits with your contractors, your consultants and every cloud tool your teams use, including the ERP that holds your accounts and payroll. Ask each vendor three questions: how do you protect the keys to our data, how fast will you tell us about an incident, and can we export our data if we need to leave.

The law also sets a clock. Under Saudi Arabia's Personal Data Protection Law, controllers must notify the data authority SDAIA within 72 hours of becoming aware of a breach that may cause harm. In Egypt, the executive regulations of Law 151 of 2020 require reporting to the Personal Data Protection Center within 72 hours and notifying affected individuals within three working days. You cannot meet those deadlines if nobody notices the breach.

What do all these incidents have in common?

• Keys were the prize. Environment variables, API keys, GitHub tokens and saved passwords appear in almost every incident above. Attackers increasingly skip your front door and go straight for the keys stored in your hosting, your build tools and your servers.
• Stolen tokens opened the door. LiteLLM, Zeabur and the OVHcloud command-line tool were all entered with valid credentials, not clever exploits. In the OVHcloud case, a hijacked contributor account replaced release files for 94 minutes.
• AI is on both sides. AI helped researchers find and exploit PHP2Shell. Attackers went after AI keys at Railway. And Reuters reported that one hacker used autonomous AI agents to break into more than 100 company websites in a couple of weeks, with instructions under 100 Chinese characters and an estimated $50 in AI costs per successful hack.
• Speed decides the damage. PHP2Shell was being probed before the patch existed. At Railway, wallets were drained more than two hours before the disclosure. The gap between "something is wrong" and "the damage is done" is now measured in hours.

Why is AI not enough, and where must a human step in?

AI is now part of good defence. It can scan every server for vulnerable versions in minutes, read logs no person has time to read, and flag a strange login at 3 a.m. But look at who made the decisions that limited the damage this month:

• At OVHcloud, a customer's automated build job had pinned the exact fingerprint of a file and started failing when the file changed. A person then filed a public report at 13:50 UTC and the malicious files were deleted at 14:21 UTC. The machine raised the alarm; people acted on it.
• At Onamae, the investigation started from a customer's inquiry.
• In the Netherlands and at BambooHR, people chose a few hours of downtime over the risk of a breach.
• At Zeabur, the failure was human too: admin tokens that should have been rotated after the first breach were left in place, and the second breach ended the company.

The model that works is clear. Let AI watch, sort and alert at machine speed. Let a named person decide what to switch off, which keys to rotate, what to tell clients and when to notify the regulator, and log every one of those actions. We explain how to set those rules in our guide to AI governance: permissions, data and approvals, and why human judgment still matters in our summary of where AI hits its limits.

What should your company do in the next 24 hours?

1. Make a list. Every website, server and cloud platform you use, the PHP version on each, and every place your API keys and passwords are stored.
2. Patch or pause. Update PHP to a fixed version. If a site cannot be updated today, consider taking it offline until it can.
3. Check the specific products. Did anyone install LiteLLM 1.107.0 or the OVHcloud CLI on 19 October? Do you host on Railway, Zeabur or Onamae Desktop Cloud? If yes, follow each provider's instructions above.
4. Rotate secrets from a clean machine. Change keys and passwords from a device you trust, not from the server that may be compromised, and revoke the old ones.
5. Turn on two-factor authentication for hosting panels, GitHub, cloud consoles, payment gateways and email.
6. Read the logs back to 17 October. Use automated tools to find the anomalies, and have a person review what they flag.
7. Prepare to notify. If personal data may have been exposed, the 72-hour clock in Egypt and Saudi Arabia starts when you become aware. Decide now who is responsible for that call.

Breaches do not always look like a ransom note. We have seen this first-hand: in our PCE case study we explain how we cleaned a hidden hack that filled a client's site with Japanese spam pages in Google results.

If your website or system runs on PHP, or your API keys live on a hosting platform, do not wait for the next headline. Contact the HBS team and we will help you check your PHP version, close the gaps, rotate your keys safely and set up monitoring that combines automated alerts with a person who acts on them. If we build or maintain your site, our web development team can schedule the update with you today.