vBulletin Exploits (CVE-2025-48827, CVE-2025-48828), (Tue, Jun 3rd) SANS Internet Storm Center, InfoCON: green

Last week, Ryan Dewhurst disclosed an interesting and easily exploitable vulnerability in vBulltin. These days, bulletin boards are not quite as popular as they used to be, but they are still being used, and vBulletin is one of the most common commercially supported platforms to create a bulletin board. The vulnerability is remarkable as it exemplifies some common issues with patching and keeping your software up to date. 

Last week, Ryan Dewhurst disclosed an interesting and easily exploitable vulnerability in vBulltin. These days, bulletin boards are not quite as popular as they used to be, but they are still being used, and vBulletin is one of the most common commercially supported platforms to create a bulletin board. The vulnerability is remarkable as it exemplifies some common issues with patching and keeping your software up to date.

vBulletin is written in PHP (just like this website). To create a modern single-page application in PHP, one typically needs to create an API. This API often exposes internal classes. A URL like https://example.com/api/test may be called the “test” method in our “API” class. Of course, you may not want to expose all your methods to the API, but only select methods you think are safe to use. 

One way to restrict access to specific methods has been to mark them as “private.” Only “public” methods are typically accessible from outside the particular class. To evaluate any function, vBulletin uses “Reflection,” an API that allows your code to interrogate classes to see what is available and how to call specific methods. As brilliantly explained by Karmainsecurity [1], this is where the problem arises.

PHP 8.1 changed the behavior of the Reflection to allow the execution of private methods. Earlier, PHP used “ReflectionMethod::setAccessible” to regulate if a method was accessible. However, “As of PHP 8.1.0, calling this method has no effect; all methods are invokable by default.” [2] This change is not very prominent, and it took me a while to find it after seeing it mentioned in the Karmainsecurity blog.

Lesson #1: Patches MAY include subtle changes in behavior, removing security controls that you are used to and expect to “just work.”

The next issue is the patch for this vulnerability. The patch was released over a year ago, in April 2024 [3]. The patch notice mentions: “To maintain site security, you should apply this patch as soon as possible.” There were no details, no CVEs, no statement as to the nature or impact of the vulnerabilities. In other words, There is no help gauging the criticality of the vulnerability.

Lesson #2: Patches MAY include essential security improvements, even if vendors do not disclose them.

In other words, If you upgrade PHP too early, you lose. If you upgrade vBulletin too late, you lose.

We started seeing exploit attempts on May 25th, two days after the blog post was released.

So far, we have seen these IP addresses scanning for the vulnerability:

195.3.221.137: This appears to be a mail server in Poland. It has been doing various recon scans for web applications starting back on May 12th.
169.150.203.14: This IP address is located with a British colo provider (Datapacket) and has done little other scanning. 
23.162.40.123: Scanning very much like 169.150.203.14. These may be under the control of the same threat actor. Located with Cyber Data.
176.65.149.193: Also similar to the prior two IPs.  
 

[1] https://karmainsecurity.com/dont-call-that-protected-method-vbulletin-rce?ref=blog.kevintel.com
[2] https://www.php.net/manual/en/reflectionmethod.setaccessible.php
[3] https://forum.vbulletin.com/forum/vbulletin-announcements/vbulletin-announcements_aa/4491049-security-patch-released-for-vbulletin-6-x-and-5-7-5

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License. 

​Read More