跳过导航
返回列表
2026/10/29

PHP 严重漏洞“PHP2shell”公开一周：利用情况、各国应对与遗留问题（2026年10月后续报道）

PHP の重大脆弱性「PHP2shell」公開から1週間：悪用状況・各国の対応・残る課題（2026年10月続報）

PHP 的 CVE-2026-109618/109619（俗称“PHP2shell”）公开已满一周。本文整理了美国 CISA 将其列入“已确认被利用的漏洞”、第3个漏洞 CVE-2026-115560（尚未修复）、修复版中发现的缺陷，以及日本和各国公共机构与服务商的应对，并说明现在应确认的事项和排查入侵痕迹的方法。

分享

要点

  • 美国 CISA 于10月26日（美国时间）将两个 CVE 列入 KEV（已确认被利用的漏洞）。部分产品的管理界面也已遭利用，但截至10月29日，尚无被入侵组织的名称公开
  • 第3个漏洞 CVE-2026-115560 在最新版中仍未修复。在下一次定期发布之前，请设置 session.upload_progress.enabled=0（已设置的请保留）
  • 修复版 8.4.27 / 8.5.12 存在 SimpleXML 崩溃等缺陷。SimpleXML 的修复预计纳入下一个版本（发布日期未定）。请避免回退版本
  • 多国机构建议“无法升级就停用、隔离”。日本国内也有地方政府和企业暂停了网站，主要虚拟主机服务商大多已完成修复，包括旧版本
  • 攻击尝试早在公开前的10月17日就已被观测到。即使已经升级，也请检查10月17日以来的日志、文件和进程

关于本文

本文是10月22日发布的“2026年10月 PHP・Node.js・Go 安全修复汇总”的后续报道。漏洞原理、修复版本以及按系统和环境分列的升级步骤，请参阅该文。

本文核对了从2026年10月21日公开到10月29日（日本时间）为止，PHP 项目、各国公共机构、操作系统厂商、安全公司、研究人员和大学、主机服务商和产品厂商自己发布的信息，整理了这一周里弄清了什么、发生了哪些变化。仅见于媒体报道、无法核实的信息未予收录。

事态仍在发展。标有“截至某日”的项目，动手前请通过文末的官方链接确认最新情况。

这一周的经过

日期方面，日本机构采用日本时间，海外机构按发布方的标注（美国时间或 UTC）。

  • 10月17日：Amazon 的诱饵环境（蜜罐）在漏洞公开前就观测到了疑似针对该漏洞的流量（Amazon 于10月21日公布）
  • 10月20日（UTC）：CVE 编号连同错误的评分（CVSS 10.0）被提前传出，PHP 提前发布了预告，并将发布时间从22日改为21日。欧盟的 CERT-EU 在修复发布前就发出了安全提醒
  • 10月21日（日本时间晚间）：PHP 发布 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。Cloudflare 等 WAF 服务商在发布前约7〜9个小时就已启用防护规则
  • 10月22日：JPCERT/CC、IPA、JVN 发出安全提醒。中国的 CNCERT 也发出提醒，韩国上调了民间网络危机预警级别。日本国内各虚拟主机服务商进行紧急维护
  • 10月23日：PHP 公告第3个漏洞 CVE-2026-115560（尚无修复版）。美国 FBI 也发布了安全提醒
  • 10月24日（UTC）：研究人员公开的诱饵环境数据中，确认了疑似利用该漏洞的代码执行
  • 10月26日（美国时间）：美国 CISA 将这两个 CVE 列入 KEV（已确认被利用漏洞目录）。JPCERT/CC 更新了安全提醒
  • 10月28〜29日：GreyNoise 的诱饵环境中也确认了代码执行。各产品厂商的修复版仍在陆续发布

利用情况：已经确认到什么程度

