← Back to blog
Company UpdateOctober 25, 2026

Our Response to the October 2026 Software Security Incidents

Three security weaknesses were disclosed across the software industry in October 2026. None originated at Valiance. We checked our exposure to each within days and used the moment to strengthen our defences further.

In the week of 17 October 2026, three security weaknesses were disclosed across the wider software industry. None originated at Valiance, but because modern software is built on shared open-source components, responsible providers check themselves against every such disclosure. We did, within days, and took the opportunity to strengthen several defences further.

What was disclosed

  • A compromised certificate authority (eMudhra). Certificates are the digital "ID cards" that let one system confirm it is talking to the genuine other system and not an impostor. In October, Mozilla reported that "the private key of 8 eMudhra Intermediate certificates have been compromised" (Mozilla incident record). A forged certificate matters because of a man-in-the-middle attack: an attacker sitting on the network between two systems could impersonate one of them and read or alter what passes between them. Firefox and Chrome have blocked the affected certificates since 17 October, and Mozilla removed trust in eMudhra's parent root to "protect clients which do not use revocation information."
  • A breach at a cloud database provider (PingCAP), disclosed in PingCAP's security incident report.
  • Critical vulnerabilities in the PHP programming language (PHP2Shell), flagged by Malaysia's National Cyber Coordination and Command Centre in NC4 advisory NC4-ALR-2026-000011.

Were Valiance or its clients affected?

We have found no evidence that they were. Taking each in turn:

  • Certificates. Valiance has never used eMudhra as a certificate issuer. Our own websites and services present certificates from a major, unaffected authority, so anyone connecting to Valiance was never relying on an eMudhra certificate. eMudhra's root was, however, present in the standard trust lists built into common open-source components, as it was for most of the industry, and we removed it regardless. The affected certificates show no record of use in the public Certificate Transparency logs, and we have found no indication that this weakness was used against Valiance.
  • PingCAP. We have never been a PingCAP or TiDB Cloud customer.
  • PHP2Shell. We do not run PHP anywhere in our systems, so these vulnerabilities do not apply.

What we did

  • Removed the compromised certificate everywhere. Every server and service we operate now runs without eMudhra's affected root, and an automated safeguard blocks any future build that would trust it again. One third-party component is awaiting an update from its own vendor.
  • Strengthened sign-in security. We replaced the keys that protect user sessions and made sign-in tokens stricter. As a result, users were asked to sign in again once.
  • Tightened how customer data connections are authorised. Each customer data connection that uses our cloud query service now requires a unique, customer-specific key in addition to Valiance's own identity, so a connection intended for one organisation can never be turned toward another's data.
  • Reduced reliance on long-lived credentials. Where possible, our systems now authenticate using temporary, automatically-rotated credentials scoped to the minimum each task requires, rather than long-lived passwords or keys. A review of our full code history confirmed that any credential it had ever contained was already rotated or retired.
  • Moved hospital data extraction to our managed cloud platform, which lets us apply security updates faster and more safely and removes software from on-site servers.
  • Applied the October security updates across our platform, patched known vulnerabilities in third-party libraries, and enabled automatic scanning of our software images.

What this means for you

The only change you may have noticed is being signed out once and asked to sign in again. No action is required on your part, and we have no indication that any patient or client data was affected.

Our approach

Security at Valiance is continuous, not occasional. We monitor industry and national advisories, verify our exposure against each one, and prefer durable safeguards (automated checks that keep a fix in place) over one-off fixes.

If you have questions, contact your Valiance representative or email security@valiancehealth.com.

Sources