В PHP закрыты критические уязвимости: что проверить владельцу сайта
21 октября вышли исправления двух критических ошибок PHP, а 23 октября разработчики уточнили дополнительный редкий риск. Разбираем версии с исправлениями и вопросы администратору сайта на 1С-Битрикс или другой PHP-системе.
В этой статье
21 октября 2026 года разработчики PHP выпустили исправления двух критических уязвимостей, которые при определённых условиях позволяют выполнить код на сервере без авторизации. Если ваш сайт работает на PHP, сейчас стоит получить подтверждение обновления от администратора или хостинг-провайдера. Это относится и к сайтам на 1С-Битрикс: проверять нужно серверный обработчик PHP.
Главное для владельца бизнеса — убедиться, что исправление получил именно тот PHP, который обслуживает сайт, а затем проверить ключевые операции магазина. Доступная главная страница сама по себе ничего не говорит о наличии исправления.
Что известно на 23 октября
В официальном сообщении PHP от 21 октября перечислены CVE-2026-109618 и CVE-2026-109619. Разработчики призывают обновить установки, обрабатывающие веб-запросы. Риск касается разных способов запуска PHP; для Apache с mod_php описан особенно опасный сценарий, срабатывающий до выполнения кода приложения.
PHP Foundation подтверждает серьёзность обеих ошибок. Они связаны с управлением памятью и обработкой внутренних состояний PHP. Наличие уязвимой версии требует проверки и обновления, но само по себе ещё не доказывает, что конкретный сайт уже взломан. Для PHP-FPM Foundation также подтверждает выполнение кода через определённые пути приложения; считать эту среду автоматически безопасной нельзя.
Amazon Threat Intelligence сообщила о попытках эксплуатации PHP2Shell, замеченных её системами наблюдения начиная с 17 октября, до публичного раскрытия. В сообщении отдельно отмечено: неизвестно, завершились бы наблюдавшиеся попытки успешной атакой на реальные системы. Это основание ускорить защиту, а не объявлять все PHP-сайты скомпрометированными.
Какие версии содержат исправления
- PHP 8.5 — исправления выпущены в 8.5.12.
- PHP 8.4 — в 8.4.27.
- PHP 8.3 — в 8.3.36.
- PHP 8.2 — в 8.2.35.
Указаны выпуски проекта PHP от 21 октября. Поставщик Linux-дистрибутива или долгосрочной поддержки может перенести исправление в свой пакет с другим номером. Поэтому решение принимают по уведомлению поставщика и версии установленного пакета, а не только по сравнению коротких номеров.
Для PHP 8.1 и старше нужно отдельно проверить поддержку и наличие исправления у поставщика. Сам проект PHP больше не выпускает для этих веток обычные обновления; переход на поддерживаемую ветку планируют с проверкой совместимости сайта.
Уточнение PHP от 23 октября
23 октября PHP опубликовал дополнительное уведомление о редком сценарии выполнения кода, которому присвоен CVE-2026-115560. Он зависит от необычного сочетания настроек и кода приложения: формата сериализации сессии, его переключения во время запроса и включённого отслеживания прогресса загрузки. Полное уведомление и исправление PHP планирует выпустить в обычном цикле обновлений; дату следующего выпуска в сообщении не назвали.
Попросите администратора отдельно проверить применимость этого уточнения после установки исправлений от 21 октября. PHP рекомендует до следующего выпуска временно отключить отслеживание прогресса загрузки в сессии для защиты от этого сценария. Если приложение никогда не меняет обработчик сериализации во время работы, PHP разрешает оставить функцию включённой. Настройку выбирают с учётом приложения и проверяют загрузку файлов; ранее применённое отключение следует сохранить.
Что запросить у ответственного за сайт
Уточнить, какой обработчик и пакет PHP обслуживают каждый сайт. Версия консольной команды и версия веб-обработчика могут различаться.
Подтвердить устранение обеих CVE: назвать пакет, источник исправления и время установки. Ответа «сервер обновлён» без привязки к обработчику недостаточно.
Проверить, что обслуживающие сайт процессы используют исправленную сборку. Необходимые перезапуски и окно работ определяет администратор с учётом архитектуры.
Проверить после обновления вход, формы, корзину, оформление заказа, загрузки и обмен с внешними системами — те функции, которые действительно используются.
Отдельно оценить признаки возможной компрометации. Обновление закрывает уязвимость, но не удаляет последствия уже состоявшегося проникновения.
На виртуальном хостинге начните с поддержки провайдера: настройка PHP в панели не всегда показывает полную информацию о пакете. Для VPS или выделенного сервера назначьте ответственного администратора и запросите тот же набор подтверждений. Если сервер общий для нескольких сайтов, проверка одного домена не подтверждает состояние остальных обработчиков.
Если обновление пока невозможно
PHP сообщает, что изменение конфигурации не даёт полного устранения обеих уязвимостей. Временные меры необходимо выбирать по официальному уведомлению и условиям конкретной системы. Не копируйте настройки ограничения памяти или загрузки файлов в рабочий сервер без проверки: это может изменить поведение приложения и доступность магазина.
Работы по защите стоит отделить от расследования. Администратору полезно проверить неожиданные изменения файлов, запуск процессов и журналы веб-сервера. Если журналы доступны, период проверки следует начинать как минимум с 17 октября; сохраните их до очистки или перезаписи. При признаках проникновения сохраните доступные сведения и привлеките специалиста по реагированию. Наличие патча не заменяет эту проверку.
Какой ответ считать достаточным
Полезный результат — подтверждение по каждому используемому обработчику: обе уязвимости исправлены пакетом конкретного поставщика, рабочие процессы используют обновление, ключевые сценарии сайта проверены, а подозрительная активность при наличии признаков изучается отдельно.
Сведения актуальны на 23 октября 2026 года, 17:58 МСК. Источники: уведомления PHP от 21 и 23 октября, PHP Foundation и Amazon Threat Intelligence. Материал объясняет опубликованные сведения и порядок проверки; состояние конкретного сайта или инфраструктуры устанавливается отдельно.
On 21 October 2026, the PHP developers released fixes for two critical vulnerabilities that can, under certain conditions, allow unauthenticated code execution on a server. If your website runs on PHP, now is the time to obtain confirmation of the update from your administrator or hosting provider. This also applies to websites running on 1C-Bitrix: the PHP runtime serving web requests is what needs to be checked.
For a business owner, the priority is to confirm that the PHP runtime actually serving the website has received the fix, then test the store's key operations. An accessible home page alone tells you nothing about whether the fix is installed.
What is known as of 23 October
The official PHP advisory of 21 October lists CVE-2026-109618 and CVE-2026-109619. The developers urge users to update installations that serve web requests. The risk affects different ways of running PHP; a particularly dangerous scenario has been described for Apache with mod_php, where the attack is triggered before application code runs.
The PHP Foundation confirms the severity of both vulnerabilities. They concern memory management and the handling of PHP's internal state. A vulnerable version requires investigation and an update, but does not in itself prove that a particular website has already been compromised. The Foundation also confirms code execution through certain application-level paths on PHP-FPM; this environment must not be assumed safe.
Amazon Threat Intelligence reported PHP2Shell exploitation attempts detected by its monitoring systems from 17 October, before public disclosure. The report specifically notes that it is unclear whether the observed attempts would have succeeded against real-world systems. This is a reason to accelerate protection, rather than declare all PHP websites compromised.
Which versions include the fixes
- PHP 8.5 — fixes were released in 8.5.12.
- PHP 8.4 — in 8.4.27.
- PHP 8.3 — in 8.3.36.
- PHP 8.2 — in 8.2.35.
These are the PHP project's releases dated 21 October. A Linux distribution or long-term support vendor may backport the fix to a package with a different version number. Decisions should therefore be based on the vendor's advisory and the installed package version, rather than a comparison of short version numbers alone.
For PHP 8.1 and older, check support status and the availability of a fix with the vendor separately. The PHP project itself no longer provides regular updates for these branches; migration to a supported branch should be planned with website compatibility testing.
PHP's clarification of 23 October
On 23 October, PHP published an additional advisory on a rare code execution scenario, assigned CVE-2026-115560. It depends on an unusual combination of configuration and application code: the session serialization format, changing it during a request, and upload progress tracking being enabled. PHP plans to publish a full advisory and a fix in its regular release cycle; the announcement did not specify the date of the next release.
Ask the administrator to assess separately whether this clarification applies after installing the fixes released on 21 October. PHP recommends temporarily disabling session upload progress tracking until the next release to protect against this scenario. If the application never changes the serialization handler at runtime, PHP says the feature can remain enabled. Choose the setting with the application in mind and test file uploads; if the feature was disabled earlier, keep it disabled.
What to ask the person responsible for the website
Identify the PHP runtime and package serving each website. The command-line version and the version serving web requests may differ.
Confirm that both CVEs have been addressed: identify the package, the source of the fix, and when it was installed. Saying that the server has been updated is insufficient without identifying the runtime concerned.
Check that the processes serving the website are using the fixed build. The administrator should determine the necessary restarts and maintenance window based on the architecture.
After the update, test login, forms, the cart, checkout, uploads, and exchanges with external systems — the features that are actually used.
Assess signs of possible compromise separately. Updating closes the vulnerability, but does not remove the consequences of an intrusion that has already occurred.
On shared hosting, start with the provider's support team: the PHP settings in the control panel do not always show full package details. For a VPS or dedicated server, appoint a responsible administrator and request the same confirmations. If a server hosts several websites, checking one domain does not establish the status of the other runtimes.
If an update is not yet possible
PHP states that configuration changes do not fully mitigate both vulnerabilities. Temporary measures must be chosen according to the official advisory and the conditions of the particular system. Do not copy memory or file upload limit settings to a production server without testing: they may change application behaviour and the store's availability.
Keep protective measures separate from the investigation. The administrator should check for unexpected file changes, process execution, and web server logs. Where logs are available, the review period should start no later than 17 October; preserve the logs before they are cleared or overwritten. If there are signs of intrusion, preserve the available evidence and involve an incident response specialist. Having a patch installed does not replace this review.
What constitutes a sufficient response
A useful outcome is confirmation for every runtime in use: both vulnerabilities have been fixed with a package from an identified vendor, the running processes are using the update, the website's key workflows have been tested, and any signs of suspicious activity are being investigated separately.
Information current as of 23 October 2026, 17:58 Moscow time. Sources: the PHP advisories of 21 and 23 October, the PHP Foundation, and Amazon Threat Intelligence. This article explains the published information and the checks to perform; the status of a particular website or infrastructure must be established separately.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.