CloudLinux Hardened PHP: legacy PHP without the CVE risk

Roughly a third of WordPress installs in the wild are still on PHP 7.4 or older, and the Magento 2 long tail is worse — plenty of stores stuck on 7.4 because an extension vendor went silent in 2022. Upstream PHP stopped publishing security patches for 7.4 in November 2022, for 8.0 in November 2023, and for 8.1 in December 2025. Every CVE since then is unpatched on the official source.

CloudLinux Hardened PHP is the backport channel that fills that gap. It replaces the standard alt-php packages with builds that carry security fixes cherry-picked from upstream and from CloudLinux's own audit, while staying API-compatible with the original version. Your customer's plugins keep working; the CVEs stop.

This guide covers what Hardened PHP actually changes, how to switch a CloudLinux server over to the hardened channel, and the licensing decision behind whether it's worth doing.

What Hardened PHP actually patches

Hardened PHP is not a fork. The version your customer sees in phpinfo() is still 7.4.33 — it just has a CloudLinux-specific build suffix and a patch list that grows over time. The backports cover:

• Core engine CVEs — overflow, type-confusion, and use-after-free bugs in Zend.
• Standard extensions — gd, imap, mysqlnd, openssl, pcre, phar, soap, xml, zip.
• OpenSSL compatibility — keeps the older PHP versions building against current OpenSSL 3.x, which upstream EOL versions don't.

What it does not cover:

• PECL extensions — redis, imagick, xdebug, third-party stuff. Those still come from PECL and follow their own support cycles.
• Feature backports — no new language features, no new opcodes. The point is stability for legacy apps, not catch-up.
• Performance work — JIT improvements, ZTS fixes, anything not security-related stays in modern PHP only.

Versions currently in the Hardened PHP channel run from PHP 5.6 through 8.1. Modern versions (8.2, 8.3, 8.4) come from the regular alt-php repo with upstream patches — there's no Hardened build because upstream is still patching them itself.

When Hardened PHP is the right answer

You want Hardened PHP if:

• You run shared hosting and customers refuse to upgrade off PHP 7.4 because of plugin compatibility, and you can't realistically force them.
• You sell Magento hosting where a 2.3.x store on PHP 7.4 still pays well.
• A compliance auditor (PCI, ISO) asks "what's your process for patching end-of-life PHP?" and "we don't" is no longer an acceptable answer.

You don't need it if your customer base is fully on PHP 8.2+, or if you're happy to enforce a policy of migrating customers off EOL versions on a deadline. The PHP Selector setup is enough on its own for that workflow.

Licensing — where this fits in the CloudLinux SKUs

Hardened PHP is not bundled with the base CloudLinux OS Shared licence. You get it either by:

1. Upgrading to CloudLinux OS Shared Pro — Hardened PHP is one of the Pro-only features, alongside AccelerateWP Premium and a few others. This is the cleanest option if you also want the extra performance and management features in Pro.
2. Buying a standalone Hardened PHP / TuxCare ELS for PHP subscription — covers only the PHP backports, keeps the rest of the CloudLinux stack on the standard tier. Cheaper per server if you only care about the security backports.

Both options entitle the server to the cloudlinux-hardened-php repo. The mechanics from here are the same. For the upgrade path between SKUs, check the CloudLinux pricing overview or contact sales for a quote across multiple servers.

Step 1 — Confirm your licence covers it

On the server, check the active entitlements:

clnreg_ks --status

Look for Hardened PHP or CloudLinux Shared Pro in the feature list. If it's missing, the licence on this server doesn't include the hardened channel — fix that first via the CloudLinux product page before continuing, because the repo will refuse to install packages on an unlicensed host.

Step 2 — Enable the Hardened PHP repository

Once entitled, the activation is a single command:

yum install cloudlinux-hardened-php

This adds /etc/yum.repos.d/cloudlinux-hardened-php.repo, configured to pull from CloudLinux's hardened mirrors using your existing CLN credentials. Confirm the repo is enabled:

yum repolist | grep -i hardened

You should see cloudlinux-hardened-php listed with a non-zero package count.

Step 3 — Switch alt-php packages to the hardened build

The hardened repo provides packages with the same names as the standard alt-php set, but a higher epoch or build number, so a plain yum update will pull the hardened versions in automatically. Run it explicitly so you can see what's changing:

yum update 'alt-php*'

On a server with the full alt-php set installed this is a 400-600 MB download. The hardened packages drop in as straight replacements — no config changes, no rebuild of CageFS, no restart of php-fpm pools required. Existing user PHP profiles continue to point at the same version strings, now backed by the patched binaries.

Verify a single version is now on the hardened build:

/opt/alt/php74/usr/bin/php -v

Look for built: <date> later than the upstream EOL date, and a CloudLinux tag in the banner. If you see the original upstream build date, the package update didn't take — re-run yum update and check for held packages.

Step 4 — Verify patches are applied per-user

For a given cPanel user, check the actual PHP binary they're running against:

su - exampleuser -c '/usr/bin/php -v'

Under CageFS this resolves to /opt/alt/phpXX/usr/bin/php for the user's selected version. The output should match the hardened banner from Step 3. If a user is on the "native" EasyApache PHP rather than alt-php, Hardened PHP doesn't apply to them — you need to either move them onto an alt-php version via PHP Selector, or accept that the native handler stays on upstream EOL.

Step 5 — Subscribe to the security advisory feed

Hardened PHP ships patches as yum update lands them, but you'll want notification before the package hits your mirror so you know which CVE was fixed. CloudLinux publishes the advisory feed at the CloudLinux Hardened PHP changelog, typically within a few days of the upstream CVE disclosure.

Set up automatic updates for the hardened repo only, leaving everything else manual:

yum-config-manager --enable cloudlinux-hardened-php
echo "0 4 * * * root yum update -y 'alt-php*' >> /var/log/hardened-php-update.log 2>&1" \
  > /etc/cron.d/hardened-php-auto

Patch lag matters more than uptime for security packages; nightly is fine.

The realistic limits

A few things Hardened PHP does not fix on its own:

1. WordPress core and plugins. Hardened PHP closes engine-level holes, not application- level ones. A vulnerable 2021 WP plugin is still vulnerable. Pair this with Imunify360 for the application-layer side.
2. Operating system EOL. CentOS 7 reached EOL in June 2024. Hardened PHP packages will refuse to install on it eventually — move to AlmaLinux 9 via the CentOS-to-AlmaLinux migration guide before this becomes the blocker.
3. Customer mindset. Hardened PHP buys time, not infinite life. Use the breathing room to plan an upgrade path off PHP 7.x, not as an excuse to never move.

FAQ

Next steps

• Most customers reach Hardened PHP via the per-user picker — set that up first with PHP Selector on a cPanel server.
• If you're standardising on a hardened legacy version, tighten the per-account resource ceilings around it with CloudLinux LVE tuning.
• Pair the engine-level patching with application-layer detection from Imunify360 on cPanel for the full defence-in-depth story.