---
title: "PHP2Shell：用 Harbyn 从有漏洞的 PHP 版本走到可评审的拉取请求 | Harbyn"
description: "跟随一次公开的 Harbyn 扫描，从 PHP2Shell 的发现到一个真实的更新 PR：精确的版本锁定、浮动标签，以及留给评审的决定。"
canonical: "https://harbyn.com/cn/blog/php2shell-production-runtime"
last-updated: 2026-10-22
---

# PHP2Shell：用 Harbyn 从有漏洞的 PHP 版本走到可评审的拉取请求

由 Harbyn 发布于 2026年10月22日。标签：php, security, php2shell, developer-tools。

一次关键的 PHP 更新发布时，公告只是开始。接下来的问题取决于你的项目：受影响的版本在哪里声明，需要改什么？

PHP2Shell 给了我们一个具体的例子。我们在一个公开的演示仓库上运行了 Harbyn，这个仓库用多种方式声明 PHP 版本。扫描在 11 个文件中报告了 6 处发现，Harbyn 随后打开了一个拉取请求，更新了两处精确的版本锁定。

你可以查看[扫描的运行记录](https://github.com/harbyn/php2shell-demo/actions/runs/39718957930)和[实际的拉取请求](https://github.com/harbyn/php2shell-demo/pull/1)。下面说明发生了什么，以及如何在你自己的仓库上试同样的流程。

## PHP2Shell 发生了什么

2026年10月21日，PHP 发布了两个严重漏洞 CVE-2026-109618 和 CVE-2026-109619 的修复，这两个漏洞可能导致无需认证的远程代码执行。修复后的版本是 **8.2.35、8.3.36、8.4.27 和 8.5.12**。参见 [PHP 官方安全公告](https://www.php.net/archive/2026.php#2026-10-21-5)。

对开发团队来说，响应这份公告意味着找到分散在仓库各处的 PHP 声明。运行时可能固定在 Dockerfile 里，在 Compose 中引用，在工作流中配置，或体现在 Composer 设置里。这些声明的含义并不相同，因此不应做同样的修改。

## 演示：6 处发现，1 个可评审的 PR

我们的[演示仓库](https://github.com/harbyn/php2shell-demo)是为这次演示创建的一个小型虚构 PHP 应用。它包含精确的版本锁定、浮动版本、一个 Composer 要求，以及一个 PHP 8.1 镜像。

借助 Harbyn，GitHub Action 扫描了 11 个文件，报告了 6 行需要关注的内容。随后 Harbyn 针对支持的更新打开了一个 PR。

这样就有了一条可追溯的路径：从安全公告，到仓库中的声明，再到提议的修改。证据在运行日志和 diff 里，而不是一张示意性的终端截图。

## 为什么不同的发现对应不同的操作

这 6 处发现并不是 6 个相同的修复：

| 演示中的声明 | 怎么做 |
| --- | --- |
| 两处精确的 PHP 版本锁定 | 更新到同一 PHP 分支中已修复的补丁版本。 |
| 两处浮动版本 | 重新构建或更新相关环境，并检查实际在用的运行时。 |
| 一个 Composer 中的 PHP 要求 | 将兼容性要求与已安装的解释器分开评估。 |
| 一个 PHP 8.1 镜像 | 评估迁移到受支持分支，包括应用的兼容性。 |

像 `php:8.3-fpm` 这样的浮动标签可能保持不变，而旧镜像仍在部署中。Dockerfile 里也许没有可以替换的版本字符串；要做的是获取并部署修复后的镜像。

较旧的 PHP 分支也需要另做决定。把应用从 PHP 8.1 迁移到受支持的分支可能影响兼容性。发行版或扩展支持的软件包可能已经回移了修复，因此请查看你实际使用的软件包的安全公告。[PHP 公告](https://www.php.net/archive/2026.php#2026-10-21-5)也讨论了这些选项。

## 拉取请求里有什么

[生成的 PR](https://github.com/harbyn/php2shell-demo/pull/1) 包含两处有针对性的修改。

在 `Dockerfile` 中，它更新了 PHP 基础镜像：

```diff
-FROM php:8.3.35-fpm
+FROM php:8.3.36-fpm
```

在 `composer.json` 中，它更新了 `config.platform.php`：

```diff
-      "php": "8.3.35"
+      "php": "8.3.36"
```

第二处修改值得解释。Composer 的 platform 设置告诉依赖解析应假定哪个 PHP 版本。它不会安装或升级 PHP。与 Dockerfile 一起更新，可以让这个假定与预期的运行时保持一致。参见 [Composer 关于平台依赖的文档](https://getcomposer.org/doc/articles/composer-platform-dependencies.md)。

PR 把提议的修改集中起来供评审。评审之后，团队仍然需要构建并部署更新后的镜像，替换旧实例，并确认实际处理请求的运行时。仓库里的修改就是这样到达应用的。

## 在你的仓库上试试 Harbyn

在你的仓库目录下运行：

```sh
npx harbyn scan
```

扫描器在本地运行，下载 Harbyn 签名的变更 Feed，在不上传源代码的情况下检查支持的声明。

查看报告的文件、行号和来源。要设置 PR 流程，请参阅 [Harbyn 文档](https://harbyn.com/docs)。

PHP2Shell 是 Harbyn 帮助开发者处理的一类问题的例子：一项外部变更变得与仓库中的某一行相关。Harbyn 把这项变更与代码联系起来，并在有受支持的修复时，准备好更新供评审。

[扫描你的项目](https://harbyn.com)，或者先看看 [PHP2Shell 的公开 PR](https://github.com/harbyn/php2shell-demo/pull/1)。