CVE-2025-48827

What it actually does

This is an unauthenticated authentication-bypass flaw in vBulletin when affected 5.x and 6.x releases run on PHP 8.1 or later. A remote attacker can craft requests to the vBulletin API endpoint, such as requests using the /api.php?method=... pattern, to invoke API controller methods that are intended to be protected by authentication and authorization checks. Depending on which protected methods are reachable and how the forum is configured, this can expose privileged application functions, enable unauthorized data access or modification, and potentially support follow-on compromise such as account manipulation, configuration changes, file abuse, or chaining with other application weaknesses.

Why it matters to the business

A public-facing vBulletin forum running an affected version can be acted on by an unauthenticated attacker as if protected API functionality were available to them. This can lead to forum defacement, user data exposure, account takeover, service disruption, spam or malware distribution from a trusted community site, and reputational damage. The risk is high because the issue has a critical CVSS score, a high EPSS probability, weaponized exploitation, and documented exploitation in the wild since May 2025, even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an internet-exposed vBulletin instance and determines whether it is in an affected version range and running on PHP 8.1 or later. They then send unauthenticated HTTP requests directly to the API endpoint using a crafted method parameter, commonly following the /api.php?method=... request pattern, to reach controller methods that should normally require a logged-in or privileged user. If the server accepts the request and returns successful responses, the attacker enumerates which protected methods are callable and uses those methods to read sensitive application data, modify forum state, manipulate accounts or sessions, or prepare additional persistence. In higher-impact intrusions, the attacker may chain this bypass with upload, template, plugin, or administrative-function abuse to place web-accessible malware, create privileged accounts, alter site content, or use the forum as infrastructure for phishing, spam, or malware delivery.

How to fix it

Upgrade vBulletin to a vendor-supported release newer than the affected ranges: do not run vBulletin 5.0.0 through 5.7.5 or 6.0.0 through 6.0.3 on PHP 8.1 or later. If an exact fixed version is not available from internal package metadata, obtain the latest security release directly from vBulletin and verify vendor advisories for the branch in use. Treat downgrade of PHP below 8.1 only as a temporary risk-reduction measure, not a primary fix, because it may introduce other security and support risks. If immediate patching is not possible, restrict external access to /api.php at the web server or WAF layer where business functionality permits, require network-level access controls for administrative/API paths, monitor and rate-limit suspicious API traffic, disable unused plugins, remove write permissions from web-accessible directories where feasible, and ensure recent offline backups are available. After patching, review forum users, administrator accounts, plugins, templates, scheduled tasks, uploaded files, and configuration for unauthorized changes.

How to confirm the fix worked

Confirm the running vBulletin version is outside the affected ranges and that the application is using a vendor security-fixed build. Confirm PHP runtime version and verify that any temporary PHP workaround has not replaced the actual application update. From an unauthenticated test client, send benign requests to /api.php using method parameters that previously exercised protected API routing and verify the application rejects them with an authentication or authorization failure rather than executing the method. Review web server logs after the update to ensure suspicious /api.php?method= requests no longer return successful responses. Validate WAF or reverse-proxy controls, if used, by testing that unauthorized API method invocation attempts are blocked or logged. Run file-integrity checks against the vBulletin web root and compare plugins, templates, and administrator accounts against a known-good baseline.

Typical attack path

1. Discover an internet-facing vBulletin site and fingerprint the application/version behavior.
2. Confirm the server is likely running an affected vBulletin 5.0.0-5.7.5 or 6.0.0-6.0.3 build on PHP 8.1 or later.
3. Send unauthenticated requests to /api.php with a crafted method parameter that targets protected API controller functionality.
4. Observe HTTP 200/redirect/structured API responses indicating protected methods are reachable without authentication.
5. Enumerate callable protected methods and identify those that expose data or change application state.
6. Use reachable methods to access sensitive information, manipulate accounts/content/configuration, or create conditions for persistence.
7. Optionally chain the bypass with upload, template, plugin, or file-write functionality to deploy a web shell or other malware.
8. Clean up obvious artifacts, rotate request sources, and continue abusing the compromised forum for data theft, spam, defacement, or further attacks.

How to detect it

Check for prior exploitation by reviewing HTTP access logs, reverse-proxy logs, WAF events, CDN logs, application logs, and authentication/audit logs for unauthenticated requests to /api.php containing a method parameter. Prioritize requests from external IPs, requests with no authenticated session cookie, requests returning HTTP 200/302/500, bursts of varied method names, and automation user agents such as curl, python-requests, Go-http-client, masscan, zgrab, or custom scanners. Correlate suspicious API requests with subsequent administrator logins, new user or administrator creation, password/email changes, template or plugin edits, file uploads, configuration changes, and unexpected outbound connections from the web server. On disk, look for recently modified files in the vBulletin web root and writable upload/static-content directories, especially PHP files in locations that normally should contain images or attachments. Inspect suspicious files for common web-shell patterns such as system execution wrappers, base64/gzip decoding, eval-like obfuscation, and single-parameter command execution. If exploitation is suspected, preserve web logs, application logs, affected files, and database/application audit records before remediation.

• /api.php?method=
• POST /api.php?method=
• GET /api.php?method=
• method=protectedMethod
• api.php%3Fmethod%3D
• curl/
• python-requests
• Go-http-client
• masscan
• zgrab
• eval(
• base64_decode(
• gzinflate(
• shell_exec(
• passthru(
• system($_
• cmd=
• /images/*.php
• /attachments/*.php
• /customavatars/*.php
• /signaturepics/*.php

What your security team should do

• Immediately inventory all internet-facing vBulletin deployments and identify versions 5.0.0-5.7.5 and 6.0.0-6.0.3, especially those running PHP 8.1 or later.
• Prioritize emergency upgrade to the latest vendor-supported vBulletin security release because exploitation is weaponized and has been observed in the wild.
• If patching cannot be completed immediately, temporarily restrict or block unauthenticated access to /api.php and monitor for business impact.
• Hunt historical web access logs for unauthenticated /api.php requests with method parameters, especially requests returning HTTP 200, 302, or 500 responses.
• Review administrator accounts, moderator accounts, API-accessible functionality, plugins, templates, and recent content changes for unauthorized activity.
• Search the web root and writable upload directories for recently created PHP files, obfuscated scripts, or files with unexpected extensions.
• Reset credentials and invalidate sessions for privileged forum users if suspicious API activity or unauthorized changes are found.
• Add SIEM detections for abnormal /api.php?method= traffic, high-rate API enumeration, and requests from automation user agents.
• Preserve logs and forensic images before cleanup where compromise is suspected.
• Track vendor advisories and threat-intelligence reporting for additional method names, exploit chains, and actor infrastructure associated with this vulnerability.