Угрозы

Нулевой байт пробил защиту PHP и открыл путь к базам данных

Маша Даровская
By Маша Даровская , IT-редактор и автор
Нулевой байт пробил защиту PHP и открыл путь к базам данных
Обложка © Anonhaven

Исследователи Positive Technologies Алексей Соловьёв и Никита Свешников обнаружили две уязвимости в компонентах PHP, отвечающих за работу с базами данных PostgreSQL и Firebird. Одна ошибка позволяла внедрять произвольные SQL-команды, вторая — аварийно завершать процесс PHP и нарушать работу интернет-магазинов, внутренних сервисов и других веб-приложений. Разработчики языка получили отчёты в рамках ответственного раскрытия и выпустили исправления.

Проблемы зарегистрированы под номерами CVE-2025-14179 и CVE-2025-14180. Они находились не в WordPress, Drupal, Magento или другом отдельном продукте, а внутри PHP Data Objects — стандартного слоя PHP для подключения приложений к разным системам управления базами данных через единый интерфейс.

Такое расположение делало ошибки особенно неприятными. Разработчик мог правильно использовать штатные функции экранирования и подготовленные запросы, однако уязвимость срабатывала уровнем ниже — при обработке данных самим драйвером.

Самой опасной стала CVE-2025-14179 в драйвере pdo_firebird, через который PHP-приложения подключаются к базе данных Firebird. Национальная база уязвимостей США оценила её в 9,8 балла из 10 по версии CVSS 3.1, что соответствует критическому уровню опасности. При использовании более новой методики CVSS 4.0 разработчики PHP присвоили ошибке 7,4 балла и высокий уровень. Разница связана с условиями эксплуатации, которые по-разному учитываются двумя версиями шкалы.

Причиной стал нулевой байт \x00. Он используется в низкоуровневых языках и библиотеках как признак окончания строки. Драйвер Firebird собирал SQL-запрос из отдельных частей и для копирования строки применял функцию, которая прекращала работу после встречи с нулевым байтом.

Закрывающая кавычка при этом терялась. Оставшаяся часть запроса начинала интерпретироваться в другом контексте, а управляемые пользователем данные могли превратиться в SQL-команду.

Официальное уведомление PHP показывает, что проблема затрагивала операции SELECT, INSERT, UPDATE, DELETE, MERGE, WITH и EXECUTE. Уязвимость могла проявиться при использовании PDO::quote(), то есть функции, предназначенной для безопасной подготовки значения перед включением в запрос.

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

Дальнейший захват сервера не являлся автоматическим результатом SQL-инъекции. Такой сценарий требовал дополнительных условий: опасных функций в базе, избыточных прав, возможности загрузить исполняемый файл или другой уязвимости в веб-приложении.

CVE-2025-14180 затрагивала работу PDO с PostgreSQL. Уязвимость проявлялась, когда приложение включало эмуляцию подготовленных запросов через параметр PDO::ATTR_EMULATE_PREPARES.

В этом режиме PHP самостоятельно объединяет шаблон SQL-запроса с его параметрами. База данных получает уже сформированную строку, а не исходный шаблон и отдельный набор значений.

Специально сформированная недопустимая последовательность символов могла заставить функцию PostgreSQL вернуть пустой указатель. PHP продолжал обращаться к нему как к существующему объекту. Возникало разыменование нулевого указателя, после чего процесс завершался с ошибкой сегментации. NVD оценивает уязвимость в 7,5 балла по CVSS 3.1; разработчики PHP указывают 8,2 балла по CVSS 4.0.

Обработка исключений через try-catch в таком случае не спасала. Ошибка происходила внутри интерпретатора и приводила к завершению процесса операционной системой.

Одиночное падение PHP-процесса обычно не означает длительную остановку всего сайта: менеджер процессов или веб-сервер может запустить новый обработчик. Регулярная отправка вредоносных запросов способна вызвать повторяющиеся сбои, увеличить нагрузку и нарушить выполнение составных операций.

Особенно опасны процессы, разделённые между несколькими системами. Платёж уже может пройти, а создание заказа, формирование документа или отправка задания на склад — прерваться. Без общей транзакции и механизма повторной обработки данные окажутся в разных состояниях.

