如果你的 Symfony 網站用 access_control 守住後台，先看規則是否只寫了 GET。Symfony 在 11 月 4 日公開一批安全修補，其中一項就是補上 HEAD 與 GET 在路由和權限規則之間的落差。另一項涉及編譯後的路由，升級後還要清除並重建正式環境的路由快取。
先核對正式環境的套件版本
以下挑出這批更新中，與後台權限、上傳及憑證登入有關的四項公告。表中是這四項的最低修補版本。從正式環境部署的 composer.lock 或已安裝套件查起；專案宣告允許安裝的版本範圍，不能證明正式站已用上修補。
| 目前分支 | 最低修補版本 |
|---|---|
| 5.4 | 5.4.56 |
| 6.x | 6.4.50 |
| 7.x | 7.4.23 |
| 8.x | 8.1.11 |
哪些設定需要優先檢查？
- 只限制 GET 的存取規則（CVE-2026-118514，
symfony/http-foundation）：路由可用同一個處理程式回應 HEAD，舊版比對器卻不會套用只列 GET 的權限規則或防火牆。HEAD 不會回傳正文，但仍可能露出回應標頭，處理程式也可能執行寫入等操作。若同一路徑要為 HEAD 保留不同規則，升級後要把它排在 GET 規則之前。 - 用網址路徑保護跨子網域的路由（CVE-2026-118516，
symfony/routing）：如果路由的主機名稱含變數，又靠網址路徑決定權限，舊版編譯路由可能把部分路徑誤當成主機名稱的一部分，導致規則漏攔。修補在產生路由快取的程式，舊快取留在正式站就仍有風險。 - 將外部請求轉成含上傳檔案欄位的物件（CVE-2026-118515，
symfony/serializer）：若程式把不可信的資料轉成含UploadedFile欄位的物件，伺服器本機檔案可能被當作上傳檔處理。後果取決於程式怎麼讀取、搬移或提供這些檔案。自行組裝 Serializer 的專案，還要確認DataUriNormalizer排在物件正規化器之前。 - 用用戶端憑證登入（CVE-2026-118513，
symfony/security-http）：若登入流程會從憑證主體名稱擷取帳號，持有受信任憑證且能影響憑證通用名稱（CN）的人，可能冒用其他帳號。直接傳入獨立憑證欄位作為帳號，或由憑證機構產生或驗證主體值的部署，不符合這個利用條件。
這四份公告說明了觸發條件，沒有通報已觀察到的在野利用。若你只負責營運網站，可以把套件清單、後台的權限規則和部署方式交給維護者確認。
更新後，確認後台的門還是鎖著
先在測試環境升級相關套件，再部署更新後的鎖定檔與依賴，並依既有部署流程清除、重建正式路由快取。用自家測試站的訪客與已授權帳號核對後台：匿名 GET 和 HEAD 都應按預期被拒絕或導向登入，授權使用者仍能照常操作。若站上也有上傳或憑證登入，再用正常的檔案和測試帳號各走一次流程。
封面為 AI 生成的概念插圖。
