一、同一来源地址，出现在两扇门外
假设你维护一套 Langflow：工作流需要调用模型，服务启动时从环境变量读取 API 密钥。你在代码仓库里查不到密钥，很自然会把这项检查打勾。接下来还有一个更贴近运行现场的问题：如果有人能让 Langflow 进程执行代码，这个进程能替他看到什么？
🔎 2026 年 11 月 5 日，微软披露，有攻击者用代理式工具在公开 GitHub 仓库寻找密钥，并用有效的应用凭据访问 Entra ID 等云资源。应用凭据就像服务自己的通行证；对方取得有效凭据后，能做什么取决于这个服务身份已经被授予哪些权限。微软从 10 月 28 日起观察到来自一个地址的成功服务身份登录。
三天后，VulnCheck 披露，同一来源地址在 11 月 7 日访问过它的 Langflow 诱捕器。诱捕器是专门放置的仿真目标，里面的凭据是诱饵。公开记录里的 Langflow 请求从 00:02 持续到 00:38（UTC），共 11 个阶段；报告中的 13 条不同请求还包括 11 月 2 日两条 PHP 探测，不能都算成 Langflow 攻击。
仓库扫描检查密钥有没有被公开；运行边界检查应用能把什么交出去。 两份报告能放在一起读，是因为它们有同一个来源地址和相似的凭据搜索目标。要做防守判断，可以先把两条路径拆开：
同一来源 IP 可以作为关联线索。仅凭它不能判定是同一操作者，也不能把诱捕器中拿到的测试数据接到微软看到的真实云端访问上。
二、为什么变量加密了，进程还是能把它读出来
Langflow 的代码校验接口原本用于验证工作流组件的 Python 代码。维护方公告确认，低于 1.3.0 的版本存在 CVE-2025-3248：远程请求在未认证时就能触发任意代码执行。危险的变化发生在 HTTP 请求进入校验逻辑后：外部输入开始以服务进程的权限运行。1.3.0 修复的是这个具体漏洞，排查生产版本时仍要核对后续安全公告。
诱捕器记录显示，请求先查进程环境、配置文件和本地数据库，接着按前一步发现的目录与表名缩小范围，后续再读日志、已保存的工作流和变量。部分结果被放进异常文本，由原来的 HTTP 响应带回。这条路径无需再向外部服务器建立连接，所以只找可疑的出站流量会漏掉这一段。
🔐 Langflow 用 Fernet 加密持久化变量。可把它想成一只上锁的抽屉：单独拿到数据库的人还差一把钥匙，但应用运行时必须能打开抽屉才能使用变量。研究者看到，来访请求先后尝试几种办法，最后把从诱饵环境拿到的密钥交给 Langflow 自己的密钥处理函数，读出了诱饵变量。磁盘上的密文能减少单份文件外泄的风险；同一进程同时能接触密文和解密材料时，要靠运行权限隔离。
把这个例子换成你自己的部署，可以用三次只读核对定位风险：
- 从反向代理、负载均衡和入口配置确认外部是否真的能到达校验路由。只看到后台首页要求登录，还不能说明所有 API 都走同一层认证。
- 对照正在运行的镜像或包版本与官方公告，再查进程可见的环境变量、挂载、持久卷和工作负载身份。记下密钥归属与权限范围即可，别把值抄进工单。
- 把每项身份对到下游：哪一把钥匙只能调用模型、哪一个身份还能读取存储或密钥库？前者可能表现为费用或配额异常，后者则需要把对应资源也纳入排查。
找到可达的受影响实例时，先限制入口并保全日志；不要在生产上发送执行代码的请求来证明它有问题。
三、从响应到云审计，怎样判断影响走到了哪一步
🎯校验接口只报了错，为什么还要看那段时间的云日志？
- 一串校验请求里，哪些痕迹能把「有人碰了接口」推进到「进程可能读过凭据」？
- 容器探测过云元数据地址之后，怎样用签发和登录记录核对它有没有跨到云端？
完整的取证顺序和轮换决策放在知识星球。
📚AI 文献解读：最前沿的 LLM 安全论文深度剖析。
🐛AI 漏洞情报：第一时间掌握主流大模型的 0-day 漏洞与越狱方式。
🛡AI 安全体系：从红队攻击到蓝队防御的全方位知识图谱。
🛠AI 攻防工具：红队专属的自动化测试与扫描工具箱。
🚀立即加入 Oxo AI Security 知识星球，掌握 AI 安全攻防核心能力！
