Обсуждение ⚠️ Критические дыры в PHP: сегодня после 17:00 МСК обновляем PHP на серверах с DLE

[iCooLER]

Всем привет!

В PHP нашли серьезные уязвимости — их называют «php2shell».

— Возможно затронуты версии php от 5.4 и выше (неподтверждено).
— Думаю слово "шелл" уже многим должно намекнуть, что дело неладно.
— Можно удалённо выполнить код на сервере, то есть захватить сайт. Опасность — 9.2 из 10.
— Сегодня, 21 октября, в 17:00 МСК разработчики PHP выпустят исправления.
— Обновления ждут для PHP 8.2, 8.3, 8.4 и 8.5.
— PHP 8.1, 7.x и 5.x официальных патчей, скорее всего, не получат.
— Уязвимости получили номера CVE-2026-109618 и CVE-2026-109619.

 

[iCooLER]

Выкатили инфу и патчи PHP: News Archive - 2026

 

[Sardorbek]

Если вы хотите обновить все ожидающие обновления пакеты в вашей системе одновременно (включая PHP 7.4, 8.3 и 8.5), вы можете использовать эту универсальную команду (Ubuntu):

apt-get update && apt-get upgrade

2. Применение изменений После успешного завершения обновления перезапустите веб-сервер, чтобы новые модули работали корректно:

systemctl restart apache2
systemctl restart nginx
systemctl restart 'apache2-isp@*'
systemctl restart 'php*fpm*'

Для информации:
Версии от 7.4 до 8.5 опубликованы.
Версии от 5.6 до 7.3 задерживаются

 

[Sardorbek]

Версии пакетов с исправлениями:

7.4.33-1782
8.0.30-1782
8.1.34-1782
8.2.35-1781
8.3.36-1781
8.4.27-1781
8.5.12-1781

 

[Zagad]

@Sardorbek Как узнать, что именно 7.4.33-1782 версия пакета стоит?

 

[ZerocooL]

Как узнать, что именно 7.4.33-1782 версия пакета стоит?

Zagad, на Ubuntu/Debian корректнее проверять именно версию установленного пакета, а не только вывод php -v.

Для PHP 7.4 выполните:

dpkg-query -W -f='${Package}\t${Version}\n' 'php7.4*'

Либо по конкретным пакетам:

apt-cache policy php7.4-cli php7.4-fpm php7.4-common

Если используется Apache-модуль:

apt-cache policy libapache2-mod-php7.4

Также можно посмотреть все установленные PHP-пакеты:

dpkg -l | grep php

Важно: php -v обычно покажет версию PHP, например 7.4.33, но не всегда покажет номер сборки пакета вида -1782. Поэтому для проверки именно 7.4.33-1782 лучше использовать dpkg-query или apt-cache policy.

После обновления не забудьте перезапустить PHP-FPM/веб-сервер, например:

systemctl restart php7.4-fpm
systemctl restart nginx

или для Apache:

systemctl restart apache2

 

[ZerocooL]

Ai все верно ?

 

[Ai]

все верно ?

Да, в целом всё верно.

Главное уточнение: для проверки сборки вида 7.4.33-1782 действительно надо смотреть пакет, а не только php -v.

Проверка установленной версии:

dpkg-query -W -f='${Package}\t${Version}\n' 'php7.4*'

Или точечно:

apt-cache policy php7.4-cli php7.4-fpm php7.4-common libapache2-mod-php7.4

Обновление:

apt-get update && apt-get upgrade

После обновления перезапустить нужные сервисы:

systemctl restart php7.4-fpm
systemctl restart nginx

Для Apache:

systemctl restart apache2

Если ISPmanager/панель с отдельными Apache-инстансами:

systemctl restart 'apache2-isp@*'

Важно: если на сервере несколько версий PHP, проверять и перезапускать надо именно ту, которая используется сайтом в панели/виртхосте. php -v в консоли может показывать CLI-версию, а сайт может работать через другой php-fpm.

 

[Sardorbek]

Версии пакетов с исправлениями:

7.4.33-1782
8.0.30-1782
8.1.34-1782
8.2.35-1781
8.3.36-1781
8.4.27-1781
8.5.12-1781

Выпустили сборки, исправляющие уязвимость в устаревших версиях PHP:

5.4.45-1794
5.5.38-1794
5.6.40-1786
7.0.33-1786
7.1.33-1786
7.2.34-1786
7.3.33-1786
7.4.33-1782
8.0.30-1782
8.1.34-1782

Ранее выпустили патчи к актуальным версиям:

8.2.35-1781
8.3.36-1781
8.4.27-1781
8.5.12-1781

 

[Skyworker]

Типа, уязвимость обнаружили только что? А раньше как? Те, кому надо использовали эту уязвимость, как здрасьте? Или, просто, произошла какая-то критическая утечка данных о том, как можно использовать эту уязвимость? Пиздец! Ну, если дыры находят в php движках то, что уже говорить о бесплатных плагинах, которые слеплены кем-то на коленке?

 

[iCooLER]

в php движках

в языке php уязвимость нашли, а не в движке (dle или wp, например).

что уже говорить о бесплатных плагинах

как раз в плагинах всегда баги и были. почитай про wp например - большинство дыр находится в плагинах.

Ai я прав? например wp - чаще ведь плагины дырявые а не движок wp?

 

[Ai]

в языке php уязвимость нашли, а не в движке (dle или wp, например).

как раз в плагинах всегда баги и были. почитай про wp например - большинство...

Да, в целом прав.

По WordPress чаще всего дыры находят именно в:

• плагинах;
• темах;
• самописных доработках;
• старых не обновлённых компонентах.

Сам ядро WordPress тоже не идеальное, уязвимости бывают, но оно намного активнее проверяется, быстрее патчится и стоит на миллионах сайтов. А вот плагин может написать один человек, забросить на 2 года — и привет.

С PHP ситуация другая: если уязвимость в самом интерпретаторе/рантайме PHP, то потенциально под ударом могут быть разные CMS: DLE, WP, Joomla, самопис и т.д. Тут уже не важно, какой движок, если связка PHP + веб-сервер + конфиг позволяет это эксплуатировать.

Правильный вывод такой:

• ядро CMS держать обновлённым;
• PHP обновлять обязательно;
• плагины/модули ставить только нужные;
• удалять неиспользуемые, а не просто отключать;
• не держать старые PHP 5.x/7.x без крайней необходимости;
• делать бэкапы перед обновлениями;
• следить за правами файлов и запретами на выполнение PHP в upload/cache.

Для WP статистически да — чаще стреляют именно плагины и темы, а не само ядро. Для DLE похожая история: самописные хаки, модули, шаблоны и старые сборки часто опаснее чистого актуального движка.

 

[Skyworker]

Ai, почему уязвимость php нашли только сейчас? Получается, что ее раньше использовали те, кто о ней знал?

 

[Ai]

, почему уязвимость php нашли только сейчас? Получается, что ее раньше использовали те, кто о ней знал?

Да, такое теоретически возможно, но из факта патча это не следует.

Обычно варианты такие:

• Баг существовал давно, но его нашли только сейчас через аудит, fuzzing, crash-репорты или исследователей.
• Эксплуатируемость стала понятна позже: раньше это выглядело как обычный баг/краш, а потом доказали, что можно получить серьёзные последствия.
• Уязвимость была закрыто сообщена разработчикам, они подготовили патчи, потом вышел публичный advisory.
• Кто-то мог использовать как 0-day, если знал раньше, но это не всегда подтверждается.
• В старые ветки PHP патч просто бэкпортнули, поэтому версии 5.4–8.1 тоже получили новые сборки, хотя сами ветки давно устаревшие.

То есть логика такая: дыра могла быть в коде годами, но массово опасной она становится после публичного раскрытия деталей или появления готового PoC/эксплойта.

Поэтому правильная реакция — не гадать, кто и когда знал, а быстро обновить PHP, перезапустить FPM/веб-сервер и проверить версии пакетов через dpkg-query / apt-cache policy, а не только php -v.

 

[iCooLER]

Ai есть примеры когда найденная дыра затрагивала старые версии многолетней давности? помимо php

 

[Ai]

есть примеры когда найденная дыра затрагивала старые версии многолетней давности? помимо php

Да, таких примеров полно. Дыра может жить в коде годами, пока её не найдут или не поймут, как нормально эксплуатировать.

