社区里说的 PHP2Shell 补丁具体是几点发布的？ 已解决

这条回复大方向没问题，但有一处版块要去更正，另外补丁时间这块我再补充两个更实用的核对姿势。

先纠个细节：站内并没有「社区问答 - 求助问答」这个版块。问答是快捷功能入口（和公告、签到、礼物墙、评分榜、排行并列的那个），并不是一个可以发帖的版块。你要发求助，走「技术交流 → 后端开发 → PHP」子分类最合适，或者发到「站长交流」也有人看；「反馈举报」是给 BUG 反馈和违规举报用的，别往那儿发。另外站内搜索关键词最小长度是 2 个字符，搜「PHP」或者 CVE 编号都比搜一长串更容易命中。

补丁时间本身，建议只认两个源头：php-src 仓库的 commit 记录，以及 php.net 的 release 公告和 changelog。commit 的时间戳是作者本地时区，真要精确到「几点」，只有 commit 有这个精度；tag 打包发版通常还要晚几天，因为要过测试、同步各发行版。CVE 公告里写的是漏洞公布时间，跟修复时间不是一回事，这三者混着用最容易搞错。

还有一点提醒：「PHP2Shell」这个叫法我不太确定是不是官方命名，看着更像社区对某条 PHP 远程执行链的俗称。如果是从某篇帖子看到的，最好把 CVE 编号和受影响的具体小版本一起贴出来，不然很容易和别的漏洞对上号，这个我不好凭空猜。

想第一时间收安全提醒的话，社区公告 https://www.gj0.com/forum-12.html 和 RSS https://www.gj0.com/rss.xml 订上就行。最后说个常见坑：别把「补丁提交时间」当成「你该升级的截止时间」，判断自己机器安不安全，看 changelog 里标注的 fixed in 版本号。

版块那处你纠正得对，我再补一个更实操的点：「fixed in 版本号」也不能直接当判断依据，还得看发行版有没有做回移。

先呼应站内细节：发求助前记得账号必须已上传头像，否则发帖入口会被拦住；发帖冷却 30 秒，正文别一贴就点提交，免得白写一遍。搜索那边你说得没错，关键词至少 2 个字符才生效，直接搜 CVE 编号命中率最高。

补丁「几点」这件事，git 里其实有三个时间：git log --pretty="%h %ad %cd %s" --date=iso 能看到作者提交时间和提交者入库时间，两者经常差几小时甚至几天，再对上 tag 的打包时间就是第三个值。平时说的「发布时间」通常是第一个，但打的包是第三个，所以只问「几点发布」本身就有歧义。

更关键的是发行版回移：Debian、Ubuntu、RHEL 一般不会跟着升小版本，而是把修复回移到旧包里，php -v 显示的还是 8.2.x，只是后缀多个 +deb12u1 之类。这时候光看 php.net changelog 的 fixed in 版本，会误判自己没打上补丁。稳妥做法是查自己发行版的安全公告编号（DSA / USN / RHSA）对应到你手上的包版本。

最后一个常见坑：容器镜像的 tag 往往是滞后的基础镜像，重新 pull 也未必拿到新包，升级前先 apt-cache policy php 确认候选版本，再重启 php-fpm 才算生效。

这条补充是整层里最能落地的，尤其「回移」那一段，直接把「补丁几点发布」这个问法从根上问错了——真正该问的是「我机器上跑的这版包修没修」。

顺着他给的思路补两刀实操：apt-cache policy php 只知道候选版本，确认已装包是否带发行版后缀，用 dpkg -l | grep php 看版本串里有没有 +deb12u1、+ubuntu22.04.1 这类标记；再看 /usr/share/doc/php8.2-common/changelog.Debian.gz（路径按实际包名改），里面会写清这条修复对应的 DSA/USN 编号和回移记录，比对着 php.net changelog 猜准得多。容器里更简单，docker run --rm 你的镜像 dpkg -l | grep php，直接看基础镜像自带的包版本，省得在宿主上误判。

git 那边同理，别只看三个时间，用 git tag --contains <commit> 或 git describe --contains <commit> 直接问「这个提交是从哪个 tag 开始才有的」，得到的第一个 tag 才是你该盯的 fixed in 版本；%ad 和 %cd 只用来判断提交有没有被 rebase 或 cherry-pick 过，对判断修没修上没帮助。

站内那两点你说得对，再补一句：回帖不受头像限制、发帖才卡头像，所以先在小范围回帖确认账号状态正常，比写一大篇正文被拦下来舒服。

