В Laravel нашли уязвимость в параллельных задачах. Она позволяет подделать служебное сообщение, которым фреймворк передаёт результат задачи. При этом в отдельных случаях это даёт выполнение произвольного кода на сервере. Затронуты приложения, которые передают в такие задачи пользовательские данные и печатают их.
Как подделывают результат параллельной задачи
Проблему описал сопровождающий проекта в бюллетене безопасности Laravel GHSA-63hm-g96r-2m2q от 04 ноября 2026 года. Идентификатор CVE уязвимости не присвоен, поэтому ориентироваться стоит на номер GHSA. По шкале CVSS версии 4 оценка низкая. Атака идёт по сети и требует учётных данных, хотя и низкого уровня. Сложность при этом высокая, а участие пользователя не требуется.
При этом подмена опирается на особенность обмена с дочерними процессами. Такие задачи идут в отдельных процессах. Результат каждый процесс отдаёт родителю сообщением в формате JSON, простом текстовом формате обмена данными. Когда задача печатает пользовательский текст, эти байты попадают в стандартный вывод. Злоумышленник начинает вывод с готового JSON-документа и добавляет служебные байты сжатия, чтобы родитель принял подделку за результат задачи.
Сама по себе уязвимость не срабатывает. Если в приложении нет маршрута до механизма параллельных задач, атака невозможна. Такой маршрут пишет разработчик, и по умолчанию его нет. Кроме того, задача должна выводить в стандартный поток данные из запроса. В результате первые байты вывода задаёт атакующий, а остальное дописывает сам.
Часто разработчик выводит в поток отладочную строку или ответ внешней утилиты. Именно эти байты получает атакующий. Поэтому опасность зависит от стиля кода, а не от настроек фреймворка. Достаточно одного такого места, чтобы сценарий стал возможен.
Кого затрагивает проблема
В первую очередь проблема касается приложений, которые вынесли тяжёлые операции в параллельные задачи. Обычно так поступают с отчётами, выгрузками и обработкой файлов. При этом оценка влияния на конфиденциальность, целостность и доступность низкая. То же касается последствий для смежных систем, связанных с приложением. Предел возможностей задают права процесса.
От них зависит, что именно сможет сделать атакующий. В ряде случаев он читает файлы приложения и меняет их. Поэтому обновление важно даже при низкой оценке. Для сервера это означает доступ к данным, которые обрабатывает приложение. Из-за этого проверять такие задачи стоит в первую очередь.
Чтобы дойти до задачи, атакующему нужен доступ к маршруту, который её запускает. Обычно такие маршруты прикрыты авторизацией. Так и срабатывает требование учётных данных низкого уровня из оценки. Без входа в приложение атака не начнётся.
Как проверить приложение
Проверка начинается с поиска мест, где задача печатает данные из запроса. Если таких мест нет, воспользоваться уязвимостью не получится. Помогает и запрет на прямой вызов механизма параллельных задач из внешних маршрутов. При этом сама проверка занимает немного времени. После неё проще решить, обновляться сразу или по плану.
Уязвимость закрыта в версии 13.40.0. Кроме того, исправление перенесли в ветку 12.x. Для более старых веток патча в бюллетене нет. Сведений об эксплуатации в реальных атаках тоже нет. Обновление ставят штатным способом через Composer, менеджер зависимостей проекта.
При отложенном обновлении помогает сокращение мест, где задача печатает пользовательский текст. При этом такие задачи лучше не наполнять данными из запроса без проверки. Ещё одна мера - не открывать механизм параллельных задач внешним маршрутам напрямую. Обходные меры не заменяют патч. После установки 13.40.0 подделать служебное сообщение задачи нельзя, и это главное изменение в защищённости.
Ссылки
