PHP 高危漏洞发布后，观测 Agent Teams 如何自主排查应用风险？

“PHP 出现高危漏洞，我们的哪些业务系统需要处理？”这次，我们向观测云 Agent Team 提交了一份漏洞检测提示词。随后，Agent 自主收集情报、关联应用数据并开展协作，最终给出了包含应用对象、判断依据和处理建议的审查报告。

高危漏洞发布后，我们的应用是否受影响？

2026 年 10 月 21 日，PHP 官方发布安全版本，修复 CVE-2026-109618、CVE-2026-109619 两个可能导致未认证远程代码执行的严重漏洞。这组被称为 PHP2Shell 的漏洞，让使用 PHP 的应用需要尽快核实运行版本与风险条件。查看 PHP 官方公告。

公告给出了受影响组件与修复版本，但企业还需要确认：这些组件运行在哪些服务中，对应哪些业务应用，哪些对象需要优先处理？应用能正常访问，也无法说明底层组件已经安全。要把公开漏洞与自身业务对应起来，需要从已有运行数据中发现相关应用，再核实版本与风险条件。

传统响应：从漏洞情报到业务应用，需要跨团队接力

传统漏洞响应需要多个团队协作。安全团队核实情报、提出排查要求，运维团队核查资产与运行环境、汇总相关应用，再由应用负责人评估业务影响、安排升级与修复，最后反馈结果并复核。

这条流程中的每一次交接，都需要把漏洞条件、环境事实和业务信息对应起来。情报中的组件名称，如何关联到实际服务？记录中的版本是否就是当前运行版本？相关应用部署在哪里，又该由谁跟进？这些问题需要各团队查询数据、核对证据，并将判断传递给下一环节。

这次，我们尝试把情报核实与应用调查交给 Agent Team，由 Agent 在已有数据和授权范围内自主推进，向我们交付可继续跟进的结果。

Agent Team 响应：给出目标，自主完成调查

观测云 Agent Team 支持按业务职责创建专属 Agent，为其配置知识、工具和访问权限，并连接业务环境与观测云数据。在漏洞排查场景中，Agent 可以根据任务目标检索情报、查询环境数据，并与其他 Agent 协作完成调查。

准备：创建漏洞情报 Agent，明确职责

创建漏洞情报 Agent 时，我们为它定义的职责是：持续跟踪公开漏洞与原厂公告，核实信息来源，整理受影响产品、版本范围、利用条件和修复建议，并将确认的情报交给应用安全审查 Agent。

角色定义明确了它负责什么。实际执行时，我们向 Agent 提交检测目标、工作空间、时间范围和调查边界，具体的信息检索、任务拆解与协作由 Agent 自主开展。

执行：提交提示词，Agent 自主调查与协作

我们只指定工作空间、检测目标、时间范围和只读边界，未预先提供具体应用清单。Agent 需要自主检索漏洞情报，并从工作空间已有的可观测数据中发现相关应用、核实风险。我们提交的运行时提示词如下：

检查“观测云演示Demo”工作空间中的应用是否受到近期公开漏洞影响。

1. 获取最近7天新增或更新的漏洞情报，优先关注高危漏洞、已知被利用漏洞及常见应用框架和中间件漏洞。
2. 核实官方来源，整理受影响产品、版本范围、利用条件及修复措施。
3. 利用工作空间现有观测数据筛选相关应用，核实版本与利用条件，分析暴露面和业务影响。
4. 在数据保留范围内检查最近7天的相关攻击线索。
5. 按风险优先级输出审查报告，包含情报来源、检查范围、相关资产、判断依据、待确认项、数据缺口和处理建议。

仅执行只读调查。数据不足时标记为待确认，不将未查到记录视为没有风险。

收到任务后，Agent 自主获取最近 7 天的公开漏洞情报、核实信息来源，并结合工作空间已有的可观测数据开展关联分析。漏洞情报 Agent 与应用安全审查 Agent 自行完成信息交接和调查，从情报、资产与运行数据的关联中发现相关漏洞及应用，并继续核实适用条件。

结果：哪些应用需要关注，判断依据是什么

在漏洞情报与工作空间数据的自主关联中，应用安全审查 Agent 从调用链的运行时属性识别出 PHP 8.3.35，并结合情报中的版本范围核实风险。它继续关联服务名称与命名空间，发现了两个需要进一步核实和处理的应用：

Agent 输出的报告汇总了情报来源、检查范围、相关资产、判断依据、待确认项、数据缺口和处理建议，并将版本风险、利用条件与攻击线索分别记录。这份报告为我们安排配置核验、入口检查与升级提供了依据。

通过任务洞察，我们还可以回查 Agent 间的任务交接、执行进展以及形成的证据与结论。自主调查的过程与最终报告保持关联，方便围绕待确认项继续追问。

数据支撑：Agent 如何利用已有可观测数据

回看 Agent 发现应用的过程，关键证据来自工作空间已有的可观测数据：链路里的运行时版本帮助它匹配受影响组件，服务与部署信息帮助它定位业务应用，日志与链路的关联则为继续调查请求和异常线索提供入口。PHP 与 WordPress 是 Agent 关联这些数据后识别出的排查对象。

应用链路： 记录服务、请求路径、运行时版本及调用关系。Agent 从中识别底层组件，再将组件风险关联到业务应用。WordPress 生命周期与数据库调用，也为理解应用的实际执行过程提供上下文。

应用日志： 提供请求、错误与事件记录，并通过 Trace ID 与同一请求的链路关联。Agent 可以围绕目标应用和时间范围检查异常线索；请求体等未采集信息则需要作为数据缺口保留。

资产与容器数据： 提供服务、进程、镜像、集群和命名空间等环境信息，用于确定应用部署位置、核对运行环境。结合可用配置与入口信息，还能继续核验漏洞适用条件和暴露路径。

应用与资源指标： 请求量、错误率、响应时间及资源状态，可为评估运行影响和后续变更提供参考。指标正常时，仍需依据版本、配置与其他证据判断漏洞风险。

不同应用的数据通过服务、资源和请求标识关联起来，Agent 才能从一条公开漏洞情报，追查到某个集群中的具体应用，并说明判断来自哪里、哪些条件仍需确认。

Agent Team + 可观测数据底座，让安全响应有据可依

Agent Team 将检测目标转化为调查行动。 在这次实践中，我们提交一份提示词，Agent 自主完成情报检索、任务协作和数据查询，最终输出审查报告。人员可以从报告中的具体对象和待确认项继续处理，调查过程也有记录可回查。

可观测数据底座为调查提供环境事实。 链路中的版本、日志中的请求、资产中的部署关系，让 Agent 的判断能够对应到我们的应用。数据的覆盖范围、关联程度和保留时间，也决定了哪些问题可以直接回答，哪些需要继续取证。

对企业而言，可以从已经接入观测云的一项关键业务开始：完善应用链路、日志、资产与指标的采集，在提示词中明确目标和只读边界，让 Agent Team 围绕现有数据完成一次漏洞影响审查。随着更多应用和技术栈接入，再将这条路径扩展为持续的情报跟踪与风险复核。

当 Agent 的自主协作能力与可观测数据底座结合，漏洞响应就有了从公开情报到业务现场的调查路径，也为后续安全处理提供了可追溯的依据。

了解观测云 Agent Team，探索基于现有可观测数据的安全排查实践。