Next.js закрыл две критические RCE-уязвимости

Команда Next.js выпустила версии 16.4.1 и 15.5.28, устраняющие сразу две критические уязвимости, которые могли привести к удаленному выполнению кода без аутентификации. Первая проблема затрагивала приложения на App Router с Cache Components: опасный сценарий возникал, когда функция с директивой use cache возвращала несколько типизированных массивов. Разработчики отдельно подчеркивают, что надежного обходного решения для этой уязвимости нет. Обновиться рекомендуется даже тем проектам, в которых похожая конструкция явно не используется, поскольку реальный путь обработки данных может зависеть от библиотек и компонентов более высокого уровня.

Вторая критическая уязвимость, зарегистрированная как CVE-2026-96889, находилась в сторонней библиотеке, используемой Image Optimization API. При обработке SVG на Linux-системах с glibc ошибка управления памятью могла привести к выполнению произвольного кода. Временной мерой считается переход на sharp версии 0.35.5 или новее, однако установка исправленного выпуска Next.js надежнее, поскольку пакетный менеджер автоматически подтянет совместимую безопасную зависимость. Кроме того, обновление закрывает DoS-уязвимость высокой степени опасности: специально сформированные запросы к приложению с App Router и хотя бы одним Server Action могли вызвать чрезмерную загрузку процессора и заблокировать обработку последующих запросов в том же процессе. Pages Router и приложения без Server Actions этой проблемой не затронуты. Подробности и команды обновления опубликованы в официальном бюллетене Next.js.

Cloudflare открыла платформу Void для full-stack-приложений на Vite

Cloudflare и команда VoidZero представили три связанных проекта с открытым исходным кодом: Void Platform, Void SDK и Void CLI. Их задача — объединить разработку серверной части, типизированный доступ к данным, управление инфраструктурой и развертывание в одном рабочем процессе на базе Vite. Void SDK подключается как плагин и превращает Vite-проект в full-stack-приложение для Cloudflare Workers. Система анализирует необходимые привязки и при развертывании может автоматически подготовить базы данных, очереди и ресурсы для искусственного интеллекта. SDK также предлагает файловую маршрутизацию API, пререндеринг, кеширование, архитектуру островов и сквозную типизацию от запроса к базе данных до интерфейса.

Void не требует от команды полностью менять используемый фреймворк. Предусмотрены адаптеры для React и Vue, а отдельные возможности можно сочетать с React Router, SvelteKit, Nuxt, TanStack Start и Astro. Маршрутизацию и рендеринг разрешается оставить фреймворку, передав Void миграции, аутентификацию, ресурсные API и развертывание. Void Platform, построенная поверх Workers for Platforms, рассчитана на общую корпоративную среду: администраторы контролируют доступ, лимиты ресурсов, журналы, откаты и состояние проектов, не выдавая каждому сотруднику прямой доступ к облачному аккаунту. Void CLI завершает этот процесс одной командой: собирает приложение через Vite, применяет миграции, создает ресурсы и публикует проект. Такой подход особенно интересен командам, которые используют кодогенерацию и AI-агентов, но хотят сохранить централизованные ограничения безопасности. Архитектура и требования к самостоятельному размещению описаны в анонсе Cloudflare.

Astro 7.4 помогает находить медленные этапы сборки

Главное практическое нововведение Astro 7.4 — флаг astro build --timings, формирующий подробный отчет о затратах времени во время сборки. В статистику входят основные фазы Astro, плагины Vite, обработка Markdown, подсветка синтаксиса, рендеринг страниц, преобразование изображений и работа интеграций. Это позволяет не угадывать причину замедления, а увидеть конкретные страницы, файлы или плагины, которые занимают больше всего времени. Например, отчет может обнаружить последовательные сетевые запросы внутри компонентов, из-за которых каждая статическая страница ожидает несколько операций одну за другой. После этого разработчик может параллелизовать запросы или перенести получение данных на более подходящий уровень.

