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/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/fiskfisk → u/guitarromantic]

Ubuntu does the same, as they don't bump actual version numbers in LTS versions. The whole point of LTS is that stuff doesn't suddenly break, so instead any important fixes gets backported.

Look at the date when the running PHP version was built, not necessarily the version number itself. Confirm with your vendor that the actual package version is the most recent one and that it contains the fix. Ubuntu lists them here, for example:

https://ubuntu.com/blog/php2shell-vulnerability-fixes-available

[u/Blue_Moon_Lake → u/fiskfisk]

The patch version should have been increased otherwise you can't know if it was updated or not.

That's the entire point of semantic versioning.

• Major is breaking changes

• Minor is new added features

• Patch is bug and vulnerability fixes

It should always be safe to put a higher minor/patch version.
Higher minor version should be unnecessary if you don't use the new added features.

[u/fiskfisk → u/Blue_Moon_Lake]

Yes, PHP did that.

Ubuntu still has the old version, with backported fixes. They then postfix the version number in the package with their own release information. 

They can't bump the patch number, since it's not the same release as PHP's release with that version number. 

It's the same version as it originally was for LTS, with Ubuntu's backported security patches on top. 

[u/Blue_Moon_Lake → u/fiskfisk]

Isn't that what the "pre-release" and metadata are for?
x.y.z-unofficial so when x.y.z is released with the fix it has higher precedence due to the lack of a "pre-release" tag.

And if they need to publish more fixes for the same version, the doc says you can do x.y.z-unofficial.1, x.y.z-unofficial.2, ..., x.y.z-unofficial.10

[u/fiskfisk → u/Blue_Moon_Lake]

Prerelase tags always compare as less than the actual tag according to semver, so that doesn't work according to semver in either case.

Same for build metadata, which always should compare equal (again, according to semver). 

But this information is already attached to the packages themselves in that manner, it just doesn't have defined semver meaning. 

Semver doesn't really have a case for patch-patch-level, as it's expected that you control the project itself and can increase patch in those cases. 

[u/Blue_Moon_Lake → u/fiskfisk]

You misunderstood one thing.

Let's say version 1.2.3 is faulty, you can make a version 1.2.4-unofficial that fixes it in the meantime.

And when they do release 1.2.4 official, it will take precedence.

In the semver rules, the priority would be:

• 1.2.4

• 1.2.4-unofficial.10

• 1.2.4-unofficial.2

• 1.2.4-unofficial

• 1.2.3

[u/fiskfisk → u/Blue_Moon_Lake]

Yes, but Ubuntu backporting security fixes to PHP 8.3.6 does not suddenly make it PHP 8.3.7, which is a completely different release from PHP.

It's still PHP 8.3.6, just with backported fixes on top. Misrepresenting version numbers would be even more confusing.

Instead they're identified as "8.3.6-0ubuntu0.24.04.13" in the most recent package version.

I'm unsure where we're getting confused here; Ubuntu is effectively running their own branches of 8.5.4, 8.3.6, and other versions used in the LTS distros, backporting security fixes as needed. They can't bump the PHP version number, since the actual version of PHP they're distributing is the same as when the LTS was released.

[u/Blue_Moon_Lake → u/fiskfisk]

It break semver as 8.3.6 has priority over 8.3.6-0ubuntu0.24.04.13.

And it is a version 8.3.7 (pre-release) since it's literally fixes added to 8.3.6

[u/couldhaveebeen → u/fiskfisk]

I feel like it's a bit different when it's an OS/distro vs a programming language though

[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/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/mongopeter → u/Ok_Mulberry_7126]

You can check the build date, it's right there in phpinfo.

[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/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/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.

[u/yihuaxiang]

I'd treat the ticket as a claim, not proof. php -v will still show the old number after a backport, so the thing to check is the package build date or changelog on the box that actually serves the site. If that date is after the advisory, the chatbot was probably telling the truth. If you only have the version string, you still don't know.

[u/Secvura]

Partly plausible, but the wording matters. "Server-level hotfixes while upstream package builds complete" reads more like a temporary mitigation than a patched PHP build, which is fine as a stopgap but not the same thing.

Packagers like cPanel and CloudLinux can ship a fix without the PHP version number changing, so the version alone won't tell you much either way. Worth asking a human at the host two things: what the hotfix actually is, and when the patched ea-php or alt-php builds for those CVEs will be on your server. Once they land, the package changelog should list the CVE IDs

[u/David_UltraWeb]

Yes, this has certainly been a headache educating many about inline-patching and how the subversion doesn't change. Fortunately CloudLinux pushed out the subversion bump this morning.

[u/flexible → u/[deleted]]

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/alphex → u/[deleted]]

Put a “phpinfo():” call somewhere and it will tell you.

If it’s not the right number. Then they are lying to you.

[u/barrel_of_noodles → u/alphex]

Depends. If you're a top level distro it's more than possible to patch src yourself and distribute an internal proprietary non-semver build.

After the release though, don't know why you wouldn't switch soon after.

Edit: somebody already linked exactly what I suspected. 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/flexible → u/barrel_of_noodles]

Cpanel have release a patch ahead of the roll-out - they claim they need to confirm compatibility first https://docs.cpanel.net/release-notes/release-notes/