A newly discovered vulnerability in vBulletin, one of the world’s most popular forum
platforms, has put thousands of online communities at risk of unauthenticated remote code execution (RCE).
The flaw affects vBulletin versions 5.x and 6.x running on PHP 8.1 or later. It allows attackers to call protected internal methods, breaking key security boundaries and enabling full system compromise without needing to log in.
This vulnerability stems from vBulletin’s use of PHP’s Reflection API within its custom Model-View-Controller (MVC) framework and API system.
Reflection API and Dynamic Routing
vBulletin’s architecture uses dynamic routing, mapping API endpoints to controller methods based on incoming HTTP requests. For example, an AJAX call to /ajax/api/user/fetchProfileInfo routes to the method vB_Api_User::fetchProfileInfo().
The core issue lies in how vBulletin uses the ReflectionMethod::invoke() and ReflectionMethod::invokeArgs() functions. Starting with PHP 8.1, these functions can call protected and private methods without requiring setAccessible(true), which is different from earlier PHP versions.
This change means methods intended to be internal helpers, and never accessible publicly, can now be invoked directly by remote users if the application does not enforce access controls. A request like /api.php?method=protectedMethod would trigger a protected method directly on PHP 8.1 or later, bypassing intended restrictions.
A simplified vulnerable code pattern includes:
Exploitation Path
While invoking protected methods is dangerous, the real risk occurs when one of those methods can be used for code execution.
In vBulletin, the protected method vB_Api_Ad::replaceAdTemplate() is designed to insert or update advertisement templates.
Attackers found they could inject arbitrary template code by calling this method through a crafted HTTP POST request. The vBulletin template engine supports conditional logic using <vb:if> tags. Due to a separate issue with how the template parser filters input, attackers can bypass restrictions and insert PHP code via variable function calls. This injected template lets attackers execute system commands sent in POST requests, effectively providing a webshell on the server.
A proof-of-concept exploit shows how an attacker can gain shell access, run any commands, and fully compromise the system without authentication. For example:
This exploit has been confirmed on vBulletin versions 5.1.0, 5.7.5, 6.0.1, and 6.0.3 running PHP 8.1 or later. The vulnerability appears to be fixed in version 6.0.4.
This case serves as a warning to developers. Relying on method visibility (public, protected, or private) as a security measure is unsafe, especially when dynamic dispatch and reflection are involved.
The new behavior introduced in PHP 8.1, where ReflectionMethod can invoke protected and private methods by default, means applications must enforce access control explicitly at the application level.
The vBulletin RCE vulnerability highlights how subtle changes in programming languages can cause severe security risks for web applications. It stresses the importance of clear access controls and the dangers of depending solely on language-level visibility rules in dynamic web frameworks.
Found this article interesting? Follow us on X(Twitter) ,Threads and FaceBook to read more exclusive content we post.
