Три уяза на каждую букву
Три уяза на каждую букву Команда разработчиков PHP раскрыла три уязвимости в ядре, которые уже закрыты в версиях 8.2.33, 8.3.33, 8.4.24 и 8.5.9. Проблемы затронули расширения ext-pgsql, ext-phar и ext-bcmath, и каждая из них заслуживает отдельного внимания, потому что ломают они все по-своему. Самая опасная — CVE-2026-17543 с высоким рейтингом. SQL-инъекция в функции вроде pg_insert() и pg_update(). Дело в том, что PHP неправильно экранировал обратную косую черту в PostgreSQL, когда включен режим standard_conforming_strings (а он включен по умолчанию с версии 9.1). Атакующий мог передать значение вроде zzz\' OR 1=1 --, и это превращалось в рабочий SQL-запрос, обходящий все фильтры. Вторая уязвимость, CVE-2026-7260, уже помечена как Moderate, но тоже неприятная — она в ext-phar. Функция phar_get_link_source() рекурсивно раскрывала символьные ссылки внутри phar-архивов без ограничения глубины и без защиты от циклов. Достаточно было создать tar-архив с двумя ссылками, указывающими друг на друга, и при попытке прочитать содержимое PHP падал с переполнением стека вызовов. Хорошая новость тут, что для эксплуатации нужен локальный доступ и взаимодействие с пользователем. Третья, CVE-2026-17544, снова высокая опасность, и уже из области памяти. В ext-bcmath при обрезании нулей у числа код неправильно пересчитывал указатель, из-за чего копировал строку в буфер меньшего размера. BCMath использует стековый буфер, а потом переключается на кучу, так что в зависимости от ситуации можно испортить либо стек, либо кучу. Починили все просто — переприсвоили указатель после обрезки. В общем, разработчики PHP снова напоминают: обновляйтесь, пока кто-нибудь не решил проверить, как вы обрабатываете числа и архивы. Потому что если ваша математическая библиотека может выстрелить вам в ногу, то, может, не стоит доверять ей сложение двух чисел? Или хотя бы стоит ставить патчи вовремя, чтобы она не делала это с ошибкой переполнения буфера. @antiinfosec