By Omar Moulani, WeGetDesign.
Thirty-two government services unavailable. Four more partially unavailable. Those were the figures given to the House of Lords on 22 October as organisations responded to critical PHP vulnerabilities. The minister said the disruption arose largely from precautionary measures, with no confirmed compromise of central government systems at that stage.1
Taking a service offline was part of protecting it. For anyone running a business application, that is an uncomfortable decision: interrupt the service customers depend on, or leave it running while the team assesses the risk.
In the same month, Railway and Bubble reported security incidents involving access to parts of their infrastructure and credentials. The causes and scope differed. Read together, their accounts show why a business needs more than an assurance that its supplier takes security seriously. It needs to know who can act on an alert and what safe recovery looks like.
The warning was large. The response had to reach individual systems.
PHP is software running underneath many websites. On 21 October, the PHP project released fixes for two critical vulnerabilities that could allow an attacker to execute code without authenticating. A website could need urgent attention even if its visible pages and content management system appeared normal.2
The NCSC advised organisations to identify affected installations and apply updates, prioritising internet-facing systems. Where temporary mitigations could not be applied promptly, its guidance included considering taking the system offline.3
The government’s response also involved advance coordination with vendors and departments. The minister reported 50,000 proactive NCSC notifications to the wider economy.1
That figure describes the distribution of warnings. The next step belongs to the organisation receiving one. Someone needs to identify the affected service, reach the person responsible and confirm that the fix has actually been applied.
For a smaller business relying on managed hosting, I would ask the provider to explain which component was affected and how remediation was verified. For an internal team, I would want a named person able to authorise downtime and communicate it to customers. These responsibilities are easier to agree before an alert arrives.
Railway and Bubble show why the credentials matter too
Patching software addresses a vulnerability. Exposed credentials create another problem: the access they grant may continue until those credentials are disabled.
An API key is a credential that lets one system use another service. Depending on its permissions, it might allow access to data, administrative actions or paid computing resources. Replacing a value in your application is only one part of removing that access.
Railway’s preliminary report put its potential scope at no more than 1.85% of workspaces, approximately 100,000, with some environment variables potentially compromised. It said a subset of stored secrets had been decrypted during the intrusion.4
Railway also requested wider precautionary revocations from upstream providers. That distinction matters when an email arrives saying a key has been reset: the notice alone does not prove that the recipient’s credential was stolen or misused. It can still require urgent work to restore an integration safely.4
Bubble’s incident began on 26 October. Its initial notice reported unauthorised access and exposure of third-party credentials for a subset of users. Parts of the platform were deliberately interrupted during containment.5
The later detail was narrower. Bubble identified private keys in plugin metadata and downloads from publicly viewable app editors. At that stage, it reported no evidence of access to private app data or credentials stored inside non-public applications. Its forensic investigation remained open.5
That later account deserves to be read alongside the first warning. It helps a business understand which guidance applies without treating an interim finding as a final clearance. Bubble advised checking editor visibility, reviewing connected accounts for unusual usage and following its guidance on when to replace credentials.5
AI is involved, but the explanations still need evidence
Railway believes its attacker was seeking AI-provider keys for model distillation. That is its assessment of this incident, rather than a confirmed explanation for everything that happened in October.4
AI also helped the defenders. The PHP Foundation describes using AI tools to audit code and validate reports, alongside researchers and engineers who assessed the findings and developed fixes.6
There is enough here to take the risk seriously without assuming one attacker, one campaign or one cause. For a business, the practical concern is what each connection permits and how quickly that access can be withdrawn.
What we’ve learnt at WeGetDesign
For us, the clearest lesson is that responding to a security alert means understanding the whole connection: the supplier holding a credential, the access it grants and every service that depends on it. Replacing a key is one task within that response. Knowing what it can do, where it is used and how to disable it makes the response manageable.
That starts with keeping a useful record of integrations and their owners. Include background jobs, plugins, test environments and older services that are easy to overlook. Review permissions while doing it, so an integration has only the access it needs. Financial controls deserve the same scrutiny: establish which settings stop usage and which merely send an alert.
We also want the evidence to come from both ends of the connection. Application logs show what the app did; provider-side activity can help identify use of a credential elsewhere. Record what was checked and any gaps in visibility, so a reassuring result is not mistaken for a complete picture.
Recovery needs testing too. During a Bubble version-restore test on 27 October, we saw an old API key return to the app’s configuration. That did not make a provider-revoked key valid again, but it showed why rollback belongs in the exercise. Follow the supplier’s containment guidance, update every service using the credential, test the important user journeys and verify that old access has been revoked at its provider. Active abuse may require immediate revocation and accepted downtime.
The organisational lesson is just as practical: agree who receives supplier warnings, who can authorise an interruption and who keeps customers informed. Those decisions should be clear before the team is trying to restore a service.
The supplier still has to secure its systems. A customer’s response plan cannot excuse poor security or compensate for every architectural weakness. These incident accounts are also provisional, checked on 27 October, rather than final findings.
We would start with one important integration and walk through the whole response, from the first warning to verified recovery. The result should be a named owner, a clear record of dependencies and evidence that the service works while retired access stays disabled.
Last checked: 27 October 2026.