Critical PHP vulnerabilities: have you updated your ISO 27001 incident register?

You patched PHP. Did your ISMS notice?

If you work anywhere near a web server, late October was a busy week.

On 21 October 2026, ASD's Australian Cyber Security Centre (ACSC) issued a critical alert about two flaws in PHP, the programming language behind a large share of the world's websites, including anything built on WordPress, Drupal or Joomla. Within a day, PHP had released emergency patches. Plenty of organisations spent the night updating servers, and some took websites offline until they could.

Hopefully you patched. But here's the question your ISO 27001 auditor is going to ask: where's the record?

Because in ISO 27001 land, if it isn't in your ISMS, it didn't happen.

What happened

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, quickly picked up the nickname "php2shell". Both are rated 9.2 out of 10 for severity, and both allow an attacker with no login to run code on an affected web server. That's about as bad as it gets.

The timeline moved fast:

• 20 October: details leaked online before the planned disclosure date.
• 21 October: the ACSC issued a critical alert, warning that versions from PHP 5 onwards may be affected. cyber.gov.au itself went down for a time.
• 22 October (Australian time): PHP released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and said updating was the only safe option.
• 26 October: the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its catalogue of known exploited vulnerabilities, confirming attackers were using them.

Two more details are worth noting. PHP 8.1 and earlier are end of life, so they get no official fix at all. And the flaws were found with help from AI, which is a fair sign of how quickly the next one might turn up.

Patching is only half the job

Under ISO 27001, fixing the problem is the technical bit. Showing that your management system handled it properly is the ISMS bit, and that's what your auditor will look for at your next surveillance audit.

A critical, widely reported vulnerability is exactly the kind of event auditors like to pick as a sample. They'll want to see that you heard about it, worked out whether you were affected, acted in a reasonable timeframe, checked for signs of compromise and learned something along the way. An emergency patch with no record behind it can turn into a finding, even if the patching itself was flawless.

Incident, event or vulnerability?

The first decision is how to classify it. ISO 27001 (control 5.25) asks you to assess security events and decide whether they're incidents. For php2shell, it depends on what you found:

• You weren't running affected PHP. Record that you received the alert, checked and found nothing in scope. It's a short entry, but it proves your process works.
• You were affected and patched, with no sign of attack. Log it as a vulnerability management action, and record your log review as a security event that was assessed and closed.
• You found exploitation attempts in your logs. Record a security event, show how you assessed it, and record why you concluded it wasn't a breach.
• You found signs of compromise. That's an incident. Run your incident response plan, keep the evidence, and if personal information may be involved, assess it under the Notifiable Data Breaches scheme.

The one option that doesn't work is recording nothing at all.

The Annex A controls in play

When you write it up, link your actions to the relevant ISO 27001:2022 controls:

If you took a website offline while you patched, control 5.30 (ICT readiness for business continuity) is worth a mention too.

What your register entry should include

Whether it ends up in your incident register, your vulnerability register or both, a good entry covers five things:

1. The basics: a reference number, the date you were alerted, the source (for example, the ACSC alert) and the type of event (a critical vulnerability allowing remote code execution).
2. The scope: which PHP versions you run, which systems are affected (servers, content management systems, microservices) and the risk rating.
3. The response: what you did and when. That includes patches applied, temporary measures such as firewall rules, systems isolated or taken offline, and the log review for signs of compromise.
4. The verification: when the fix was confirmed, how you checked (a version check or vulnerability scan), and the final status, whether closed, mitigated or accepted with compensating controls.
5. The lessons learned: what you'd do differently next time. This feeds ISO 27001's continual improvement requirements in Clause 10.

Three things people forget

Your suppliers. If someone else hosts your website or runs your platform, their patching is your risk. Ask them for confirmation, and record their answer against the supplier in your register. If they took a while to reply, that's useful information for your next supplier review.

Your legacy PHP. Running PHP 8.1 or older? There's no official patch coming. You'll need to upgrade, isolate the system or formally accept the risk with compensating controls and a named owner. And with PHP 8.2 reaching end of life on 31 December 2026, it's a good time to check your upgrade plans for that version too.

Your management review. An event this size belongs in your next management review, along with what it revealed about your asset visibility, patching speed and supplier response.

The bigger lesson

These flaws were found with help from AI, and attackers were trying to exploit them within hours of the details leaking. The gap between a vulnerability becoming public and someone using it is shrinking fast.

The organisations that coped best in October knew where PHP was running, who owned each system and which suppliers to call. That's an asset register and a supplier register doing their jobs.

How de.iterate can help

de.iterate turns a scramble like php2shell into a tidy, auditable record.

• Find affected systems fast. The asset register shows what you run and who owns it, linked to the risks and suppliers behind it.
• Log it properly. Record the event in the Incident Register, linked to the affected assets, risks and controls, with actions and follow-up in one place.
• Chase your suppliers. Keep supplier responses on each record in the third-party register.
• Track corrective actions to closure. Lessons learned become actions with owners and due dates, so they don't vanish into a meeting note.
• Show your auditor. Evidence of the patch, the log review and the follow-up sits in the Evidence Store, ready for your next surveillance audit.

Get help from real people. Our Aussie GRC experts can help you classify events like this and write them up. 

Book a demo and let's get your incident register ducks in a row.