DEV Community

Anoymask
Anoymask

Posted on

vBulletin CVE-2026-61511: Unauthenticated RCE via Public AJAX Template to `eval()`

vBulletin CVE-2026-61511: Unauthenticated RCE via Public AJAX Template to eval()

1. Basic Information

2. Executive Summary

Sending a crafted pagenav[pagenumber] to vBulletin's public AJAX template rendering bypasses the weak validation of the math function runMaths() using phpfuck. It reaches PHP's eval() without authentication to execute arbitrary code. A public PoC with a known fix exists, and scanning activity is expected to increase.

3. Attack Flow

  1. The attacker searches for public sites running vBulletin 5.x/6.x.
  2. They send a request to a public template rendering endpoint like ajax/render/pagenav.
  3. They insert a PHP expression into pagenav[pagenumber] to bypass math validation.
  4. Template execution reaches vB5_Template_Runtime::runMaths().
  5. The input goes to PHP eval(), executing arbitrary PHP code.
  6. OS commands start under the PHP/web server user permissions.
  7. Inference: Leads to web shell installation, database credential theft, forum database exfiltration, defacement, and persistence.

4. Attacker Position and Execution Location

  • The attacker sends HTTP(S) requests from the internet without authentication.
  • The vulnerable processing happens inside the vBulletin template runtime.
  • PHP code runs with Web/PHP-FPM/Apache user permissions.

5. Visibility for Victims and Administrators

  • No user action or login is needed.
  • Web access logs may show ajax/render/pagenav and an unusual pagenumber parameter.
  • PHP/EDR can see shells, downloaders, and file creation from the web process.
  • The site may look normal while web shells and database theft occur.

6. Conditions for Success and Failure

Success Conditions

  • Unpatched configuration of vBulletin 5.x to 5.7.5, or 6.x to 6.2.1.
  • Reachable public template rendering route.
  • Input that passes dangerous PHP eval() expressions is processed.
  • The web process has permissions for follow-up actions.

Failure Conditions

  • vBulletin 6.2.2 or matching Patch Level 1 is applied.
  • Upgrading 5.x to a supported version.
  • WAF/reverse proxy blocks the attack route and parameters.
  • Restrictions on web user writes, shell launching, and egress.

7. What Happens on Success

The attacker runs code with PHP/web server permissions. They can read, modify, or steal configuration files, database credentials, user information, and post/admin data. If write permissions exist, they can maintain persistence via web shells or cron jobs, and potentially move to other apps on the server.

8. Observable Logs

Email

  • Suspicious bulk emails or password resets sent from vBulletin.

Proxy / SWG / DNS

  • DNS/HTTP traffic from the web server to unknown domains.
  • Downloading tools and web shells right after the attack.

Endpoint / EDR

  • Shells, curl, or wget as children of php-fpm, httpd, or apache2.
  • New PHP files, disguised image files, or .htaccess changes in the web root.
  • Database dumps, compression, or cron changes by the web user.

Identity / IdP

  • Suspicious logins by vBulletin administrators.
  • Unusual connection sources or heavy queries for database accounts.

SaaS / Cloud

  • Abuse of forum integration API keys or email credentials.
  • Inference: Abuse of cloud host instance roles.

Network

  • Repeated POST/GET requests to ajax/render/pagenav.
  • New egress traffic from the web server, or connections to internal DB/admin ports.

9. Attack Success Determination

  • Contact Only: PoC-style requests, 404/403/errors only.
  • User Action: None required.
  • Initial Execution: Command output in HTTP responses, child processes of the web process.
  • Malware or Successful Auth: Web shells, use of database credentials.
  • Data Theft / Session Compromise: Database dumps, stolen admin sessions/API keys.
  • Follow-on Intrusion Confirmation: Persistence, defacement, internal lateral movement, outbound transfer.

10. Investigation Playbook

Trigger

Detection of PoC routes/parameters, web process child shells, new PHP files, heavy vBulletin database reads.