• Heartbleed / OpenSSL / CVE-2014-0160
  Баг был добавлен примерно в 2012, публично нашли в 2014. Затрагивал кучу серверов с OpenSSL 1.0.1.
  
• Shellshock / Bash / CVE-2014-6271
  Уязвимость в Bash существовала очень давно, фактически десятилетиями. Опасна была через CGI, DHCP и разные системные обвязки.
  
• GHOST / glibc / CVE-2015-0235
  Баг в gethostbyname() был в glibc с 2000-х, обнаружили как серьёзную уязвимость намного позже.
  
• ImageTragick / ImageMagick / CVE-2016-3714
  Проблема в обработке изображений. Часто била по сайтам, где разрешена загрузка картинок/аватарок.
  
• Log4Shell / Log4j / CVE-2021-44228
  Библиотека Java, дыра была в популярных версиях Log4j 2 много лет. После раскрытия началась массовая эксплуатация.
  
• Baron Samedit / sudo / CVE-2021-3156
  Уязвимость в sudo, существовала около 10 лет. Давала локальное повышение привилегий.
  
• Apache Struts / CVE-2017-5638
  Старая дыра в фреймворке, через неё массово ломали сайты/сервисы, если Struts не обновляли.
  
• Exim / разные CVE
  В почтовом сервере Exim регулярно находили критичные уязвимости, часть затрагивала старые ветки и долго не обновляемые серверы.

Итого: это обычная история. Код может быть старый, популярный и всеми используемый, но конкретный сценарий эксплуатации находят только спустя годы. Поэтому важны не только CMS/плагины, но и системные пакеты: OpenSSL, glibc, nginx/apache, imagemagick, exim, sudo и т.д.

 

[Skyworker]

Ai пошагово объясни, как и что обновлять и как проверить после обновления.

 

[Ai]

пошагово объясни, как и что обновлять и как проверить после обновления.

Пошагово для Debian/Ubuntu + DLE/PHP-FPM

1. Сначала сделай бэкап
   
   Файлы сайта + база:
   
   

   tar -czf /root/site_backup_$(date +%F).tar.gz /var/www/site.ru
   mysqldump -uUSER -p DBNAME > /root/db_backup_$(date +%F).sql

2. Посмотри, какие PHP стоят на сервере
   
   

   dpkg-query -W -f='${Package}\t${Version}\n' 'php*' | sort

   
   Отдельно по FPM:
   
   

   systemctl list-units --type=service | grep php

   
   И CLI-версия:
   
   

   php -v

   
   Важно: php -v показывает PHP в консоли, а сайт может работать через другой php-fpm.
   
3. Проверь, какой PHP использует сайт
   
   Если nginx:
   
   

   grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/null

   
   Обычно будет что-то типа:
   
   

   fastcgi_pass unix:/run/php/php7.4-fpm.sock;

   
   Значит сайт работает через php7.4-fpm.
   
   Если Apache:
   
   

   apache2ctl -M | grep php

   
   Или для FPM:
   
   

   grep -R "SetHandler\|proxy:unix\|php-fpm" /etc/apache2/ 2>/dev/null

4. Обнови список пакетов
   
   

   apt update

5. Посмотри, какие обновления доступны
   
   

   apt list --upgradable | grep php

   
   И точечно по нужным версиям:
   
   

   apt-cache policy php7.4-cli php7.4-fpm php7.4-common

   
   Для других версий меняешь 7.4 на свою: 5.6, 7.2, 8.1, 8.2 и т.д.
   
6. Обнови PHP
   
   Лучше обновить все пакеты PHP:
   
   

   apt install --only-upgrade 'php*'

   
   Либо обычное обновление системы:
   
   

   apt upgrade

   
   Если надо конкретную ветку, например PHP 7.4:
   
   

   apt install --only-upgrade php7.4-cli php7.4-fpm php7.4-common php7.4-mysql php7.4-curl php7.4-mbstring php7.4-xml php7.4-zip php7.4-gd

7. Перезапусти PHP-FPM и веб-сервер
   
   Для PHP 7.4:
   
   

   systemctl restart php7.4-fpm

   
   Для nginx:
   
   

   systemctl restart nginx

   
   Для Apache:
   
   

   systemctl restart apache2

   
   Если стоит несколько версий PHP, перезапусти нужные:
   
   

   systemctl restart php5.6-fpm
   systemctl restart php7.4-fpm
   systemctl restart php8.1-fpm

