A newly discovered flaw in the vBulletin forum software has left thousands of online communities vulnerable to unauthenticated remote code execution (RCE). The issue affects vBulletin versions 5.x and 6.x when running on PHP 8.1 or later.
This high-risk vulnerability allows attackers to invoke protected internal methods, potentially compromising the entire server with no need for login credentials.
How the Flaw Works
vBulletin uses a custom Model-View-Controller (MVC) framework that relies on PHP’s Reflection API to route HTTP requests to internal controller methods. For example, a request to /ajax/api/user/fetchProfileInfo
triggers the method vB_Api_User::fetchProfileInfo()
.
However, starting with PHP 8.1, the ReflectionMethod::invoke()
and invokeArgs()
functions can now access protected and private methods without needing setAccessible(true)
. This change breaks a critical security assumption in vBulletin’s architecture.
This means attackers can send crafted requests to /api.php?method=someProtectedMethod
and call internal methods not meant for public access.
From Access to Exploitation
The real danger comes when these internal methods can be used for code execution. One such method is vB_Api_Ad::replaceAdTemplate()
, which is meant to manage ad templates in the system.
By invoking this method with a specially crafted POST request, attackers can inject malicious template code into the forum system.
vBulletin’s template engine supports logic using <vb:if>
tags. Due to a separate flaw in the template parser, attackers can bypass input filtering and inject arbitrary PHP code. This lets them turn the template into a remote webshell that can execute commands sent through POST data.
This exploit has been successfully tested on vBulletin versions 5.1.0, 5.7.5, 6.0.1, and 6.0.3 running on PHP 8.1+.
Proof-of-Concept and Patch
A proof-of-concept attack shows how a hacker can upload a template, run system commands, and take full control of a server. This can be done without needing a username or password.
The vulnerability has been patched in vBulletin version 6.0.4, and users are strongly urged to upgrade immediately.
Security Lessons
This incident highlights a major risk in relying on programming language features like method visibility (public, protected, private) as security controls—especially in web applications that use dynamic routing and reflection.
With PHP 8.1 changing how ReflectionMethod behaves, developers must now explicitly enforce access control within their application code. Assuming visibility modifiers will block access is no longer safe.
The vBulletin RCE vulnerability is a reminder of how small changes in programming languages can lead to major security failures when frameworks don’t adapt.