PHP曝两大漏洞:七成网站受威胁,WordPress等平台在列

PHP核心曝出两个高危漏洞,波及约七成网站,考验生态响应速度。
安全研究人员在PHP语言核心中发现两个高危漏洞,影响范围覆盖约七成使用PHP的网站。由于缺陷位于运行时层面而非某个框架或插件,WordPress、Drupal、Wikipedia、DeviantArt、4Chan等依赖PHP的平台均暴露在风险中,部分站点曾被迫临时下线。文章分析了PHP漏洞的放大效应:修补需要托管商、运维团队与开发者协同,链条长、惯性大,而大量中小站点甚至不清楚自己运行的具体版本。文章建议尽快核对PHP版本并升级至受支持分支,同时以WAF、最小权限配置和输入校验构建纵深防御,并将PHP版本管理纳入常规安全流程。
PHP,这门驱动了互联网近七成网站的后端语言,再次因为安全问题被推上风口浪尖。安全研究人员在PHP核心中发现了两个高危漏洞,波及范围之广,足以让半个互联网的管理员彻夜难眠。

漏洞概况:两个缺陷,一场风暴
据安全媒体披露,此次发现的漏洞存在于PHP语言本身,而非某个特定的框架或插件。这意味着任何运行受影响PHP版本的服务器都可能暴露在攻击面之下。PHP的普及程度决定了问题的严重性——WordPress、Drupal、Wikipedia,乃至DeviantArt和4Chan这类高流量社区,底层都依赖PHP运行。报道提到,DeviantArt和4Chan在漏洞披露后曾被迫临时下线,以评估和修补风险。
两个漏洞的具体技术细节在原始信源中着墨不多,但从“让大片互联网陷入危险”的定性来看,其利用门槛和潜在影响都不容小觑。对于依赖PHP构建业务的企业而言,这不是一次可以观望的预警。
什么是“PHP核心漏洞”
PHP作为解释型语言,其执行环境由Zend引擎、标准库和各类内置扩展组成,这套运行时整体被称为PHP核心。核心层面的漏洞与WordPress插件漏洞有本质区别:后者只影响安装了特定插件的站点,而前者一旦被触发,任何调用相关函数的PHP应用都可能受影响,攻击者甚至无需接触业务代码。
常见的高危类型包括内存越界、释放后使用(use-after-free)和整数溢出,它们多由C语言实现细节引起,可导致远程代码执行或信息泄露。由于PHP以模块形式嵌入Apache、Nginx+FPM等不同运行模式,同一漏洞在不同部署下的可利用性也存在差异。这也是评估影响面时必须结合实际托管环境判断的原因。
为什么PHP的漏洞总是“牵一发而动全身”
PHP的生态位决定了它的安全事件具有放大效应。它不是小众技术栈,而是共享主机、CMS系统和老牌Web应用的默认选择。一个PHP运行时层面的缺陷,会沿着依赖链向下传导,最终影响到数百万个彼此无关的网站。
这种结构性风险有两层含义。第一层是修补速度:PHP版本的升级往往需要托管商、运维团队和应用开发者协同,链条长、惯性大,漏洞窗口期可能被拉得很长。第二层是可见性:大量中小站点由非专业团队维护,他们甚至不知道自己跑的是哪个PHP小版本,也就无从判断是否暴露。
PHP版本碎片化与生命周期
PHP社区采用分支化维护策略:每个主版本(如8.1、8.2、8.3)获得约两年的主动支持,随后进入仅修安全问题的阶段,最终停止维护(EOL)。一旦分支EOL,官方不再发布补丁,继续使用该版本的站点在遇到新漏洞时将没有任何官方修复可用。
问题在于,共享主机商和发行版仓库常常长期停留在旧分支以保持兼容性,导致大量站点运行着已停止支持的PHP。漏洞披露时,这些站点既拿不到补丁,也难以在短时间内完成跨版本迁移,因为旧代码可能依赖已被移除的函数或行为。这种版本碎片化正是修补窗口被拉长的结构性原因。“确认小版本号”之所以重要,正是因为安全修复通常只回补到仍受支持的分支。
对开发者和站点运营者的现实提醒
从这次事件可以提炼出几条可操作的防线。其一,尽快确认生产环境使用的PHP版本,并对照官方安全公告判断是否受影响。其二,优先通过包管理器或官方渠道升级,避免使用已停止维护的分支。其三,对于使用WordPress、Drupal等CMS的站点,关注上游的安全通告,因为CMS厂商通常会跟进发布兼容性指引。
另一条常被忽视的路径是运行时隔离。即便无法立刻升级PHP版本,也可以通过Web应用防火墙、最小权限配置和输入校验层来压缩攻击面。安全从来不是单一动作,而是一组纵深防御的组合。
WAF与最小权限为何能“争取时间”
Web应用防火墙(WAF)在请求到达PHP运行时之前进行规则匹配,可以拦截已知的攻击特征,例如恶意的请求参数或异常的序列化载荷。它无法修复底层缺陷,但能在官方补丁尚未部署时降低被利用的概率。
最小权限配置的作用同理:以非root用户运行PHP-FPM、通过open_basedir限制文件访问范围、关闭不必要的危险函数(如eval、system),可以显著压缩漏洞成功利用后的影响半径。输入校验层则从应用侧减少不可信数据进入敏感函数的机会。三者叠加形成纵深防御:WAF挡在入口,权限限制兜住后果,输入校验减少触发面。需要强调的是,这些都是缓解措施,升级到受支持版本仍是根本解法。
开源基础设施的安全悖论
PHP的处境折射出开源基础设施的普遍困境:使用越广泛,越容易被攻击者盯上,但维护资源却未必与用户规模匹配。PHP支撑着互联网的相当一部分骨架,其安全投入的回报是公共品性质的,单个企业缺乏动力为全行业买单。
这次的两个漏洞不会是最后一次。对技术决策者来说,把PHP版本管理纳入常规的安全卫生流程,比在每次危机中应急更有价值。三个字母的PHP,考验的其实是整个生态的响应速度和协作意愿。
相关推荐

64G内存笔记本跑大模型,实际可用仅46.7G
华硕ProArt创16实测:64G内存标称值下模型可用仅46.7G,128G版官方上限1200亿参数。本文拆解9000元内存差价、统一内存占用真相、续航表现,并给出三步自查方法,帮你判断本地跑大模型该买多大内存。

Ollama零基础教程:本地部署大模型入门指南
Ollama零基础入门教程:了解Ollama是什么、核心特点与本地部署大模型的价值。涵盖开源免费、跨平台、CPU/GPU调度、API集成等关键信息,助你快速上手本地大模型管理工具。

LangGraph 实战:开发者真实工作流与技术栈剖析
从 Reddit 开发者提问切入,剖析 LangGraph 在实际生产中的工作流设计、技术栈组合、图结构模式与调试痛点,总结从教程走向落地的关键实践与可观测性需求。