美国 CISA 将其列入“已确认被利用的漏洞”

  • 美国 CISA 于10月26日（美国时间）将 CVE-2026-109618 和 CVE-2026-109619 列入 KEV 目录。KEV 只收录有实际被利用证据的漏洞。CISA 要求美国联邦政府机构在10月29日前完成处置，并确认是否遭到入侵（取证调查）。是否被用于勒索软件标为“未知”
  • CISA 的安全提醒要求“无法立即升级，或在使用 PHP 8.1 及更早版本时，在修复之前让使用 PHP 的系统下线”，并指出 WAF 只是临时防护。CISA 还公开了检测规则（SIGMA）
  • 美国 NVD 于10月22日（UTC）将 CVE-2026-109619 的 CVSS v3.1 评分从 9.8 下调至 8.1。CVE-2026-109618 仍为 9.8。PHP 自己的评分（CVSS v4.0 9.2）没有变化

诱饵环境中确认代码执行，攻击工具四处流传

  • 研究人员公开的诱饵环境数据显示，10月24日（UTC，日本时间为25日凌晨）在3台诱饵服务器上，Apache 进程直接启动了35次 shell。环境为 PHP 8.4.26、Apache + mod_php。报告者本人也表示，该环境是为便于攻击成功而特意配置的
  • GreyNoise 称，10月28日至29日，在来自德国同一个 IP 地址的攻击中，确认了5例诱饵服务器执行 OS 命令的情况（截至日本时间10月29日 13:44）
  • 据荷兰代尔夫特理工大学的观测，攻击中使用的程序包括 Mirai 系 DDoS 僵尸程序和用 Nim 语言编写的后门
  • 大量未经验证能否运行的攻击代码（PoC）被发布到 GitHub 等处。VulnCheck 称其中只有极少数是真的。韩国 KISA 指出，流传的“攻击测试代码”中有不少被植入了恶意软件，呼吁不要运行未经验证的代码
  • 另一方面，Sansec 介绍了研究人员“公开的 PoC 大多对标准配置的 PHP 无效”的分析，认为大规模利用的可能性低于最初预期。VulnCheck 则称已自行编写出在默认设置的 mod_php 上对多个版本有效的攻击代码。攻击能否成功，很大程度上取决于版本、配置和内存布局

被撤回的报告，以及尚未确认的事项

  • Sophos 于10月22日（UTC）宣布“确认1起攻击成功”，但当天就更正为“只是扫描，没有入侵证据”。Palo Alto Networks 的 Unit 42 也在25日（美国时间）以“无法确认与该 CVE 有关”为由，撤回了10月23日（美国时间）补充的、将针对欧洲某政府机构的攻击与 PHP2shell 关联起来的内容
  • 截至10月29日，在一手资料中未能确认有任何实际被 PHP2shell 入侵的组织名称。CrowdSec 也称，截至10月25日公开确认的入侵为“0起”
  • 不过，Palo Alto Networks 称观测到了针对自家产品（PAN-OS）暴露在互联网上的管理界面的利用（见后文）

观测到的攻击流量规模

  • GreyNoise：10月21日至29日，来自 417 个 IP 地址约24万次访问（其中攻击尝试约21万次）
  • 代尔夫特理工大学：来自 73 个国家、664 个 IP 地址约7.3万次攻击请求。峰值为10月26日 23:00（日本时间）这一小时，共8,179次
  • Fastly：从公开前的10月21日 12:59（日本时间）到22日晚间（日本时间，UTC 为22日中午），名为“PHP2shell”的工具发出约25万次请求。约三分之一自称是防御方的检测
  • WP Engine 称24小时内用 WAF 拦截了100万次以上的相关请求，未确认有攻击成功
  • 据 Censys，互联网上运行 PHP 的主机约有418万台（截至10月23日。不区分是否已修复）

各国家和地区公共机构的应对

