最近安全圈又炸锅了。vBulletin这个老牌论坛程序，被曝出一个堪称"核弹级"的预认证远程代码执行漏洞——CVE-2026-61511。不需要账号，不需要登录，甚至连点一下鼠标都不需要，攻击者就能直接在你的服务器上跑PHP代码。目前漏洞细节和完整利用代码已经公开，虽然还没看到大规模野外利用，但风险窗口已经打开，跑在受影响版本上的论坛随时可能成为靶子。

漏洞速览

这个漏洞的"成绩单"相当刺眼。CVSS v3.1评分直接拉满到9.8分，属于最高危级别。它影响的范围也比最初披露的更广——不只是6.x版本，vBulletin 5.x全系列直到5.7.5同样中招。核心问题出在模板引擎的runMaths()方法上，文件路径位于includes/vb5/template/runtime.php。

攻击者通过向公开的ajax/render路由发送精心构造的请求，把恶意载荷塞进pagenav[pagenumber]参数。这个参数最终会流入{vb:math}模板标签，而标签背后的runMaths()方法在把输入交给PHP的eval()函数之前，只做了一层形同虚设的过滤。正则表达式虽然拦掉了字母，却漏掉了数字、括号、运算符和异或符号——这就给了攻击者用"PHPFuck"编码技术拼凑出任意PHP代码的机会。

为什么这个漏洞特别危险

vBulletin在全球支撑着大量高流量社区，从游戏论坛到企业技术支持站点都有它的身影。这次漏洞最要命的地方在于完全零门槛：不需要任何身份凭证，不需要管理员权限，不需要社工诱导用户点击链接。只要你的论坛暴露在公网上，攻击者发个POST请求就能尝试利用。

一旦得手，后果几乎是全方位的。攻击者可以以Web服务进程的权限执行任意操作系统命令，这意味着数据库可能被拖走、用户密码哈希可能泄露、服务器上可能被植入后门，甚至整个站点都会被篡改或下线。更麻烦的是，如果这台服务器还连着内网其他资产，它很可能成为横向移动的跳板。

SSD Secure Disclosure在7月27日正式公开了这个漏洞的完整技术细节。值得注意的是，vBulletin官方其实在6月底就已经给6.2.1、6.2.0和6.1.6分支推送了安全补丁，并在7月1日发布了修复版本6.2.2——比公开披露早了将近四周。这段时间差里有没有被悄悄利用过，目前公开渠道还没有确切说法。

攻击链路拆解

从技术层面看，这个漏洞的利用路径并不复杂，但设计得很精巧。

runMaths()方法里的过滤正则长这样：

plain

preg_replace('#([^+\-*=/\(\)\d\^<>&|\.]*)#', '', $str)

它允许通过的字符包括数字、括号、加减乘除、异或、位运算和比较运算符。乍一看似乎挺安全——毕竟字母都被过滤掉了，总写不了system()或者exec()了吧？

但安全研究者Egidio Romano（网名EgiX）早就证明，仅靠这些"残缺的"字符，通过PHPFuck编码技巧完全可以构造出任意PHP函数调用。原理类似JavaScript界的JSFuck：利用类型转换、位运算和字符串拼接，从极有限的字符集中"拼"出想要的代码。

具体到这次漏洞，攻击者向ajax/render/pagenav端点发送请求，在pagenav[pagenumber]参数里塞入经过编码的载荷。这个参数被模板引擎读取后赋值给pagenav.currentpage，随后进入{vb:math}标签做数学运算——实际上就是被eval()直接执行。整个链条从入口到代码执行，没有任何身份校验挡在中间。

影响范围与当前态势

受影响的版本清单如下：

• vBulletin 5.x：5.0.0 到 5.7.5

• vBulletin 6.x：6.0.0 到 6.2.1

如果你还在用这些版本，并且论坛面向公网开放，那现在就应该把升级提到最高优先级。vBulletin Cloud托管服务的用户相对幸运，官方表示云端环境已经自动完成补丁更新。但自建服务器的管理员就得自己动手了。

截至7月27日公开披露时，还没有权威来源确认这个漏洞已经被野外大规模利用，CISA的已知被利用漏洞目录里也没有它。不过历史经验告诉我们，vBulletin的模板引擎漏洞向来是攻击者眼中的"香饽饽"。2025年的CVE-2025-48827和CVE-2025-48828就是前车之鉴——那两枚漏洞在公开后很快就被观察到实际利用活动。现在PoC已经满天飞，留给管理员修漏洞的时间窗口正在快速收窄。

修复方案与应急建议

最直接的解决办法就是升级。vBulletin 6.2.2已经彻底修复了这个问题，建议所有能升级的用户直接跳到这个版本。如果因为某些原因暂时无法大版本升级，至少要把对应分支的安全补丁打上——6.2.1、6.2.0和6.1.6都有官方补丁可用。

除了打补丁，安全团队还应该马上做几件事：

日志排查：检查Web服务器和vBulletin的访问日志，重点搜索指向ajax/render/pagenav的POST请求。如果看到pagenav[pagenumber]参数异常冗长、包含大量运算符和编码字符，那很可能有人在试探这个漏洞。

主机巡检：已经暴露在外网的vBulletin服务器需要全面排查webshell、异常进程、未授权的管理员活动，以及Web服务账户下是否有不该出现的命令执行记录。

网络隔离：如果短期内确实无法打补丁，考虑通过WAF规则临时拦截对ajax/render路径的异常请求，或者把管理后台和论坛前端做更严格的网络分层。但说实话，这些措施只能算权宜之计，补丁才是根本。

写在最后

CVE-2026-61511再次给所有依赖vBulletin的社区敲响了警钟。一个正则表达式的疏忽，加上eval()这种"危险函数"的滥用，最终酿成了预认证RCE的严重后果。对于运营者来说，现在不是观望的时候——PoC已公开、攻击门槛极低、潜在影响极大，这三个条件凑在一起，意味着漏洞被武器化只是时间问题。

如果你负责维护vBulletin站点，今天就去检查版本号。是6.2.2或者打了最新补丁的，可以松口气；还在受影响范围内的，建议放下手里其他活，先把这事办了。毕竟等日志里出现可疑请求的时候，可能就已经晚了。