對象：應用程式（或安裝的擴充套件）會接收檔案的人，例如表單、管理後台、CMS 外掛、API。本文不包含攻擊方法，只依據公開事實說明如何讓自己的上傳功能變得安全。相關文章：在 CVE 修補手冊中徹底修正相依套件的缺陷，以及組織的資安基本對策。
實際會發生什麼（用白話說）
多數應用程式都有接收檔案的地方，例如「上傳圖片」「更換圖示」「附加文件」。如果這裡防護薄弱，攻擊者會送出偽裝成圖片的腳本檔，讓它被存進網頁可存取的資料夾。接著只要在瀏覽器中開啟那個檔案的 URL，如果伺服器把內容當成程式執行，攻擊者就能遠端執行指令。這就是 web shell（被留下的小型遠端控制程式），之後就會發生竄改網頁、竊取資料、偷偷建立管理員帳號，以及擴散到其他系統。
問題在於存放位置與執行，而不是接收檔案
上傳是正當的功能。危險在於把收到的東西，以可以執行的形式放在可以執行的地方。反過來說，即使收到可疑的檔案，只要它落在絕不執行的地方、內容經過檢查、端點需要驗證，就不會造成損害。請把思維從「擋下壞檔案」轉換為「絕不讓存放位置執行任何東西」。
2026 年的真實案例：Joomla 擴充套件遭大規模利用（相同模式）
2026 年，多個 Joomla 擴充套件接連公開了完全相同的「免驗證上傳 → RCE」模式，並被廣泛利用。據報導，它們都是「沒有驗證檢查＋沒有檔案類型檢查＋存放在網站根目錄下」這種典型組合。範圍從頁面建構器擴大到活動行事曆擴充套件，CISA 也設定了很短的修補期限。
- SP Page Builder（CVE-2026-48908）
- JoomShaper 開發。影響 6.6.1 以下版本，於 6.6.2 修正。據報導，自訂圖示的上傳沒有執行驗證或類型檢查；CVSS 10.0，已遭實際利用（列入 CISA KEV）。警示解說：CVE-2026-48908。
- iCagenda（CVE-2026-48939）
- joomlic 開發的活動行事曆擴充套件。影響 3.2.1–3.9.14／4.0.0–4.0.7，於 3.9.15／4.0.8 修正。據報導，公開活動報名表單的附件處理，其存取控制只在顯示層執行；CVSS 10.0，已遭實際利用（列入 CISA KEV）。警示解說：CVE-2026-48939。
- Page Builder CK（CVE-2026-56290）
- joomlack.fr 開發。影響 3.5.10 以下版本，於 3.6.0 修正（舊版系列回溯修正至 3.1.1／3.4.10）。據報導是相同的免驗證上傳導致 RCE；CVSS 10.0。
- 共同點
- 不需要登入就能利用＝成為無差別掃描的目標。據報導，攻擊著重於維持存取：建立隱藏的管理員帳號並植入 web shell，讓攻擊者在漏洞修補後仍能保有存取。
- 第一步修正
- 把受影響的擴充套件更新到修補版本（並盤點、移除不使用的擴充套件）。再加上下文的設計與設定，分層防禦。
教訓：沒在用的擴充套件，往往是最常被利用的弱點
這些案例有一個共同點：攻擊者是透過被遺忘、卻仍安裝著的擴充套件進來的。每增加一個 CMS 外掛或擴充套件，攻擊面就多一分。光是盤點並刪除不使用的東西，就能減少這類大規模利用可以打中的目標（如何盤點你的資產）。
攻擊的每個階段，以及如何擋下
這種模式每一步都有可以擋下它的地方。請把它當成「可以在哪裡擋下」來閱讀，而不是攻擊方法。
1. 檔案被送到未經驗證的端點
任何人都能連到上傳處理程式並送出腳本。
對策：驗證＋權限檢查＋CSRF 權杖
2. 通過類型檢查並被儲存
副檔名／Content-Type 被偽造，偽裝成「圖片」。
對策：伺服器端允許清單＋內容（magic bytes）檢查
3. 落在網站根目錄下，可以用 URL 連到
存放在可被猜到的路徑，能直接在瀏覽器中開啟。
對策：存放在網站根目錄之外／隨機化檔名
4. 伺服器把它當成腳本執行
存放目錄允許執行＝web shell → RCE。
對策：在上傳區域禁止執行腳本
不安全的設定與安全的設定
會失守的設定
- 端點沒有驗證／權限檢查（任何人都能連到）
- 只依副檔名或 Content-Type 判斷（會被偽造、雙重副檔名）
- 收到的檔案直接存在網站根目錄下
- 存放位置仍允許執行腳本
- 檔名是使用者提供的／可被猜到的
守得住的設定
- 端點要求驗證＋權限＋CSRF
- 用允許清單限制類型，並檢查實際的位元組（magic bytes）
- 存放在網站根目錄之外（透過專用的處理程式提供）
- 上傳區域禁止執行腳本
- 重新命名為隨機檔名；絕不信任使用者提供的路徑
如何實作（依優先順序）
在端點要求驗證、權限和 CSRF
處理上傳的端點，必須只有已登入且具備適當權限的使用者才能存取，並且要驗證 CSRF 權杖。據報導，2026 年的 Joomla 案例缺少的正是這個驗證／權限檢查。首先，消除「任何人都能呼叫」的狀態。
在伺服器端使用允許清單並檢查內容
絕不信任用戶端的檢查或瀏覽器送出的 Content-Type。在伺服器端用允許清單只允許已知安全的類型，並檢查檔案實際的位元組（magic bytes），確認它真的是那種類型。在判斷之前，先把雙重副檔名、大小寫和結尾的點正規化。
存放在網站根目錄之外（或禁止執行）
把收到的檔案存在無法直接用 URL 開啟的地方，透過專用的控制器提供（並設定適當的 Content-Disposition）。如果做不到，至少要在上傳區域禁止執行腳本（網頁伺服器設定）。只要這一點成立，即使是惡意檔案也不會執行。當其他控制失效時，它能保護你。
隨機化檔名；加上大小與頻率限制
重新命名為由伺服器決定的隨機名稱，絕不信任使用者提供的路徑或檔名（避免路徑穿越）。加上大小限制和頻率限制，可能的話再加上惡意軟體掃描。
盤點並更新你的擴充套件／CMS
盤點你使用的擴充套件／外掛，刪除不使用的，其餘的保持更新。在 2026 年的大規模利用中，攻擊者就是從沒有更新的擴充套件進來的。依照 CVE 修補手冊，加入變更偵測，以便發現問題再次出現。
與本站建置方式的共通之處
這種模式的核心問題，是**把不可信任的輸入，以可以執行的形式放在可以執行的地方。**本站自己的原則正好相反：不信任收到的東西、隔離重要的東西、分層防禦。不只是上傳，「在伺服器端驗證輸入」和「隔離機密與可執行區域」都是同一種防禦。也請參考不要把機密放在公開目錄中的放置錯誤。
延伸閱讀
- AI 代理入侵：Hugging Face 入侵事件（2026）：自主 AI 代理的攻擊
- Gyazo 資料外洩（2026 年 9 月）：外洩了什麼，使用者今天該做什麼
- 付款頁面遭竄改（2026 年 9 月）：PhotoGoods（大興印刷）付款頁面上的盜卡程式（被指出檔案上傳功能遭濫用是原因之一的案例）
- 用語：不安全的反序列化（由外部資料決定型別）／RCE（遠端程式碼執行）是什麼／惡意軟體是什麼（web shell 是其中一種）
- 警示：CVE-2026-48908（SP Page Builder）／CVE-2026-48939（iCagenda）（相同的免驗證上傳 → RCE 模式）
- 實務：組織的資安基本對策／CVE 修補手冊／不要把機密放在公開目錄
FAQ
Q為什麼檔案上傳的缺陷會讓攻擊者接管伺服器？
如果攻擊者能放置一個伺服器會執行的檔案（腳本），只要在瀏覽器中開啟它，就會在伺服器上執行程式碼（web shell → 遠端程式碼執行，RCE）。接下來就是竄改網頁、竊取資料、偷偷建立管理員帳號，以及擴散到其他系統。關鍵不在於收到了檔案，而在於檔案在它落腳的地方能被執行。
Q檢查副檔名就夠了嗎？
不夠。副檔名和瀏覽器送出的 Content-Type 都很容易偽造。雙重副檔名（picture.php.jpg）、大小寫混用、結尾的點或空字元，以及較少人知道的可執行副檔名，都能繞過簡單的檢查。要組合使用允許清單（只允許已知安全的類型）、檢查檔案實際的位元組（magic bytes），而最重要的是讓存放位置不執行任何東西。不要依賴拒絕清單。
Q小網站也會被盯上嗎？
會。這類漏洞不需要驗證就能利用，所以攻擊者會掃描整個網際網路，不分對象地攻擊有漏洞的版本。在 2026 年 Joomla 頁面建構器擴充套件的大規模利用中，所有受影響的安裝不論規模都是目標。「我們太小不會被攻擊」並不成立。