日本

  • JPCERT/CC（JPCERT-AT-2026-0033，10月22日发布、26日更新）：表示收到多起攻击尝试流量的报告，同时指出代码执行能否成功取决于版本、环境和内存布局。26日的更新中加入了 CVE-2026-115560 及缓解措施。作为痕迹线索，列出了异常的 PHPSESSID、可疑 multipart/form-data 请求之后的内存上限错误或 HTTP 500、PHP 工作进程意外异常退出或重启，并指出即使没有确认到痕迹，也“不能断定没有遭到攻击”
  • IPA（10月22日发布、27日更新）：补充了 CISA 列入 KEV 的信息。表示尚未掌握日本国内的攻击受害案例。要求无法升级时采取临时措施或访问限制，如果仍有困难，则考虑切断外部连接或停止服务
  • JVN（JVNVU#99905564，10月28日更新）：刊载了日本国内厂商的情况。Soliton Systems（ソリトンシステムズ）和 FFRI Security（FFRI セキュリティ）表示“有受影响的产品”
  • 地方政府：滋贺县154个系统中有13个（其中县立学校6个）截至10月26日中午仍处于停用状态；东京都港区从10月21日深夜起停用了官网的部分功能，截至28日已恢复一部分。大阪市也停用了部分服务，福冈县已于23日恢复县官网全部停用的功能（各部门自行管理的部分网站仍在处理中）。港区、大阪市和福冈县表示未发现非法访问或信息泄露等受害
  • 企业：软银（SoftBank）为进行紧急维护，暂停了部分面向企业的网站和服务。LINE WORKS 表示只有自家网站使用了 PHP，已于22日处理完毕

美国

  • CISA：除上述列入 KEV 和安全提醒外，还要求梳理包括嵌入式产品在内所有使用 PHP 的地方，优先处理暴露在互联网上的部分
  • FBI（PSA I-102326-PSA，10月23日）：要求无法立即升级时，在完成处置前让系统下线；如果已被入侵，则隔离系统、保全 Web 和 PHP 日志，并向 FBI 报告

欧洲

  • 欧盟：欧盟委员会、ENISA、CERT-EU、Europol 等于10月21日发表联合声明，呼吁与主机服务商合作排查和升级，并隔离无法升级的应用。CERT-EU（Security Advisory 2026-018）在修复发布前的10月20日就发布了第1版
  • 法国（CERT-FR）：在10月26日的更新中表示，观测到了针对特定 PHP 环境的攻击尝试
  • 德国（BSI）：警戒级别“3／橙色”。表示部分企业预防性地断开了系统，德国国内多个网站访问不畅。虽然没有关于受监管行业或联邦行政部门遭入侵的报告，但自动化的攻击尝试正在发生（10月22日第1.2版）
  • 英国（NCSC）：要求识别 PHP、升级、采用临时措施，无法立即处置时考虑下线，并检查是否遭入侵、有无后门
  • 荷兰：10月21日预防性地停用了政府门户 Overheid.nl、MijnOverheid.nl 以及公共身份认证 DigiD 的网站等。NCSC-NL 在 GitHub 上列出了内置 PHP 的产品的应对情况（截至10月28日共757个产品，其中“存在漏洞”218个、“已修复”144个、“调查中”354个）

亚太及其他

  • 韩国：科学技术信息通信部和 KISA 于10月22日中午将民间网络危机预警从“关注”上调为“注意”。KISA 给出了8项处置步骤，包括连同外包方、闲置服务器和测试环境在内全面排查，更换修复前已对外公开的服务器的数据库、API 和管理员认证信息，以及不要运行未经验证的 PoC 等
  • 中国：CNCERT 于10月22日发出安全提醒（CNTA-2026-0006），以 CNVD-2026-41674 / CNVD-2026-41675 将其定为“高危”。指出技术细节和 PoC 已广泛流传，要求确认 PHP 的使用情况并通过官方渠道升级
  • 香港（HKCERT）：将风险定为“极高”，并注明已被利用。10月27日的更新中加入了 F5、Citrix、Palo Alto Networks、QNAP、Cisco 等产品的信息
  • 新加坡（CSA）、印度（CERT-In）、加拿大（CCCS）、新西兰（NCSC）等也发出了安全提醒。对利用情况的表述因机构而异，加拿大根据公开信息称“正在被利用”，印度称“大规模利用”

服务商与产品厂商的应对

日本国内的虚拟主机

