Three critical CVEs in one week: PHP2Shell and CVE-2026-98432

October 21: the advisory

A security feed drops a critical advisory into Caliptic: PHP2Shell, CVE-2026-109618 and CVE-2026-109619, two flaws in PHP that let an attacker run code without logging in. Exploitation attempts start within hours. Event Management turns the advisory into an incident, and the Triage Agent classifies it as a security incident in the PHP runtime and routes it to the Security Analyst agent.

Who runs PHP?

The analyst asks the CMDB one question: which hosts run PHP, which versions, and which face the internet? Four hosts run PHP. Two of them, the billing portal and the marketing site, are internet-facing. The old helpdesk server still runs PHP 7.4, which gets no fixes at all. Impact analysis shows the billing portal sits right in front of the Billing service, so it goes first.

Buy time, then patch

• Interim mitigations from the PHP advisory go in at once: session upload progress off, and PHP restricted in what it may execute.
• The billing portal fix can't wait for the weekly change board. The DevOps agent drafts an emergency change with the steps, the test plan and the rollback; one approval on the record is enough, and PHP 8.4.27 goes out that morning.
• The marketing site and the intranet follow the same evening as a normal change approved by the board.
• The helpdesk server on PHP 7.4 becomes a known error: isolated now, decommissioned soon, because no patch is coming for it.

On October 26, CISA adds CVE-2026-109618 to its catalog of known exploited vulnerabilities. By then every PHP host is patched or isolated.

October 27: a second advisory

The next day brings CVE-2026-98432, a flaw in the Linux kernel's TCP code that goes back to kernel 4.4. Same CMDB question, this time about kernels: three hosts already have a fixed kernel from their vendor, five are still waiting for one. The three get a planned update and reboot window that night. The five are tracked as a known error: check every day for the vendor's fixed kernel, and patch internet-facing hosts first.

Closing the loop

• The PHP fixes ship together in one release, and its readiness gate confirms both changes were approved and completed.
• A post-implementation review records what went well and what to do faster next time.
• The method goes into the knowledge base: how to check PHP and kernel exposure from the CMDB.
• Both security incidents are resolved within their service levels, and the Ops Assistant writes the summary for management straight from the records.

What made the difference

• The CMDB answered the exposure question in minutes, without a spreadsheet hunt.
• Agents did the groundwork — triage, change plans, inventories — and people made the decisions.
• Hosts without a fix were not forgotten: they became known errors with a daily check.
• Every step is on the record, ready for the next audit.