一、为什么要升级系统版本
2026 年 10 月 21 日，CNVD 收录两个 PHP 远程代码执行漏洞（CNVD-2026-41674 / CNVD-2026-41675，对应 CVE-2026-109618 / CVE-2026-109619，业界合称 PHP2SHELL），评级“高危”，技术细节与 PoC 已广泛传播。修复版本为 PHP 8.2.35、8.3.36、8.4.27、8.5.12。
PHP 层面的升级属于环境操作，用包管理器、面板或容器换一个版本即可，不展开。真正容易出问题的是应用层：运行环境换了，CMS 系统不跟上，站点就跑不起来。 这次 MetInfo 的统一做法是环境与系统同步升级，系统侧升至 V8.1——该版本经测试兼容上述四个 PHP 修复版本，收费模板与插件也已同步完成适配。
下面记录的就是这个过程。
二、升级前：先确认备份范围
帮助文档里有一句容易被跳过的话：升级前建议先备份数据库。 这句话经常被当成免责声明划过去，实际上它是操作前提。
从失败恢复路径反推，需要备份的东西共有三样：
对象 |
内容 |
为什么必须备 |
数据库 |
全部数据表 |
升级涉及表结构变更，失败后无法回滚 |
|
用户上传的图片、附件 |
升级过程不触碰，但恢复老版本时要配套使用 |
|
站点当前使用的模板文件 |
模板是升级后白屏的主要出事点 |
后台提供图形化备份入口，升级弹窗里点“备份”即跳转到“备份与恢复”页面。习惯走命令行的，用下面这套更可控：
# 数据库（把 db_name / db_user 换成实际值） mysqldump -u db_user -p --single-transaction --routines \ --default-character-set=utf8mb4 db_name > /backup/db_$(date +%F).sql # 站点目录与模板 tar -czf /backup/site_$(date +%F).tar.gz \ -C /var/www/metinfo upload templates config # 记录当前版本号，升级出问题时便于对照 mysql -u db_user -p -e "select * from met_config where name like '%version%'" db_name
最后一条顺手把升级前的版本号存下来。真出问题时，“原来是什么版本、要回退到哪”这件事，事后很难凭记忆确认。
备份文件不要放在站点目录内。放在 web 根目录下的备份，等于把一个可下载的数据库快照公开在互联网上。
三、升级系统至 V8.1
3.1 触发升级
两个入口，任选其一：
- 可视化后台 → 更多 → 检测更新
- 传统后台 → 页面头部右上角 → 检测更新
存在新版本升级包时，页面上会出现“在线下载”按钮。点击后弹窗展示更新日志，阅读完点“确定”，开始在线下载升级文件。
3.2 安装
下载完成后按钮变为“安装”。点击进入在线升级安装提示界面，此时会再次提示备份——如果前面已经备份过，直接进入下一步。
点“安装”后系统开始执行升级，期间不要刷新页面、不要关闭浏览器。
3.3 四个已知的失败点
这几条是实际操作中最常遇到的，写在文档正文里但很少被读到：
下载长时间没有反应。 刷新浏览器，重新点击下载升级文件即可，不会产生脏数据。
服务器无法在线下载升级包。 部分服务器因 PHP 配置或网络出口限制拉不到升级文件，此时需要改用手动升级包，按包内附的操作说明逐步执行。判断方法：点“在线下载”后长时间空白且浏览器网络面板无请求发出，基本就是这个原因。
升级失败或升级后异常。 按顺序排查三件事：模板是否可以升级（见下一节，这是最高频原因）、用系统自带的“系统诊所”插件在线诊断修复、最后才考虑回退。
升级失败且不知道原因。 退路是用备份的数据库、upload 文件夹、templates 文件夹，在本地电脑恢复出老版本站点，在本地把升级流程跑通、确认无误后，再整体搬到服务器。这条路比在生产环境反复试要稳妥得多。若服务器本身提供了自动备份快照，也可以直接联系服务器提供商恢复到升级前的状态。
四、升级收费模板
这一步是升级后“后台能进、前台打不开”的直接解药，也是最多人卡住的地方。
4.1 为什么必须单独升级模板
模板和系统是两个独立发布的单元。系统升级带来新功能和新接口，旧模板可能仍在调用已被移除的方法，结果就是后台走系统自带模板、显示正常，前台走站点自选模板、直接报错。
规则是：升级 MetInfo 版本时，一般都需要升级模板以适配新系统版本。
4.2 操作路径
- 可视化后台 → 风格 → 网站模板 → 商业模板（后台菜单即此名称）
- 传统后台 → 网站模板 → 商业模板
4.3 最容易漏的一步
进到页面后，必须在右上角登录模板的授权账号，否则不会提示升级。
这是“我按教程进了模板页面，但没有升级按钮”的唯一原因。系统不知道这个模板归谁所有，自然不会推送对应的升级包。升级按钮只有在登录后、且存在更新版本时才会出现。
4.4 自定义修改会不会被覆盖
会，但可以避免。
如果修改过模板的源代码，并且按模板的修改规则给修改过的 UI 区块设置了版本号，在线升级就不会覆盖这些自行修改的文件，可以放心点升级。
反之，如果改过代码但没有设置版本号，升级会认为这些文件是旧版本，直接覆盖。改过模板代码的站点，升级前先确认这一步有没有做。
4.5 升级后
模板升级不影响网站内容，这一点可以放心。但如果新版本模板增加了功能项，可能需要在可视化编辑里补充设置参数，否则新功能会以默认值呈现或显示为空。
升级过程中进度条长时间无响应，刷新页面重新升级即可。
五、升级应用插件
5.1 关键风险
升级插件一般不会影响已配置的数据，但会覆盖插件的源文件。
这条需要特别注意的对象是做过插件二次开发的站点。如果直接修改过插件目录下的文件，在线升级会全部覆盖，改动丢失且不可恢复。这类站点应当先在本地合并改动，或暂缓该插件的升级。
5.2 操作路径
后台 → 我的插件 管理页面 → 登录插件授权账号 → 插件存在更新版本时，点击“升级”按钮在线升级。
与模板同理，未登录账号时不会显示可升级状态。
六、三步的先后顺序
系统、模板、插件必须按这个顺序，不能并行：
系统升级至 V8.1 → 模板升级 → 插件升级
原因在于依赖方向。模板的新版本是针对新系统接口编写的，系统还没升级就升模板，模板会调用不存在的接口；插件同理，它依赖系统与模板提供的挂载点。顺序颠倒不会立刻报错，但会在某个页面某个功能上零星出错，排查成本很高。
三步全部完成后，清一次系统缓存，再检查前台。
七、升级后的验证
三项全部通过才算完成。
检查项 |
方法 |
通过标准 |
版本一致性 |
后台“检查更新”页 |
系统显示 V8.1，PHP 版本为 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 之一或更高 |
前台可用性 |
访问首页与内页，逐个抽查栏目 |
正常渲染，无空白、无报错 |
入侵迹象 |
检查异常进程与可疑执行记录 |
无异常条目 |
第三项不能省略。PHP 补丁只阻断新的利用路径，不会清除已经写入的后门。 只升级不排查，等于做了一半。
以漏洞披露日 2026-10-21 为基准，筛出之后被修改的文件：
find /var/www -type f -name '*.php' -newermt '2026-10-21' -ls
正常业务更新也会命中，重点看两类：web 根目录下不认识的单文件，以及上传目录、缓存目录这类本该只读的目录里出现的 PHP 文件。发现异常先隔离再取证，不要直接删除——删了就没有追溯线索了。
八、几个高频问题
Q：后台能进，前台打不开，是什么原因？
绝大多数是模板没升级。先确认模板页面右上角是否已登录授权账号、升级按钮是否出现。若模板已是最新版仍然报错，再查 PHP 扩展是否缺失（升级环境时容易漏装 fileinfo、intl、redis）。
Q：模板页面没有升级按钮。
两个原因：未登录模板授权账号；或者当前模板本身就是最新版。先登录再刷新。
Q：系统升级失败，站点打不开了，怎么办？
不要在出问题的环境上继续试。用升级前的备份（数据库 + upload + templates）在本地恢复老版本，本地跑通升级流程，确认无误后再整体搬回服务器。这条路径比重试快得多。
Q：只升级系统，不升级模板和插件，行不行？
系统能跑，但前台很可能报错。模板和插件调用的是系统接口，接口变更后旧版本不保证兼容。若确实暂时不能升级，至少先在测试环境验证一遍前台各页面。
Q：升级会不会影响网站内容？
模板升级不影响内容。系统升级涉及数据结构变更，因此必须提前备份数据库。插件升级不影响配置数据，但会覆盖插件源文件。
Q：旧版本 PHP（如 7.4）的站点怎么办？
先升级 PHP。MetInfo V8.1 声明兼容 PHP 5.6 ~ 8.5.12，这里的“兼容”指程序可以运行在该区间，不等于区间内每个版本都安全。7.4 已无安全补丁，该升级仍然要升级。
九、小结
- 备份是前提不是免责。 数据库、
upload、templates三样缺一不可。 - 顺序不能乱。 系统 → 模板 → 插件，依赖方向决定了这个次序。
- 模板升级要登录授权账号。 没有升级按钮，十有八九是这一步漏了。
- 改过代码的模板和插件要单独评估。 设置了 UI 区块版本号的模板不会被覆盖，改过源文件的插件一定会。
- 升级之后必须排查后门。 补丁不清除已存在的 webshell。