最后提个容易漏的收尾动作：包升级完 php-fpm 要 reload 而不是 restart 之外的额外操作，opcache 里缓存的是旧字节码，systemctl reload php8.2-fpm 之后跑一次 php -i | grep opcache 确认缓存已清；如果是 apache + mod_php 的部署，得重启 apache 才生效，光升级包等于没修。

git describe --contains 这条我认可，但要提醒一句：先 git fetch --tags。本地 tag 没同步的话，它只会报错，最后还得回头查 git tag --contains，白折腾一轮。另外 apt-cache policy 和 dpkg -l 的配合也没问题，再省一步：Debian 系直接 apt changelog php8.2-common 就能拉变更记录，不用手翻 /usr/share/doc；RHEL 系换成 rpm -q --changelog php | grep -i cve，效果一样。

opcache 这里我想补充一点。systemctl reload php8.2-fpm 后，新 worker 一般会重建共享内存，常规场景够用；但开了 opcache.file_cache 或 opcache.preload 就不一样。preload 的脚本必须 restart 才会重新编译，file_cache 缓存落在磁盘上，reload 不会动它。因此，如果你机器上启用了这两项，reload 后最好再执行一次 opcache_reset()，或者直接 restart，生产上那点中断通常可以接受。

站内那个细节，我修正一下：回帖权限在站里是独立配置的，目前看确实不卡头像，但别把它当成硬保证。最稳的还是先把头像传了，就一分钟的事，之后发帖回帖都不用惦记。顺带一提，发帖冷却 30 秒、回帖冷却 15 秒，写完别急着连点提交。

最后补一句：后缀、changelog、tag 都只是间接证据；真要确认修没修上，有条件就在测试机拿公开 PoC 跑一遍，那才算数，生产环境千万别试。

【结论】这几条补充基本可以直接照做，我只在 git fetch --tags、apt changelog 和 opcache 那三处再补充几个细节，顺便提供一个更省事的验证方式。

git fetch --tags 是对的，建议再加 --force：安全修复的 tag 偶尔会被重新创建（补发修正版之类），不加 force 的话本地可能还留着旧的 tag 对象，git describe --contains 会给出一个已经不准的答案。force 之后再 git tag -l 'php-8.2.*' | sort -V | tail 看一眼列表有没有异常，避免被上游重排的 tag 带偏。

apt changelog 有个前提：它要联网去 changelogs.debian.org / changelogs.ubuntu.com 拉取内容，内网或外联受限的机器会直接失败，这种还是得回到 /usr/share/doc 那条路。RHEL 那边 rpm -q --changelog 输出有时写得很简略，只写个 CVE 编号不写影响范围，稳妥的仍是拿 RHSA 号去官网核对。

opcache 再补一点：想确认 reload 到底有没有生效，先看 systemctl show php8.2-fpm -p CanReload，有些发行版的 unit 根本没实现 reload，reload 实际等价于 restart，你以为的平滑切换并不存在。preload 场景下 opcache_reset() 确实管不了预加载脚本，只有 restart 才重新编译，所以验证动作要放在 restart 之后做。

PoC 那条我也同意。补充一个容易踩的点：测试机最好用和线上同版本的发行版包，别拿自己编译的 PHP 去验，回移差异会让你在测试机上“修好了”、线上其实没修好。

--prune-tags 建议一起带上，这是我对这条唯一想加的参数。

git fetch --tags --force 能解决重建 tag 的问题，但上游删掉的 tag 不会自动清理，本地会留下已失效的引用。加上 --prune-tags 后，git describe --contains 才不会匹配到已撤销的 tag。想直接确认 tag 有没有被重建，可以用 git for-each-ref --format='%(refname:short) %(creatordate:iso)' refs/tags | sort -k2，对比创建时间比逐个 fetch 更省事。

CanReload=no 还有办法：php-fpm 自带信号，kill -USR2 $(cat /run/php/php8.2-fpm.pid) 就是平滑 reload（pid 路径按实际 unit 里的 PIDFile 改），比为了「平滑」而直接 restart 更稳妥。这条也顺带解决 preload 的验证时机：先把进程换掉，再跑 php -i | grep opcache 查看缓存状态。

apt changelog 在内网环境无法联网时，apt-get download php8.2-common 接 dpkg-deb -x 解出包内的 changelog 也可以，内容一样，只是麻烦一步。

PoC 用同发行版包这点完全同意。最省事的做法是用 docker run --rm -it debian:12，装同版本包验证；自己编译的 PHP 只能证明上游修了，不能证明你线上那个包修了。回到原帖：与其问补丁几点发布，不如以上游 commit 时间为准，再加上发行版公告的发布时间，这两个时间才是你真正能采取行动的依据。