27 июля в открытом доступе появился рабочий эксплойт для vBulletin, который позволяет запускать код на сервере форума без учётной записи, без прав администратора и без какого-либо взаимодействия с пользователем. Всё, что нужно атакующему — отправить один HTTP-запрос. Уязвимость получила номер CVE-2026-61511 и была раскрыта через SSD Secure Disclosure. Затрагивает версии 6.2.1 и более ранние, а также 6.1.6 и более ранние — нижняя граница версий в описании вообще не указана, что само по себе странно для настолько серьёзной дыры. CVSS-оценки нет ни на , ни в NVD: последняя, к слову, в начале этого года перестала регулярно присваивать баллы новым CVE, так что отсутствие цифры теперь не редкость. В список известных эксплуатируемых уязвимостей CISA KEV запись тоже не попала, и на момент публикации подтверждённых случаев атак в реальном мире не зафиксировано.
Патчи вышли задолго до эксплойта. В конце июня vBulletin выпустил обновления для веток 6.2.1, 6.2.0 и 6.1.6, а 1 июля появилась полностью исправленная версия 6.2.2. Получается, между закрытием бага и публичным раскрытием прошло почти четыре недели. Облачные инсталляции, по заявлению разработчиков, уже защищены автоматически. А вот владельцам форумов на собственном хостинге придётся вручную накатить патч на свою ветку или обновиться до 6.2.2 — никто это за них не сделает. Остаётся неясным один момент: эксплуатировалась ли уязвимость в те четыре недели между выходом патча и публикацией PoC. Ни SSD, ни сама компания vBulletin на этот вопрос не отвечают.
Корень проблемы — файл includes/vb5/template/runtime.php и метод vB5_Template_Runtime::runMaths(). Он отвечает за обработку встроенной математики в шаблонах форума. Логика вроде бы простая: функция вырезает все символы, не входящие в разрешённый набор, а оставшееся передаёт прямо в eval(). Фильтр действительно блокирует буквы. Но пропускает цифры, круглые скобки, операторы конкатенации, арифметику и побитовые операции вроде XOR. И этого набора символов, как выяснилось, вполне достаточно, чтобы собрать любую PHP-строку и вызвать любую функцию — без единой буквы в исходном запросе. В своём advisory SSD называет эту технику «phpfuck», и название довольно точно описывает суть происходящего.
Цепочка атаки выстраивается через публичный маршрут ajax/render/pagenav, который vBulletin использует для рендеринга шаблонов постраничной навигации. Стандартный шаблон pagenav копирует значение pagenav[pagenumber], присланное посетителем сайта, прямо в тег {vb:math}. Это значение улетает в runMaths() без какой-либо авторизации. В PoC от SSD этот механизм используется для восстановления PHP-функции system и выполнения команд операционной системы — вывод команды прилетает прямиком в ответ HTTP-сервера.
С самим PoC вышла казус: в опубликованном интерактивном скрипте есть опечатка — буква стоит там, где должна быть цифра. Из-за этого эксплойт не запускается «из коробки». На саму уязвимость это, впрочем, не влияет — исправить строку можно за секунду. Издание The Hacker News независимо воспроизвело логику фильтрации и вычисления локально. С исправленной опечаткой безобидный тестовый payload с strlen() выполнился без проблем. Без исправления белый список отфильтровывал случайную букву, и получившийся код был просто невалидным PHP. Это подтвердило именно механизм построения выражений — но не полноценную атаку на реально работающий сервер.
Что касается авторства, SSD указывает неназванного независимого исследователя как первооткрывателя. А вот подпись самого эксплойта — «EgiX», и это давно известный псевдоним Эджидио Романо (Egidio Romano). Романо уже отметился в истории vBulletin: именно он раскрывал цепочку уязвимостей в шаблонном движке форума в 2025 году.
В баннере эксплойта проблему называют «zero-day», хотя факты говорят об обратном. Патчи и релиз 6.2.2 появились почти за четыре недели до того, как эксплойт стал публичным. Так что новым здесь можно назвать разве что сам код атаки — уязвимость на момент публикации уже была закрыта производителем.
Основная группа риска — форумы на самостоятельном хостинге, доступные из интернета и до сих пор не обновлённые. Облачные версии, по данным vBulletin, уже прикрыты. При этом исправление для самохостящихся инсталляций доступно почти месяц на момент выхода эксплойта — времени было достаточно.
Для защитников сетей полезно следить за POST-запросами, содержащими routestring=ajax/render/pagenav в сочетании с необычно длинными или перегруженными операторами значениями pagenav[pagenumber]. Стоит оговориться: этот паттерн детекции выведен из анализа публичного PoC, а не из официальных рекомендаций разработчика.
Похожая история с vBulletin уже случалась в мае 2025 года. Тогда речь шла о CVE-2025-48827 и CVE-2025-48828 — тоже связанных с шаблонным движком, но через другой механизм. Производитель тихо закрыл проблему за несколько месяцев до публичного раскрытия. Попытки эксплуатации начались буквально в течение нескольких дней после того, как информация стала публичной. И многие форумы так и не установили исправление вовсе.
Складывается устойчивая закономерность в истории безопасности vBulletin: сначала выходит тихий патч, спустя недели или месяцы всплывает работающий эксплойт, и к моменту его публикации значительная часть форумов, доступных из интернета, всё ещё сидит на старых, уязвимых сборках.
Изображение носит иллюстративный характер
Патчи вышли задолго до эксплойта. В конце июня vBulletin выпустил обновления для веток 6.2.1, 6.2.0 и 6.1.6, а 1 июля появилась полностью исправленная версия 6.2.2. Получается, между закрытием бага и публичным раскрытием прошло почти четыре недели. Облачные инсталляции, по заявлению разработчиков, уже защищены автоматически. А вот владельцам форумов на собственном хостинге придётся вручную накатить патч на свою ветку или обновиться до 6.2.2 — никто это за них не сделает. Остаётся неясным один момент: эксплуатировалась ли уязвимость в те четыре недели между выходом патча и публикацией PoC. Ни SSD, ни сама компания vBulletin на этот вопрос не отвечают.
Корень проблемы — файл includes/vb5/template/runtime.php и метод vB5_Template_Runtime::runMaths(). Он отвечает за обработку встроенной математики в шаблонах форума. Логика вроде бы простая: функция вырезает все символы, не входящие в разрешённый набор, а оставшееся передаёт прямо в eval(). Фильтр действительно блокирует буквы. Но пропускает цифры, круглые скобки, операторы конкатенации, арифметику и побитовые операции вроде XOR. И этого набора символов, как выяснилось, вполне достаточно, чтобы собрать любую PHP-строку и вызвать любую функцию — без единой буквы в исходном запросе. В своём advisory SSD называет эту технику «phpfuck», и название довольно точно описывает суть происходящего.
Цепочка атаки выстраивается через публичный маршрут ajax/render/pagenav, который vBulletin использует для рендеринга шаблонов постраничной навигации. Стандартный шаблон pagenav копирует значение pagenav[pagenumber], присланное посетителем сайта, прямо в тег {vb:math}. Это значение улетает в runMaths() без какой-либо авторизации. В PoC от SSD этот механизм используется для восстановления PHP-функции system и выполнения команд операционной системы — вывод команды прилетает прямиком в ответ HTTP-сервера.
С самим PoC вышла казус: в опубликованном интерактивном скрипте есть опечатка — буква стоит там, где должна быть цифра. Из-за этого эксплойт не запускается «из коробки». На саму уязвимость это, впрочем, не влияет — исправить строку можно за секунду. Издание The Hacker News независимо воспроизвело логику фильтрации и вычисления локально. С исправленной опечаткой безобидный тестовый payload с strlen() выполнился без проблем. Без исправления белый список отфильтровывал случайную букву, и получившийся код был просто невалидным PHP. Это подтвердило именно механизм построения выражений — но не полноценную атаку на реально работающий сервер.
Что касается авторства, SSD указывает неназванного независимого исследователя как первооткрывателя. А вот подпись самого эксплойта — «EgiX», и это давно известный псевдоним Эджидио Романо (Egidio Romano). Романо уже отметился в истории vBulletin: именно он раскрывал цепочку уязвимостей в шаблонном движке форума в 2025 году.
В баннере эксплойта проблему называют «zero-day», хотя факты говорят об обратном. Патчи и релиз 6.2.2 появились почти за четыре недели до того, как эксплойт стал публичным. Так что новым здесь можно назвать разве что сам код атаки — уязвимость на момент публикации уже была закрыта производителем.
Основная группа риска — форумы на самостоятельном хостинге, доступные из интернета и до сих пор не обновлённые. Облачные версии, по данным vBulletin, уже прикрыты. При этом исправление для самохостящихся инсталляций доступно почти месяц на момент выхода эксплойта — времени было достаточно.
Для защитников сетей полезно следить за POST-запросами, содержащими routestring=ajax/render/pagenav в сочетании с необычно длинными или перегруженными операторами значениями pagenav[pagenumber]. Стоит оговориться: этот паттерн детекции выведен из анализа публичного PoC, а не из официальных рекомендаций разработчика.
Похожая история с vBulletin уже случалась в мае 2025 года. Тогда речь шла о CVE-2025-48827 и CVE-2025-48828 — тоже связанных с шаблонным движком, но через другой механизм. Производитель тихо закрыл проблему за несколько месяцев до публичного раскрытия. Попытки эксплуатации начались буквально в течение нескольких дней после того, как информация стала публичной. И многие форумы так и не установили исправление вовсе.
Складывается устойчивая закономерность в истории безопасности vBulletin: сначала выходит тихий патч, спустя недели или месяцы всплывает работающий эксплойт, и к моменту его публикации значительная часть форумов, доступных из интернета, всё ещё сидит на старых, уязвимых сборках.