Для крупных статических сайтов появилась экспериментальная настройка parallelPrerender. Раньше Astro мог одновременно обрабатывать страницы, но сам рендеринг выполнялся в одном потоке и не использовал все ядра процессора. Теперь страницы можно распределять между worker-потоками Node.js, в том числе задавая число работников вручную. Функция хорошо сочетается с инкрементальными сборками, хотя она игнорируется адаптерами с собственным механизмом пререндеринга, включая официальный адаптер Cloudflare. В версии 7.4 также разрешено назначать разные сервисы обработки изображений для этапов build и runtime: локальный Sharp можно использовать при сборке, а CDN — для динамических страниц. Новый обработчик notFound() возвращает пользовательскую страницу 404 в составных entrypoint-сценариях, а экспериментальный redirectPage позволяет оформить и локализовать HTML-страницы статических перенаправлений. Полный список изменений и инструкция по обновлению доступны в описании релиза Astro 7.4.

Heroku получила встроенную поддержку статических веб-приложений

Heroku выпустила официальный Front-End Web Cloud Native Buildpack, предназначенный для приложений из HTML, CSS и JavaScript. Раньше разработчики статических сайтов часто использовали сторонние buildpack-решения, самостоятельно настраивали Nginx или маскировали фронтенд под Node.js-приложение. Новый CNB делает статический веб-сервер частью поддерживаемой платформы Heroku: достаточно разместить точку входа, например public/index.html, и описать параметры в project.toml. При необходимости JavaScript-проект может быть предварительно собран с помощью Node.js Cloud Native Buildpack, что позволяет разворачивать результаты работы Vite, Create React App и статических генераторов.

Buildpack учитывает типичные требования современных одностраничных и контентных сайтов. Он поддерживает fallback для клиентского роутинга, URL без расширения .html, собственные страницы ошибок, перенаправления, health-check-ответы и HTTP Basic Authentication для закрытия проекта до публичного запуска. Через конфигурацию можно задавать заголовки безопасности и правила кеширования. Также предусмотрена передача runtime-настроек через переменные окружения без обязательной повторной сборки интерфейса. Поскольку решение основано на стандарте Cloud Native Buildpacks, результатом становится OCI-совместимый образ с данными SBOM и возможностью обновлять базовый системный слой через CNB rebase. Приложения при этом сохраняют привычный для Heroku процесс развертывания из Git или GitHub и могут использовать Pipelines и Review Apps. Пример минимальной конфигурации и рекомендации по миграции со сторонних buildpack-пакетов приведены в официальной публикации Heroku.

WordPress 7.2 готовит изменения для блоков, безопасности и Playground

Финальный релиз WordPress 7.2 запланирован на 8 декабря 2026 года, однако разработчикам плагинов и тем рекомендуется начинать проверку совместимости уже на этапе бета-версий. Одно из наиболее значимых изменений — переработка wp_kses(), основного механизма очистки HTML. Новый санитайзер строится поверх WordPress HTML API, нормализует итоговую разметку, удаляет содержимое элементов script и style, а также строже обрабатывает поврежденные SVG, MathML и комментарии. Это может повлиять на расширения, которые сохраняют очищенный HTML, сравнивают его с исходной строкой или проверяют точное содержимое в автоматических тестах. Для временного возврата старого поведения предусмотрен фильтр wp_kses_force_legacy_parser, но команда рассматривает его только как переходную меру.

В блоковом редакторе публичными стали функции для управления стилями на разных размерах экрана. Пользовательские блоки смогут предлагать отдельные параметры для мобильного, планшетного и другого viewport-состояния, как это уже делают блоки ядра. Gutenberg 24.1 также распространил существующие Block Supports почти на все основные блоки: разработчики тем смогут переносить настройки фонов, границ, теней, цветов и выравнивания из собственного CSS в theme.json. Одновременно меняется процесс публикации плагинов в каталоге WordPress.org: во время задержки перед релизом новые версии будут автоматически анализироваться несколькими AI-моделями и Jetpack Scan, а обновления с высоким уровнем риска смогут блокироваться до проверки автором.

Для тестирования WordPress Playground получает встроенный терминал с поддержкой PHP и неинтерактивных команд WP-CLI, а также виртуальный почтовый ящик, отображающий письма, отправленные через wp_mail(). Это упрощает проверку миграций, CLI-команд и почтовых уведомлений без настройки локального SMTP-сервера. Разработчикам также следует учесть будущую отмену нескольких компонентов пакета @wordpress/components, изменения SQL-режима NO_BACKSLASH_ESCAPES и новые адаптивные параметры Gallery. При этом дорожная карта остается предварительной: часть функций, включая обновление до React 19, может не попасть в финальную сборку. Детальный обзор изменений опубликован в блоге разработчиков WordPress.

