我把 Meetily 的旧后端翻出来看了一遍，发现它连登录都不问了

这个漏洞最反常识的地方是，厂商已经用 Tauri 重写了整个应用，旧的后端代码却还留在 main 分支上，而且不需要任何身份就能调。我把这条链路从入口到落点捋了一遍，也写清了哪些结论我只能停在推断。

评分 5.5，不等于可以拖到下周

CVSS 4.0 给了 5.5，MEDIUM。很多人看到 MEDIUM 就划过去了，我一开始也差点划过去。

但把向量拆开看，AV 是 N，网络可达，不需要先进内网。AC 是 L，攻击复杂度低，条件稳定可复现。PR 是 N，不需要任何身份。UI 是 N，不需要受害者点任何东西。

这四条叠在一起的含义是，只要那台机器上的 Meetily 后端在监听，外面的人就能直接摸到它的接口，中间没有任何一道门。

评分为什麼只有 5.5，是因为 CIA 三个影响分量都是 L，机密性、完整性、可用性都只标了低。换句话说，NVD 认为它能造成的单次破坏有限。

这里有个细节我想单独说，E 分量是 P，代表 proof of concept 已经公开。这不是理论漏洞，是已经有人把走法写出来了。

所以我的判断是，5.5 这个分数描述的是「单次能造成多大破坏」，不是「该不该今天动手」。对一台暴露在公网的后端来说，零认证这一条本身就够格今天就处理。

问题不在 Tauri 那一层，在被留下的旧后端

官方描述里有一句话是整个事件的关键，legacy backend was not removed yet。旧后端没有被移除。

厂商自己的解释是，正在迁移到基于 Tauri 框架的统一应用，client-server 架构已经被废弃。

注意这个时态，废弃了，但没删。废弃是产品决策，删除是工程动作，这两件事之间隔着一段时间，而这段时间就是漏洞的窗口。

图 1　本文示意图：一个不带任何身份的请求，是怎么一路走到业务逻辑的。

受影响文件写得很具体，backend/app/main.py。这是一个后端应用的入口文件，通常负责挂路由、注册中间件、装配依赖。

缺失认证落在这一层，意味着问题不是某个业务函数忘了查权限，而是整个应用在装配阶段就没有把认证中间件挂上去，或者挂上去了但对某些路径不生效。

我倾向于后者，因为如果是完全没挂，整个后端的所有接口都应该是裸的，描述里通常会写得更严重。公开信息只说了 missing authentication，没有列出具体是哪些路由，这一块我没查到。

拆开看，错在装配那一层

把这类后端拆成三层看会更清楚。最上面是路由层，决定哪个 URL 交给哪个函数。中间是认证层，决定这次请求带没带合法的身份。最下面是业务层，真正读写数据的地方。

CWE-306 的定义是关键功能缺失认证，CWE-287 是不当认证。两个都指向同一件事，门在，但没锁，或者锁装了但钥匙孔是通的。

在 FastAPI 这类框架里，认证通常做成依赖，挂在路由或者整个应用上。写法大致是给每个需要保护的路由加一个依赖声明，或者在应用初始化时统一注入。

如果旧后端的路由是一批一批加的，很容易出现某几个路由在加的时候忘了带依赖。这种遗漏在代码审查里极难被抓到，因为文件看起来完全正常，只是少了一个参数。

另一种可能是，迁移到 Tauri 的过程中，开发者把认证逻辑从后端挪到了前端，认为前端会拦住未登录用户。但前端拦的是界面，拦不住直接打接口的人。

到底是哪一种，公开信息没有披露。我只能说，从「unknown function」这个措辞看，NVD 的收录方也没有定位到具体函数，这个条目大概率是自动或者半自动生成的。

图 2　本文示意图：旧后端的三层结构，路由和业务都在，唯独认证这一层没有兜住。

先确认你装的是不是那个旧后端

这件事最容易被忽略的一步是，很多人根本不知道自己跑的是旧架构还是新架构。Meetily 同时存在 Tauri 桌面版和旧的 client-server 部署方式。

查本机旧后端（示意代码，确认机器上有没有在跑 Meetily 的旧后端进程）

#!/usr/bin/env bash
# 只做本地检查，不发起任何远程请求
set -u

echo "[1] 查找 main.py 相关进程"
ps aux | grep -E "backend/app/main\.py" | grep -v grep || echo "  未发现"

echo "[2] 查找监听中的 python 进程"
if command -v ss >/dev/null 2>&1; then
  ss -lntp 2>/dev/null | grep -i python || echo "  未发现"
elif command -v lsof >/dev/null 2>&1; then
  lsof -nP -iTCP -sTCP:LISTEN 2>/dev/null | grep -i python || echo "  未发现"
else
  echo "  ss 和 lsof 都不可用，请手动检查"
fi

echo "[3] 检查是否监听在 0.0.0.0"
ss -lnt 2>/dev/null | grep "0.0.0.0" || echo "  没有监听在 0.0.0.0 的条目"

如果你只是装了桌面客户端，没有单独起后端服务，那你大概率不在受影响面里。桌面版走的是本地进程，不对外监听端口。

