cPanel PHP version: where the number lives
Published · updated
cPanel does not run one PHP. It runs a set of EA-PHP builds and hands each domain whichever one is selected — while a CDN, a proxy or a stale cache can answer before PHP sees the request at all. Here is where the real number is.
Three places, in order of authority
- cPanel → MultiPHP Manager. The table lists each domain with the PHP version assigned to it, and a dropdown to change it. On older or CloudLinux-based servers the same page is called “Select PHP Version”.
- WHM → MultiPHP Manager. The server-wide view: which EA-PHP packages are installed and what each domain inherits.
- The shell.
/opt/cpanel/ea-php83/root/usr/bin/php -vprints the actual build of that branch. If the prefix isea-php83, you are looking at cPanel's own package, not the system PHP.
“Inherit” means the domain follows the server default instead of a pinned version. That is convenient and dangerous at the same time: the site's PHP can change on a server update without anyone touching the site.
Switching a branch without breaking the site
- Copy first. A staging subdomain on the same account, with a database copy.
- Change the version on the copy in MultiPHP Manager and open the site: front page, admin login, a form submission, the cron job if it runs PHP.
- Check the extensions. EA-PHP builds ship a different set per branch:
mysqli,gd,imagick,intl,zip. Enable what the site needs in “PHP Extensions” on the same page. - Apply to production, then reload: cPanel restarts FPM for that domain automatically, but a page cache or CDN can still serve the old response for minutes.
- Verify from outside — a check reads the version only if the site publishes it; otherwise the shell command is the proof.
Where the patch comes from
cPanel maintains its own PHP packages, so the October 2026 fixes reach a cPanel server through the panel's updater, not through apt upgrade. The vendor publishes the fixed EA-PHP builds for each supported branch; the build number appears in the package version and in php -v.
What that means in practice: yum update php-fpm on a cPanel box may update the system PHP and leave the site's EA-PHP build untouched. The version the domain uses is the one in MultiPHP Manager, and the fixed builds are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Full table →
If the panel does not offer a fixed build yet, that is a support question with a date attached — raise a ticket rather than compiling PHP inside a panel-managed stack.
What a stranger can see
cPanel's Apache configuration usually strips X-Powered-By, so the version is hidden from outside by default. What remains visible is the fact that the site runs PHP, the handler behind it (FPM versus a proxy), and any leftover probe file — phpinfo.php, info.php, a test script left by the previous developer — which publishes the exact build and the ini paths.
Our checker reports the version when it is public, flags those leftovers, and says “not disclosed” when the header is gone. That is the honest answer: it means the proof has to come from the panel or the shell.
Questions
Does changing the PHP version in cPanel affect other domains?
Only the domain you change. The server default applies to domains set to “inherit”, so check that column before assuming your change covered the whole account.
Why does php -v show a different version than MultiPHP Manager?
The shell opens whatever PHP is first in PATH — often the system build. The site runs the EA-PHP binary selected for the domain; compare /opt/cpanel/ea-php8x/root/usr/bin/php -v with the panel.
Our .htaccess php_value lines stopped working after switching to FPM.
PHP-FPM ignores .htaccess. Move those settings to “MultiPHP INI Editor” (per domain or per directory) or the pool configuration.
Is cPanel's PHP the same as php.net releases?
It is built from the same source with the vendor's patches and packaging. The build number matches upstream after a security release, but timing depends on the vendor's release cycle.