Our response to the Railway security incident and PHP2Shell vulnerabilities
Two security issues that could have affected us were disclosed on Wednesday 21 October. This post covers the checks we ran and the actions we took.
Two critical vulnerabilities surfaced in PHP, the language behind a large share of the world's websites. Then came a breach at Railway, a cloud hosting platform used by thousands of development teams. We use Railway to host parts of our service. To date, our investigations have shown we are unaffected by either incident, but we continue to monitor.
We build industrial AI for sites where a single mistake can stop a production line, so we started checking our exposure to both straight away.
Railway security incident
Railway has reported that an unauthorised third party may have accessed encrypted environment variables, which is where applications keep settings such as API keys and passwords. For some customers, the attacker may also have read the decrypted values. Railway believes the attack was part of a wider campaign against AI providers. It paused deployments and asked all customers to rotate every secret stored on its platform.
Railway has notified all of its customers about the incident, and we received that notice. It is separately contacting the customers it believes were directly affected. As of today, 23 October, Railway has not told us our environment variables were among those accessed, and we have found no evidence of suspicious activity. Even so, we followed Railway’s advice and took these steps.
We rotated the keys and passwords stored on Railway so that any copies taken would no longer work. We then reviewed access logs going back to a week before the disclosure, in case anything had happened before Railway detected it, and checked usage of the services those keys give access to, including our AI model providers.
We are continuing to monitor our systems and will contact customers directly if anything affects them.
PHP2Shell (CVE-2026-109618 and CVE-2026-109619)
Researchers, including Wiz, disclosed two vulnerabilities in PHP, which they named PHP2Shell, that let an attacker run code on a server without logging in. They affect nearly every version of PHP since 5.4 and are rated up to 9.2 out of 10 for severity. The UK’s National Cyber Security Centre advised patching straight away, or taking systems offline if that isn’t possible.
The researchers say they used AI models to help find the flaws and build working exploits, and that one researcher did in a week what used to take a team months. Attackers have the same tools, so we expect the time between a vulnerability being published and it being exploited to keep getting shorter.
That afternoon we checked our code, our hosting and nexusblack.com for any use of PHP, and found none. We build all of our applications, including our website, on a modern technology stack, and PHP is not part of it..
When customers asked whether our products were exposed, we were able to confirm within a day that they are not.
How we ran the checks
We ran both investigations through an incident bridge and a shared tracker. The checks themselves were quick because we generate a software bill of materials for every change to our core code, so we already had a record of what we run and where.