On Tuesday 21 October, the PHP project released emergency fixes for two critical vulnerabilities, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). PHP runs a huge share of the web, including the Medic52 dashboard. Both flaws were rated 9.2 out of 10 for severity. Together they could let an attacker run their own code on an unpatched server without logging in. A public proof-of-concept appeared quickly, and security researchers reported attack attempts the same day.

When a vulnerability like this lands, the questions that matter to a patrol director or risk manager are simple. Were we exposed? How fast was it fixed? Is our data safe? Here are the answers.

The short version

  • Every Medic52 server, in every region, was patched on 21 October, within about three hours of Ubuntu publishing the fixed packages.
  • There was no downtime. Nobody had to log out, and no incident reports were interrupted.
  • No sign of an attack. We checked our web server logs for the week before the fix. They show only the routine automated scanning every website sees: no requests matching this attack, and none of the crashes it causes.
  • Over the following days we went further: fresh servers everywhere, a safeguard that stops an unpatched server from ever going live, and an upgrade to the latest Ubuntu and PHP versions.

Timeline

All times are UTC.

  • Tue 21 Oct: PHP publishes fixes for CVE-2026-109618 and CVE-2026-109619.
  • 21 Oct, ~14:15: Ubuntu publishes its security notice (USN-8948-1) and fixed packages for the version of Ubuntu our servers run.
  • 21 Oct, 16:40: We start our response: confirm which PHP version runs in each region, and confirm the fixed package is actually available to our servers.
  • 21 Oct, 17:04: Australia servers patched and verified.
  • 21 Oct, 17:09: Canada servers patched and verified.
  • 21 Oct, 17:15: United States servers patched and verified. All regions protected.
  • 21 Oct, 17:36: Double-check across all three regions confirms there are no other servers we’d missed.
  • Wed 22 Oct: A safeguard goes live. A software release now refuses to install on any server running an unpatched PHP, and the specific PHP feature the published attack relies on is switched off as an extra layer.
  • 22 Oct: Every server in every region is replaced with a freshly built one on the latest Ubuntu images, with no downtime.
  • Sat 25 Oct: All regions move to Ubuntu 26.04 and PHP 8.5, the newest long-term versions, with no downtime.
  • Fri 31 Oct: Our build system moves to PHP 8.5 too, servers are refreshed with the latest security updates again, and monitoring is updated.

Why we could move this fast

A few things we’d already put in place paid off:

  • Every region runs the same way. Australia, the United States and Canada run identical setups, so a fix proven in one region could be applied to the next within minutes.
  • Our servers are rebuilt, not repaired. New servers are created from scratch and install the latest security fixes as they start, so replacing all of them is routine and causes no downtime.
  • Patient data is encrypted. Incident and patient records are encrypted at rest with keys held in AWS’s key management service.
  • Your data stays in your region. Australian resorts’ data stays in Australia, Canadian in Canada, and US in the US. Patching one region never touched another region’s data.

What we changed afterwards

Fixing the immediate problem is only half the job. The other half is making sure it can’t quietly come back:

1. No unpatched server can go live. Our deployment process now checks the PHP version before it installs anything, and stops if the server isn’t patched.

2. Fresh servers everywhere. We didn’t just patch the running servers. We replaced all of them, so every server now starts from a clean, current image.

3. Newest versions. Moving to Ubuntu 26.04 and PHP 8.5 means we’re on the versions that receive security fixes first and for longest.

4. Better monitoring. Every server now reports its health and its PHP version to our monitoring around the clock.

Do you need to do anything?

No. Medic52 is a hosted service, so there’s nothing to update or install on your side. The mobile app wasn’t affected: it doesn’t run PHP.

If your IT or compliance team wants more detail for their records, or a copy of this timeline, contact us through the chat in the dashboard or at support@medic52.com and we’ll send it over.

Security work is mostly invisible when it’s done well. On a bad day on the hill, Medic52 just needs to be there and to keep your patients’ information safe. This is part of how we make sure it is.

Duncan