PHP, eMudhra and Railway: security incidents this week and how Pazy stayed protected

Three security incidents were disclosed this week. Two did not apply to Pazy. The third, a set of compromised eMudhra certificate keys, needed a patch, and we finished it on the night of October 21. Pazy stayed protected throughout.

The incidents were unrelated and came out between October 17 and 21, 2026: a compromised set of eMudhra certificate authority keys, two PHP runtime vulnerabilities known as php2shell, and an exposure of customer environment variables at Railway. Below is what happened with each of this week’s incidents and how we checked our exposure. This post reflects information available on October 23, 2026, and some of it is still changing.

Pazy moves about $5 billion a year for businesses, so we treat every public security disclosure as something to assess, whether or not it looks relevant to us. We monitor public security advisories and vendor disclosures as part of our incident-response process; all three incidents came to our attention through those channels within hours of public disclosure.

At a glance

php2shell: PHP runtime vulnerabilities

What happened. On October 21, Calif.io, Wiz, OpenAI and Quarkslab disclosed two memory-handling vulnerabilities in PHP itself. They affect PHP 5.4 and later, and specially crafted HTTP requests can cause denial of service, remote code execution or exposure of data. Both are flaws in the runtime, so updating application code or plugins does not fix them. The PHP runtime has to be updated, or the hosting provider has to do it.

Our assessment. Pazy does not run PHP anywhere in the organisation. We are not affected by these vulnerabilities and no action is needed on our side.

eMudhra: compromised intermediate CA keys

What happened. On Saturday, October 17, an independent security researcher reported that the private keys behind eight eMudhra intermediate certificate authority certificates had been generated with insufficient randomness. Because the keys are weak, anyone could derive them and forge a certificate for any domain, then use it to impersonate a server and intercept or modify traffic against clients that still trusted those authorities. eMudhra attributes the weakness to a flaw in its key generation ceremony, says its systems were not breached, and says none of the intermediates issued end-entity certificates. Chrome reported finding no certificates chaining to the affected intermediates in Certificate Transparency logs before it blocked them. This is a certificate-trust problem rather than a weakness in TLS encryption itself.

Credit. Thanks to the researcher who reported it, and to the Chrome Root Program and Mozilla security teams, who blocked the affected certificates within hours of receiving the report, days before it was public.

Timeline

Times are UTC where given. Pazy’s entries are approximate local times.

Fixing it means updating whatever decides which certificate authorities to trust: browsers, operating systems, language runtimes, container images and bundled trust stores. An HTTP library, language runtime or operating system may do the certificate verification, so updating an SDK alone may not change the policy. When certificate errors appear after patching, the fix is never to turn verification off, because that removes the protection the update restores.

Our assessment. We have no direct integration with eMudhra. Our exposure is indirect, because any service that makes outbound HTTPS calls relies on a trust store that comes from its runtime or container image. By the night of October 21, we had patched our trust stores and untrusted all eMudhra certificates. Our review also found a small number of internal trust-store configurations that needed updating, and those have been fixed. No customer data was at risk and no transaction was affected.

What we did

• Patched all of our trust stores and untrusted all eMudhra certificates, completed by the night of October 21.
• Updated the internal trust-store configurations that our review turned up.
• Checked for services that bundle or pin their own list of trusted authorities.
• Verified each application through its actual TLS path, because a passing browser test does not prove a background service is protected.
• Prioritised services that handle financial traffic, since those are the most valuable connections to intercept.

All of this is complete.

Railway: exposure of environment variables

What happened. On October 21, Railway detected anomalous activity involving systems that store customer environment variables. Its investigation indicates that an unauthorised third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Railway believes this is part of a series of attacks on platform companies aimed at compromising AI inference providers, and has notified those upstream providers to revoke keys. It recommends that all users immediately roll every environment variable stored in Railway, including API keys and private registry credentials, and review logs for unusual activity.

As of the status page update on October 23 at 09:34 UTC, builds and deployments were running normally again and new signups remained paused. Railway expected to publish a preliminary incident report around midday Eastern Time on October 23.

Our assessment. Pazy does not use Railway anywhere in the organisation, and no user data is stored on or moves through it. We are not affected by this incident and no action is needed on our side.

Summary

• php2shell (PHP): Pazy does not run PHP anywhere in the organisation, so we are not affected.
• eMudhra: we had no direct integration, but certificate trust is shared by every service that makes outbound HTTPS calls. All trust stores were patched and all eMudhra certificates were untrusted by the night of October 21, and the follow-up checks are complete.
• Railway: Pazy does not use Railway, and no user data is stored on or moves through it, so we are not affected.

No action is outstanding on any of the three.

We publish this because security is not a side concern for Pazy. Businesses trust us with their money and their banking connections, and that trust is the product. As of October 2026, we are certified to ISO 27001:2022, hold SOC 1 Type 2 and SOC 2 Type 2 reports, and undergo vulnerability assessment and penetration testing (VAPT). When something is disclosed, we assess it and would rather tell you what we found than stay quiet. You can read more at the Pazy Trust Center, or reach us at security@pazy.io with questions.

Sources

• Cloudflare: 8 eMudhra certificates are compromised. Here’s what you need to know
• Calif.io: php2shell
• Wiz: php2shell PHP RCE
• OpenAI: Coordinated disclosure of critical vulnerabilities
• Cloudflare: Cloudflare deploys protections against php2shell vulnerability
• Mozilla: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Google: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
• eMudhra: Statement on Recent Certificate Security Incident
• Railway: Security Disclosure, Wednesday October 21st
• Railway status