If you run PHP, PHP2Shell cost your team more than a patch. It took engineers off the work they had planned for your customers so they could find every PHP install, work out which version and module stream each one runs, apply interim settings, and then roll out fixes, including for versions the PHP project no longer supports. That's the cost of CVE remediation that a vulnerability report doesn't show: engineering time taken from your roadmap. As AI-assisted research makes CVEs more frequent and more complex, that cost grows with every disclosure, and the decision that controls it is whose engineers do the triage and backports as their daily work.
Count what one CVE like PHP2Shell asks of your team
Start with the list. These steps come from the PHP2Shell knowledge base article:
- Find every system running PHP, including applications and appliances that bundle their own PHP runtime and need their own vendor update.
- Identify the PHP version on each one. On Enterprise Linux 8 that means the module stream too, such as 7.2, 7.4, 8.0, or 8.2, each with a different fix status.
- Work out how each system exposes PHP. Apache with mod_php is the most exposed, PHP-FPM depends on the application, and internet-facing servers come before internal ones.
- Apply interim settings where you can't patch yet, at the level PHP reads before it parses a request, then restart every worker. The PHP security team warns these settings reduce exposure without removing it.
- Rebuild container images on a fixed base.
- Install the fixed packages, restart every PHP process, and confirm the running version.
- Revert the interim settings.
Every step in a CVE response needs an engineer who knows your environment, and none of those steps writes the fix.
That list assumes a fixed package exists for every version you run. For PHP2Shell, it didn't. The PHP project released fixes for PHP 8.2 through 8.5, published source-only fix branches for 7.4, 8.0, and 8.1, and released nothing for 7.2 and 7.3 or for the PHP 5.4 that CentOS 7 ships. If your team self-supports one of those versions, your engineers build and test that fix, or the version stays exposed.
Expect each complex CVE to take longer than the last
The fixes are harder. The PHP security team spent months choosing between competing fixes for the bug tracked as CVE-2026-109618, because each option traded against compatibility, denial-of-service risk, or third-party extensions, according to the PHP Foundation's account. The engineers who backport that fix to an older branch have to understand those trade-offs too.
You run more versions than upstream fixes. Upstream patched PHP 8.2 and later. Rocky Linux 9 ships PHP 8.0, and Rocky Linux 8 ships 7.2, 7.4, and 8.0 as module streams, so a single Enterprise Linux release can put several unsupported PHP versions in production.
The reports keep coming. Google's threat intelligence group found that monthly vulnerability disclosures doubled from January to July 2026, and that half of the vulnerabilities it identified as likely AI-discovered lead to remote code execution. The PHP security team alone has published 15 CVEs since July 1, and worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible.
Put your own number on CVE work
No industry figure tells you what CVE work costs your team, and you don't need one. You have the inputs. Take the engineer-days your team spent on PHP2Shell, from the first advisory to the last reverted setting. Multiply by the critical CVEs you expect over the next year in the software you run. Then name the work those engineers would have shipped in that time: the feature, the migration, the platform project your customers are waiting on.
An upstream fix still costs your team the days it takes to triage, backport, and validate it on every version you run.
See where PHP2Shell stands on your systems. The PHP2Shell knowledge base article lists patched packages by RLC Pro variant, interim mitigations, and update steps.
Keep self-support where it works, and staff the daily CVE work
Plenty of enterprise teams prefer to self-support open source Linux, and that model works best with expert engineers working on every update. The question for a leader is whether your team should read upstream patches and backport them as a standing job, as AI-assisted research makes that job more frequent.
CIQ engineers do that work every day for Rocky Linux from CIQ Pro (RLC Pro). Through the spring, they triaged, backported, and validated a run of Linux kernel CVEs, and each one sharpened the process. For PHP2Shell, they released fixed packages for RLC Pro LTS 9.6 and 9.2 about three and a half hours after the upstream fix went public, on PHP 8.0, a version upstream no longer supports. Fixes for the php:7.4 and php:8.2 module streams followed over the next two days. [How CIQ got PHP2Shell fixes from upstream to RLC Pro, URL TBD] follows that release stream by stream.
Your team still owns its rollout. With RLC Pro, CIQ supplies tested packages and the knowledge base article; your engineers schedule the update, restart services, rebuild your container images, and get vendor updates for software that bundles its own PHP. CIQ engineers take on reading the upstream patch, backporting it, and validating the build.
Ask four questions before the next CVE is disclosed
- Which versions and module streams do we run, and which of them does upstream still fix?
- When upstream doesn't fix a version we run, who on our team backports the patch?
- How do we validate a backported fix before it goes into production?
- What did our engineers set aside for PHP2Shell, and who decided it could wait?
If the answers point to your most experienced engineers and a slipped roadmap, talk to a CIQ expert about who handles the next one.