主要的共享虚拟主机大多已在10月22日至28日之间完成修复（部分旧套餐的旧版本不在修复范围内）。很多服务商还为已停止支持的旧版本（5.x〜8.1）自行打了修复，但显示的版本号不会改变（例：ConoHa WING 仍为 8.5.11）。即使 WordPress 的“站点健康”等处显示旧版本，也请通过服务商的公告确认是否已修复。

  • Xserver（エックスサーバー）：截至10月26日 6:20 已完成所有对象服务器的处理。8.2〜8.5 升级到修复版，5.1〜8.1 在不改变版本号的情况下打入修复。作为预防措施，从21日16时起停用了服务网站和管理面板，22日起陆续恢复（用户的网站和邮件一直正常运行）
  • Lolipop（ロリポップ）：8.2 及以上使用修复版，7.4〜8.1 使用 PHP 开发者提供的修复，5.3〜7.3 使用自行开发的修复，并在所有版本中禁用了 session.upload_progress。部分服务器从22日凌晨到午后停止了所有网站的显示。表示虽观测到疑似攻击的流量，但未发现非法访问
  • ConoHa WING、お名前.com レンタルサーバー：10月22日为所有版本（5.6.40〜8.5.11）打入修复。表示用户无需任何操作
  • さくらのレンタルサーバ：已完成控制面板中可选的所有版本的修复。用户自己安装的 PHP 需要用户自行处理
  • KAGOYA：截至10月28日已完成虚拟主机的升级。表示不建议继续用未修复的 PHP 运行网站
  • CPI：很多旧的共享和托管套餐中，修复前的版本“不在修复范围内”，建议在 php.ini 中采取临时措施或切换版本。还呼吁检查有无来历不明的 .php 文件或不认识的 CMS 管理员账号
  • mixhost：10月22日已完成所有版本（5.2〜8.5）的修复
  • VPS、云服务器等由用户自行管理操作系统的服务器，需要用户自己升级（Xserver、さくらの VPS、KAGOYA CLOUD VPS 等也作了同样说明）

海外的主机与云服务

  • 面向 WordPress 等的主机服务：WP Engine、Kinsta、GoDaddy、Hostinger、SiteGround、Automattic（WordPress.com 等）均表示已完成修复或防护。WP Engine 和 Kinsta 表示未确认有攻击成功。WordPress.org 表示无需升级 WordPress 本体（这是 PHP 一侧的问题）
  • AWS：Elastic Beanstalk 的 PHP 8.2〜8.5 平台已修复。Lightsail 发布了新的镜像（蓝图），但说明正在运行的实例需要迁移到新实例。Lambda 没有 AWS 托管的 PHP 运行时，自定义运行时或容器需由用户升级后重新部署。AWS WAF 面向 PHP 的规则组（AWSManagedRulesPHPRuleSet）已默认使用 2.4 版，但 AWS 自己也表示“它不能代替升级”
  • Microsoft Azure：App Service for Linux 的内置 PHP 中，仍在支持期内的版本（8.2〜8.5）已更新到修复版（Extended 通道最后更新；已停止支持的版本不修复）。App Service for Windows 的内置 PHP 已停止支持，没有修复计划。Marketplace 的 WordPress 中基于旧 Alpine 的镜像也不会修复，官方建议迁移到基于 Debian 的镜像
  • Google Cloud：App Engine 标准环境和开启了自动更新的 Cloud Run（含 Cloud Run functions）可能会自动修复（GCP-2026-070）。Apigee 表示只有用户自行运营的、基于 Drupal 的开发者门户受影响（GCP-2026-072）
  • OVHcloud：共享主机自动升级。裸金属服务器和 VPS 由用户自行升级

中国的云服务与服务器管理面板

  • 宝塔面板（BT Panel）：Linux 版和 Windows 版提供 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35，Linux 版还为已停止支持的版本发布了自行修复的版本（8.1.35、8.0.31、7.4.34、7.3.34、7.2.35、7.1.34、7.0.34）。5.4〜5.6 仍处于测试阶段。Windows 版的 8.1 及更早没有修复，只有通过设置实现的缓解措施。请先更新软件列表，升级 PHP 后再重启 PHP
  • Alibaba Cloud Linux：Alibaba Cloud Linux 2 为 php-5.4.16-48.2.al7、3 为 php-7.4.33-8.0.1.al8、4 为 php-8.3.36-1.alnx4 及以上为修复版。阿里云提醒，php -v 的结果可能与 PHP-FPM、mod_php 和容器中实际运行的 PHP 不同
  • 腾讯云、华为云：分别发出了安全提醒。腾讯云介绍了用自家 WAF、云防火墙和主机安全产品进行防护的方法，华为云介绍了用 WAF 和云防火墙进行防护的方法。华为云表示“已发现在野攻击利用”，但未给出细节

