1C-Bitrix · PHP

Which PHP version does your Bitrix site run?

Q: Bitrix hides the PHP version — is that a problem?

Not by itself. It means an outside check cannot confirm the patch, so the proof has to come from the server. Keep the output of php -v and System check with a timestamp; that is what your client or auditor will ask for.

Q: Can I update PHP without updating Bitrix?

Sometimes, within the range the kernel supports. Outside that range the kernel usually fails on the first page load, so update the kernel first or together with PHP.

Q: Our shop runs on an old Bitrix kernel and PHP 7.4 — what now?

PHP 7.4 has been end of life since November 2022 and there is no package for the October 2026 RCEs. This is an upgrade project with a business owner, not a patch task: scope it, date it, and in the meantime reduce exposure.

Q: Does the Bitrix Security module protect against these CVEs?

No. The prologue module runs inside PHP after the vulnerable request has already been handled. It can log and block application-level patterns; it cannot intercept a bug in the interpreter.

Published 27 October 2026 · updated 27 October 2026

A Bitrix installation carries its own PHP requirements, its own way of showing them, and its own habits that hide the version from outside. Here is where the number lives and how to move it without breaking the site.

Passive. Public responses only, nothing is attacked. No account. The result is on the page. Honest: if a value is hidden, we say so instead of guessing.

Reading public responses — usually 5–20 seconds

Three places the version is stated

Admin → Settings → Tools → System check (/bitrix/admin/site_checker.php). The page lists the PHP version, loaded extensions, ini limits and the modules that fail their own checks. It also compares the version against what the current kernel requires, which is the number that matters for updates.
The server. php -v, then php-fpm<branch> -v if FPM is used. On Bitrix Virtual Appliance and panel-managed servers there are often several branches, and the site uses one specific pool.
A one-line probe file, if you have no shell and the admin is inaccessible: a temporary phpversion.php containing <?php echo PHP_VERSION;, deleted the moment you have read it. It publishes your build to anyone who guesses the filename, so keep it for seconds, not days.

What you will not get is the version from the outside. Bitrix does not print it, and most installations also strip X-Powered-By; our checker will say “PHP, version not disclosed” and is right to.

Which branches Bitrix supports

Bitrix's minimum PHP version moves with kernel releases, and it lags the newest PHP on purpose — a brand-new branch is usually supported only after a kernel update. Read the requirement from your own installation rather than from a blog: the System check page states the supported range for the kernel you run, and the marketplace module pages state it per module.

The practical consequence for this month's advisories: CVE-2026-109618 and CVE-2026-109619 are fixed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If your kernel supports the branch you are on and a fixed build exists for it, patch. If Bitrix's supported range pins you to an older branch, that is a conversation about the kernel upgrade with a deadline attached — end-of-life branches get no patch at all.

What makes a Bitrix installation different

It is a large application with its own caching and its own PHP settings. max_input_vars, memory_limit, opcache values are tuned per project; an upgrade that resets them produces “the site works but the admin panel does not”.
It often runs on mod_php behind Apache, with a .htaccess full of php_value directives. That is the configuration the PHP team rates as most exposed for these CVEs — see mod_php vs FPM.
It is frequently several sites on one server (a corporate site, a shop, a landing), each on a pool of its own. Patching “the server” without checking each pool leaves one of them on the old build.
Modules add their own PHP dependencies. A marketplace module may declare an upper bound on the PHP branch, and a kernel update may be required before you can move the branch at all.

Order of operations for a Bitrix upgrade

Snapshot. Database and files — /bitrix/backup/ or your own dump plus archive, checked by restoring it once into a test copy.
Copy to a separate vhost or server. Restore, then switch the PHP branch on the copy first.
Update the kernel on the copy if the target branch needs it, then modules. Run System check again and read what it still flags.
Walk the critical paths: catalogue and product pages, search, basket, order, payment callback, admin authorisation, the 1C exchange if you have it.
Patch and reload on production, then verify the running binary — ls -l /proc/$(pgrep -o -f 'php-fpm: master')/exe — and re-run the outside check.

Questions

Bitrix hides the PHP version — is that a problem?

Not by itself. It means an outside check cannot confirm the patch, so the proof has to come from the server. Keep the output of php -v and System check with a timestamp; that is what your client or auditor will ask for.

Can I update PHP without updating Bitrix?

Sometimes, within the range the kernel supports. Outside that range the kernel usually fails on the first page load, so update the kernel first or together with PHP.

Our shop runs on an old Bitrix kernel and PHP 7.4 — what now?

PHP 7.4 has been end of life since November 2022 and there is no package for the October 2026 RCEs. This is an upgrade project with a business owner, not a patch task: scope it, date it, and in the meantime reduce exposure.

Does the Bitrix Security module protect against these CVEs?

No. The prologue module runs inside PHP after the vulnerable request has already been handled. It can log and block application-level patterns; it cannot intercept a bug in the interpreter.