Back to Trust Center

Security Advisories

Better ISMS (ISMS Copilot, heyGRC, Aevral) public security advisories and event disclosures.

Security update: how we handled this week's wave of disclosures

Published 23 October 2026 · Better ISMS (ISMS Copilot, heyGRC, Aevral)

On 21 October, four unrelated security disclosures went public within days of each other:

  • a critical remote-code-execution flaw in PHP ("PHP2Shell");
  • weak private keys in eight eMudhra certificate-authority intermediates;
  • four high-severity fixes in the October Node.js release;
  • a breach of customer environment variables at the hosting provider Railway.

We know many of you run compliance programmes yourselves, so here is exactly what we did, the way we would want a supplier to tell us.

Bottom line: we found no evidence that any customer data or credential was accessed. Our products stayed up throughout.

What we checked. Every asset in our inventory, the same night: production services, runtimes, certificates, our own infrastructure, and the third-party services we rely on. Where a service was reachable from the internet, we tested it live. Where it wasn't, we reproduced the issue in isolation.

What we changed.

  • PHP: one legacy marketing site, which held no customer data and no production credentials, ran on shared PHP hosting. We contained it the same evening, within minutes of my approval: it now only redirects, and PHP is never reached. We checked it for signs of access and found none.
  • Node.js: we moved every Node.js production service to the fixed release (22.23.4) between the evening of 21 October and the morning of 22 October. The one service where the bug was reachable was fixed first, the same evening.
  • Certificates: none of our 34 certificates is affected.
  • Suppliers: we checked our accounts with Railway and other affected vendors and found no exposure of customer data or of our keys. Our Railway account was unused and held none of our secrets; it will be deleted. We have asked the remaining vendors for written confirmation.

How we worked. We followed our ISO 27001-aligned incident response and change management procedures:

  • I approved every emergency change before it happened;
  • each was verified afterwards and has a one-step rollback;
  • every step is recorded with evidence;
  • we classified this as a security event, not an incident: no personal data was affected.

What we're improving. We caught this wave the same evening, but we caught it by hand, not through an automated feed. We are adding automatic intake of external security advisories and a supplier-breach playbook to our incident procedures.

If your security team wants the details for your own supplier review, write to security@ismscopilot.com. I'm happy to walk you through it.

Tristan Roth, CEO, Better ISMS