Initial Checks

  1. Verify the exact vBulletin version and Patch Level.
  2. Review access logs starting before and after the fix release on July 1.
  3. Search for ajax/render/* and pagenav[pagenumber].

Endpoint

  • Preserve the web/PHP process tree, web root diffs, temp areas, cron, and systemd.
  • Check PHP settings, loaded modules, database dumps, and archives.

Authentication and Cloud

  • Rotate vBulletin admin, database, SMTP, API, and host IAM credentials.
  • Revoke admin sessions and "Remember-me" tokens.

Follow-on Actions

  • Track web shells, database theft, defacement, internal connections, and outbound transfers.

Containment

  • Update to the fixed version, and migrate 5.x to a supported version.
  • Temporarily block the attack route using a WAF.
  • Isolate and rebuild the web server if RCE is confirmed.

Verdict Categories

Scan / Exploit Attempt / PHP RCE / Web Shell / Database Compromise / Follow-on Intrusion.

11. Defense and Detection Ideas

Single Event

  • Abnormal requests to ajax/render/pagenav.
  • Long or obfuscated expressions inside pagenumber.
  • Shells from PHP/web processes.
  • New PHP files in the web root.

Time-Series Correlation

PoC Request → 200/Abnormal Response → PHP Child Shell → New PHP File → Heavy DB Read → Egress

Hunting Perspective

  • Public vBulletin version and Patch Level.
  • Broad scanning since the PoC release on July 27.
  • Files created by web users and database dumps.

Log Gaps

It is hard to confirm RCE without HTTP queries/bodies, PHP-FPM access, process creation, file audits, and database queries.

Priority Actions

  1. Apply 6.2.2 / Patch Level 1.
  2. Migrate 5.x.
  3. Monitor attack routes with a WAF.
  4. Enforce least privilege and egress limits for web processes.
  5. Monitor web root integrity.

12. Facts / Inference / Hypothesis

Facts

  • CVE-2026-61511 is an unauthenticated RCE reaching PHP eval() from runMaths().
  • Versions 5.x to 5.7.5 and 6.x to 6.2.1 were reported as affected.
  • The public PoC uses ajax/render/pagenav to run OS commands.
  • Version 6.2.2 was fixed on July 1, and Patch Level 1 was provided for several older 6.x versions.
  • No active exploitation was confirmed at the time of publication.

Inference

  • Even with minor errors in the public PoC, it is easy to fix, and scanning/exploitation may surge.
  • Applying patches alone does not remove web shells installed around the time of the PoC release.

Hypothesis

  • Combining PoC routes with PHP child shells or new PHP files provides high-confidence detection.
  • End-of-life 5.x versions remain on long-running forums and may impact community or support sites globally.

13. MITRE ATT&CK Mapping

  • T1190 Exploit Public-Facing Application — High confidence.
  • T1059.004 Unix Shell / T1059.003 Windows Command Shell — Depending on OS, medium confidence.
  • T1505.003 Web Shell — Upon placement, medium confidence.
  • T1005 Data from Local System — When acquiring DB/configs, medium confidence.
  • T1213 Data from Information Repositories — When acquiring forum DBs, medium confidence.
  • T1105 Ingress Tool Transfer — When acquiring additional tools, medium confidence.

14. Unknowns and Additional Investigations

  • Presence of active exploitation and IOCs.
  • Scope of fixes provided for 5.x.
  • PoC differences by web server/OS.
  • Number of public vBulletin instances globally.

15. Impact on SOCs and General Organizations

Long-running forums used for product support, gaming, tech communities, and other purposes are often slow to update. In addition to leaks of user emails, password hashes, and post history, vulnerabilities can spread to other sites on the same server. Organizations should perform asset inventories and investigate compromises around the time of the PoC release simultaneously.

16. Summary by Target Audience

For SOCs

Correlate PoC routes, PHP child processes, new PHP files, and heavy database reads to distinguish between scans and successful RCE.

For Administrators

Update to 6.2.2 or the matching Patch Level 1, and migrate 5.x versions. Perform retrospective investigations on web roots and logs.

For Users

Sites can be compromised without user actions. If notified by administrators, change passwords, including on other sites where the same password was reused.

Top comments (0)