Post-mortem: Service outage on 21 October 2026 (PHP security vulnerability)

On Wednesday 21 October 2026, we took TestMonitor offline as a precaution against two critical security vulnerabilities in PHP, the technology our platform runs on. Everything was back online that same evening.

We’re sorry for the disruption this caused you and your team. Below we explain what happened, why we made this decision, and what we’ve done since.

Summary

On 21 October, the PHP Foundation disclosed and fixed two critical security vulnerabilities in PHP, known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). They affect PHP-based web applications worldwide and can allow an attacker to take control of a server with a single web request. Details leaked before the fix was released, and attacks were reported in the meantime.

We took TestMonitor offline until we could install the official fix. Security checks before, during and after the outage found no signs of compromise and no evidence that customer data was accessed. You don’t need to take any action.

What happened?

PHP is the programming language TestMonitor runs on, as do a large share of websites and web applications worldwide. The PHP2Shell flaws are in PHP itself, not in our own code. A single crafted web request can make the server run commands of the attacker’s choosing. Because this happens before any application code runs, protections inside an application, such as login and permissions, cannot stop it.

The PHP Foundation released the official fix on 21 October at 14:00 UTC. Details had leaked earlier, and attacks were reported in the hours before the fix was available. For more background, see PHP2Shell on Wikipedia or the technical analyses by Datadog Security Labs and CrowdStrike.

Why we went offline

PHP published temporary mitigations, but by its own account they reduce the risk without making a server safe. Only the official fix does that. With attacks already reported and the fix not yet released, we chose to take our services offline rather than stay exposed.

National cybersecurity agencies, including CISA in the US and the NCSC in the UK and NCSC-NL in the Netherlands, gave the same advice for systems that could not be patched immediately. According to news reports, several governments, including the Dutch government, temporarily took services offline for the same reason.

We knew going offline would interrupt your work. We judged this downtime to be far less harmful than any risk to your data.

Impact

From 11:10 to 19:20 (UTC) on 21 October (8 hours and 10 minutes), all TestMonitor services were unavailable. This included the application, the API, webhooks, scheduled jobs and outgoing emails. No data was lost: everything saved before the outage is intact.

Our checks found no evidence of compromise or unauthorized access to customer data. You don’t need to take any action.

Timeline

All times listed below are in Coordinated Universal Time (UTC).

20 October

• 18:00 – The first reports and warnings about critical PHP vulnerabilities began circulating online.
• 21:00 - Reports continued to circulate, but the attack vector and which PHP setups were affected remained unclear.

21 October

• 4:00 - Still no reliable information on how the vulnerabilities could be exploited or what their impact was.
• 6:00 – We started assessing our exposure based on the information available.
• 9:30 – PHP’s temporary mitigations applied and tested.
• 10:45 – First round of security checks completed. No signs of compromise.
• 11:10 – Services taken offline as a precaution, as the mitigations alone do not fully protect against attacks.
• 11:15 - Status page update published
• 14:00 – The PHP Foundation released the official fix.
• 15:00 – Linux distributions started building updated PHP packages with the fix.
• 18:40 – Updated PHP packages became available for our servers.
• 19:10 – Fixed PHP version installed on all servers and all PHP processes restarted.
• 19:15 - Second round of security checks completed. No signs of compromise.
• 19:20 – Services restored and fully operational.

22 October

• 7:00 – Third round of security checks completed, based on the latest published information about how attackers exploit these vulnerabilities. Again, no signs of compromise were found.
• 10:00 - Precautionary rotation of passwords, keys and other secrets initiated.

What we did

• Applied PHP’s recommended temporary mitigations while we waited for the official fix.
• Took our services offline once it was clear the mitigations alone were not enough.
• Kept you informed through our status page and by support channels .
• Installed the official fix on all servers as soon as updated packages were available, and restarted all PHP processes so none were still running the old, vulnerable version.
• Ran several rounds of security checks over two days: before going offline, before restoring access and again the following day, each time based on the latest available information.
• Initiated rotation of passwords, keys and other secrets as a precaution, because a successful attack could expose data held in server memory. 
• Brought our services back online and verified that everything worked as expected.

Security checks

A successful PHP2Shell attack leaves few traces, so we looked for the specific warning signs security researchers have identified. We:

• Searched our PHP and web server error logs for the memory errors that exploitation attempts trigger.
• Reviewed our web server logs for unusually large form submissions.
• Checked whether our web server had started any unexpected processes, such as command shells.
• Scanned our servers for unknown or modified files, including web shells, and verified our application code against our repository.
• Checked for unauthorized user accounts, scheduled tasks, SSH keys and unusual outbound connections.

Result: we found no evidence of compromise, and we have no indication that any customer data was accessed or affected.

Next steps

Our checks came back clean, but we don’t consider this closed. Over the coming weeks we will:

• Keep monitoring our logs and servers for the warning signs of PHP2Shell attacks, such as memory errors at the start of a request and unexpected processes started by the web server.
• Evaluate an additional layer of protection in front of our servers, such as a more advanced web application firewall (WAF), that filters malicious requests before they reach PHP and lets us block new attack patterns quickly.
• Follow new PHP security releases closely.

Questions?

We know the outage was disruptive, and we appreciate your patience. We went offline because protecting your data and our systems comes first.

If you have any questions, please contact us at support@testmonitor.com.