Ruby выпустил исправления ошибок, связанных с критическими уязвимостями GitLab

23 октября 2026 года проект Ruby выпустил версии 4.0.9, 3.4.12 и 3.3.13 с исправлениями ошибок обработки регулярных выражений. Эти ошибки лежат в основе нескольких критических уязвимостей GitLab. Если компания держит собственный GitLab на VPS или сервере либо использует Ruby-приложение с пользовательскими шаблонами поиска, стоит проверить обновления именно работающего приложения и его среды исполнения.

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

Идентификаторы относятся к уязвимостям GitLab. На момент уведомления проект Ruby не запросил для этих исправлений собственные CVE и продолжает обсуждать подход к обработке недоверенных шаблонов. Поэтому наличие Ruby на сервере само по себе не означает, что любое размещённое там приложение уязвимо.

GitLab поставляет собственную среду Ruby. Замена системного интерпретатора без проверки состава пакета не подтверждает устранение уязвимости GitLab. Для прикладного Ruby-сервиса, напротив, нужно проверить ту среду исполнения, которую действительно используют его запущенные процессы. Поставщик пакетов может перенести исправление в свою сборку с другим номером; подтверждение ищут в его уведомлениях.

• Установить, есть ли собственный GitLab или Ruby-приложение, принимающее регулярные выражения из недоверенного ввода. Отдельно проверить сервер приложения и используемый контейнерный образ.
• Назвать установленный пакет, источник исправления и работающую среду исполнения. Версия команды в личной консоли администратора может отличаться от среды сервиса.
• Перед обновлением подготовить восстановление и проверить требования производителя. GitLab предупреждает о миграциях базы: для одиночной установки они требуют простоя.
• После обновления проверить используемые сценарии: доступ к репозиториям, запуск сборки и обмен с внешними системами. Если есть признаки проникновения, сохранить журналы и провести расследование отдельно.

Сообщение об уязвимости не доказывает успешный взлом конкретной установки. Для новых развёртываний также проверьте базовые образы и закреплённые зависимости: исправленный сервер не предотвращает повторное развёртывание старой среды из сохранённого образа.

Сведения актуальны на 24 октября 2026 года, 03:00 МСК. Даты событий: обновление GitLab — 21 октября; уведомление и выпуски Ruby — 23 октября. Источники — официальные сообщения проектов; состояние конкретного сервера устанавливают отдельно.

On October 23, 2026, the Ruby project released versions 4.0.9, 3.4.12, and 3.3.13 with fixes for regular expression handling bugs. These bugs underlie several critical GitLab vulnerabilities. If your organization hosts its own GitLab on a VPS or server, or uses a Ruby application with custom search templates, you should verify updates for the running application and its runtime environment.

A significant risk boundary exists when compiling a regular expression from a string controlled by an attacker. If an application uses only expressions written by its developers, Ruby explicitly excludes it from this scenario. Limiting expression execution time and template length do not provide reliable protection against these bugs.

The identifiers refer to GitLab vulnerabilities. At the time of notification, the Ruby project did not request its own CVEs for these fixes and continues to discuss approaches for handling untrusted templates. Therefore, the mere presence of Ruby on a server does not mean that any application hosted there is vulnerable.

GitLab provides its own Ruby environment. Replacing the system interpreter without verifying the package contents does not confirm that the GitLab vulnerability is fixed. Conversely, for an application Ruby service, you must verify the execution environment actually used by its running processes. The package provider may backport a fix to a build with a different version number; confirmation must be sought in their notifications.

• Determine whether a self-hosted GitLab or a Ruby application accepting regular expressions from untrusted input is in use. Independently verify the application server and the container image being used.
• Identify the installed package, the source of the fix, and the active execution environment. The version shown in the administrator's personal console may differ from the service environment.
• Before updating, prepare a recovery plan and verify the vendor's requirements. GitLab warns about database migrations: for a single installation, these require downtime.
• After updating, verify the used scenarios: repository access, build execution, and exchange with external systems. If signs of intrusion are detected, preserve the logs and conduct a separate investigation.

A vulnerability report does not prove a successful breach of a specific installation. For new deployments, also verify base images and pinned dependencies: a patched server does not prevent re-deploying an old environment from a saved image.

Information is current as of October 24, 2026, 03:00 MSK. Event dates: GitLab update — October 21; Ruby notifications and releases — October 23. Sources are official project announcements; the state of a specific server must be verified separately.