TL;DR
vBulletin 5.0.0–5.7.5 and 6.0.0–6.0.3 blindly expose protected API endpoints when the forum is hosted on PHP 8.1+. Attackers only need one unauthenticated POST request to reach logic that was never meant to be public. Security firms observed exploitation in May 2025 and proof-of-concept write-ups followed within days. Upgrading to the patched builds listed below or downgrading PHP to a pre-8.1 release restores the intended protections.
1. Summary
| CVE ID | CVE-2025-48827 |
| Affected Product(s) | vBulletin 5.0.0 through 5.7.5 and 6.0.0 through 6.0.3 when executed on PHP 8.1 or newer |
| Volerion Risk Score | 8.1 / 10 |
| Exploit Status | In-the-wild exploitation & public proof-of-concept |
| CISA KEV | Not listed at the time of writing |
vBulletin’s AJAX layer routes every /ajax/api/<controller>/<method> request through a dispatcher that relies on PHP’s Reflection API to confirm whether the target method is public. Starting with PHP 8.1, Reflection will happily invoke protected methods through ReflectionMethod::invokeArgs() unless the developer explicitly checks isPublic(). Because the vBulletin code base never performed that extra check, upgrading the underlying PHP interpreter silently removed a critical access control.
2. Context – Why this bug surfaced only after PHP 8.1
vBulletin’s API controllers pre-date PHP 8 and were built around the assumption that Reflection respects method visibility. PHP 8.1 introduced performance improvements that delegate visibility checks to compile-time stubs. When the method is invoked through Reflection the interpreter can no longer decide at runtime whether the caller is allowed to reach it unless the application asks for that information.
Most shared hosting providers rolled out PHP 8.1 and 8.2 during 2024 and early 2025, so thousands of live forums unknowingly flipped from protected to fully open endpoints without touching a single line of vBulletin code.
3. Technical Details – From POST to protected function
Internally, each vBulletin API controller extends vB_Api_Controller. Incoming requests hit callNamedMethod() which looks up the target via Reflection and immediately invokes it:
$reflect = new ReflectionClass($controllerClass);
$method = $reflect->getMethod($methodName);
return $method->invokeArgs($controllerObject, $arguments);Prior to PHP 8.1 the above call failed if $method was not public. Under PHP 8.1+ it succeeds, so any attacker can reach helpers such as replaceAdTemplate(), resetPassword() or importStyleXml() that were intentionally kept behind authentication.
A single unauthenticated request is enough:
POST /ajax/api/template/replaceAdTemplate HTTP/1.1
Host: forum.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
adid=1&template=<script>require('system')('id;whoami');</script>Depending on the invoked helper, the result ranges from privilege escalation to direct command execution on the web server.
4. Impact – What attackers gain in practice
Many large discussion boards run vBulletin with administrator accounts that can upload style templates and plug-ins. By skipping the login step altogether, threat actors can:
• Reset or steal administrator credentials.
• Upload arbitrary PHP through the style importing mechanism and execute it.
• Pivot further into the hosting environment using harvested session cookies.
Because forums usually sit in the same virtual host as payment portals or single-sign-on endpoints, a compromised vBulletin instance can become the initial foothold for a broader breach.
5. Remediation – Getting back to a safe baseline
vBulletin released hot-fix builds that explicitly block non-public methods:
- 5.7.5 Patch Level 3
- 6.0.1 Patch Level 1
- 6.0.2 Patch Level 1
- 6.0.3 Patch Level 1
- 6.1.1 (regular release that also contains the fix)
Apply the relevant patch or upgrade to 6.1.1 if your maintenance window permits. If you cannot patch immediately, downgrading PHP to 8.0 or 7.4 re-enables the visibility checks and serves as a temporary mitigation. Blocking direct access to /ajax/api/ through a web application firewall adds another line of defense but should not be treated as a full fix.
6. Timeline
| Date (UTC) | Milestone |
|---|---|
| 2025-05-27 | CVE-2025-48827 published in the MITRE CVE list |
| 2025-05-27 | Volerion completes enrichment and publishes risk score |
| 2025-05-?? | In-the-wild exploitation first observed (public reports cite May 2025) |
7. References
- Kevintel advisory: https://kevintel.com/CVE-2025-48827
- Karma Insecurity write-up and PoC: https://karmainsecurity.com/dont-call-that-protected-method-vbulletin-rce
- Independent researcher coverage: https://blog.kevintel.com/vbulletin-replaceadtemplate-kev/
About Volerion
Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the tradditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.
How the Volerion Risk Score Fits With CVSS, EPSS and KEV
At the time of writing:
- This CVE carries a 10.0 base score under CVSS 3.1, highlighting the combination of network reachability, zero required privileges and full confidentiality-integrity-availability impact.
- EPSS assigns 0.1327, meaning roughly a 13 percent chance of observed exploitation in the next 30 days. That seems modest compared to the already confirmed attacks, underscoring EPSS’s focus on future likelihood rather than current activity.
- The Volerion Risk Score aggregates those metrics with product prevalence, remediation friction and exploit maturity, yielding 8.1. That places CVE-2025-48827 firmly in our critical band despite its average EPSS, because real-world abuse and the reach of vBulletin forums raise both threat and spread factors considerably.