内置 PHP 的设备与产品

防火墙、VPN 设备、NAS 等的管理界面中有时内置了 PHP，升级服务器的操作系统或 PHP 修不了，需要厂商的修复版（固件等）。请查看各厂商的信息。

  • Palo Alto Networks（PAN-OS）：只有管理界面（Web UI 和 XML API，包括配置了管理配置文件的数据平面接口）受影响，并表示观测到了针对暴露在互联网上的管理界面的利用。修复版（hotfix）从10月25日起陆续发布，部分计划于10月29〜30日发布。GlobalProtect 和 Prisma Access 不受影响
  • Citrix NetScaler ADC / Gateway：在 CTX697263 中发布了修复版（14.1-73.49 及以上、13.1-64.32 及以上等）
  • Cisco：Expressway 在 15.5.21、Duo Access Gateway 在 3.2.0 中修复。表示未发现针对 Cisco 产品的利用
  • QNAP：在 QSA-26-18 中发布了 QTS 6.1.0.3656 / 5.2.11.3661 等。呼吁不要把 NAS 直接暴露在互联网上
  • Synology：在 Synology-SA-26:14 中发布了各 PHP 软件包的修复版（例：PHP 8.2 为 8.2.35-0171）。PHP 7.3 已停止支持，不会修复
  • Sophos：表示自家产品不受影响。但预防性地停用了使用受影响 PHP 的旧授权门户（MyUTM）
  • Docker：官方镜像和 Docker Hardened Images 已更新到修复版。用 FROM php:... 构建的自有镜像，不重新构建就仍是旧的

相对10月22日文章的更新（修复版的提供情况）

上一篇文章中标为“尚未提供”的项目，大多已经有了修复版。以下为截至10月29日的情况。

  • packages.sury.org（arm64）：8.2〜8.5 的 arm64 修复版（版本号含 20261021）已于10月26日（日本时间）前发布
  • Oracle Linux：OL9 的 php:8.2（ELSA-2026-87072）和 php:8.3（ELSA-2026-87079）、OL8 的 php:8.2（ELSA-2026-87073）和 php:7.4（ELSA-2026-87080）已发布。OL9 的 php:8.4 仍未提供
  • RHEL 9 的 php:8.4 模块：截至10月29日仍无修复版。请切换到已修复的 php:8.3 或 php:8.2 模块流（PHP 版本会改变，请事先测试），或采用 Red Hat RHSB-2026-013 中的临时措施
  • Red Hat 的追加修复：10月23日以后，陆续发布了面向 EUS、AUS 等长期支持版本的修复。RHEL 7（ELS）只受 CVE-2026-109619 影响，已在 php-5.4.16-48.el7_9.1 中修复
  • winget：PHP.PHP.8.4 和 NTS 版软件包也已更新到 8.4.27 等修复版
  • AWS Elastic Beanstalk：PHP 8.3 / 8.2 也已于10月22日在 AL2023 v4.13.13 中修复
  • SUSE / openSUSE：10月22日，SLES 15 SP5 / SP6（LTSS）、SLES 16.0、Leap 16.0 等也有了修复（例：SLES 16.0 和 Leap 16.0 为 php8 8.4.27-160000.1.1）
  • Fedora：F43（php 8.4.27-2.fc43）和 F45（php 8.5.12-1.fc45）也已进入稳定源
  • Alpine Linux：上一篇文章写了“v3.23 及更早不会修复”，但此后 v3.21〜v3.23 也加入了修复版（例：v3.23 的 php84 8.4.27-r0）。已停止支持的 v3.20 及更早不会修复
  • Debian（付费的 ELTS）：Debian 10 的 php7.3（ELA-1854-1）和 Debian 9 的 php7.0（ELA-1855-1）也有了修复
  • 仍然不会修复的：Amazon Linux 2 的标准 php 和 Amazon Linux 2023 的 php8.1 仍为“不计划修复”。需要迁移到 php8.2 或更新版本

