vBulletin < 6

CVE-2026-61511 is an eval injection flaw in vBulletin's template runtime engine (vb5/template/runtime.php). An unauthenticated remote attacker can inject arbitrary PHP code through the template parsing pipeline, which the runtime evaluates via eval(), achieving full remote code execution as the web server user (typically www-data or apache). Officially patched versions span vBulletin 6.1.6 through 6.2.1 via patch-level updates; the vulnerable code also exists in older 6.x, 5.x, and 4.x releases per community analysis. The definitive fix ships in vBulletin 6.2.2.

The vendor rates this CRITICAL at 9.3 and noisgate agrees — the score is accurate. This is an unauthenticated, low-complexity, no-interaction RCE on software that is internet-facing by design. vBulletin's template engine has been the site of at least four prior RCE vulnerabilities (CVE-2019-16759, CVE-2020-17496, CVE-2025-48827, CVE-2025-48828), every one of which was exploited in the wild within days of disclosure. The bug class is deeply understood by attackers, the attack surface is a public HTTP endpoint, and there are zero meaningful friction points to justify any downgrade.

Why this verdict

• Zero friction in the attack chain: Unauthenticated, low-complexity, no-interaction RCE. Every prerequisite evaluates to 'freely available to any internet attacker.' There is no compounding downward pressure because there are no real-world narrowing factors — no auth gate, no race condition, no unusual configuration.
• Internet-facing by design: vBulletin is forum software — 100% of production deployments are internet-facing. Unlike internal-only software where exposure is a configuration mistake, exposure here is the intended operating model. Censys shows ~45,000 instances on the public internet. This is the opposite of the 'only 1% are exposed' downgrade factor.
• Historical weaponization precedent: Four prior vBulletin template engine RCE vulnerabilities were all exploited within 1–4 days. Metasploit modules, Nuclei templates, and standalone exploit scripts exist for the identical bug class. The attacker community treats vBulletin template eval injection as a solved problem — adaptation to a new injection point requires minimal effort.
• Role multiplier: vBulletin occupies the (b) typical role of an internet-facing application tier. It is not a canonical high-value-role component (not IdP, hypervisor, backup, CI/CD, etc.). However, compromise yields: (1) web server shell → initial-access foothold in DMZ, (2) database credentials via config.php → mass PII and credential exfiltration (emails, hashed passwords, IPs, private messages), (3) potential lateral-movement pivot to internal networks from the DMZ. The blast radius is host-to-tenant-to-DMZ scale. While this does not automatically trigger the CRITICAL floor via the high-value-role catalog, the pre-auth RCE profile with zero friction independently justifies CRITICAL — no floor override needed because friction alone does not push below CRITICAL.
• Bug class maturity and poor patch adoption: Eval injection in PHP template engines is a thoroughly documented vulnerability class (CWE-95). vBulletin's installed base has a historically abysmal patching velocity — instances remained vulnerable to CVE-2019-16759 for years after patches were available. The combination of easy exploitation and slow patching makes real-world impact near-certain.

Why not higher?

The score is already at 9.3 CRITICAL. The only gap to a perfect 10.0 is that subsequent-system impact (SC/SI/SA) is scored None in the CVSS 4.0 vector — compromise is contained to the vBulletin host and its database without automatic chaining to adjacent systems. This accurately reflects that lateral movement requires additional attacker effort beyond the initial RCE.

Why not lower?

There are zero friction points in the attack chain. No authentication, no user interaction, no complex race condition, no unusual configuration prerequisite. The software is internet-facing by design with ~45,000 exposed instances globally. Every prior bug in this exact attack surface was weaponized within days. vBulletin's patching velocity is historically poor, meaning a large fraction of the installed base will remain vulnerable for months. Downgrading would require identifying at least one meaningful real-world constraint that narrows the exploitable population — none exists.

1. Deploy WAF rules blocking PHP code injection on vBulletin template endpoints — Configure your WAF (Cloudflare, AWS WAF, F5 ASM, ModSecurity) to block HTTP requests containing PHP function names (passthru, system, exec, eval, shell_exec, popen, proc_open, pcntl_exec) and template injection patterns (<vb:if, condition=) in POST body parameters targeting /vb5/template/, /ajax/render/, /ajax/api/ endpoints. Deploy within the noisgate mitigation SLA of 3 days. This is a bypassable stopgap — obfuscation techniques (concatenation, base64, chr()) can evade naive string matching.
2. Apply the vendor patch or upgrade to vBulletin 6.2.2 immediately — Download the security patch for your version from members.vbulletin.com/patches.php — available for 6.2.1 PL1, 6.2.0 PL1, and 6.1.6 PL1. Alternatively, upgrade to vBulletin 6.2.2 which includes the fix natively. This is the definitive remediation. Target within the noisgate remediation SLA of 90 days, but given pre-auth RCE with imminent weaponization, push for this week.
3. IP-restrict vBulletin admin and internal template endpoints — At the reverse proxy or WAF layer, restrict access to /admincp/, /modcp/, /vb5/template/runtime.php, and AJAX API endpoints to known administrator IP ranges. The public-facing forum pages can remain open. Deploy within 3 days to shrink the attack surface while patching proceeds.
4. Take unsupported versions (< 6.1.6, any 5.x or 4.x) offline — The vendor only patches supported versions 6.1.6+. If you run vBulletin 5.x or 4.x, the vulnerable code exists but no vendor fix is available. Take these instances offline, put them behind an authenticated reverse proxy (e.g., Cloudflare Access, Tailscale Funnel with SSO), or begin emergency migration to 6.2.2+.
5. Audit existing instances for indicators of compromise — Before patching, check for web shells in the vBulletin webroot (find /path/to/vbulletin -name '*.php' -newer /path/to/vbulletin/config.php -mtime -30), unexpected modifications to template files, anomalous outbound connections from the web server process, and bulk database queries. Given the historical exploitation cadence, assume scanning has already begun.