如果你是按旧文档部署的，起了 backend 目录下的服务，那就要认真对待。先看进程和监听端口。

下面这条命令能帮你确认机器上有没有在跑这个后端。它只做本地检查，不碰任何远程目标。

如果输出里有 python 进程跑着 backend/app/main.py，或者有进程监听在常见后端端口上，那就要继续往下走。

这一步我没法替你确认，因为每个人的部署方式不一样。我只能说，先搞清楚自己跑的是哪个形态，比急着找补丁更重要。

今天能做的三件事，按顺序来

第一件，立刻做的，把旧后端的监听地址从 0.0.0.0 改成 127.0.0.1。这一条不依赖任何补丁，改的是启动参数或者配置文件。

收紧监听地址（示意代码，把旧后端从对外监听改为仅本地，破掉网络可达条件）

#!/usr/bin/env bash
# 改的是启动参数，不改代码
set -eu

# 原来常见写法，监听所有网卡
# uvicorn backend.app.main:app --host 0.0.0.0 --port 8000

# 改成只监听回环地址
uvicorn backend.app.main:app --host 127.0.0.1 --port 8000

# 如果必须对外，前面加一层带认证的反向代理
# 示例 Nginx 片段
# location / {
#     auth_basic "restricted";
#     auth_basic_user_file /etc/nginx/.htpasswd;
#     proxy_pass
# }

很多部署脚本默认写 0.0.0.0，图的是方便从别的机器访问。但这个方便在零认证的前提下就是敞开的门。改成只监听本地，外部就打不到了。

图 3　本文示意图：同样是零认证，公网暴露和内网自用是两件完全不同的事。

第二件，这周做的，如果旧后端必须对外提供服务，在前面加一层反向代理，把认证挡在代理层。Nginx 的 auth_basic 或者接一个 OAuth2 代理都行。

这不是根治，是过渡。但它能把 PR 为 N 这个条件破掉，攻击者至少要先过一道身份。

第三件，如果这两件都做不了，那就把旧后端停掉，只用 Tauri 桌面版。厂商的方向本来就是统一到 Tauri，旧后端迟早要下线，早停早安全。

我不建议等官方补丁。厂商说的是「正在迁移」，没有给时间表。等一个没有日期的修复，不如先把自己这侧的门关上。

同类项目里，这个坑长得很常见

这不是 Meetily 一家的问题。凡是经历过架构迁移的项目，旧代码都容易变成没人管的角落。新功能都往新架构上写，旧的那套只求别挂，没人再去看它的权限模型。

更麻烦的是，旧后端的文档往往还留在仓库里，新用户照着旧文档部署，就把一个本该下线的组件又拉起来了。

我见过的同类情况里，旧服务的认证缺失通常不是被删掉的，而是在某次重构里被绕过去的。比如认证从后端挪到网关，后端就默认「进来的请求都是可信的」。

一旦网关配置出错，或者有人绕过网关直接打后端端口，这层信任就塌了。这次 Meetily 的情况，从描述看很接近这个模式。

所以判断一个项目有没有这类风险，不要只看它最新版本的架构图，要去看仓库里还有没有能独立启动的旧服务。

这条经验对所有做过大版本重写的团队都成立。重写不是写完新的就结束了，删掉旧的是重写的一部分。

我没查到的那部分，得说清楚

第一，具体是哪些路由缺认证，公开信息没有列。NVD 写的是 unknown function，说明收录时也没有定位到函数级。

第二，PoC 的具体形态我没有看到。描述里说 exploit is publicly available，但我没有去复现，也没有验证它到底能读到什么数据。

第三，受影响版本写的是 up to 0.4.1，0.4.1 之后有没有修，公开信息没有明确说。厂商的表态是迁移，不是打补丁，所以很可能 0.4.2 也没有单独修这条。

第四，5.5 这个分数里的 CIA 都是 L，是基于什么假设打的，我没有查到评分方的说明。如果实际能读到的数据比预期敏感，这个分数可能偏低。

这些空白意味着，我上面关于「装配层漏挂认证」的判断是推断，不是事实。事实只有一条，旧后端还在，而且不需要认证就能远程访问。

如果后续 NVD 更新了条目，把具体路由或者修复版本补上，这篇里的推断部分需要重新对一遍。

旧代码不删，等于把门留在墙上

这件事真正值得记住的不是 5.5 这个分数，是一个团队在迁移架构时，把旧的那扇门留在了墙上，而且忘了锁。

新架构再好，只要旧服务还能被启动、还能被访问，攻击面就还在。安全不是看你最新的代码写得多干净，是看你最旧的那部分有没有被真正关掉。

所以今天该问自己的不是「我升级到最新版了吗」，是「我机器上还有没有那个本该下线的服务在跑」。

去查一下，比看十篇分析都管用。

写在最后

一个团队把架构从 client-server 迁到 Tauri，技术上是对的，但只要旧服务还能被拉起来、还能被外面摸到，这次迁移在安全上就还没完成。删掉旧代码和写好新代码，是同一件事的两半。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。