Drupal 11.3.16 вышел 23 июля 2026 года как исправляющий релиз для ветки 11.3.x. Обновление переводит HTTP-библиотеки Guzzle на безопасные версии и устраняет ошибки Composer Audit, из-за которых установка drupal/core-recommended и автоматические проверки зависимостей могли завершаться предупреждением или блокировкой.
Drupal 11.3.16 исправляет цепочку зависимостей core-recommended
Команда Drupal опубликовала версию 11.3.16 23 июля 2026 года. Официальная страница относит её к исправляющим релизам, разрешённым для рабочих сайтов. Состав обновления получился компактным: разработчики обновили несколько пакетов Guzzle и поправили тест, связанный с Composer 2.10.
Причина выпуска связана с метапакетом drupal/core-recommended. Он фиксирует проверенные версии библиотек Drupal, чтобы разные серверы и среды разработки получали одинаковый набор зависимостей. Такая схема делает сборку предсказуемой, но создаёт понятную загвоздку: после публикации предупреждения безопасности зафиксированная версия остаётся в проекте, пока Drupal не обновит ограничение в своём метапакете.
В Drupal 11.3.14 использовались версии Guzzle, которые новые базы уязвимостей начали считать затронутыми. В результате composer audit, Dependabot и корпоративные сканеры могли обнаружить проблему даже на только что обновлённом сайте. В задаче Drupal Core №3612247 разработчики присвоили исправлению критический приоритет: участники обсуждения сообщали, что автоматические проверки уже блокировали сборки.
Итоговый коммит обновил:
guzzlehttp/guzzleс 7.12.1 до 7.15.1;guzzlehttp/promisesс 2.5.0 до 2.5.1;guzzlehttp/psr7с 2.12.1 до 2.13.0.
На странице задачи в заголовке сохранилось упоминание guzzlehttp/psr7 2.12.3. Фактический коммит в ветке Drupal 11.3.x и опубликованное временное решение указывают версию 2.13.0.
Guzzle 7.15.1 закрывает три сценария утечки данных и отказа в обслуживании
Guzzle — популярный HTTP-клиент для PHP. Drupal и сторонние модули используют его, когда серверу нужно обратиться к внешнему API, загрузить удалённый ресурс, пройти перенаправление или работать с HTTP-cookie. Уязвимость такой библиотеки попадает в цепочку зависимостей сайта, даже когда администратор никогда не устанавливал Guzzle вручную.
В июле 2026 года для версий Guzzle ниже 7.15.1 опубликовали три предупреждения средней серьёзности. Риск зависит от того, какие функции HTTP-клиента использует конкретный проект.
Фрагмент адреса мог попасть в заголовок Referer
Предупреждение GHSA-h95v-h523-3mw8 описывает утечку части URL после символа #. Браузеры и HTTP-клиенты обычно обрабатывают такой фрагмент локально и не передают его серверу как часть запроса.
В уязвимых версиях Guzzle middleware перенаправлений мог добавить фрагмент в автоматически сформированный заголовок Referer. Для эксплуатации требовалось включить параметр allow_redirects.referer, обратиться к адресу с секретом во фрагменте и перейти по перенаправлению на менее доверенный сервер с той же схемой, например с HTTPS на HTTPS.
Такой сценарий мог раскрыть одноразовый токен, значение состояния авторизации или другой секрет из URL. Настройка генерации Referer по умолчанию отключена. Guzzle 7.15.1 удаляет фрагмент перед формированием заголовка.
Cookie для одного хоста мог отправиться его поддомену
В GHSA-wm3w-8rrp-j577 разобрана ошибка встроенного CookieJar. Cookie без атрибута Domain должен возвращаться только тому хосту, который его установил. Старые версии Guzzle сохраняли имя хоста в поле домена и затем применяли обычное сопоставление доменов.
Из-за этого cookie, полученный от example.com, при определённых условиях мог уйти на child.example.com. Опасность появлялась, когда приложение использовало общий контейнер cookie для родительского домена и менее доверенных поддоменов. В таком cookie могли храниться идентификатор сессии или токен доступа.
Guzzle 7.15.1 сохраняет отдельный признак HostOnly и проверяет точное совпадение хоста. Старые данные FileCookieJar и SessionCookieJar без этого признака могут потребовать очистки или повторного создания после обновления.
Неограниченное число cookie позволяло расходовать память
Предупреждение GHSA-f283-ghqc-fg79 связано с обработкой большого числа заголовков Set-Cookie. Уязвимая версия принимала их без ограничения количества и размера, сохраняла в памяти, а затем собирала все совпадения в один исходящий заголовок Cookie.
Злоумышленник или скомпрометированный сервер мог вернуть множество крупных cookie. Повторное использование контейнера увеличивало расход памяти и время обработки, а сформированный HTTP-заголовок мог превысить лимиты прокси или конечного сервера.
В Guzzle 7.15.1 появились конкретные границы: значение одного Set-Cookie ограничено 8190 байтами, один ответ может добавить или заменить до 50 cookie, а исходящий запрос получает до 150 пар name=value при общей длине строки до 8190 байт.
Composer Audit мог останавливать установку и автоматическую доставку сайта
composer audit сверяет установленные PHP-пакеты с базами предупреждений безопасности. Команду часто запускают в CI/CD перед развёртыванием, а хостинги и системы контроля зависимостей выполняют аналогичную проверку автоматически.
После публикации предупреждений о Guzzle проект на Drupal 11.3.14 мог получить уязвимую зависимость через drupal/core-recommended. Код самого сайта при этом мог не использовать опасные сценарии с перенаправлениями или cookie. Для сканера достаточно присутствия затронутой версии в composer.lock.
Такой результат создавал несколько практических проблем:
- новая установка Drupal 11.3.x могла завершиться сообщением об известных уязвимостях;
- сборочный конвейер мог отклонить обновлённый
composer.lock; - корпоративная политика безопасности могла запретить выкладку;
- Dependabot и другие сервисы продолжали показывать открытые предупреждения;
- командам приходилось временно задавать Composer-алиасы для безопасных версий Guzzle.
Drupal 11.3.16 переносит исправленные версии прямо в core-recommended. После обновления временные алиасы из composer.json больше не нужны.
Исправление тестов Composer 2.10 отделяет аудит от проверки рецептов Drupal
В релиз вошла ещё одна правка — адаптация теста распаковки Drupal Recipes к Composer 2.10. После обновления тестового окружения команды Composer начали выполнять аудит зависимостей и завершать тест с ошибкой из-за сторонних предупреждений безопасности.
Разработчики добавили переменную окружения COMPOSER_NO_AUDIT=1 только в функциональный тест распаковки рецептов. Такой тест проверяет установку и структуру рецепта, поэтому сторонний advisory не должен менять результат этой конкретной проверки.
Для рабочих проектов аудит остаётся полезным. Команда composer audit по-прежнему показывает известные проблемы во всём дереве PHP-зависимостей. Изменение в Drupal Core касается тестового окружения проекта и не отключает проверку безопасности на сайтах.
Состав релиза ограничен зависимостями и внутренним тестом
Официальный список изменений между Drupal 11.3.14 и 11.3.16 содержит обновление Guzzle, правку теста Composer 2.10 и служебные коммиты слияния веток. В release notes отсутствуют изменения административного интерфейса, схемы базы данных, публичного API, структуры контента и системы конфигурации.
Такой объём снижает вероятность проблем совместимости с темами и модулями. Проверка на тестовой среде всё равно нужна: Composer обновляет связанные библиотеки, а собственный код проекта или дополнительный модуль может напрямую работать с Guzzle и его контейнерами cookie.
Особого внимания требуют приложения, которые сохраняют FileCookieJar или SessionCookieJar. Guzzle 7.15.1 проверяет новый флаг HostOnly, поэтому ранее записанные cookie без этого поля могут вызвать RuntimeException. Для типового Drupal-сайта этот сценарий встречается редко, но интеграции с внешними сервисами могут хранить cookie между запросами.
Drupal 11.3.16 устанавливается стандартной командой Composer
Официальная документация Drupal предлагает сначала сделать резервную копию и проверить обновление на локальной или тестовой среде. Для проекта на drupal/core-recommended базовый порядок выглядит так:
composer outdated "drupal/*"
composer audit
composer update "drupal/core-*" --with-all-dependencies
drush updatedb
drush cache:rebuild
composer auditПервая проверка показывает доступные обновления Drupal, вторая фиксирует исходное состояние зависимостей. После обновления повторный аудит должен перестать сообщать об устранённых предупреждениях Guzzle.
Текущие версии пакетов можно проверить отдельно:
composer show drupal/core-recommended
composer show guzzlehttp/guzzle
composer show guzzlehttp/promises
composer show guzzlehttp/psr7Для принудительной установки именно 11.3.16 официальная страница релиза приводит команду:
composer require drupal/core-recommended:11.3.16 drupal/core-composer-scaffold:11.3.16 drupal/core-project-message:11.3.16 --update-with-all-dependenciesФиксация точной версии добавляет ограничение в проект и может помешать автоматическому переходу на следующий патч-релиз. Для обычного обновления внутри разрешённой ветки удобнее команда composer update "drupal/core-*" --with-all-dependencies.
В среде с отдельным сервером разработки обновлённые composer.json и composer.lock сначала проходят тесты и попадают в репозиторий. На рабочем сервере Drupal рекомендует выполнять composer install --no-dev, чтобы развернуть уже проверенный набор версий без повторного пересчёта зависимостей.
Ветка Drupal 11.3.x получает поддержку до декабря 2026 года
Drupal 11.3.16 адресован проектам, которые продолжают работать на ветке 11.3.x. По данным команды Drupal, эта линия будет получать исправления безопасности до декабря 2026 года, когда ожидается Drupal 11.5.0.
Сайты теперь могут получать безопасные версии Guzzle через стандартный метапакет, что позволяет Composer Audit больше не блокировать установку из-за уже устранённых уязвимостей в зависимостях. Кроме того, командам разработчиков больше не нужно поддерживать временные алиасы в файле composer.json.
Обновление закрывает свежие предупреждения в HTTP-библиотеках и возвращает чистый результат проверки зависимостей без изменений редакционного интерфейса и структуры сайта.
