MacCMS 還在用 PHP 7.2？PHP2Shell 緩解、修補與升級路線

MacCMS 網站還在用 PHP 7.2，遇到 PHP2Shell 時，不能只在面板按「更新至 7.2 最新版」便結案。PHP 7.2 已於 2020 年 11 月 30 日結束上游支援，最後一版 7.2.34 早於這次漏洞。先確認自己的 7.2 是誰提供的，再決定使用供應商回移補丁，或把 MacCMS 搬到已修補且仍受支援的 PHP 環境。

短期可在正確的 PHP 設定中關閉 session.upload_progress.enabled，減少部分攻擊路徑；這不是完整修復。若沒有可核實的修補，應先限制站點的外部存取，利用維護窗口完成副本測試，不要把「舊模板只能用 7.2」當成可以一直公開運行的理由。

先分清：Ubuntu 的 PHP 7.2，還是寶塔的 PHP 7.2？

登入 SSH 後先盤點，不要先改設定：

cat /etc/os-release
command -v php
php -v
ps -eo pid,ppid,args | grep '[p]hp-fpm'
systemctl list-units --type=service --all | grep -E 'php.*fpm'

如果系統有 APT，再查是否真的安裝了發行版的 7.2 套件：

dpkg-query -W php7.2-common php7.2-fpm
apt-cache policy php7.2-common php7.2-fpm

找不到這些套件，不等於網站沒有 PHP。寶塔或其他面板可能維護自己的安裝目錄，網站也可能在容器內。請把 MacCMS 網域的 FastCGI socket／連接埠，對到實際 FPM master 與 pool。命令列的 php -v 不能單獨證明這個網域正在使用哪套 PHP。

只有在你的環境確實存在下列寶塔式目錄時，才使用這組路徑查驗：

/www/server/php/72/bin/php -v
/www/server/php/72/bin/php --ini
ls -l /www/server/php/72/etc/php.ini
ls -l /etc/init.d/php-fpm-72

這些是路徑範例，並非所有面板的共同標準。--ini 仍是該二進位檔的 CLI 查詢，網站端還須核對 FPM 啟動設定與實際讀值。不要因為主機的 Ubuntu 套件已更新，就推定 /www/server/php/72/ 裡的另一套 PHP 也已修補。

關閉上傳進度：改 PHP，別改 MacCMS 核心檔

PHP 官方對這項緩解的要求是：設定須在解析請求之前生效，並重新啟動所有相關工作程序。若你已確認上述 FPM 使用 /www/server/php/72/etc/php.ini，先把原設定備份到非公開位置，再用編輯器找到這個選項並改成：

session.upload_progress.enabled = 0

不要只在 MacCMS 的入口檔、控制器或模板裡加 ini_set()，也不要依賴 FPM 的 .user.ini 完成緩解。確認沒有其他伺服器或 pool 設定覆寫它，先做 FPM 配置測試：

sudo /www/server/php/72/sbin/php-fpm -t

配置測試通過，且已確認 /etc/init.d/php-fpm-72 是管理這個 FPM 的既有服務腳本後，才在維護窗口重啟：

sudo /etc/init.d/php-fpm-72 restart

沒有這個腳本就停在這裡，改用已查明的 systemd 服務或面板內該 PHP 版本的重啟功能，不要猜服務名稱。重啟可能影響共用 PHP 7.2 的其他網站；之後也要確認舊 worker 已退出。

這項設定停用的是 PHP session 的上傳進度追蹤，不會自動關掉所有圖片或影片上傳。PHP2Shell 包含 CVE-2026-109618、CVE-2026-109619，仍有其他攻擊路徑；不能只測一次上傳或看到 Off，就宣布網站已安全。

能留在 PHP 7.2 嗎？先看修補供應商

Ubuntu 官方公布，18.04 的 php7.2 修補套件為 7.2.24-0ubuntu0.18.04.17+esm14，適用 Ubuntu Pro／ESM 的相應套件來源。這個版號不是讓你拿去安裝到任意 Linux 或寶塔 PHP 裡的通用補丁。

若網站真的使用 Ubuntu 18.04 的發行版 PHP 7.2，先確認 ESM 已啟用並有此安全更新可用，再按該套件來源更新網站使用的 PHP、FPM 與擴展。套件顯示 7.2.24 仍可能已回移修補；完整版本與來源公告才是判斷依據。更新後仍需重啟對應服務並核網站實際使用的版本。

若使用面板編譯的 7.2、第三方 RPM 或自建容器，就向該供應商索取明確涵蓋兩個 CVE 的修補建置與驗證方式。單純重新編譯舊原始碼，或升至 7.2.34，都不能補上這次漏洞。拿不到可靠修補時，走遷移路線；升至同樣已停止上游支援的 7.4，也不是長期解法。

MacCMS 能不能直接切到 PHP 8.3？

先記錄自己的 MacCMS 程式、模板與插件版本。自有文件的版本與驗證範圍列出，文件以程式版本 2026.1000.4056 為基準，曾在 PHP 8.3.33 與 MySQL 8.4.9 做隔離安裝檢查。這能作為準備副本的參考，不能保證你的舊核心、加密模板、支付插件或二次開發都能直接切換。

PHP 8.3.33 是該文件的歷史相容性環境，早於本次上游修補版 8.3.36。今天建立新環境時，要使用已修補的 8.3 版本或有供應商回移補丁的套件，不能為了照抄文件而刻意安裝舊安全版本。依PHP 版本與環境準備逐項補齊擴展，重新核對目標 PHP 的資料庫驅動、curl、mbstring、GD 等依賴。

實際遷移可按以下順序進行：

1. 保存整站程式、資料庫、upload、template、addons、application/database.php、application/extra 與路由及 Web 設定。備份移到站點根目錄之外，確認可以還原。
2. 建立獨立測試網域與資料庫，還原同一組備份；限制訪問，停用複製過來的正式採集排程、付款與通知出口。
3. 在副本依所用 MacCMS 發行版的升級路線處理程式與資料庫，再配置修補過的 PHP 8.3 和所需擴展。不要把新版整份資料庫直接覆蓋舊庫。
4. 先用對應的基本模板檢查，再逐一啟用正式模板與插件；若使用加密擴展，取得供應商對目標 PHP 的相容版本。
5. 副本通過後安排切換，保留可配對恢復的檔案、資料庫與 Web 設定。正式庫已有新寫入時，回退前先處理資料差異。

備份範圍與恢復方法可對照MacCMS 備份、恢復與遷移。這次不只是在面板換一個 PHP 下拉選單：若程式或資料庫已升級，失敗時只切回 PHP 7.2，未必能恢復原站。

切換前後，站長至少要驗哪些功能？

用測試內容核對首頁、分類、詳情與播放入口，再測後台登入、內容儲存、會員登入／退出、圖片上傳及網站實際使用的採集與插件流程。付費功能使用受控測試資料或供應商測試模式，不拿真會員的餘額與訂單做試驗；沒有條件驗的支付或播放來源，不要視為已通過。

最後從網站實際處理請求的環境確認 PHP 版本、SAPI、設定檔，以及 session.upload_progress.enabled 的讀值；診斷入口只對管理者開放，完成後移除。詳細的受限檢查頁與 Ubuntu／容器更新步驟見PHP2Shell SSH 處理教學，其中 PHP 8.3 的套件名稱與路徑不能直接貼到 PHP 7.2 主機。

若網站已經有陌生管理員、被改寫的 PHP 檔或異常任務，請保留紀錄並另做入侵調查。換 PHP 或停用上傳進度，都不會自動清除既有後門。

參考資料