新发现的问题

第3个漏洞 CVE-2026-115560（尚无修复版）

  • PHP 于10月23日公告，会话上传进度功能中还有另一个可能导致远程代码执行的问题（CVE-2026-115560）。10月21日的修复版（8.5.12 等最新版）中也没有修复
  • 触发条件有限：配置文件中把 session.serialize_handler 设为 php_binary 或 php_serialize，应用在 session_start() 之前用 ini_set() 切换为 php，并且启用了上传进度功能。PHP 自己也表示“不太可能发生”
  • 对策是把 session.upload_progress.enabled=0 写进 php.ini 或 FPM 进程池配置（php_admin_flag[session.upload_progress.enabled] = off），并重启所有 PHP 工作进程。这与上一篇文章中作为 CVE-2026-109619 临时措施介绍的设置相同，已经设置的话请保留、不要撤掉。PHP 表示将在下一次定期发布中提供修复和详细信息
  • 该设置会影响部分使用上传进度显示的应用。PHP 本体也已有将默认值改为禁用的提案（GH-24648）
  • 截至10月29日，该 CVE 的正式记录（cve.org 或 NVD）尚未公开
  • Cloudflare 表示现有 WAF 规则可以防御该 CVE，但把 session.upload_progress.name 改为非默认值的网站不在防护范围内

修复版中发现的缺陷（回归）

  • SimpleXML 崩溃（GH-24488）：在 8.4.27 和 8.5.12 中，用 get_object_vars()、(array) 强制转换或 json_encode() 读取过属性的 SimpleXML 对象在被垃圾回收释放时，PHP 可能异常退出（PHP-FPM 日志中出现 exited on signal 6 等）。原因是同一次发布中加入的另一项修复，而不是安全修复本身。修复预计纳入 8.4.28 / 8.5.13，但发布日期未定。WordPress 面向主机服务商的手册呼吁不要回退到修复前的版本，并指出 8.3.36 没有这个缺陷
  • 在内存上限处被强制终止（GH-24492）：触及安全修复中新加入的“硬内存上限”（默认为 memory_limit 的2倍）时，进程可能不会报出通常的“Allowed memory size”错误，而是以退出码137终止。8.2〜8.5 中均有报告，截至10月29日尚未解决。处理大量数据时，如果出现“Hard memory limit”消息或以退出码137中断，请怀疑是这个问题
  • 会话丢失（GH-24493）：有报告称在 8.5.12 中，上传进度处理会拒绝部分正常数据，导致整个会话被销毁（截至10月29日尚未解决）
  • 截至10月29日，PHP 尚未公布 8.5.13 / 8.4.28 的发布日期

Windows 版重新构建（Brotli）

  • PHP 于10月26日发布了用 Brotli 1.2.1 重新构建的 Windows 版 8.5.12-1 / 8.4.27-1 / 8.3.36-1 / 8.2.35-1。这是针对 Brotli 越界写入（CVE-2026-111497，即上一篇文章 Node.js 部分介绍过的漏洞）的处理
  • 只在启用了 cURL 的 HTTP 响应自动解压时受影响（默认禁用）。PHP 本体的版本号不变
  • 截至10月29日，winget 软件包指向的仍是重新构建前的 zip。如有需要，请直接从 php.net 的 Windows 版下载页获取
  • CISA 于10月27日（美国时间）将 CVE-2026-111497 也列入了 KEV

现在应确认和处置的事项

1. 修复是否真正生效

  • 请按上一篇文章的步骤，确认软件包版本和网页端实际运行的 PHP 版本，并确认已完全重启 Apache、重启 PHP-FPM。旧进程会一直跑着旧代码
  • 确认 session.upload_progress.enabled 已被禁用。命令行版可用 php -r 'var_dump(ini_get("session.upload_progress.enabled"));' 查看，但网页端可能是另一套设置，因此请放一个只允许管理员 IP 访问的临时脚本，输出 ini_get('session.upload_progress.enabled') 来确认，看完立刻删除
  • 梳理防火墙、VPN 设备、NAS、业务系统等内置 PHP 的产品，查看厂商的信息。NCSC-NL 的列表（见文末链接）也可作参考

