RLC Pro LTS 9.6 and 9.2: base PHP fixed in hours

How CIQ got PHP2Shell fixes from upstream to RLC Pro

Contributors

The CIQ Team

Your exposure to a CVE lasts until you can install a tested fix for the version you run in production. For PHP2Shell, CIQ shipped fixed PHP 8.0 packages for Rocky Linux from CIQ Pro (RLC Pro) LTS 9.6 and 9.2 about three and a half hours after the upstream fix went public. PHP 8.0 is a version the PHP project no longer supports, and CIQ built those packages from the source-only fix the project published for it. That's how fast this CVE got patched on those releases, by engineers who read, backport, validate, and ship fixes as their daily work, using the same process on every CVE.

Follow the fix from the upstream release to RLC Pro LTS

The day before the release, the PHP project announced a critical security release and gave only its severity. CIQ staffed up ahead of disclosure so engineers could start the moment the fix landed. The upstream fix went public just before 14:00 UTC. Within the hour, fixes for the base PHP 8.0 packages on RLC Pro LTS 9.6 and 9.2 were in review, and both shipped about three and a half hours after the upstream release.

Those packages weren't a rebuild of an upstream release. The PHP project shipped fixed releases for PHP 8.2, 8.3, 8.4, and 8.5. RLC Pro LTS 9.6 and 9.2 ship PHP 8.0.30, and for 8.0 the project published what it called "minimal source-backports," with no official binaries. LTS releases are pinned minor releases that keep receiving backported security fixes from CIQ after the community project releases the next minor version. CIQ engineers built that fix into the PHP packages for each release, tested them, and published php-8.0.30-3.4.el9_6_ciq for LTS 9.6 and php-8.0.30-1.2.el9_2_ciq for LTS 9.2.

Three and a half hours to LTS packages came from engineers who staffed up early and had already worked through months of kernel CVEs.

Nathan Blackham, who leads the CIQ engineers who shipped these fixes, wrote about the response the day it happened.

See why each module stream needs its own build

Enterprise Linux 8 ships PHP only as module streams, and each stream is a separate package line with its own upstream fix status. The php:8.2 stream picked up the official 8.2.35 release. The php:7.4 stream needed a build from the source-only fix branch for 7.4. The php:7.2 stream has no upstream fix branch at all. CIQ isn't building PHP2Shell fixes for php:7.2, php:7.3, or php:8.0 on RLC Pro LTS 8.6 and 8.10, or for php:8.1 on LTS 9.2 and 9.6. Systems on those streams need to switch to php:7.4 or php:8.2 on Enterprise Linux 8, or to php:8.2 or php:8.3 on Enterprise Linux 9, and can apply interim mitigations until they do. For any stream without a patched build, the knowledge base article lists the configuration settings the PHP security team published, along with its warning that they reduce exposure without removing it.

The fixes rolled out release by release. RLC Pro 10, 9, and 8 had the Rocky Linux project's patched packages the next day. RLC Pro LTS 8.6 had fixed php:7.4 and php:8.2 builds the next day too, and because php:8.2 is a new stream on LTS 8.6, systems on another stream have to switch to it. On LTS 9.2, fixed php:8.2 and php:8.3 streams followed three days after the upstream release. On RLC Pro 8 and LTS 8.6, those packages are php-7.4.33-8 for php:7.4 and php-8.2.35 for php:8.2. Each build started from a different upstream branch, and CIQ listed each one in the knowledge base only once the tested package was available.

The PHP2Shell knowledge base article has the current table by product and stream, with package versions, repositories, and release dates. Check it before you plan a rollout, because CIQ updates the table as each tested package becomes available.

Find your fixed package. The PHP2Shell knowledge base article lists patched PHP versions for each RLC Pro variant, interim mitigations for unpatched streams, and the update and verification commands.

Fix PHP 5.4 on CentOS 7.9 while you migrate

The oldest version CIQ patched for PHP2Shell is PHP 5.4, which CentOS 7.9 ships. The oldest branch the PHP project fixed, even as source only, is 7.4. Starting from an existing community backport, CIQ engineers adapted the fix to the PHP 5.4 package for CIQ Bridge and released php-5.4.45-1.2.el7_9.ciqcbr for x86_64 two days after the upstream release. Hosts on CIQ Bridge pick up the fix with a standard yum update from the CIQ Bridge repository, followed by a restart of the PHP services.

The fix that counts is the one built for the version in production, including PHP 5.4, which upstream no longer fixes.

CIQ Bridge is for existing CentOS 7 estates. It delivers fixes for Critical and Important/High CVEs in a curated set of priority packages on CentOS 7.9, while you migrate to RLC Pro or RLC Pro Hardened. The migration is the plan, and CIQ Bridge delivers CVE fixes to those hosts while it happens.

Repeat the same process on every CVE

The three and a half hours describe one PHP2Shell release. The process that produced them runs on every CVE that CIQ engineers fix.

CIQ engineers read an upstream patch under pressure, judge where it touches the code paths customers depend on, backport it into versions upstream has moved past, and validate it before it's installed on a production system. Through the spring, that process ran against a series of Linux kernel CVEs, including Copy Fail, Dirty Frag, Fragnesia, and CIFSwitch, and the AI-found kernel vulnerabilities that followed. Each one sharpened how the team triages, backports, and validates. PHP2Shell took the same process from the kernel into user space, against remote code execution instead of local privilege escalation.

You can check the result on your own hosts. CIQ publishes advisories for its fixes. After an update, rpm -q php shows whether a host has the patched package release listed in the knowledge base article. php -v doesn't, because backported builds keep the upstream version number.

With RLC Pro, CIQ ships the tested packages and publishes the knowledge base article with interim mitigations and update steps. Your team schedules the update, restarts PHP services, rebuilds container images on a fixed base, and gets vendor updates for software that bundles its own PHP runtime. For community Rocky Linux, the Rocky Linux project publishes its own errata.

If AI-found CVEs are pulling your engineers off the roadmap, [Cost of CVE remediation is paid in roadmap time] (https://ciq.com/blog/cost-of-cve-remediation), URL TBD] shows where that time goes.

To see how RLC Pro fits the versions you run before the next CVE is disclosed, talk to a CIQ expert.

Subscribe to our newsletter

Related posts

OpenAI generated 948 Linux kernel patches, but CVEs aren’t solved

How CIQ shipped CVE-2026-98432 fixes in three days

How CIQ shipped CVE-2026-98432 fixes in three days

Cost of CVE remediation is paid in roadmap time

Cost of CVE remediation is paid in roadmap time

AI-found CVEs: what PHP2Shell means for your triage

Built for scale. Chosen by the world’s best.

2.75M+

Rocky Linux instances

Being used world wide

90%

Of fortune 100 companies

Use CIQ supported technologies

250k

Avg. monthly downloads

Rocky Linux

9

Enterprise products

Spanning the kernel to the orchestrator

Have questions about your infrastructure?

Talk to a CIQ engineer about Rocky Linux, HPC, and AI infrastructure.

Talk to an Expert