Critical vBulletin Pre-Auth RCE: Public PoC Now Available
Hey everyone,
Just spotted a concerning disclosure from SSD Secure Disclosure regarding a Pre-Auth Code Execution flaw in vBulletin. The public exploit dropped on July 27 demonstrates how an unauthenticated attacker can trigger PHP's eval() function, leading to full RCE without needing any user interaction or administrative privileges.
The Details:
- Affected: vBulletin 6.2.1 and earlier, 6.1.6 and earlier.
- Impact: Unauthenticated code execution.
- Vector: The exploit chain allows a single request to reach a dangerous
eval()call in the core application logic.
If you are still hosting vBulletin instances, especially older versions, patching should be your immediate priority. Since the PoC is public, expect automated scanners to ramp up quickly.
Detection & Hunting: While patching is the only fix, you can hunt for scanning activity. Since the exploit targets unauthenticated endpoints, look for anomalous POST requests to unusual scripts or parameters containing encoded PHP code.
You can quickly grep your access logs for suspicious POST patterns that might indicate probing:
grep -i "POST" /var/log/httpd/access_log | awk '{print $7}' | sort | uniq -c | sort -rn | head -n 20
Additionally, if you need to scan internal assets to identify vulnerable versions before patching, you can use a simple Python script to check the generator tag:
import requests
def check_vbulletion(url):
try:
r = requests.get(url, timeout=5)
if "vBulletin 6.2" in r.text or "vBulletin 6.1" in r.text:
print(f"[!] Potential vulnerable version at {url}")
except Exception as e:
print(f"Error connecting to {url}")
# Usage: check_vbulletion("http://target-forum.com")
Does anyone else still have legacy vBulletin instances in their environment, or have we mostly migrated away? I'm curious how widespread the 6.x adoption is compared to the older 5.x/4.x end-of-life versions that are likely still lingering.
Thanks for the heads-up. We still have a few client instances running vBulletin 5.x (end of life) that we've been begging to migrate. This new flaw in 6.x is a good reminder of the risks of staying on forum software that exposes so much logic to the public web. If you can't patch immediately, I highly recommend putting it behind a strict WAF with virtual patching.
I've already started seeing mass scanning activity targeting this on our honeypots. The requests are hitting the ajax/api/hook/ endpoint with malformed eval payloads. If you are running Suricata, you can write a quick rule to block the specific header combination used in the PoC. Don't wait for the official signature if you have a large exposure.
The fact that it hits eval() directly is brutal. No SQLi tricks needed, just straight code injection. For sysadmins who are stuck on this, ensure your PHP disable_functions is locked down tight. While it won't stop the initial execution, it might prevent the attacker from getting a reverse shell if shell_exec or passthru are disabled.
Solid advice from the team. For those potentially compromised, immediate forensics are key. Successful exploitation often leads to webshell uploads. I recommend scanning for recently modified PHP files in your web root. This one-liner helps pinpoint suspicious activity in the last 24 hours:
find /var/www/html -name "*.php" -mtime -1 -ls
Solid advice everyone. If you can't patch immediately, implementing a virtual patch at the WAF level is your best stopgap. This ModSecurity rule blocks the specific route involved:
apache
SecRule REQUEST_URI "@beginsWith /ajax/api/hook/"
"id:100010,phase:1,deny,status:403,msg:'Block vBulletin RCE'"
It might break some legitimate forum features, but it stops the eval() chain cold while you organize the migration. Has anyone verified if legacy vB5 paths are susceptible to similar logic?
Great insights, everyone. If you're hunting for potential compromises based on Dana's forensics tip, you can quickly correlate the webshell upload with the initial request in your access logs. Look for spikes in 200 or 500 responses to that specific endpoint around the time of file creation.
Here is a quick bash one-liner to extract suspicious IPs hitting the vulnerable route:
awk '$7 ~ /ajax\/api\/hook/ {print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head
Great advice on the virtual patching. To add a layer of defense-in-depth, consider strict egress filtering if the WAF fails. Even if they achieve RCE, blocking outbound traffic prevents the attacker from establishing a C2 channel or downloading further tools. Ensure your web server can only talk to the database and specific internal services.
# Drop all new outbound connections from the web server
iptables -A OUTPUT -o eth0 -m state --state NEW -j DROP
Here is the full ModSecurity rule to block the specific ajax/api/hook/ endpoint mentioned in the PoC. This serves as a quick virtual patch while you organize upgrades.
apache
SecRule REQUEST_URI "@rx /ajax/api/hook/"
"id:1001234,phase:1,deny,status:403,msg:'Block vBulletin RCE Attempt'"
Just be aware that this might interfere with legitimate plugins that rely on that specific hook API, so monitor your logs after deploying.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access