Обе уязвимости располагались внутри самого PHP и его драйверов баз данных. Код приложения при этом мог выглядеть корректно: данные передавались в PDO, использовались штатные функции, явной склейки запроса с пользовательской строкой разработчик не выполнял.

Статические анализаторы обычно проверяют исходный код приложения и доступные зависимости. Они ищут путь от пользовательского ввода до опасной функции, неправильное экранирование или прямое объединение строк. Ошибка в низкоуровневой реализации интерпретатора может остаться за пределами такой модели. В результате защитный механизм сам становился точкой обхода защиты. 

PHP применяется на 70,8% сайтов, для которых W3Techs смог определить серверный язык программирования.

Positive Technologies обнаружила в России около 1,8 млн потенциально уязвимых ресурсов с PHP. Эта цифра не означает, что все 1,8 млн сайтов можно было атаковать через найденные ошибки. Для CVE-2025-14179 требовался драйвер Firebird и уязвимый способ формирования запроса. Для CVE-2025-14180 — PostgreSQL, драйвер PDO, включённая эмуляция подготовленных запросов и возможность передать повреждённую последовательность в обрабатываемый параметр.

Обычный сайт на PHP с MySQL или MariaDB напрямую этими двумя ошибками не затрагивался. Наличие WordPress тоже не подтверждает уязвимость: стандартные установки WordPress чаще используют MySQL или MariaDB.

В зоне риска находились интернет-магазины, корпоративные порталы, прикладные интерфейсы, внутренние системы автоматизации и собственные PHP-приложения, подключённые к Firebird или PostgreSQL через уязвимые компоненты PDO.

CVE-2025-14179 затрагивала PHP 8.2 до версии 8.2.31, PHP 8.3 до 8.3.31, PHP 8.4 до 8.4.21 и PHP 8.5 до 8.5.6.

CVE-2025-14180 присутствовала в PHP 8.1 до 8.1.34, PHP 8.2 до 8.2.30, PHP 8.3 до 8.3.29, PHP 8.4 до 8.4.16 и PHP 8.5 до 8.5.1. Исправленные сборки перечислены в официальных уведомлениях проекта.

Устанавливать минимальную исправленную сборку сейчас нет особого смысла. На 14 июля 2026 года актуальными выпусками являются PHP 8.5.8, 8.4.23, 8.3.32 и 8.2.32. Ветка PHP 8.1 уже снята с поддержки, даже если последняя версия 8.1.34 содержит исправление CVE-2025-14180.

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

Вопросы и ответы

Уязвимы ли все сайты на PHP?

Нет. CVE-2025-14179 связана с драйвером Firebird, а CVE-2025-14180 — с PostgreSQL и эмуляцией подготовленных запросов. Сайты, которые не используют эти компоненты, напрямую найденными ошибками не затрагиваются.

Почему говорится о 1,8 млн ресурсов?

Это оценка числа потенциально уязвимых PHP-ресурсов в России. Она не подтверждает наличие нужного драйвера, конфигурации и достижимого пользовательского ввода на каждом сайте.

Какая уязвимость считается критической?

CVE-2025-14179 получила 9,8 балла по CVSS 3.1 в оценке NVD. Она позволяет провести SQL-инъекцию через драйвер pdo_firebird. Оценка PHP Group по CVSS 4.0 составляет 7,4 балла, то есть высокий уровень.

Можно ли закрыть проблему настройками?

Для PostgreSQL отключение эмуляции подготовленных запросов сокращает риск CVE-2025-14180. Надёжное решение — обновление PHP. Для Firebird полагаться на обходные меры не стоит.

Поможет ли веб-экран или система предотвращения атак?

Такие средства могут заблокировать известную вредоносную последовательность, но не гарантируют защиту от всех вариантов. Ошибка находится внутри интерпретатора, поэтому приоритетом остаётся установка исправленной версии.

Затрагивает ли проблема WordPress?

Типичная установка WordPress использует MySQL или MariaDB и не попадает под условия этих двух CVE. Отдельная сборка WordPress или плагин могут подключаться к PostgreSQL либо Firebird через собственный код, поэтому конфигурацию всё равно следует проверить.

Были ли реальные атаки?

Публичные технические примеры эксплуатации существуют. Подтверждённые сведения о массовом применении CVE-2025-14179 или CVE-2025-14180 в реальных атаках на момент публикации

Есть новость? Станьте автором.

Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.