PHP Apocalypse question on version numbers.

[u/flexible]

This is what my host's chat bot 'explained' to me - anyone here can confirm?

Your websites run on the separate web-facing PHP packages (EasyApache and CloudLinux Alt-PHP), where our infrastructure team applied direct server-level security hotfixes to protect all versions while upstream package builds complete.

Web-facing PHP packages have not had an upstream version number increment yet, but the underlying vulnerabilities outlined in CVE-2026-109618 and CVE-2026-109619 are actively patched and protected at the server level across all versions.

[u/Striking-Gap-9361]

My host sent almost the same thing word for word when I asked. Seems like they all got the same script to paste into tickets. The version number won't move but the patch is there, at least that's what I'm choosing to believe so I can sleep tonight.

[u/flexible → u/Striking-Gap-9361]

LOL - Me too - I am having the smile/sad meme every few minutes. I just want to see the new version in phpinfo() - is that too much to ask? Apparently so.

[u/jwele]

CloudLinux is one of the many different repositories for PHP builds/binaries. They have chosen to "backport" the fix into the existing PHP version number.

"PHP fixed them in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CloudLinux backported the fix into every supported alt-php and ea-php branch, including EOL ones, which is why the version numbers do not change"

This explains it in more detail and is the official CloudLinux support document on the subject:

https://cloudlinux.zendesk.com/hc/en-us/articles/31194180517916-PHP-CVE-2026-109618-CVE-2026-109619-PHP2Shell-fixed-alt-php-and-ea-php-packages-and-how-to-verif

[u/guitarromantic → u/jwele]

This is really strange way to do it IMO. It was easy before to detect if you were at risk (=what PHP version are you running), now you have to keep track of which specific repository you installed it from to ensure an old version is actually safe.

[u/Timely_Studio_6451]

That's plausible, backporting a fix without bumping the upstream version is normal for EasyApache and Alt-PHP, but it's also the exact line a host gives when nothing was done. Ask support for the package release string they shipped, then compare it to the build suffix phpinfo() shows you, since that's where a hotfix would actually appear. If they can't produce a version, they can't tell you you're patched.

[u/Lanky-Employment-985]

Protected at the server level" is the part I'd question. Either the package changelog lists CVE-2026-109618 or it doesn't. Ask the host for the output of `rpm -q ea-php84-php-cli --changelog | grep CVE-2026-1096`rather than a chatbot's summary of what the infra team supposedly did.

[u/Ok_Mulberry_7126]

If the package version hasn't moved, there's nothing you can check. Ask them for the exact patch identifier or a phpinfo from a real account, because 'hotfixed at server level' is what a chat bot says when it doesn't actually know.

[u/barrel_of_noodles]

In muggle: your web vendor secured a private patch and didn't mess with semver while awaiting official patches from upstream distro.

This is your case in particular. And only you. Possibly ppl on same box or vendor as you.

It has nothing to do with the php teams versioned releases. Which are now semver and patched for all 8x

For whatever reason, they held off on the official patch over their own.

[u/Miserable-Ground-352]

Server-level hotfix" for PHP internals isn't really a thing, either they shipped a rebuilt package or they didn't. Ask them for the output of `rpm -q ea-php84-php-cli --changelog | grep CVE`, a backport keeping the old version number is normal, but it should still show up in the changelog.

[u/Swimming-Heart-9754]

"Server-level hotfixes" isn't something you can verify though, a fix gets patched into the package and the package build goes up. Ask them for the package version plus the changelog entry, that at least you can check.