AI辅助WAF拦住了攻击,BIG-IP自身却也有暴露面: F5谈PHP2Shell的边界与残余风险
10月下旬,两个被合称为PHP2Shell的严重漏洞(CVE-2026-109618和CVE-2026-109619)引发全球性应急响应。漏洞存在于PHP引擎本身,而非某个应用或框架,意味着即便网站代码毫无问题,只要PHP运行时版本受影响,服务器就暴露在未经认证的远程代码执行风险之下。英国32项政府服务被迫下线,德国、法国、比利时、荷兰等多国政府网站采取预防性断网措施。PHP项目于10月21日发布修复版本,但亚马逊的遥测数据显示,漏洞探测活动在补丁发布前四天就已开始。
F5在10月22日发布博客,说明了其WAF在专用签名缺位时的实际拦截机制:现有的PHP对象序列化注入签名首先标记了PHP2Shell式请求,随后AI风险评分将该请求评为95/100的严重风险,使WAF能够在阻止模式下执行拦截,而非停留在告警。与此同时,F5同步更新了安全公告K000163821,确认BIG-IP的APM数据平面存在可被远程未认证攻击者利用的风险,而控制平面(TMUI) 则需要认证。作为以“应用交付与安全平台(ADSP)”为核心,致力于保护、交付、优化任何应用和API的科技厂商,F5为企业应用与API提供了一致的交付和安全能力。当“交付”所依赖的设备自身也出现在受影响清单中时,平台承诺的一致性与边界如何被理解,就成了比“WAF是否拦截”更基础的问题。带着问题,IT168采访了F5亚太区首席技术官Mohan Veloo。
F5亚太区首席技术官Mohan Veloo
1. F5称AI WAF已提前拦截PHP2Shell变种,但BIG-IP自身TMUI/APM也被列入受影响范围。WAF保护和产品自身暴露面的边界怎么界定?
Mohan Veloo:客户应将应用防护与基础设施安全视为相辅相成的两项责任。
F5 AI 赋能的 WAF 能够帮助识别并拦截恶意应用请求。结合安全特征库和安全策略,这一能力可以支持虚拟补丁,在受影响软件完成更新之前降低风险暴露。但这种防护仅适用于相关安全策略所检查的流量,并不会自动覆盖基础设施中的所有组件。
我的建议是从两个方面进行验证:一是确认应用流量确实经过有效的 WAF 防护;二是针对受影响的基础设施,及时应用官方建议的更新。虚拟补丁与软件修复应协同发挥作用。
2. PHP官方称“无完整缓解措施,升级是唯一安全选择”,而BIG-IP hotfix尚未普遍可用。F5如何评估当前缓解方案的残余风险?
Mohan Veloo:首先分享一个重要更新:F5 已发布针对 PHP2Shell 两个漏洞的关键安全更新。建议客户尽快部署适用的更新。
在安装更新之前,残余风险取决于受影响的组件、这些组件的可访问性,以及现有安全控制措施。客户应识别暴露于攻击风险中的系统,限制不必要的访问,并落实已公布的缓解措施。
在此期间,虚拟补丁可以提供额外的防护,但无法修复存在漏洞的软件。我建议客户为每一项临时缓解措施明确指定负责人,并设定清晰的修复期限。我们的目标是立即降低风险暴露,并尽快完成更新。
F5 的关键安全更新会全面整合安全补丁。对于高度定制化的部署环境,我们建议客户直接与 F5 技术支持团队沟通,确保更新方案与其具体的部署架构相匹配。
3. AI既降低了漏洞利用门槛,也被F5用作防御卖点。如何避免客户把“AI已拦截”误解为“无需紧急修复”?
Mohan Veloo:阻止攻击并不意味着底层漏洞已经被修复。
F5 AI 赋能的WAF 能够帮助识别恶意请求,包括我们研究中测试的 PHP2Shell 攻击变体。这一点尤为重要,因为现代威胁正在利用 AI 快速调整攻击手法,并将已知漏洞利用方式规模化应用于不同环境,从而规避传统静态特征检测。
对于安全团队而言,这能够在漏洞修复窗口期提供额外一层防护。但其实际防护效果取决于相关流量是否经过 WAF,以及相应的防护能力是否已启用并真正执行安全策略。同时,能够阻止已测试的攻击变体,并不意味着可以防御所有可能的攻击方式。
我们的建议是,将虚拟补丁作为紧急修复计划的补充措施。企业应验证相关安全控制是否有效运行,明确更新工作的负责人,并持续跟进直至更新完成。成功阻止攻击应当为修复计划争取时间和提供支持,而不应成为延迟修复的理由。
4. BIG-IP的TMUI和APM受影响后,PHP2Shell在BIG-IP上的利用是否需要先认证?未认证攻击面是否可达?
Mohan Veloo:管理界面与应用访问服务之间的区别非常重要。F5 发布的安全公告指出,配置实用程序所在的控制平面存在需要身份认证才能触及的风险,而受影响的 APM 数据平面则可能存在无需身份认证即可利用的风险。
因此,如果受影响的 APM 服务可从互联网直接访问,就可能形成一个无需身份验证的攻击面。客户应根据自身实际使用的软件版本、配置情况和网络暴露范围进行评估,而不能仅仅因为存在登录界面,就认为其背后的所有功能都已得到保护。
我们的建议是,首先将管理界面的访问权限限制在可信网络范围内,同时根据 F5 发布的安全公告,单独审查受影响的 APM 服务。针对这两个方面,都应采取相应的缓解措施,并尽快完成相关软件更新。
5. F5博客的拦截证据主要来自Distributed Cloud WAF。BIG-IP Advanced WAF和NGINX App Protect客户能否获得同等覆盖?签名发布节奏是否有差异?
Mohan Veloo:F5 已针对旗下 WAF 产品组合发布防护指南和攻击防护安全更新。尽管详细展示 AI 拦截能力的演示主要基于 F5分布式云WAF(Distributed Cloud WAF),但使用 F5 Advanced WAF 和 NGINX App Protect 的客户同样能够获得针对各自平台设计的强大防护能力,旨在实现同等的防护效果。
虚拟补丁可以通过安全特征库、安全策略,以及在具备相应能力的情况下通过 AI 驱动的检测机制来实现。客户应确认自身所使用的产品及其具体配置适用哪些防护措施。
在实际操作中,首要任务是确认所需的安全更新已安装、相关安全特征已启用,且安全策略正在执行拦截操作。同时,还必须确保流量经过这些防护机制。
关于各项更新的发布时间和可用性,客户应以 F5 官方安全公告及其中链接的各产品防护指南为准。需要注意的是,不应假定相关攻击特征会在所有平台上同步提供。
6. hotfix发布前,F5是否建议互联网暴露的BIG-IP客户优先撤下或隔离TMUI/APM管理面?hotfix预计时间窗口和版本优先级如何?
Mohan Veloo:目前相关修复版本已经发布,因此客户应尽快选择并部署适用于自身环境的更新。已发布的版本包括BIG-IP 17.1.3.7、17.5.1.11 和 21.1.0.4,以及 BIG-IP Next for Kubernetes 2.4.2。客户应根据自身使用的产品及所处的受支持版本分支,遵循相应的更新指南。
对于管理界面,应仅允许可信用户和设备通过安全网络进行访问。对于 APM 应用访问服务,则需要单独进行风险评估,因为这些服务本身可能需要面向外部用户开放。因此,仅隔离管理访问并不能覆盖所有受影响的部署场景。此外,企业还应评估临时缓解措施可能带来的业务影响,因为重启某些访问服务可能会暂时影响新的用户会话或身份验证流程。
从风险优先级来看,我们建议首先处理可从不受信任网络访问的受影响服务。如果无法立即完成更新,应及时采取 F5 已发布的缓解措施,并将可能出现的服务中断纳入实施计划。对于具体环境应采取哪些措施,客户也可以联系 F5 Support,进一步确认适合自身部署环境的修复和缓解方案。
7. PHP2Shell是否在推动一种预期转变:客户是否有权要求安全设备厂商在公告中不仅列出“是否受影响”,还要披露管理面PHP的版本、ASLR状态和补丁可验证性?
Mohan Veloo:客户需要获得足够的信息,以便评估自身风险暴露、采取相应措施,并验证漏洞是否已完成修复。这些信息应包括受影响的版本和组件、身份验证要求、可用的修复方案,以及临时缓解措施的适用范围和局限性。
组件版本和安全加固信息可以帮助客户进行风险评估,但必须结合具体环境来判断。例如,某个系统可能包含用于内部流程的旧版软件组件,但如果该组件与 Web 管理界面完全隔离,且无法通过网络访问,那么它实际上不存在可被利用的攻击面。因此,某个组件的存在本身并不意味着漏洞一定可被利用,同样,安全加固措施也不能替代对漏洞本身的修复。
我们的建议是聚焦几个具体的操作性问题:我的部署是否受到影响?攻击者实际能够访问哪些部分?我现在应该采取哪些措施?如何确认建议的更新已经成功应用?
独立验证可以进一步增强客户对修复效果的信心,但其验证范围和方法需要明确定义。对于 F5 的部署环境,应以 F5 发布的安全公告和相关产品指南作为判断和决策的主要依据;如果存在不明确之处,建议联系 F5 Support 进一步确认。
综合来看,F5做了一件对客户判断力有实际帮助的事:它没有用“AI已拦截”覆盖一切,而是在多个关键节点上主动限定了能力边界——WAF只覆盖流经策略的流量,拦截已测试变种不等于防御所有攻击方式,攻击特征不会在所有平台同步提供,仅隔离管理面也不能覆盖APM数据平面可能无需认证即可利用的场景。对于一个以“保护、交付、优化任何应用和API”为承诺的平台型厂商来说,这些限定不是自我削弱,而是把平台承诺还原为可操作、可验证的条件。尤其值得肯定的是,F5明确区分了控制平面与数据平面,确认了APM数据平面存在未认证利用的可能,也提示客户不应假定攻击特征会在所有平台上同步提供。在安全设备厂商普遍倾向于弱化自身暴露面的语境下,这种把边界说清楚的姿态,本身就是对客户知情权的一种尊重。