<div id="post_message_794784">

Один шаблон и всё летит в тартарары. Спасибо, PHP 8.1.<br/>
<br/>
<img alt="" border="0" class="bbCodeImage" src="https://dl3.joxi.net/drive/2025/06/01/0048/3474/3202450/50/14081ef4bf.jpg"/><br/>
<br/>
В популярных форумах на vBulletin вновь обнаружены дыры, через которые можно выполнить произвольный код прямо на сервере — без логина и пароля. Речь идёт сразу о двух критических уязвимостях, получивших идентификаторы <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-48827" target="_blank">CVE-2025-48827</a> и <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-48828" target="_blank">CVE-2025-48828</a> . <a href="https://karmainsecurity.com/dont-call-that-protected-method-vbulletin-rce" target="_blank">Первая из них уже используется</a> в реальных атаках, а вторая позволяет довести цепочку до полноценного захвата контроля над системой.<br/>
<br/>
Уязвимости были выявлены 23 мая 2025 года независимым исследователем Эджидио Романо (EgiX), который опубликовал подробный технический разбор с описанием механизмов эксплуатации. В центре всей конструкции — изменения в поведении PHP начиная с версии 8.1 и ошибки в логике работы шаблонизатора vBulletin. Вместе они дают неожиданный и опасный результат: удалённый, неаутентифицированный запуск произвольных команд на сервере.<br/>
<br/>
Первая проблема связана с неправильным использованием Reflection API. Этот механизм позволяет вызывать защищённые методы объектов, и раньше требовал явного обхода ограничений доступа. Однако в PHP 8.1 всё изменилось: определённые вызовы с помощью отражения больше не требуют принудительного открытия доступа. И если в коде это не было учтено — метод можно вызвать напрямую, без каких-либо обходных манипуляций.<br/>
<br/>
В vBulletin таких вызовов достаточно. Например, через уязвимый метод replaceAdTemplate можно внедрить специально подготовленный шаблон прямо из URL-запроса. CVE-2025-48828 же позволяет <a href="https://www.securitylab.ru/analytics/498356.php" target="_blank">обойти фильтрацию небезопасных функций</a> за счёт использования PHP-хаков, вроде вызовов переменных как функций (${'assert'} и т. д.). Таким образом, система принимает вредоносный код как допустимый.<br/>
<br/>
Комбинация этих двух ошибок превращается в мощный инструмент: достаточно одного запроса, чтобы внедрить произвольную команду и запустить её на сервере от имени веб-пользователя. В большинстве случаев это www-data на Linux, что открывает путь к скачиванию бэкдоров, запуску скриптов и углублению в систему.<br/>
<br/>
Через три дня после публикации Романо, 26 мая, другой исследователь — <a href="https://blog.kevintel.com/vbulletin-replaceadtemplate-kev/" target="_blank">Райан Дьюхерст</a> — зафиксировал реальные попытки эксплуатации. Он проанализировал логи своих honeypot-серверов и обнаружил подозрительные запросы к уязвимому endpoint'у /ajax/api/ad/replaceAdTemplate. Все признаки указывали на сканирование и попытки внедрения зловредного PHP.<br/>
<br/>
Одного из злоумышленников удалось отследить — атаки исходили с IP-адресов, зарегистрированных в Польше. В запросах явно прослеживалась попытка загрузить удалённую веб-оболочку, которая бы обеспечила постоянный доступ и возможность выполнять произвольные команды через интерфейс браузера.<br/>
<br/>
Хотя пока зафиксированы только атаки с применением первой уязвимости (CVE-2025-48827), логика опубликованной цепочки явно предполагает дальнейшую эксплуатацию второй. Все необходимые компоненты уже есть, включая публичный PoC и даже готовые шаблоны для системы автоматического сканирования Nuclei, которые появились уже 24 мая. По сути, сценарий нападения уже упакован и доступен.<br/>
<br/>
Особую тревогу вызывает то, что эти баги затрагивают не только последние релизы, но и весь диапазон от vBulletin 5.0.0 до 5.7.5 и от 6.0.0 до 6.0.3, при условии работы на PHP 8.1 и выше. При этом сами обновления, закрывающие уязвимости, были выпущены ещё в прошлом году — в виде Patch Level 3 для 5.7.5 и Patch Level 1 для всех версий 6.*. Однако разработчики сделали это без громких анонсов, поэтому многие администраторы попросту не знали о том, насколько критична установка патча.<br/>
<br/>
Как следствие, значительное количество форумов по-прежнему остаётся под угрозой. Даже те, кто установил последние мажорные версии, но не применил минорные обновления, находятся в зоне риска. Особенно это касается проектов с высокой посещаемостью, где атака может привести к краже данных пользователей, модификации контента и полной компрометации ресурса.<br/>
<br/>
vBulletin остаётся одним из самых распространённых движков для форумов на PHP/MySQL, его используют тысячи сайтов по всему миру. За счёт модульной архитектуры и поддержки мобильных API он подходит как для небольших сообществ, так и для крупных коммерческих площадок. Но именно гибкость и расширяемость платформы обеспечивают широкую поверхность атаки — и в очередной раз доказывают, насколько важно регулярно обновлять даже казалось бы безобидные компоненты.<br/>
<br/>
Ранее vBulletin уже становился объектом громких взломов. В прошлом <a href="https://www.securitylab.ru/news/490355.php" target="_blank">уязвимости в его коде</a> позволяли атакующим получить доступ к базе данных, выкладывать вредоносные объявления и использовать платформу как точку входа в более крупные системы. Текущие баги — из той же категории: простые в применении, но чрезвычайно разрушительные, если подойти к делу с умом.<br/>
<br/>
Разработчики рекомендуют администраторам форумов срочно установить обновления безопасности и, если возможно, перейти на версию vBulletin 6.1.1, в которой описанные проблемы устранены. В противном случае сайты остаются открытыми для атак через шаблоны, API и уязвимости уровня ядра.<br/>
<br/>
<a href="https://www.securitylab.ru/news/559936.php" target="_blank">@ SecurityLab </a>
</div>