Ruby 4.0.5 — небольшой релиз, но откладывать его не стоит: он закрывает CVE-2026-46727, ошибку use-after-free в обработчике тайм-аута getaddrinfo на базе pthread. Также релиз исправляет регрессию системы сборки, появившуюся в Ruby 4.0.4 при C locale.
Это не релиз с новыми возможностями — и в этом смысл. Для команд на Ruby 4.0 обновление выглядит как точечное обслуживание: security fix плюс ремонт регрессии, без большого события по совместимости.
Что изменилось в Ruby 4.0.5#
В анонсе Ruby сказано, что Ruby 4.0.5 содержит только два изменения:
- исправление безопасности для CVE-2026-46727
- исправление регрессии системы сборки в Ruby 4.0.4 при C locale
Уязвимость описана как use-after-free в обработчике тайм-аута getaddrinfo на базе pthread. В уведомлении нет деталей об эксплуатируемости, затронутых сценариях развертывания или оценке серьезности. Это важно. Use-after-free — класс ошибок безопасности памяти, который может быть серьезным, но один только release note не дает оснований говорить об активной эксплуатации, RCE или широком влиянии на уровне приложений.
Более осторожная трактовка такая: если вы используете Ruby 4.0, это security update, и его стоит быстро провести через обычный процесс патчей. Если среда зависит от сборки из исходников, особенно при условиях сборки, чувствительных к locale, Ruby 4.0.5 также убирает регрессию из 4.0.4.
Почему исправление getaddrinfo важно#
Исправленная уязвимость находится в обработке тайм-аута для getaddrinfo, когда Ruby использует реализацию на базе pthread. Getaddrinfo участвует в разрешении имен и сервисов. На практике этот код задействуется, когда ПО разрешает hostnames или сетевые endpoints.
Одного этого достаточно, чтобы исправление было операционно значимым. Сетевые Ruby-приложения, фоновые workers, сервисные clients, automation-код и инструменты разработчиков могут запускать разрешение адресов в обычной работе. Анонс не говорит, что любой workload на Ruby подвержен одинаково. Он также не утверждает, что до ошибки можно добраться по сети в приложении по умолчанию. Но код разрешения адресов достаточно распространен, чтобы не считать проблему экзотическим углом, пока ваши runtime- и build-детали это не подтвердят.
Практичная позиция здесь простая: не ждать более драматичного разбора, прежде чем патчить runtime-level ошибку безопасности памяти. Уязвимости рантайма лежат ниже кода приложения. Они могут затронуть ПО, в логике которого нет очевидной ошибки.
Исправление регрессии 4.0.4 тоже важно на практике#
Ruby 4.0.5 также исправляет регрессию системы сборки в Ruby 4.0.4 при C locale. Анонс не раскрывает конкретный сценарий сбоя, поэтому не стоит придумывать лишние детали. Но сама область важна для команд, которые собирают Ruby в CI, containers, воспроизводимых build pipelines или минимальных server images.
Ошибочные предположения о locale часто ломают сборки. Многие production images и CI runners используют урезанные окружения. Если регрессия сборки проявляется только при C locale, она может ударить по автоматизированным средам раньше, чем по ноутбуку разработчика.
Поэтому Ruby 4.0.5 важен даже для команд, которые уже перешли на 4.0.4 и не увидели проблем на уровне приложения. Если где-то в вашей delivery chain Ruby собирается из исходников, этот релиз заслуживает тестовой сборки, а не пассивной заметки в changelog.
Чего не стоит утверждать#
Уведомление Ruby короткое. В нем есть CVE, класс ошибки, затронутая подсистема, область регрессии и release artifacts. В нем нет публичного статуса exploit. Там не сказано, что уязвимость эксплуатируется in the wild. Нет proof of concept. Нет оценки бизнес-эффекта по типам workloads.
Поэтому корректная формулировка — не «Ruby-приложения сейчас активно атакуют». Корректная формулировка такая: Ruby 4.0.5 содержит исправление безопасности для ошибки памяти в обработке тайм-аута разрешения адресов, и пользователям Ruby 4.0 стоит запланировать обновление.
Разница важна. Преувеличения здесь никому не помогают. Патчи рантайма и так требуют достаточно операционного внимания — без неподтвержденных заявлений.
Что проверить командам сейчас#
Командам на Ruby 4.0 стоит найти, где установлен Ruby и как он туда попадает. Сюда входят production hosts, containers, CI runners, локальные окружения разработчиков, build images и любое embedded Ruby внутри внутренних инструментов.
Для большинства команд короткий список действий такой:
- проверить, есть ли где-то Ruby 4.0.0–4.0.4
- поставить Ruby 4.0.5 в приоритет там, где Ruby 4.0 используется в production
- пересобрать base images, где закреплен Ruby 4.0.x
- протестировать сборку из исходников, если pipeline использует C locale или минимальные build-окружения
- сверить скачанные release artifacts с checksums, опубликованными Ruby
- следить за каналами package manager, если Ruby приходит через OS packages или language runtime managers
Проект Ruby опубликовал для Ruby 4.0.5 release artifacts в форматах tar.gz, tar.xz и zip, с checksums SHA1, SHA256 и SHA512. Командам, которые скачивают напрямую с cache.ruby-lang.org, стоит проверять используемый artifact, а не полагаться только на имя файла.
График релизов дает окно для планирования#
В анонсе Ruby также указан ожидаемый ритм stable releases для Ruby 4.0: каждые два месяца после последнего релиза. Согласно уведомлению, Ruby 4.0.6 запланирован на июль, Ruby 4.0.7 — на сентябрь, Ruby 4.0.8 — на ноябрь.
Это не жесткое обещание. Команда Ruby говорит, что релиз может выйти раньше, если изменение заметно влияет на пользователей, а более поздние точки графика могут из-за этого сдвинуться.
Для инженерных команд польза в планировании очевидна. Сопровождение Ruby 4.0 идет по предсказуемому треку, но security fixes и исправления с большим влиянием все равно могут прервать календарь. Считайте двухмесячный ритм базой для dependency hygiene, а не поводом откладывать security patch, который уже вышел.
Ruby 4.0.5 — узкое обновление. Поэтому его проще оценить и проще запланировать. Главный риск не в сложности. Главный риск — принять маленький релиз за необязательный только потому, что у него нет длинного changelog.