
Неофициальное исправление для CVE-2026-109618 / CVE-2026-109619 (php2shell) для пакетов PHP 5.4 / 5.3 с истёкшим сроком поддержки в RHEL, CentOS и Oracle Linux 7 / 6
Неофициальное исправление для CVE-2026-109618 и CVE-2026-109619 ("php2shell") для пакетов PHP с истёкшим сроком поддержки
в Enterprise Linux 6 и 7: php-5.3.3 (RHEL / CentOS / Oracle Linux 6) и php-5.4.16
(RHEL / CentOS / Oracle Linux / Scientific Linux 7).
PHP исправил обе уязвимости 21 октября 2026 года в версиях 8.2.35, 8.3.36, 8.4.27 и 8.5.12, а также опубликовал исходные бэкпорты для 7.4, 8.0 и 8.1. Для PHP 5 ничего не выпускалось, и поставщики EL6 / EL7 не выпустили исправление. Если вам необходимо поддерживать работу такой системы, этот проект предоставляет пересобранные пакеты поставщика с портированием официального минимального исправления.
Это не официальное исправление от PHP, Red Hat или Oracle. Оно снижает риск до тех пор, пока вы не сможете перейти на поддерживаемую версию PHP — сделайте это как можно скорее. На EL8 / EL9 / EL10 вместо этого устанавливайте обновления вашего поставщика (например, ELSA/RHSA-2026:87080, 87151, 87079).
php-5.4.16 /
php-5.3.3, в которых отсутствуют более поздние исправления безопасности поставщика в том же коде
(например, CVE-2015-4024 в разборе заголовков multipart).| Дистрибутив | Пакет поставщика | Исправленный пакет из этого проекта |
|---|---|---|
| RHEL / CentOS / Oracle Linux / Scientific Linux 7 | php-5.4.16-48.el7 | php-5.4.16-48.el7.php2shell.1 |
| RHEL / CentOS / Oracle Linux 6 | php-5.3.3-50.el6_10 | php-5.3.3-50.el6_10.php2shell.1 |
Суффикс релиза сортируется выше пакета поставщика и ниже любого будущего исправления поставщика
(например, 48.el7_9.1), поэтому официальное исправление, если оно когда-либо появится, заменит это обычным обновлением.
Вероятно, менее серьёзно, чем для PHP 7 и 8, но однозначного ответа пока нет:
php для RHEL 6 / 7 как не подверженные CVE-2026-109619 ("уязвимый код отсутствует")
и указывает CVE-2026-109618 как находящуюся на рассмотрении
(CSAF VEX).Этот проект всё равно применяет официальную меру защиты: он устраняет сам небезопасный путь обработки ошибок, а не только известный способ его достижения.
Из подписанного репозитория yum на GitHub Pages:
# EL7
curl -o /etc/yum.repos.d/php2shell-eol-backport.repo \
https://alvm.github.io/php2shell-eol-backport/php2shell-eol-backport-el7.repo
# EL6
curl -o /etc/yum.repos.d/php2shell-eol-backport.repo \
https://alvm.github.io/php2shell-eol-backport/php2shell-eol-backport-el6.repo
yum update 'php*' # confirm the signing key: fingerprint under "Signing key" below
service httpd restart # and php-fpm, if you use it
Репозиторий содержит только PHP-пакеты этого проекта, и как пакеты, так и метаданные
репозитория подписаны (gpgcheck=1, repo_gpgcheck=1). RPM-пакеты и исходные RPM-пакеты также прикреплены к каждому
релизу вместе с подписанным SHA256SUMS; устанавливайте их
с помощью yum localinstall.
./tools/check-patched.sh
Он перечисляет каждый установленный пакет PHP 5 как FIXED или VULNERABLE, проверяет, что PHP CLI запускает исправленный
код, и предупреждает, если httpd или php-fpm были запущены до обновления и всё ещё выполняют старый код.
Исправление следует официальному минимальному бэкпорту, который отдаёт предпочтение безопасности, а не изящной обработке ошибок:
memory_limit (или размер выделения
переполняется), PHP выводит Fatal error: ... в stderr (журнал ошибок веб-сервера), и процесс немедленно завершается.
Apache / php-fpm запускают новый рабочий процесс. Функции завершения не выполняются, а временные файлы загрузок в этом
запросе не удаляются — tmpwatch (EL6) и systemd-tmpfiles (EL7) со временем очищают их из /tmp.Content-Disposition и Content-Type каждой части
(единственные, которые использует PHP), а новая директива php.ini max_multipart_body_parts ограничивает число
частей (по умолчанию -1 = max_input_vars + max_file_uploads).zend_mm_safe_error_ex) и не изменяет существующий API или ABI, поэтому
расширения, собранные для пакета вендора, продолжают работать.Это минимальная мера против опубликованных путей атаки, а не полное обновление безопасности PHP 5.
Собрано из исходных RPM вендора (закреплённый SHA-256 в build/build.sh); изменение spec-файла составляет 8 строк
(spec/*/php.spec.diff).
Набор тестов PHP (make test, запускаемый во время сборки RPM) сравнивался с немодифицированной пересборкой
того же пакета вендора. Новые сбои только ожидаемые:
тесты прогресса загрузки сессии (функция отключена) и tests/lang/bug45392.phpt (сообщение о фатальной ошибке
теперь начинается с пустой строки, как в официальном патче 7.4).
| тесты | сбоев: вендор | сбоев: с патчем | |
|---|---|---|---|
| EL7, PHP 5.4.16 | 12373 | 14 | 23 (8 прогресс загрузки + bug45392) |
| EL6, PHP 5.3.3 | 11213 | 55 | 56 (bug45392) |
Точные значения немного различаются между средами сборки: на GitHub runners также падают два теста SPL на владельца файла
(DirectoryIterator_getOwner/getGroup_basic), а time_sleep_until_basic чувствителен к таймингам.
Ни один из них не затрагивает код, изменённый патчем.
Патч для PHP 5.4 сравнивался с независимым портом того же исправления для php-5.4.16 в Amazon Linux 2:
основные изменения идентичны. Различия перечислены в docs/ALTERNATIVES.md.
Код эксплойта не писался и не использовался. Пожалуйста, самостоятельно проверьте патч на соответствие upstream-коммиту.
См. docs/ALTERNATIVES.md для статуса вендора, списка проектов и сравнения.
Требуется Docker и около 3 ГБ свободного дискового пространства на каждую сборку.
build/build.sh el7 # results in _build/el7/RPMS
build/build.sh el6 # results in _build/el6/RPMS