Lessons from the front line.

The week beginning 19 October 2026 showed how hard vulnerability management is becoming.

On 21 October, fixes were released for two critical flaws in PHP, a widely used web programming language that is also built into other products. The NCSC urged organisations to identify systems running PHP and update them, starting with those reachable from the internet. The same week, Fortinet announced critical and high-severity fixes across several products, and Palo Alto Networks listed its PAN-OS firewalls as affected by the PHP flaws. A different PAN-OS flaw, disclosed on 14 October, had already seen very limited exploitation.

The lesson is not that updates can wait. It is that organisations need to get better at deciding which ones matter first.

Why the pace is changing

Fortinet says some of its fixes came from AI-assisted testing. It also warns that AI tools can now help attackers “reverse-engineer patches and build working exploits in hours or days, rather than weeks”. In plain terms, once a fix is published, an attacker can compare it with the old version to see where the flaw was.

The window between disclosure and exploitation continues to shrink, and we expect it to keep shrinking.

For a smaller organisation, IT may be one person’s job alongside operations or finance, or it may sit largely with an external provider. Such organisations cannot investigate every vulnerability in the news, and in Amana’s view they should not need to. It is the security industry’s responsibility to make announcements that help organisations decide what to do, not simply label an issue critical.

‘Critical’ does not answer the key question

A severity rating describes what a flaw could allow. It does not say how urgent it is for your organisation. A flaw in software you do not use is irrelevant. One in a system an attacker cannot reach may need action, but not at the speed of the same flaw on an internet-facing server. Evidence of exploitation changes the picture again.

Ratings also move. An advisory published one week can be revised the next as a vendor learns more, so the label you acted on may not be the label that stands a few days later.

A simple routine

This routine is Amana’s own advice, not NCSC or vendor guidance.

1. Establish whether you use the technology. This is harder when software is embedded in another product or managed by a supplier. The NCSC advised monitoring updates from third-party vendors whose products may include PHP, and not limiting the search to outdated versions.
2. Understand the exposure. Is the system reachable from the internet? Is an administration interface exposed? Does an attacker already need an account?
3. Check what is known about exploitation. Read vendor wording carefully and distinguish confirmed activity from possibility or speculation. A vendor’s “not aware of exploitation” describes what it currently knows, and attempts against an internet-facing system are reason enough to act.
4. Agree the action and who owns it. Sometimes this is an immediate update. Where an update is not possible, the NCSC advised applying PHP’s temporary mitigations and, if that is not possible or would take too long, considering taking the system offline. Fortinet and Palo Alto Networks both advise restricting access to administration interfaces.

If an IT provider looks after this for you

For an important vulnerability, the provider should explain whether you are affected, how exposed you are, what it recommends and when the work will be done.

Some decisions cannot be made by the provider alone. If an urgent update needs downtime, who can authorise it? If that person is unavailable, who is the deputy? If an update is not possible, who decides whether the temporary risk is acceptable? These questions are easier to answer before an emergency than during one.

Sources: NCSC, “Critical security issue affecting PHP”, 21 October 2026; Fortinet, “Fortinet Releases Security Hardening Release for Multiple Products”, 21 October 2026; Palo Alto Networks, advisory on the impact of the PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619), published 21 October and updated 29 October 2026; Palo Alto Networks, advisory CVE-2026-0322, published 14 October and updated 15 October 2026.