Node.js 26.12.0: встроенные операции маскирования WebSocket-фреймов

Node.js 26.12.0, опубликованный 14 октября 2026 года в текущей ветке, добавил функции websocketMask() и websocketUnmask() в HTTP API. Они выполняют низкоуровневое маскирование и обратное преобразование полезной нагрузки WebSocket-фреймов. По протоколу клиентские кадры маскируются перед отправкой серверу, поэтому такие операции необходимы библиотекам, прокси-серверам и другим компонентам, самостоятельно работающим с форматом кадров. Появление встроенных функций позволяет перенести эту работу ближе к среде выполнения и сократить потребность в собственных JavaScript-реализациях. Для большинства прикладных проектов, использующих готовые WebSocket-библиотеки, новый API останется внутренней деталью, однако авторы сетевых библиотек смогут применить его для упрощения кода и потенциального снижения накладных расходов.

Релиз также добавляет поддержку Python 3.15 в процессе сборки Node.js и обновляет встроенную SQLite до версии 3.54.0. В файловом API исправлены синхронизация асинхронной записи через FileHandle и блокировка дескриптора при первом чтении. Значительная часть изменений относится к потокам: разработчики уменьшили накладные расходы при обработке фрагментов данных, скорректировали обработку закрытия и ошибок, а также добавили методы dump() и dumpSync(). Есть исправления загрузки ES-модулей, модели разрешений, QUIC, диагностических каналов и тестового раннера. Поскольку ветка 26 обозначена как Current, перед переносом производственных систем следует проверить совместимость зависимостей и нативных модулей, а не рассматривать выпуск как автоматическую замену используемой LTS-версии.

GitHub Actions: воспроизводимые workflow с lock-файлами

GitHub 14 октября 2026 года запустил публичное тестирование lock-файлов зависимостей GitHub Actions. Проблема, которую решает механизм, связана с изменяемыми ссылками: workflow может подключать Action по тегу или ветке, но их владелец способен позднее переместить эту ссылку на другой коммит. В результате повторный запуск проверенного workflow теоретически выполнит уже другой код, хотя в самом репозитории пользователя ничего не изменилось. Lock-файл сохраняет точные идентификаторы коммитов и заставляет GitHub Actions использовать зафиксированные версии, одновременно позволяя оставить в YAML удобные и понятные ссылки на теги или ветки.

Для подключения функции предлагается расширение GitHub CLI gh actions-lock. Оно формирует файл .github/workflows/actions.lock, куда попадают прямые и транзитивные зависимости Actions, а также зависимости переиспользуемых workflow. Внедрять блокировку можно постепенно, подключая отдельные процессы автоматизации. Для уже подключенного workflow каждая зависимость должна присутствовать в lock-файле; предусмотрена и проверка его актуальности без изменения файлов, которую можно включить в CI. Администраторы репозиториев, организаций и предприятий могут тестировать политику обязательного использования lock-файлов. Dependabot при обновлении Action способен одновременно обновить соответствующую запись, сохраняя YAML и точный коммит согласованными. При этом lock-файл не доказывает безопасность зависимости: он защищает от незаметной смены уже выбранного кода, но первоначальную версию по-прежнему необходимо проверять.

Gutenberg 24.2: React 19 по умолчанию и развитие редактора

В Gutenberg 24.2 эксперимент с React 19 включен по умолчанию. Скрипты react и react-dom теперь загружают новую основную версию библиотеки, если на сайте не активна тема или плагин, известные проблемами совместимости. Для таких конфигураций предусмотрено сохранение React 18. Авторам расширений WordPress рекомендуется протестировать собственные компоненты, хуки, порталы и взаимодействие со сторонними библиотеками. Если после обновления редактор работает некорректно, React 19 можно временно отключить в разделе экспериментов Gutenberg. Для совместимой установки атрибута inert разработчикам также предложен пакет @wordpress/react-inert-value.

