这篇文章是对 watchTowr Platform 背后能力的一次窥探，该平台是一套 Preemptive Exposure Management 解决方案。我们帮助各类组织在威胁于野外被利用之前，自主验证并缓解其面对新兴威胁的暴露风险。 没错，就是这样！今天我们来到了水族馆。 欢迎回到又一篇 watchTowr Labs 博客文章。现在你可以开始准备你的评论了。 0:00 /0:20 1× 什么是 Barracuda，又为什么非谈它不可？ Barracuda 的 Email Security Gateway 解决方案（ESG）之所以备受“青睐”，原因有几个： 无论你是谁，有一点在你的体验中始终一致：它又是一台部署在网络边缘的设备，检查一切流量，并且以恰好且仅有的权限运行，用来拦截一封关于你博客文章的恶意邮件。 一如既往，CVE 编号往往出奇地好记——这两个也不例外，我们可以在 Barracuda 自己的公告中看到，摘要如下： 单独来看，你大可以很英式地说其中任何一个“不太理想”。但情况还会更糟——如果把它们串联起来，而你又是个英国人，你会说它们“还行”。真是刻薄。 所以，毫不意外，这些漏洞正是今天 watchTowr Labs 博客文章的焦点——那就拿杯咖啡，我们边走边聊。 为了支撑今天的分析，我们搭建了设备，并用惯常的“到底改了什么”流程对比了两个版本： 作为背景说明，在进入本文之前需要指出，Barracuda 发布了多个补丁文件来修复 CVE-2026-111560 和 CVE-2026-116606。不过我们重点审查了其中两个，它们的称呼如下： 没有什么比回想起因为一个漏洞而对一台机架式服务器进行物理驱魔更让我们感到温暖的了（是的，我们知道事情没那么简单）。 这正是我们坐下来问自己的问题。幸运的是，我们没等太久。 查看 Patch-1，安装程序至少对它的用途做了说明： ..snip..

Pre-authentication authorization bypass permits

arbitrary Spam_Config restore

CVSS 9.8 Critical

顺便说一句，眼尖的读者会注意到，这里该漏洞的 CVSS 评分为 9.8，而 Barracuda 公告中是 9.3。我们最好的猜测是，9.8 反映的是两个漏洞被合并评分（CVSS 专家会立刻认出这是一种罪过），而不是这里发生了什么不当之事。 深入查看此补丁中改动的文件，我们很快得到了一份嫌疑名单： Index.pm 的改动很奇怪，但幸好很微小。 值得称赞的是，Barracuda 加入了这条描述隐晦的提示，说明问题可能出在哪里：

• Send the error and stop here. Returning a userrole

• would let response() run module handlers.

这条注释反映在整个补丁中： if ($password_change_status == $Login::status_codes{ERROR_PASSWD_CHANGE}->{val}) {

• $params->{json_authenticate} = {

• $self->audit("failed_password_change", $params->{user});

• Send the error and stop here. Returning a userrole

• would let response() run module handlers.

• return $self->_bailout_with_json_login_response(
• $env, $params, { success => 'true', message => $Login::status_codes{ERROR_PASSWD_CHANGE}->{msg} . ": " . $message, status => $Login::status_codes{ERROR_PASSWD_CHANGE}->{val},

• };
• return $userrole;

• }); 所以 Index.pm 处理的是密码修改尝试，但麻烦始于补丁前的代码：当密码修改尝试失败时（返回 ERROR_PASSWD_CHANGE）。 下面是整个存在漏洞的函数，行号沿用 Index.pm 中的原始编号： 383: if(defined($params->{new_password}) && defined($params->{retype_password}) && ! (-e "/tmp/bypass_password")){ 384: my $password_change_status=0; 385: my $message = ""; 386: ($password_change_status, $message,$user) = Login::change_admin_password($params); 387: if($password_change_status == 1 && $user){ 388: # Dont allow logoff unless the request is from an authenticated logged in user 389: my $url = "/cgi-mod/index.cgi" . uri_hash_to_querystring({ 390: locale => $MS_globals::params{locale}, 391: error => $status 392: }); 393: my %redir = (-location=>$url); 394: $self->audit('password_change', $params->{user}); 395: Login::logoff_user($status, 1, $params->{user}); 396: return bailout(); 397: } 398: else{ 399: if ($password_change_status == $Login::status_codes{ERROR_PASSWD_CHANGE}->{val}) { 400: $params->{json_authenticate} = { 401: success => 'true', 402: message => $Login::status_codes{ERROR_PASSWD_CHANGE}->{msg}.": ". $message, 403: status => $Login::status_codes{ERROR_PASSWD_CHANGE}->{val}, 404: }; 405: $self->audit("failed_password_change", $params->{user}); 406: return $userrole; 407: } 虽然补丁前的代码返回了一个详细的 JSON 块，表明密码修改尝试失败，但它实际上并没有停止执行。 下一个合乎逻辑的问题是：“$userrole 是什么？”$userrole“只不过”是当前会话的角色对象，对于我们这个未认证的请求来说，它就是低权限的登录界面角色。 为什么这很重要？因为上面的密码修改代码位于 process_params 之中，而调用它的方法是 response： 584: sub response { 585: my ($self, $env, $params) = @; 586: 587: $self->set_self_url($env, $params); 588: 589: # If we are not activated, this removes various changes the user may 590: # have tried to make from the params hash. 591: $self->_check_activation($env, $params); 592: 593: $self->_process_params($env, $params); 594: 595: $self->_update_variables($env, $params); 596: 597: Barracuda::Hooks::run_hooks("after write config"); _process_params 在第 593 行返回，把我们的 $userrole 直接交还给了 response——这次返回没有指示任何错误，函数便照原样继续执行。 为了复现这一行为，我们向 /cgi-mod/index.cgi（最终会到达此代码路径的端点）发送一个 POST 请求，请求体中有两个参数： POST /cgi-mod/index.cgi HTTP/1.1

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）