PHP security vulnerabilities: Questions to ask your web agency

Information checked: 1 November 2026. A PHP security alert does not automatically mean that every company website is affected or has been attacked. The first step is to identify the applications and providers actually in use, including older forms, subdomains, customer portals, integrations and test systems.

What was announced in October

Security researchers at Calif identified a critical PHP flaw with support from OpenAI; Wiz Research independently discovered and reported two vulnerabilities. The developers maintaining the open-source PHP project led the fixes and released security updates on 21 October 2026. Under certain conditions, the vulnerabilities can allow unauthenticated remote code execution. The first fixed versions named by the project were 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Wiz research report · OpenAI account. PHP recommends updating affected installations and says there is no complete substitute mitigation. The responsible operator should check the latest supplier guidance for an appropriate supported version. PHP security announcement.

A vulnerability does not establish that an organisation was compromised. Some services were taken offline as a precaution to patch; simultaneous outages do not prove a shared cause. The separately reported Railway incident is not evidence that PHP caused it.

Find systems nobody remembers

A company may have replaced its main site while an older form or separate application continues to receive enquiries. A vendor may manage components that internal teams rarely see. This is an illustrative scenario: each system must be assessed on its own merits, and the SaaS provider may be responsible for its own software updates.

Ask your agency or IT provider:

1. Which sites, subdomains, forms, portals and test environments do you operate for us?

2. Which use PHP, who manages updates, and what evidence can a managed provider give us?

3. What versions are actually running across servers and containers, and are they supported?

4. Were affected systems patched and tested? Record the systems, date, tests and exceptions.

5. Which databases, customer records and integrations could be affected? Never send secret values in an email as proof.

6. What do available access, application and provider logs show? The absence of an obvious anomaly does not prove that nothing happened.

7. Who receives future security notices, who is the backup, and how are backup restoration and emergency changes tested?

Agree a migration plan for unsupported software with its operator. Consult the current PHP support schedule.

Look for weaknesses before an incident

Have responsible IT staff regularly compare the inventory with supplier advisories, prioritise findings and track an owner and deadline. Agreed vulnerability scans and independent tests can complement patching and access reviews. Document the scope, authorisation, test window and handling of findings with the relevant operators before testing. The Swiss BACS guidance on vulnerability disclosure describes how to handle reports.

Employees may try a new tool, request a quick campaign page or share a login without understanding the downstream effects. Make it easy to report those changes or mistakes without blame, and ensure alerts reach a monitored team address and a named backup.

If misuse is suspected, coordinate containment and evidence preservation with the responsible IT or incident-response specialists. Patching alone cannot establish whether access occurred earlier. If personal data may be affected, involve the privacy lead and assess notification duties under applicable law. Starting points include the Swiss FDPIC and German BSI guidance for SMEs.

For connected business processes, see process automation.