Изменения затронули не только технологическую основу редактора. Заметки переместились в отдельное поле рядом с холстом и могут оставаться видимыми одновременно с панелью настроек. На узком экране обсуждения сворачиваются до аватаров, а выбранный режим отображения запоминается. Удаление заметки теперь допускает отмену, незавершенный ответ сохраняется при переключении блока, а колонка комментариев прокручивается вместе с контентом. Поиск в блоке навигации объединяет страницы, записи, категории и метки, галереи получили сортировку и общий двухцветный фильтр, а инструменты размеров, теней и фонов стали доступны большему числу блоков. В Interactivity API появилась директива data-wp-html, принимающая только явно помеченный доверенный HTML через asDangerousHTML(). Состояния state.navigating и state.initiator позволяют компонентам отслеживать клиентскую навигацию и определять запустивший ее блок.

GitLab устранил критическую RCE-уязвимость с CVSS 10.0

GitLab сообщил о выпуске критических исправлений 19.4.2, 19.3.5 и 19.2.8 для Community Edition и Enterprise Edition. Главная закрытая уязвимость зарегистрирована как CVE-2026-97229 и получила максимальную оценку CVSS 10.0. Из-за недостаточной проверки регулярных выражений специально подготовленное выражение в конфигурации CI/CD при определенных условиях могло привести к выполнению произвольного кода на сервере GitLab. Для эксплуатации не требовались учетная запись и действия со стороны пользователя, а атака могла проводиться удаленно по сети, что объясняет критический уровень риска.

Проблеме подвержены выпуски GitLab CE и EE начиная с 19.2 до 19.2.8, ветка 19.3 до 19.3.5 и ветка 19.4 до 19.4.2. Владельцам self-managed-инсталляций необходимо как можно скорее перейти на исправленный патч своей ветки и убедиться, что обновлены все узлы распределенной установки. GitLab.com уже работал на защищенной версии на момент публикации, а клиентам GitLab Dedicated дополнительных действий не требовалось. Пакет закрывает и другие уязвимости: межсайтовый скриптинг в подсветке синтаксиса, ошибки авторизации в нисходящих и плановых конвейерах, проблемы доступа к файлам репозитория, утечки данных и ряд недостатков GraphQL API. После обновления разумно проверить журналы, историю изменений CI/CD-конфигураций и необычные процессы на сервере, особенно если экземпляр был доступен из интернета.

Inertia.js 3.9.1: XSRF-токены и уникальные векторы шифрования

Патч Inertia.js 3.9.1 содержит всего два заявленных изменения, но оба относятся к защите данных. Первое ограничивает отправку заголовка с XSRF-токеном запросами к тому же origin. Ранее служебный заголовок мог добавляться и при обращении к внешнему адресу, если такой запрос инициировался через клиентский механизм Inertia. Ограничение по origin снижает риск раскрытия токена стороннему серверу при некорректно сформированном URL, ошибке интеграции или перенаправлении логики запросов на другой домен. Это не отменяет серверную проверку CSRF и корректную настройку cookie, но делает поведение клиента более строгим и соответствующим принципу минимальной передачи секретов.

Второе изменение касается зашифрованной истории браузера. Каждая запись теперь получает уникальный вектор инициализации, или IV. Повторное использование одного IV вместе с тем же ключом способно раскрывать закономерности между зашифрованными значениями и ослаблять гарантии выбранного режима шифрования, даже если сам ключ остается неизвестным атакующему. Уникальный IV не обязан быть секретным, но он должен корректно генерироваться и не повторяться в пределах одного ключа. Обновление особенно важно для приложений, использующих шифрование истории Inertia для защиты состояния страниц. Командам следует установить 3.9.1, заново собрать клиентские ресурсы и проверить переходы назад и вперед, восстановление состояния после перезагрузки, внешние ссылки и запросы к API на отдельных доменах.

Вывод

Общий мотив этих выпусков — усиление базовой инфраструктуры разработки. Node.js предоставляет более эффективные примитивы для сетевых библиотек, GitHub делает цепочку зависимостей CI/CD воспроизводимой, а Gutenberg завершает важный этап перехода на React 19 и одновременно улучшает совместную работу с контентом. Наиболее срочное действие требуется администраторам self-managed GitLab: уязвимость с удаленным выполнением кода и оценкой CVSS 10.0 не оставляет оснований откладывать установку патча. Пользователям Inertia.js также стоит применить небольшое обновление без ожидания крупного релиза, поскольку оно исправляет правила обращения с XSRF-токенами и криптографическими параметрами. Lock-файлы GitHub Actions пока находятся в публичном тестировании, но уже заслуживают пилотного внедрения в проектах с чувствительными секретами и производственными развертываниями.