8. Проверь, что службы живые
   
   

   systemctl status php7.4-fpm --no-pager
   systemctl status nginx --no-pager

   
   Или Apache:
   
   

   systemctl status apache2 --no-pager

   
   Проверка ошибок nginx:
   
   

   nginx -t

   
   Проверка Apache:
   
   

   apache2ctl configtest

9. Проверь версии пакетов после обновления
   
   Например для PHP 7.4:
   
   

   dpkg-query -W -f='${Package}\t${Version}\n' php7.4-cli php7.4-fpm php7.4-common

   
   Для всех PHP:
   
   

   dpkg-query -W -f='${Package}\t${Version}\n' 'php*' | sort

   
   Сверяешь, чтобы были нужные сборки, например:
   
   

   php7.4-fpm 7.4.33-1782
   php7.4-cli 7.4.33-1782
   php7.4-common 7.4.33-1782

10. Проверь сайт
    
    Открой сайт в браузере и админку DLE.
    
    Также можно проверить ответ через консоль:
    
    

    curl -I https://site.ru

    
    Если 200/301/302 — нормально. Если 500 — смотри логи.
    
11. Проверь логи после обновления
    
    Для nginx:
    
    

    tail -n 100 /var/log/nginx/error.log

    
    Для Apache:
    
    

    tail -n 100 /var/log/apache2/error.log

    
    Для PHP-FPM:
    
    

    journalctl -u php7.4-fpm -n 100 --no-pager

    
    Для DLE также глянь логи движка, если включены.

Короткая проверочная команда

Для PHP 7.4:

apt update
apt install --only-upgrade 'php7.4*'
systemctl restart php7.4-fpm
systemctl restart nginx
dpkg-query -W -f='${Package}\t${Version}\n' 'php7.4*' | sort

Важный момент

Если сайт на DLE работает на PHP 7.4 через FPM, то обновление php8.2-cli ничего для сайта не даст. Проверять надо именно ту версию PHP, к которой подключен виртуальный хост сайта.

 

[Skyworker]

Ai ты мне дичи тут понаписал. Пошел и спросил у ИИ Гугла, как проверить наличие патча для Ubuntu, он мне сразу выдал команду - pro fix CVE-2026-109618, если патч уже есть, то, все, что ты написал не нужно, все уже стоит и сервер в безопасности.

 

[Ai]

ты мне дичи тут понаписал. Пошел и спросил у ИИ Гугла, как проверить наличие патча для Ubuntu, он мне сразу выдал команду - pro fix CVE-2026-109618,...

Да, pro fix CVE-2026-109618 — нормальный вариант для Ubuntu, если PHP установлен из реп Ubuntu/Ubuntu Pro и CVE уже есть в их базе.

Но нюанс: это не универсальная проверка “сервер точно в безопасности”.

Проверь так:

pro status
pro fix CVE-2026-109618

Если пишет, что пакет уже исправлен / обновлений не требуется — ок для пакетов Ubuntu.

Но я бы всё равно проверил 3 вещи:

• Какая версия PHP реально обслуживает сайт, а не только CLI:

grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/null

• Какие PHP-пакеты стоят и откуда они:

apt-cache policy php php-fpm php8.1-fpm php8.2-fpm php8.3-fpm

• Перезапущен ли PHP-FPM после обновления:

systemctl restart php8.2-fpm
systemctl restart nginx

Версию замени на свою: php7.4-fpm, php8.1-fpm, php8.3-fpm и т.д.

Почему мой список был длиннее: потому что на серверах часто PHP стоит не из стандартных реп Ubuntu, а из:

• Ondrej PPA;
• реп ISPmanager;
• реп Plesk;
• CloudLinux/alt-php;
• ручных сборок;
• Docker-контейнеров.

В этих случаях pro fix CVE-... может вообще не закрывать конкретный PHP, на котором работает сайт.

Минимальная нормальная проверка после pro fix:

php -v
dpkg -l | grep php
systemctl list-units --type=service | grep php

И главное — смотреть именно тот php-fpm, к которому подключен nginx/apache. Если pro fix подтвердил, что CVE закрыта, PHP из официальных реп Ubuntu и FPM перезапущен — тогда да, сервер по этой дыре закрыт.