2. 有无入侵痕迹（以10月17日以后为对象）

Amazon 鉴于发现了公开前的攻击尝试，建议至少把10月17日以后作为调查范围。以下以 Debian / Ubuntu 的路径为例（RHEL 系请把 apache2 换成 httpd；日志位置不同的，已在各项中一并注明）。

  • Web 服务器或 PHP 进程是否启动了 shell 或下载工具：用 ps -ef --forest 查看 apache2、httpd、php-fpm 下面有没有 sh、bash、curl、wget 等
  • 新建或被改写的 PHP 文件：sudo find /var/www -type f -name '*.php' -newermt 2026-10-17 -ls（网站目录在别处的话就换成那个位置）
  • 异常退出记录：sudo sh -c 'zgrep AH00051 /var/log/apache2/error.log*'（Apache 子进程异常退出。RHEL 系为 /var/log/httpd/error_log*）、sudo sh -c "zgrep 'exited on signal' /var/log/php8.4-fpm.log*"（PHP-FPM。版本号换成实际使用的，RHEL 系为 /var/log/php-fpm/error.log*）。日志会按天或按周轮转，因此要连同旧日志一起检查。不过，异常退出记录也可能由上述 SimpleXML 缺陷等攻击以外的原因产生
  • 可疑 multipart/form-data 请求之后是否紧跟着大量“Allowed memory size”错误或 HTTP 500（JPCERT/CC 列出的线索）
  • Web 服务器进程的连接：sudo ss -tnp | grep -E 'apache2|httpd|php-fpm'（访问本机 80 / 443 端口的连接属于正常浏览。除此之外，看有没有连向陌生地址的连接）
  • 不认识的文件或定时任务：sudo find /tmp /var/tmp /dev/shm -newermt 2026-10-17 -ls（Apache 等按 systemd 的设置会写入 /tmp/systemd-private-* 下，只用 ls /tmp 看不到。Sophos 举了 /tmp/nfs 作为痕迹的例子）、sudo crontab -u www-data -l（RHEL 系为 apache）
  • CMS 中有没有不认识的管理员账号
  • 即使没有发现痕迹，也不能断定没有遭到攻击（JPCERT/CC）

3. 怀疑已被入侵时

  • 把服务器从网络中隔离。KISA 建议为保留证据，不要重启，直接隔离
  • 保全 Web 服务器和 PHP 的日志，在日本请联系 JPCERT/CC，在其他国家请联系当地的 CERT 或执法机构
  • 修复前已暴露在互联网上的服务器，请更换数据库、API 密钥、管理员密码等认证信息（KISA）
  • 请不要用网上流传的攻击代码来测试“自己的服务器会不会被攻击”。已有报告指出其中被植入了恶意软件

4. 使用已停止支持的版本（8.1 及更早）时

  • PHP 项目没有为 8.1 及更早版本发布新版本，只以源码形式公开了面向 7.4 / 8.0 / 8.1 的最小修复。很多共享虚拟主机已自行打了修复，但 VPS 或自有服务器需要自己处理
  • 可以使用已修复软件包的选项有：packages.sury.org（Debian / Ubuntu，7.4〜8.1 也有修复）、Debian 付费的 ELTS、Ubuntu Pro（ESM）、宝塔面板的自行构建版等
  • 美国 CISA 要求使用 8.1 及更早版本时，在修复前让系统下线。根本办法是迁移到新版本。PHP 8.2 的安全支持将于2026年12月31日结束，因此 KISA 推荐 8.3 及以上

官方信息（一手资料）

免责声明

本文是 Two Sheep株式会社根据截至2026年10月29日的公开信息整理而成，不对任何产品的运行或安全性作出保证。动手前请务必查看各厂商的最新信息。文中提到的企业和机构只是为了说明相关动态而列举，并不表示与本公司有业务往来。文中出现的公司名和产品名均为各公司的商标或注册商标。

如果放在数据中心的服务器需要现场处理，例如重启、控制台操作、更换硬件，欢迎咨询我们的远程代维（Remote Hands）服务。

分享