发布日期： 2026 年 10 月 23 日
关键词： PHP2Shell、CVE-2026-109618、CVE-2026-109619、阿里云 ECS、1Panel、Docker、Linux 安全
前言
2026 年 10 月 21 日，PHP 官方发布了一则严重安全公告，披露了两个可能导致未经身份验证的远程代码执行（RCE）的漏洞，分别为 CVE-2026-109618 和 CVE-2026-109619，合称为 PHP2Shell。
由于这两个漏洞的 CVSS v4.0 评分均达到 9.2，且涉及广泛使用的 PHP Web 运行环境，因此引起了我的关注。
值得注意的是，这次安全更新并不是按照原定时间发布的。由于漏洞信息提前泄露，PHP 官方将原定于 10 月 22 日的协调披露及补丁发布时间提前至 10 月 21 日。
我自己也有一台阿里云 ECS 服务器，上面安装了 1Panel 运维面板，并通过 Docker 运行着个人博客、数据库、反向代理和内网穿透等服务。
看到相关消息后，我首先想到的问题就是：
我的服务器是否也会受到这次漏洞的影响？
虽然我没有主动安装过 PHP，但考虑到服务器中存在 Web 服务以及 Docker 容器，仅凭印象并不能完全排除风险。
于是，我决定对自己的服务器进行一次简单的安全排查，并将整个过程记录下来。
需要说明的是，本次排查的主要目的是确认服务器是否存在 PHP2Shell 的直接受影响环境，并不是完整的漏洞扫描、渗透测试或入侵取证。
一、PHP2Shell 漏洞背景
1.1 漏洞基本信息
根据 PHP 官方公告，PHP2Shell 涉及两个严重漏洞：
两个漏洞均可能造成远程代码执行（Remote Code Execution，简称 RCE）。
简单来说，如果攻击者能够成功利用这些漏洞，就可能通过恶意网络请求，在存在漏洞的 PHP 服务中执行代码。
这类漏洞之所以危险，是因为成功利用不一定需要登录网站后台，也不一定需要获取管理员账号。
当然，存在受影响版本并不代表服务器已经被攻击，实际风险还与 PHP 的部署方式、网络可达性以及补丁状态有关。
1.2 漏洞披露与补丁发布时间线
此次漏洞的披露过程比较特殊。
按照最初的协调披露计划，PHP 官方原本准备在 2026 年 10 月 22 日 14:00 UTC（北京时间 22:00） 正式公开相关漏洞信息和修复版本。
但是，在预定披露时间之前，漏洞相关信息已经在互联网上流传，引起安全研究人员和厂商的关注。
为缩短漏洞信息已经外泄、但安全补丁尚未公开的风险窗口，PHP 官方决定将协调披露及补丁发布时间提前一天。
2026 年 10 月 21 日，北京时间 22:00 左右，PHP 官方开始陆续发布修复版本。
根据 PHP 官方公告以及官方发布邮件，可以整理出以下时间线：
需要说明的是，以上精确到秒的时间为 PHP 官方发布邮件所标注的发送时间，不一定等于补丁文件首次可供下载的时间。
从这次事件中可以看出，在高危漏洞信息提前泄露的情况下，安全补丁的发布时间也可能临时调整。
对于服务器管理员而言，及时关注软件官方安全公告非常重要，尤其是在出现未经身份验证的远程代码执行漏洞时。
官方资料：
1.3 哪些服务器可能受到影响？
PHP 官方指出，风险主要涉及处理 Web 请求的 PHP 运行环境，例如：
PHP-FPM
Apache mod_php
php-cgi
FrankenPHP
LiteSpeed 的 PHP 运行环境
这意味着，判断服务器是否受影响，不能仅仅查看服务器有没有安装 Nginx、Apache 或其他 Web 服务。
真正需要确认的是：
服务器是否正在使用存在漏洞的 PHP 运行时处理请求。
例如，Nginx 本身并不是 PHP 解释器，但它可以将请求转发到 PHP-FPM。如果 PHP-FPM 使用受影响的版本，网站仍可能面临风险。
1.4 官方修复版本
PHP 官方于 2026 年 10 月 21 日发布的安全修复版本如下：
需要注意，Ubuntu、Debian 等 Linux 发行版可能采用补丁回移（Backport）的方式修复漏洞。
例如，Ubuntu 24.04 LTS 官方公告中提供的已修复 PHP 8.3 软件包版本为：
8.3.6-0ubuntu0.24.04.13
因此，不能简单地因为 php -v 显示的版本低于 PHP 官方最低修复版本，就直接断言服务器存在漏洞。对于发行版提供的软件包，还需要核对其完整包版本和安全公告。
二、我的服务器环境
我的服务器部署在阿里云 ECS 上，主要使用 1Panel 进行日常管理。
目前的服务主要通过 Docker 容器运行。
根据 1Panel 应用列表和实际的 Docker 镜像信息，本次排查涉及以下组件：
服务器使用 Ubuntu 系列系统，软件包提示信息中出现了 Ubuntu 24.04 的版本标识，但本次没有通过 /etc/os-release 单独核实系统发行版本。
其中，Halo 基于 Java / Spring Boot，OpenResty 基于 Nginx 和 LuaJIT，而 MySQL 与 frps 也不属于 PHP 运行环境。
从现有服务架构来看，我的服务器似乎并不依赖 PHP。
不过，我仍然决定从宿主机、1Panel 运行环境以及 Docker 容器三个层面进行验证。
【图片 1：1Panel 应用列表截图】
建议在这里插入安装了 OpenResty、Halo、MySQL 和 frps 的 1Panel 页面截图。
三、第一步：检查宿主机是否安装 PHP
首先，通过 SSH 登录到阿里云 ECS 服务器。
3.1 查看 PHP 版本
执行：
php -v终端返回：
Command 'php' not found系统同时给出了通过 apt 安装 PHP 的相关提示。
这个结果说明，当前终端无法直接找到 php 命令。
但它并不等价于服务器完全没有 PHP。
原因是 php -v 通常调用的是 PHP 命令行解释器（PHP CLI）。
某些服务器即使没有安装 PHP CLI，也可能运行 PHP-FPM；此外，PHP 还有可能安装在 Docker 容器、独立目录或其他运行环境中。
因此，我没有立即得出结论，而是继续检查。
3.2 检查 PHP 配置
接着，我尝试执行：
php -i | grep session.upload_progress这条命令原本用于查看 PHP 配置信息中的 session.upload_progress 项。
然而，由于系统无法找到 php 命令，终端仍然返回：
Command 'php' not found这里需要补充说明：session.upload_progress 并不是此次 PHP2Shell 两个漏洞的完整检测条件，也不能通过该配置项是否启用来判断漏洞是否存在。
对于这次漏洞，更重要的是确认 PHP 运行环境和补丁状态。
3.3 检查 PHP 软件包
为了进一步确认宿主机是否通过 Ubuntu 软件包管理器安装了 PHP，执行：
dpkg -l | grep -Ei 'php|libapache2-mod-php'实际结果：没有输出。
这说明在当前软件包查询结果中，没有找到名称匹配的 PHP 相关软件包。
不过，这种方法只能检查 dpkg 所管理的软件包，无法覆盖源码编译安装或容器内部安装的软件。
3.4 检查 PHP 相关进程
接下来，查看系统中是否存在常见 PHP 服务进程：
ps aux | grep -Ei '[p]hp-fpm|[p]hp-cgi|[f]rankenphp|[l]sphp'实际结果：没有输出。
这个结果说明，在当时的进程列表中，没有发现匹配上述名称的常见 PHP 运行进程。
至此，宿主机层面的检查已经得到了三个相互支持的结果：
找不到 PHP CLI。
未发现 PHP 相关软件包。
未发现常见 PHP 服务进程。
虽然这些结果还不能证明系统内绝对不存在任何 PHP 文件，但已经可以初步判断，宿主机没有明显运行 PHP 服务的迹象。
四、第二步：检查 1Panel 的 PHP 运行环境
由于我的服务器使用 1Panel 进行管理，因此还需要检查面板自身管理的 PHP 环境。
具体操作路径为：
1Panel → 网站 → 运行环境 → PHP
进入页面后，可以看到 PHP 运行环境列表。
实际检查结果：
暂无数据，共 0 条记录。
也就是说，当前 1Panel 中并没有创建 PHP 运行环境。
【图片 2：1Panel PHP 运行环境截图】
建议插入 PHP 运行环境列表显示“暂无数据”的截图。
这一检查尤其重要。
因为对于使用 1Panel 的服务器而言，即使宿主机没有安装 PHP CLI，也可能通过面板创建独立的 PHP 运行环境。
因此，相比只执行一次 php -v，结合 1Panel 管理界面的结果更有参考价值。
不过，1Panel 的运行环境列表只能反映其管理范围内的环境，仍然无法单独排除手动创建的 Docker 容器或其他独立部署。
所以还需要进行最后一步检查。
五、第三步：检查 Docker 容器
5.1 查看所有容器
由于服务器上的主要应用都通过 Docker 运行，因此容器检查是本次排查中非常关键的一个环节。
执行：
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"其中：
docker ps用来查看容器。-a表示同时显示运行中和已停止的容器。--format用于指定输出格式。Names、Image和Ports分别代表容器名称、镜像及端口信息。
终端实际显示了四个容器。以下为整理后的结果，省略了容器名称中的随机后缀：
【图片 3：Docker 容器检查终端截图】
建议插入包含 docker ps -a、ps aux 和 dpkg -l 检查结果的终端截图。
5.2 分析各个容器
Halo
Halo 是基于 Java / Spring Boot 开发的应用，并不依靠 PHP 解释器运行。当前部署的官方 Halo 镜像不属于这次 PHP2Shell 漏洞的直接受影响范围。
MySQL
MySQL 是关系型数据库系统，不是 PHP 运行环境。虽然 PHP 网站经常搭配 MySQL 使用，但安装 MySQL 并不意味着安装了 PHP。
OpenResty
OpenResty 基于 Nginx 与 LuaJIT，可以提供 HTTP 服务、反向代理等功能，本身并不是 PHP 解释器。
需要注意的是，OpenResty 也可以把请求转发给 PHP-FPM，因此必须结合具体的网站配置和后端应用进行判断。
frps
frps 是 FRP 的服务端程序，主要用于反向代理及内网穿透，采用 Go 开发，也不属于此次 PHP 运行时漏洞的直接影响对象。
综合镜像信息来看，本次列出的四个容器均不是常见 PHP 运行环境容器。
5.3 为什么不能只看 Docker 镜像名称？
需要注意，镜像名称与容器中实际存在的软件并不完全等价。
某些定制镜像可能把多种组件打包在一起，而 docker ps 也不能直接列出镜像内部安装的所有软件。
因此，如果检查的是来源不明的定制镜像，还应该进一步查看镜像构建文件、软件清单，必要时进入容器检查。
不过，本次服务器所使用的四个镜像，结合它们的常规功能和之前的宿主机检查结果，没有发现 PHP2Shell 所要求的典型 PHP 运行环境。
六、排查中发现的另一个问题：Docker 端口暴露
检查 Docker 容器时，我还注意到了一个值得记录的细节。
Halo 的端口映射为：
127.0.0.1:8090->8090/tcpMySQL 的端口映射为：
127.0.0.1:3306->3306/tcp这里的 127.0.0.1 是宿主机的 IPv4 回环地址。
在常规 Docker 端口发布配置下，这表示容器的对应端口只发布到宿主机本地，而不是直接发布到所有网络接口。
相比：
0.0.0.0:3306->3306/tcp这种写法能够减少数据库端口被公网直接访问的可能性。
这对于 MySQL 尤其重要。
一般情况下，如果数据库只供服务器内部的应用使用，就没有必要直接向整个互联网开放 3306 端口。
不过，绑定到 127.0.0.1 并不代表服务完全无法被外部访问。反向代理、内网穿透、特殊 Docker 网络配置等，都可能提供其他访问路径。
此外，我发现 OpenResty 和 frps 在 docker ps 的端口映射一栏中没有显示具体端口。
这也不一定意味着它们没有开放端口。
例如，如果容器使用了 Docker 的 Host 网络模式，就不会通过普通的端口映射方式展示其监听端口。
这部分并非 PHP2Shell 漏洞排查的必要条件，但提醒了我：今后还需要关注服务的公网暴露情况。
如果希望进一步检查，可以执行：
docker inspect --format '{{.Name}} | {{.HostConfig.NetworkMode}}' $(docker ps -q)以及：
sudo ss -lntup前者用于查看运行中容器的网络模式，后者用于查看宿主机监听的 TCP 和 UDP 端口。
以上两项属于后续加固检查建议，并非本次已经完成的实测结果。
七、本次排查结果汇总
经过上述检查，可以将本次结果整理如下：
结合这几个方面的证据，我认为：
在本次检查覆盖的范围内，没有发现服务器正在运行受 PHP2Shell 影响的 PHP Web 运行环境，因此遭受这两个 PHP 漏洞直接影响的可能性较低。
这并不是说服务器绝对安全，也不是证明系统从未遭到入侵。
本次检查并没有对每一个镜像文件进行深度分析，也没有开展历史日志审计或完整的公网攻击面扫描。
排查结论只针对当时的服务器环境和这两个 PHP 漏洞。
另外，本次排查没有进行 PHP 安装、服务重启、容器重建或漏洞利用测试，也没有修改现有的业务配置。
因此，整个检查过程对正常运行的网站和数据库基本没有干扰。
八、这次排查让我学到了什么？
8.1 没有 PHP 命令，不代表没有 PHP
这是我此次排查中最先意识到的问题。
以前如果遇到：
Command 'php' not found我可能会直接认为系统没有安装 PHP。
但现在我了解到，PHP CLI、PHP-FPM、Apache PHP 模块以及 Docker 中的 PHP 环境可以采用不同的安装和运行方式。
仅凭一个命令的返回结果，并不能得出完整结论。
8.2 宿主机和容器是两个不同的检查层面
Docker 容器拥有相对独立的运行环境。
即使宿主机没有安装某个软件，容器内部也可能存在。
因此，在使用 Docker 部署应用时，安全排查至少需要同时考虑宿主机和容器。
对于使用 1Panel 的服务器，还应结合面板管理的运行环境进行检查。
8.3 有 Web 服务，不代表一定有 PHP
以前我对 Nginx、OpenResty、PHP 等组件之间的关系了解得不够清楚。
通过这次排查，我进一步理解了它们之间的区别。
OpenResty 可以接收 HTTP 请求并进行反向代理，Halo 可以通过 Java 独立运行，而 MySQL 负责数据库存储。
它们完全可以共同构成一个网站系统，而不需要 PHP。
因此，在分析某个安全漏洞时，不能仅仅根据服务器是否运行网站来判断，而是应该先弄清楚漏洞属于哪个组件、影响哪些部署方式。
8.4 安全排查需要建立证据链
这次排查并没有使用复杂的安全工具，但通过逐步验证，我得到了比单个命令更可靠的结果。
整个排查思路可以概括为：
漏洞影响条件 → 宿主机检查 → 运行环境检查 → 容器检查 → 综合风险判断。
如果其中某一步发现 PHP 服务，就应该进一步确认具体版本、发行版补丁及网络暴露情况。
如果多个检查结果相互印证，则可以逐步缩小需要关注的风险范围。
8.5 安全不等于一次性检查
即使本次没有发现 PHP2Shell 的直接受影响环境，也不代表服务器可以长期不更新、不维护。
未来如果安装了 WordPress、其他 PHP 网站或新的 Docker 镜像，服务器的风险情况就可能发生变化。
因此，仍然需要持续关注系统和应用的安全公告，及时备份重要数据，并检查公网开放的端口。
九、总结
2026 年 10 月 21 日，PHP 官方因漏洞信息提前泄露，将原定于次日进行的安全披露和补丁发布计划提前，并陆续发布多个安全更新版本，修复了两个严重的远程代码执行漏洞。
这次 PHP2Shell 漏洞排查，从最初的一条 php -v 命令开始，逐步扩展到了 Ubuntu 软件包、进程、1Panel 运行环境和 Docker 容器等多个方面。
最终，没有在我的阿里云 ECS 服务器上发现典型的 PHP Web 运行环境，因此可以初步判断，目前部署的这几个服务不属于 PHP2Shell 的直接受影响对象。
比起排查结果本身，我认为更重要的是这次实践带来的认识：
面对一个新出现的安全漏洞，首先需要搞清楚它影响什么，然后根据自己真实的系统架构逐步验证，而不是看到“高危漏洞”就立即恐慌、升级甚至重装服务器。
准确理解漏洞的影响范围、谨慎分析系统现状，往往是安全排查中最重要的第一步。
对我来说，这也是一次学习 Linux、Docker、Web 服务架构和基础安全运维知识的机会。
希望这篇记录能够为同样使用 1Panel 管理服务器的朋友提供一些参考。
参考资料
PHP 官方安全公告（2026 年 10 月 21 日）
https://www.php.net/archive/2026.php#2026-10-21-5PHP 官方紧急安全更新预告（2026 年 10 月 20 日，UTC）
https://www.php.net/archive/2026.php#2026-10-20-1Ubuntu 官方：PHP2Shell 漏洞及提前披露背景
https://ubuntu.com/blog/php2shell-vulnerability-fixes-availableUbuntu 官方安全公告：USN-8948-1
https://ubuntu.com/security/notices/USN-8948-1PHP 8.3.36 官方发布邮件
https://news-web.php.net/php.announce/511PHP 8.5.12 官方发布邮件
https://news-web.php.net/php.announce/513PHP 8.4.27 官方发布邮件
https://news-web.php.net/php.announce/512Docker 官方文档：Port publishing and mapping
https://docs.docker.com/engine/network/port-publishing/Docker 官方文档：Host network driver
https://docs.docker.com/engine/network/drivers/host/Halo 官方架构文档
https://docs.halo.run/developer-guide/core/frameworkOpenResty 官方网站
https://openresty.org/en/
本文记录的是 2026 年 10 月 23 日的个人服务器安全排查过程，仅供学习和参考。漏洞影响范围、补丁状态及系统配置应以实际环境和官方公告为准。