Главные новости разработки и безопасности: Bun, LiteLLM, HTTP/3, Laravel и PHP

Последние новости экосистем JavaScript, Python, PHP и сетевых протоколов показывают сразу несколько важных тенденций: инструменты разработки становятся быстрее и автономнее, но одновременно растет цена ошибок в цепочках поставок и конфигурации серверов. В этом обзоре разбираем новый форматтер Bun, атаку на пакет LiteLLM, проблемы с обработкой QPACK в HTTP/3, уязвимости Laravel и активно эксплуатируемые ошибки PHP.

Bun 1.4.4 получил встроенный форматтер bun fmt

Выпуск Bun 1.4.4, опубликованный 22 октября 2026 года, добавил в среду выполнения встроенный форматтер bun fmt. Он предназначен для JavaScript, TypeScript, JSX, CSS, HTML, Vue, Svelte, JSON, YAML, TOML, Markdown и ряда других форматов. Команда умеет работать в режимах проверки и автоматического исправления, а параметры --check, --staged и --changed позволяют встроить форматирование в CI и Git-хуки. Это избавляет проект от отдельной зависимости на Prettier или другой форматтер, что особенно заметно в больших монорепозиториях, где запуск подобных инструментов занимает существенное время.

Одним из главных преимуществ стала совместимость с уже существующими настройками. bun fmt читает конфигурационные файлы Prettier, .editorconfig, .prettierignore и настройки oxfmt. При этом совместимость конфигурации не означает полного совпадения результата побайтно. По данным Bun, 9648 из 9731 теста Prettier дали идентичный результат, но в полном сравнении репозитория Prettier совпали только 57 из 74 сценариев. Поддержка отдельных плагинов может отсутствовать, а синтаксис, который обрабатывается только через Babel или специализированные расширения, способен привести к ошибке. Поэтому перед миграцией стоит запустить bun fmt --check на реальной кодовой базе, проверить изменения и закрепить версию Bun. Важно также не путать новую команду с прежней bun format: последняя запускает скрипт форматирования, указанный в package.json.

В LiteLLM 1.107.0 обнаружили бэкдор для кражи учетных данных

С выпуском LiteLLM 1.107.0 произошел серьезный инцидент в цепочке поставок. 21 октября 2026 года скомпрометированные артефакты были опубликованы в PyPI, а вредоносные варианты появились также в Docker-образах. На PyPI затронуты все семь wheel-пакетов версии 1.107.0, распространявшихся в период примерно с 11:39 до 13:23 UTC. В Docker Hub были затронуты теги v1.107.0, latest, main-latest и main-stable. Наиболее опасной особенностью атаки стало то, что вредоносный код мог выполняться при запуске интерпретатора Python даже без явного импорта LiteLLM.

В пакетах присутствовали файлы cook.pth, cook.py и sitecustomize.py. Они использовали механизм автозагрузки Python, собирали доступные секреты и устанавливали загрузчик удаленного кода. В зоне риска могли оказаться ключи облачных провайдеров, токены LLM-сервисов, учетные данные баз данных, переменные CI/CD и доступы к контейнерным реестрам. Важный вывод инцидента заключается в том, что простая переустановка на безопасную версию не устраняет последствия: если секрет уже был прочитан, его необходимо отозвать и заменить. Команда LiteLLM рекомендовала использовать версию 1.106.2 или другую явно проверенную безопасную версию, пересобрать окружения и проверить фактически установленные wheel-файлы и дайджесты образов. Также следует анализировать кэш CI, журналы запуска Python, историю контейнеров и все системы, которым были доступны переменные окружения зараженного процесса.

Атаки усиления через HTTP/3 QPACK могут привести к исчерпанию памяти

Исследование FoxIO по HTTP/3 и QPACK показало, что ошибки учета размера распакованных заголовков могут позволить неаутентифицированному клиенту вызвать чрезмерное потребление памяти или падение сервера. QPACK сжимает HTTP-заголовки при передаче, однако серверу необходимо учитывать объем уже распакованной структуры, включая накладные расходы каждого поля. Если реализация ограничивает только размер сетевого фрейма или отдельно проверяет поля, но не контролирует суммарный объем результата, небольшой запрос может преобразоваться в гораздо более крупное выделение памяти.