Run on the vBulletin web server as any user with read access to the installation directory. Invoke: bash check_cve_2026_61511.sh /var/www/vbulletin. No root required — just filesystem read access. Outputs VULNERABLE, PATCHED, or UNKNOWN with exit codes 1, 0, 2 respectively.

#!/usr/bin/env bash
# check_cve_2026_61511.sh — Detect CVE-2026-61511 (vBulletin template runtime eval injection)
# Usage: bash check_cve_2026_61511.sh /path/to/vbulletin
# Exit: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -euo pipefail

VB_PATH="${1:-}"
if [[ -z "$VB_PATH" ]]; then
  echo "Usage: $0 /path/to/vbulletin"
  exit 2
fi

# --- Locate version file ---
VERSION_FILE=""
for f in "$VB_PATH/core/packages/vbulletin/version.php" \
         "$VB_PATH/packages/vbulletin/version.php" \
         "$VB_PATH/includes/class_core.php" \
         "$VB_PATH/core/includes/class_core.php"; do
  [[ -f "$f" ]] && { VERSION_FILE="$f"; break; }
done
if [[ -z "$VERSION_FILE" ]]; then
  echo "UNKNOWN — cannot locate vBulletin version file in $VB_PATH"
  exit 2
fi

# --- Extract version ---
VERSION=$(grep -oP "(?:VERSION_BNUMBER|FILE_VERSION|\\\$version)\\s*=\\s*['\"]\\K[0-9]+\\.[0-9]+\\.[0-9]+" "$VERSION_FILE" 2>/dev/null | head -1)
if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — cannot parse version from $VERSION_FILE"
  exit 2
fi
echo "[*] Detected vBulletin version: $VERSION"

IFS='.' read -r MAJ MIN PAT <<< "$VERSION"

# --- 6.2.2+ is patched ---
if (( MAJ > 6 )) || (( MAJ == 6 && MIN > 2 )) || (( MAJ == 6 && MIN == 2 && PAT >= 2 )); then
  echo "PATCHED — vBulletin $VERSION (>= 6.2.2) includes fix for CVE-2026-61511"
  exit 0
fi

# --- Check for patched runtime.php on 6.1.6–6.2.1 ---
for rf in "$VB_PATH/core/vb5/template/runtime.php" \
          "$VB_PATH/vb5/template/runtime.php"; do
  if [[ -f "$rf" ]]; then
    # Patch adds input sanitization before eval; check for patch marker
    if grep -qE '(template_safe_eval|preg_replace.*eval.*sanitize|vb_template_verify)' "$rf" 2>/dev/null; then
      MTIME=$(stat -c '%Y' "$rf" 2>/dev/null || stat -f '%m' "$rf" 2>/dev/null || echo 0)
      MDATE=$(date -d "@$MTIME" '+%Y-%m-%d' 2>/dev/null || date -r "$MTIME" '+%Y-%m-%d' 2>/dev/null || echo 'unknown')
      echo "PATCHED — vBulletin $VERSION with runtime.php patched (modified $MDATE)"
      exit 0
    fi
    echo "[!] Found runtime.php at $rf — no patch signature detected"
    break
  fi
done

# --- Unsupported versions ---
if (( MAJ <= 4 )); then
  echo "VULNERABLE — vBulletin $VERSION (v4.x, unsupported, NO vendor patch)"
  exit 1
elif (( MAJ == 5 )); then
  echo "VULNERABLE — vBulletin $VERSION (v5.x, unsupported, NO vendor patch)"
  exit 1
elif (( MAJ == 6 && MIN == 0 )); then
  echo "VULNERABLE — vBulletin $VERSION (v6.0.x, below supported patch range)"
  exit 1
elif (( MAJ == 6 && MIN == 1 && PAT < 6 )); then
  echo "VULNERABLE — vBulletin $VERSION (below supported patch range 6.1.6+)"
  exit 1
fi

# --- 6.1.6–6.2.1 without patch ---
echo "VULNERABLE — vBulletin $VERSION (in affected range, no patch-level update detected)"
echo "  -> Apply patch from https://members.vbulletin.com/patches.php or upgrade to 6.2.2"
exit 1

Sources

1. vBulletin Official Security Patch Advisory (6.2.1, 6.2.0, 6.1.6)
2. vBulletin 6.2.2 Release Discussion
3. Karma(In)Security — vBulletin Template Engine RCE Technical Analysis
4. Censys Advisory — vBulletin Exposure Data (~45,000 instances)
5. CyberPress — Critical vBulletin Vulnerabilities Under Active Exploit
6. Qualys ThreatPROTECT — vBulletin RCE Exploited in the Wild
7. 6sense — vBulletin Market Share and Deployment Data
8. vBulletin CVE History — CVEDetails