更新日期：2026-10-27｜對象：學校網站管理員、委外維護廠商
本篇說明如何檢查 PHP 漏洞 CVE-2026-109618、CVE-2026-109619，安排修補、降低升級前暴露風險，並限制登入來源。範例僅使用文件專用位址 192.0.2.10、192.0.2.0/24 與 school.example.org，不代表任何學校的真實環境；實際操作前必須替換。
一、先了解：修補 PHP 才是完整處理方式
PHP 官方於 2026-10-21 公布兩個可能導致未經驗證遠端程式執行的重大漏洞。CVE-2026-109618 涉及記憶體不足時的資料處理；CVE-2026-109619 涉及跨請求殘留狀態。Apache mod_php 的已展示攻擊風險尤其高，PHP-FPM 也不能直接當成安全。
上游修補基準為各分支的 8.5.12、8.4.27、8.3.36、8.2.35。應採用所選分支當下最新的安全版本，或 Linux 發行商明確公告包含這兩案修補的回補套件。以下防護不是漏洞修補，也不能清除已存在的後門。
二、盤點：網站或主機是否使用 PHP？
WordPress、Drupal、Joomla、XOOPS 等系統通常使用 PHP。只看副檔名或 HTTP 標頭不足以判斷，應同時確認服務、設定、容器及網站程式。以下為 Linux 唯讀盤點範例：
cat /etc/os-release
command -v php
php -v
ps -eo user,pid,ppid,args | grep -E 'php-fpm|apache2|httpd|nginx'
systemctl list-units --type=service | grep -E 'php|nginx|apache|httpd'
sudo ss -lntp
# Ubuntu／Debian 套件
dpkg-query -W 'php*' 2>/dev/null
# RHEL 系列另用：rpm -qa | grep -i php
# 根目錄請依實際環境修改；不輸出設定檔密碼
sudo find /var/www -type f -name 'wp-config.php' -print
sudo find /var/www -type f -name 'configuration.php' -print
sudo find /var/www -type f -name 'settings.php' -print
sudo find /var/www -type f -name 'mainfile.php' -print
# Nginx 設定可能含內部位址；僅在管理端查看，勿直接公開
sudo nginx -T 2>&1 | grep -E 'server_name|root |fastcgi_pass|PHP_VALUE|PHP_ADMIN_VALUE'
# Apache 可另查：sudo apachectl -M若有 Docker、Podman、多個虛擬主機或不同 FPM pool，要逐一盤點。PHP CLI 與網站使用的 PHP 可能不同，不能只執行 php -v 就結案。依 Nginx 的 fastcgi_pass 或 Apache 模組設定，找到實際執行的版本；FPM 可使用對應的 php-fpm8.3 -i 檢查。不要在公開網站長期放置 phpinfo()。
三、確認版本與供應商回補
Ubuntu／Debian 可檢查已安裝與候選套件版本（版本名稱請依盤點替換）：
dpkg-query -W php8.3-fpm php8.3-common php8.3-cli
apt-cache policy php8.3-fpm
zgrep -iE 'CVE-2026-109618|CVE-2026-109619' /usr/share/doc/php8.3*/changelog* 2>/dev/null本機套件索引可能過期，changelog 沒找到編號也不是最終判定；須核對發行商對兩個 CVE 的公告及實際安裝版本。截至本文更新日，Ubuntu 公告列出的修補版本包括：Ubuntu 24.04 的 8.3.6-0ubuntu0.24.04.13、22.04 的 8.1.2-1ubuntu2.28，以及 18.04 的 7.2.24-0ubuntu0.18.04.17+esm14（需對應 Ubuntu Pro 服務）。版本看起來低於上游基準，不代表沒有回補；反之，僅有 ESM 字樣也不能證明已修補。
PHP 8.1 以前：PHP 專案已不提供例行維護。若供應商仍有支援且明確回補兩案，可作短期過渡；長期仍應遷移受支援版本。官方提供的部分舊分支來源回補不等同恢復完整維護，更不能跨版本亂套補丁。
四、最安全的升級順序
- 盤點 OS、Web 服務、PHP、擴充套件、CMS、外掛／模組、佈景及資料庫；確認管理主控台與 SSH 不會被鎖住。
- 建立 VM／磁碟快照，另存設定、網站、日誌與一致性資料庫備份，實際測試還原。不要只複製執行中的資料庫目錄。
- 在隔離測試站升級 CMS／模組與 PHP；舊站從 7.x 跨到 8.x，先查相容性，不能直接覆蓋正式站。
- 同分支供應商回補通常變動較小，但仍需檢查套件交易、測試及維護時段。過舊 OS 建議建立乾淨新主機再搬遷。
- 測試登入、權限、消息非同步載入、搜尋、分頁、圖片、中文附件、下載、郵件及排程。
- 切換後重啟真正承接網站請求的所有 PHP worker，再確認套件及 Web 實際版本，移除臨時探針。
- 若發現後門，先保存證據、隔離並從可信來源重建；單純升級 PHP 不等於完成除惡。
以下只示範 Ubuntu 24.04／PHP 8.3 同分支更新流程。先確認官方套件來源與所需擴充，再決定交易內容，不適合直接套用於其他版本：
sudo apt-get update
apt-cache policy php8.3-fpm php8.3-common
sudo apt-get -s install --only-upgrade php8.3-fpm php8.3-common php8.3-cli
# 檢閱模擬結果、完成備份與測試後才執行
sudo apt-get install --only-upgrade php8.3-fpm php8.3-common php8.3-cli
sudo php-fpm8.3 -t
sudo nginx -t
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx上例不包含所有擴充套件。實際需將已安裝且受影響的 PHP 套件一併更新；Apache mod_php 或容器也要採用其對應重啟方式。
五、升級前怎麼保護？優先避免公開請求進入舊 PHP
最保守是由防火牆、反向代理或 Nginx 暫停對外動態服務，改由獨立靜態頁提供公告。CMS 內建關站若仍執行 PHP，或只有首頁顯示維護中，仍可能被直接呼叫其他 PHP 路徑繞過。不要一併停用必要 SSH／遠端管理通道。
若網站已停止更新，可規劃經審查的靜態封存。若仍保留 PHP 供閱讀，以下只是降低暴露風險。所有修改都先備份：
sudo cp -a /etc/nginx /root/nginx-backup-$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/php /root/php-backup-$(date +%Y%m%d-%H%M%S)5-1 關閉不需要的 PHP 上傳
以下以 PHP 8.3 FPM 為例，先確認版本與路徑，勿直接改到錯誤的 CLI 設定。若 pool 有更高優先設定，也須一併確認。
sudo tee /etc/php/8.3/fpm/conf.d/99-school-protection.ini >/dev/null <<'EOF'
file_uploads = Off
session.upload_progress.enabled = Off
post_max_size = 1M
upload_max_filesize = 1M
display_errors = Off
expose_php = Off
EOF
sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpmsession.upload_progress.enabled 必須在請求解析前生效並重啟 worker，不能只靠程式內 ini_set()。官方另列 memory_limit=-1 的部分緩解，但可能增加記憶體耗盡風險，須配合資源隔離與專業評估，不建議直接盲目套用。
5-2 封鎖上傳目錄 PHP 與不需要的資料庫管理入口
以下放在實際網站的 server 區塊內，且在一般 PHP 正規表示式 location 前。已有相同 location 或 ^~ 規則時須合併檢查；上傳路徑也須依 CMS 調整。
# XOOPS 範例；WordPress 通常另有 /wp-content/uploads/
location ~* ^/uploads/.*[.](php[0-9]*|phtml|phar|inc)(/|$) {
return 403;
}
location ~* ^/(pma|phpmyadmin|install|upgrade|setup)(/|[.]|$) {
return 403;
}不要直接封鎖所有含「點」的目錄，否則合法的 .thumbs 圖片或 .well-known 憑證路徑可能失效。封鎖上傳目錄 PHP 只阻止直接 HTTP 存取，不能阻止其他受害程式在主機內 include 後門。
5-3 純閱讀站可阻擋寫入方法，但先測試 AJAX
以下是「完全禁止登入／提交」模式，與下一節需要登入 POST 的模式不可直接同時使用。GET 也可能被舊模組拿來刪除資料，所以方法限制並不是資料庫唯讀保證。
# 放在網站 server 區塊
if ($request_method !~ ^(GET|HEAD)$) { return 405; }
if ($http_content_length !~ ^(0)?$) { return 413; }
if ($http_transfer_encoding != "") { return 413; }若最新消息卡在「載入中」，先在瀏覽器 Network 查是否 POST 被擋。確認端點確實只讀、支援 GET 後，才將該 AJAX 改為 GET 並清除對應模板快取；不可將所有 $.post 全站取代，也不要為了修畫面全面重新開放 POST。搜尋、分類、分頁、下載須一起測試。
六、限制登入「來源網段」：一般訪客可讀，指定 IP 才能登入
這裡的限制是來源 IP／網段，不是校網網址或電子郵件網域。用 Referer、Host 或網址文字判斷登入來源並不可靠。示範 192.0.2.10/32 只代表單一文件用 IP；192.0.2.0/24 代表整個示範網段，實際優先採最小範圍。
以下是 Nginx＋XOOPS 範例；WordPress 須改成 wp-login.php、wp-admin 等路徑，並評估 admin-ajax.php、REST、XML-RPC 的公開需求；Drupal、Joomla 也需依路由重寫與登入端點另訂規則。限制來源仍不能取代密碼、MFA、權限與修補。
6-1 建立來源與路徑判斷
先確認 /etc/nginx/conf.d/*.conf 是在 nginx.conf 的 http 區塊被 include。以下以新檔建立，若檔案已存在請先檢查，勿覆蓋其他設定。
sudo nano /etc/nginx/conf.d/school-login-access.confgeo $school_allowed_ip {
default 0;
192.0.2.10/32 1;
# 若確定需要整段，再改用：192.0.2.0/24 1;
}
map $uri $school_login_path {
default 0;
~*^/user[.]php(/|$) 1;
~*^/admin([.]php|/|$) 1;
~*^/modules/[^/]+/admin([.]php|/|$) 1;
}
map "$school_allowed_ip:$school_login_path" $school_block_login {
default 0;
"0:1" 1;
}6-2 在提供網站的 server 區塊加入
if ($school_block_login = 1) {
return 403;
}此方式在伺服器層先判斷，不會以一個不完整的 PHP location 取代現有 FastCGI 設定。多個網址、HTTP／HTTPS 或其他對外入口須逐一納管。若現有 location 已一律 return 403，加入白名單不會自動解除它，須將登入／後台的既有封鎖整合為來源判斷。
登入 POST 注意：本節不要求全站禁止 POST。若先前啟用第 5-3 節，須先設計精確例外：僅白名單來源的登入端點允許必要 POST、限制本文大小與格式，其他寫入／上傳維持封鎖。不要只移除 POST 禁令卻保留其他不完整保護；後台若只供檢視，也不要順便開放修改表單。
代理注意：上述 geo 預設依 Nginx 看到的來源位址判斷。若前面有 CDN／反向代理，先核對可信代理清單與 real_ip 設定，避免全部被當成代理 IP。不能信任任何訪客自行提交的 X-Forwarded-For，也不能把所有網路都設為可信代理。IPv6 需另加經確認的來源範圍。
6-3 檢查與驗證
sudo nginx -t && sudo systemctl reload nginx
curl -I https://school.example.org/user.php
curl -I https://school.example.org/admin.php
curl -I -H 'X-Forwarded-For: 192.0.2.10' https://school.example.org/user.php必須分別從允許及不允許的實際網路測試；curl 加上 X-Forwarded-For 不會真的改變來源。非白名單應為 403，偽造標頭也不能繞過。允許來源應能取得登入頁，並由管理員驗證實際登入、重新導向及後台；只看到 200 不代表登入成功。再測首頁消息、篩選、分頁、縮圖與附件，避免防護誤擋閱讀。
七、如何檢查入侵跡象？
先保留程序、連線與日誌，必要時在隔離前後記錄時間與雜湊。不要先刪除疑似後門，也不要用瀏覽器開啟或執行可疑 PHP。
date -Is
sudo ss -ntup
ps -eo user,pid,ppid,lstart,args
last -ai | head -30
sudo ls -lh /var/log/nginx/ /var/log/auth.log* /var/log/php* 2>/dev/null
sudo crontab -l
sudo ls -la /etc/cron.d /etc/systemd/system
awk -F: '$3==0 {print $1,$3,$6,$7}' /etc/passwd
# 最近修改的 PHP：正常快取／更新也可能命中
sudo find /var/www -type f -name '*.php' -mtime -30 -print
# 上傳區程式候選：路徑依實際調整
sudo find /var/www/html/uploads -type f -iname '*.php*' -print
sudo find /var/www/html/uploads -type f -iname '*.phtml' -print
sudo find /var/www/html/uploads -type f -name '.user.ini' -print
# 僅做候選篩選，eval/base64 也可能出現在正常程式
sudo grep -RIlF -e 'eval(' -e 'base64_decode(' /var/www/html/uploads 2>/dev/null
# 對確認要保存的個別檔案計算雜湊，不要執行
sudo sha256sum /path/to/suspicious-file.php應同時查網站管理員帳號異動、資料庫、SSH key、排程、systemd、auto_prepend_file、外連與檔案完整性。陌生亂數檔名、加密載入器、外部輸入交給 eval、異常程序值得追查，但單一關鍵字不能直接定罪。
日誌出現掃描請求只證明有人嘗試；回應 200 可能是首頁回退，不一定是外洩。SIGTERM 可能來自正常重啟；檔案時間可能被修改，不能據此認定攻擊日期或歸因特定 CVE。沒有命中也不能宣稱未入侵：日誌可能輪替、缺少 POST 內容，或攻擊者已移除痕跡。
若確認後門：啟動校方事件通報流程、保留證據、隔離、調查範圍，從乾淨映像與可信程式重建；在乾淨端輪替憑證並撤銷工作階段，審查後才匯入資料。不要把整份被入侵網站程式原封不動還原上線。
八、交給維護廠商或 AI 助手的檢查指令
請在已授權的網站主機進行唯讀盤點，確認所有 Web PHP、CMS、容器與版本，核對 CVE-2026-109618／109619 的上游或供應商回補公告。提出備份、還原測試、相容性與升級方案。若需暫時防護，先辨識登入、AJAX、搜尋及下載入口，保留正常閱讀；登入來源使用本校確認的最小 IP 範圍，不信任偽造代理標頭。檢查後門、帳號、排程、外連與日誌，保留證據，不執行疑似後門。報告必須區分已確認、待確認及未測試項目；對外分享前移除真實 IP、帳密、內部路徑與日誌個資。
官方參考資料
- PHP 官方安全公告與版本資訊
- CVE-2026-109618：OOM corruption
- CVE-2026-109619：stale global state
- Ubuntu：CVE-2026-109618 修補狀態
- Ubuntu：CVE-2026-109619 修補狀態
- Nginx geo 模組、可信代理與 realip 模組
本文指令為教學範例，未包含任何學校的真實 IP、網站網址、帳密或入侵日誌。實際設定須依作業系統、CMS 路由與代理架構調整，修補狀態以操作當日官方公告為準。