FoxIO протестировала десять реализаций, и в рассматриваемых версиях семь демонстрировали уязвимое или приводящее к сбою поведение. Исправления уже были доступны для ряда проектов: Cloudflare quiche исправила проблему в версии 0.29.3, quic-go устраняла связанные ошибки в 0.57.0 и 0.59.1, а обновления также появились в lsquic и Wireshark. В исследовательском снимке Bun 1.4.3, hyperium h3 и aioquic/mitmproxy оставались уязвимыми, поэтому наличие более новой версии само по себе не доказывает исправление. Речь идет о нарушении доступности, а не о подтвержденной краже данных или удаленном выполнении кода. Владельцам сервисов следует определить фактические версии QUIC-библиотек в прокси, рантаймах и контейнерах, обновить их до исправленных сборок, а до этого отключить HTTP/3 либо установить строгие лимиты на распакованные заголовки.

Laravel исправил обход аутентификации в TokenGuard

В Laravel раскрыли две проблемы, одна из которых получила критическую оценку. Уязвимость GHSA-f9x3-7vq9-cph6 затрагивала встроенный TokenGuard при использовании определенной конфигурации MySQL или MariaDB. Специально сформированное значение токена, не являющееся строкой, могло пройти в обработку и повлиять на запрос к базе данных так, что приложение идентифицировало атакующего как другого пользователя. В результате злоумышленник мог получить доступ к защищенным API-маршрутам без корректного токена. Проблема относится именно к guard с драйвером token в config/auth.php; Sanctum и Passport используют другие механизмы и в данном бюллетене затронутыми не названы.

Исправление проверяет тип входного значения до выполнения поиска пользователя. Обновления Laravel 12.68.0 и 13.29.0 содержат исправление TokenGuard; эти версии были выпущены 25 августа 2026 года, хотя публичные сведения об уязвимости появились позже. Отдельно разработчики устранили ошибку JSON:API, при которой запрос на чтение с включением связанных сущностей в определенных условиях мог привести к удалению связанных данных. Для ветки Laravel 12 исправление появилось в 12.68.0, а для Laravel 13 достаточно версии 13.27.0 или новее. Командам следует проверить реальный composer.lock, конфигурацию guards и API-маршруты, обновить фреймворк, а затем протестировать операции JSON:API на копии базы данных. При использовании уязвимой конфигурации также стоит проверить журналы входа, но отсутствие подозрительных записей не заменяет обновление.

PHP2Shell: критические уязвимости PHP начали эксплуатировать до раскрытия

История PHP2Shell требует особенно быстрой реакции, поскольку попытки эксплуатации начались еще до публичного выпуска исправлений. AWS Threat Intelligence зафиксировала попытку атаки 17 октября 2026 года, тогда как скоординированное раскрытие и публикация патчей состоялись 21 октября. Позднее специалисты сообщили о множественных атакующих и широком распространении эксплуатационных попыток. Это не доказывает успешную компрометацию каждого сервера, но означает, что расследование нельзя начинать только с момента установки обновления.

Под общим названием PHP2Shell объединены две критические уязвимости: CVE-2026-109618, связанная с повреждением состояния и ошибками работы с памятью, и CVE-2026-109619, при которой после освобождения памяти могло сохраняться устаревшее состояние запроса. Обе получили оценку CVSS 4.0 9.2. Риск затрагивает веб-серверные варианты PHP, включая PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed; для mod_php разработчики указали особенно высокий уровень опасности. Исправленные версии: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Нужно обновить все доступные из интернета процессы, перезапустить PHP-FPM и Apache, а затем убедиться, что работает именно исправленный бинарник. WAF и ограничение отдельных настроек могут временно снизить риск, но не заменяют патч. Журналы, телеметрию, загруженные файлы и подозрительные процессы следует проверять начиная как минимум с 17 октября. Отдельно стоит учесть, что ветка PHP 8.2 завершает поддержку 31 декабря 2026 года.