原倉庫失聯的 AI 自主滲透工具 ARTEX：備份流通、傳出濫用，中小企業官網該怎麼自保

結論：AI 自主滲透工具 ARTEX 的備份仍在流通，還傳出疑似遭濫用的報導。中小企業先盤點對外系統、補基本防線，再找人在授權範圍內掃一遍。

時間說明：本文撰稿日為 2026-10-09。文中 GitHub 星數與 Fork 數，是撰稿時擷取的頁面數字，之後會持續變動。

ARTEX 是什麼？AI 真的能自己做滲透測試嗎？

ARTEX 是一套開源的 AI 自主滲透測試系統，GitHub 專案頁自述為百度「agent+」攻防挑戰賽冠軍專案，採 AGPL-3.0 授權（mhtsec/ARTEX）。它讓大型語言模型（LLM）指揮多個代理，自己拆目標、跑工具、記錄發現。

先把兩個詞講白。滲透測試，是在取得授權的前提下模擬攻擊者，去找系統漏洞的檢測工作。AI agent（代理），是能自己規劃步驟、呼叫工具完成任務的 AI 程式。兩者合起來，就是讓 AI 代替資安人員跑掉大部分流程。

韓文在地化版的說明寫得更直白：ARTEX 由 LLM 操控的多個代理自行拆解目標、執行實際工具，把找到的資產與漏洞累積成圖譜，自主推進整個測試（artex-ko）。同一份文件也警告，它強到幾乎不需要人介入，就能自己走完偵察、入侵到資料外流的攻擊流程。

從專案頁截圖與目錄看得到的功能，包括任務執行過程與工具呼叫紀錄、資產覆蓋圖、流量錄製、人在環路對話、攔截審批與審批紀錄。執行需要 PostgreSQL 資料庫（一種常見的開源資料庫軟體），以及 Anthropic 或 OpenAI 的 API 金鑰（向 AI 服務商申請的存取憑證，依用量計費）。Docker 是一種把程式連同執行環境打包成「映像檔」、一個指令就能部署的工具；原專案 README 說明映像檔含 nmap、playwright 等工具，但目前 Docker 部署源已失效，需自行在本機建置，例如用 Go（ARTEX 後端使用的程式語言）把原始碼編譯成單一執行檔（mhtsec/ARTEX）。

它實際打得下多少真實系統？本文引用的來源中未見成功率數據，本文不推測它打下真實系統的能力。能確定的只有一件事：這是一套設計成自主作業、而且已經公開的框架。

為什麼這個專案現在值得中小企業注意？

因為三件事同時發生：擴散規模大、來源狀態難以追查、已有疑似濫用的報導。對有技術的人來說，取得門檻已經很低，原始專案的去向與用途又有爭議。

第一是擴散規模。撰稿時 mhtsec/ARTEX 頁面顯示 Fork 數 3.4k、星數 1.5k；韓文版 artex-ko 另有 784 星、637 個 Fork，兩個 repo 合計超過兩千星（mhtsec/ARTEX、artex-ko）。Fork 是把整份程式碼複製到自己帳號。Fork 數高於星數，這個落差可能反映擴散的不只是關注，還有副本。

第二是來源狀態。mhtsec/ARTEX 自述是「ARTEX 最後一個版本純源碼備份」，Docker 部署源已失效（mhtsec/ARTEX）；韓文版則註明原始專案 Autumn-27/ARTEX 在 2026 年 10 月確認無法連線（artex-ko）。原始倉庫連不上了，備份和衍生版本仍在外面流通。

第三點最嚴重。韓文版 README 轉述，2026 年 10 月多家韓國媒體報導，原版 ARTEX 疑似被用於針對韓國金融機構的個資外洩攻擊，調查當局已掌握相關跡象，案件仍在偵辦（artex-ko）。這是單一二手來源，本文未能獨立查證該批韓國媒體報導。即使尚無定論，疑似遭濫用的報導已經出現，防守方不能再當作與自己無關。

中小企業可以自己拿 ARTEX 掃自己的網站嗎？

可以，前提是目標屬於你自己、或拿到書面授權，而且最好先在隔離的複本上跑。這套工具對有技術的人門檻低，對沒有技術人員的老闆，自己用的門檻仍高；直接拿它打正在營運的官網或電商後台，風險比收穫大。

韓文版的使用規範寫得很清楚：只對自己擁有或取得書面明確授權的對象使用；學習與驗證，請在 OWASP Juice Shop、DVWA（兩者都是專門做來給人練習攻防、刻意留有漏洞的靶機）這類本機隔離環境進行（artex-ko）。正式系統要測，事先要談好範圍與時間窗。

「自己擁有」在台灣中小企業身上常常不只是自己。官網放在虛擬主機、Wix 這類架站平台、雲端主機，或由外包商代管時，你擁有的是網站內容，底下的主機與平台屬於別人；掃描前還要取得主機商、平台或代管方的同意，並確認對方的服務條款允許。

程式碼本身也要先過一關。mhtsec/ARTEX 是第三方保存的備份，又牽涉疑似攻擊案，外人無從比對這份程式碼是否完整、有沒有被動過。動手前先讀過原始碼與 install.sh（專案頁說明這支安裝腳本會自動安裝 Docker），在隔離環境執行，API 金鑰另開一把專用、設好用量上限。另有一點是作者依其需要 LLM API 金鑰的架構推論，來源沒有直接寫：ARTEX 探索時會把內容交給你設定的第三方 LLM 服務商處理，掃描過程碰到的網頁內容，甚至客戶資料，都可能一起送出去。

實務門檻也要算進去：要架 PostgreSQL、要會 Docker 或編譯 Go、要準備 LLM 的 API 金鑰，而且每次探索都在消耗 token（大型語言模型的計費單位，按處理的文字量計算），儀表板本身就有一欄專門統計 Token 消耗（mhtsec/ARTEX）。三種做法攤開比：

決策

比較項

自己用 ARTEX 掃

前置條件

資料庫、Docker、API 金鑰、基本資安知識，最好有測試複本

費用型態

API 用量計費，加上自己的工時

主要風險

打錯目標或把正式機打掛

適合誰

有工程師、有測試環境的團隊

建議

外包給資安業者

前置條件

簽約、確認範圍與時間窗，自己先補完基本防線

費用型態

依案報價

主要風險

業者品質參差，要看報告寫法；基本功沒做就送測，報告會塞滿低級問題

適合誰

有金流、會員個資或訂位系統的公司

暫不掃描，只做基本防線

前置條件

盤點、更新、多重驗證、備份

費用型態

多半不需額外採購工具，主要是工時

主要風險

沒有人驗證防線是否真的有效

適合誰

只有形象官網、沒有登入功能的公司

有金流或會員資料的公司，補完基本防線後外包檢測最划算

想拿 ARTEX 做資安服務，AGPL 授權有什麼限制？

可以商用。但改過的版本只要透過網路提供給客戶操作，就得把修改後的原始碼提供給這些使用者。想把改過的 ARTEX 包成 SaaS（讓客戶上網租用的軟體服務）來賣，若要維持封閉就會碰壁；沒修改原始碼、或願意公開修改版，就沒有這個問題。

AGPL-3.0 是一種「傳染性」較強的開源授權。依官方條文，它比一般 GPL 多出第 13 條的網路條款：修改後的程式只要讓使用者透過網路互動，就要向這些使用者提供對應的原始碼（條文原文見連結：GNU AGPL-3.0 全文）。ARTEX 與韓文版都標示採用 AGPL-3.0（mhtsec/ARTEX、artex-ko）。

對想接案的資訊服務業者，判斷可以這樣下：由你的工程師在內部跑工具、交付一份人工整理的報告，屬於使用工具的服務；把改過的 ARTEX 架成網站讓客戶自己登入操作，就落入網路條款。另外，原始倉庫既已失聯，長期維護與安全更新由誰負責也要評估。以上是一般性說明，簽約前請找律師確認。

授權之外還有一條更硬的線。依官方條文，台灣刑法第 358 條處罰無故利用電腦系統漏洞入侵他人電腦（條文原文見連結：全國法規資料庫）。工具是否開源與這條線無關，沒有授權就動手，有觸犯第 358 條的風險。

這對台灣中小企業意味著什麼？

意味著「沒人有空來打我這種小網站」這個假設要重新檢查。依專案頁的安裝說明，架起 ARTEX 需要的是一套 PostgreSQL 資料庫加上 LLM 的 API 金鑰，對懂 Docker 或 Go 的人來說門檻不高；一般老闆要自己架仍然吃力，但會拿它來打你的人，本來就不是一般老闆。ARTEX 內建資產圖與資產同步功能，設計目標就是自動盤點並逐一探索目標，防守方也該用同樣的視角先盤點自己（mhtsec/ARTEX）。

台灣讀者要多算一筆。以下是作者的判斷：有會員資料的公司一旦外洩，可能面臨法律與商譽責任，細節請諮詢律師，事後處理的麻煩遠大於事前一次檢測；接大型企業或公部門的案子時，對方寄來的資安問卷可能會問到是否做過弱點檢測、後台有沒有多重驗證。這兩件事都讓基本防線變成接單條件。

有會員資料、線上金流或訂位系統的公司，今年就該把對外系統做一次完整盤點，並排進至少一次授權範圍內的檢測。只有形象官網、沒有登入功能的公司，優先順序是更新與備份，暫時不必花錢做完整滲透測試。

常見的破口類型包括：多年沒更新的外掛、外包商留下沒關的測試後台、共用的管理員帳號、沒人記得存在的舊子網域（主網址底下另外開出的網址，例如 shop.example.com.tw）。本文來源沒有這些類型的發生比例統計，列出來是讓防守方知道該先翻哪些角落。

還有一個判斷：別把「買了掃描服務」當成安全。報告只是起點，修補要有人負責、有期限，下一次上線前再驗一次。資安的成本主要在持續維護，單次檢測只是其中一小段。

官網和後台上線前，最低限度該補哪幾件事？

最低限度五件事，順序比工具重要。前四件多半不需要額外採購工具，主要是工時，掃描放在最後。

流程

上線前最低限度的順序

1. 盤點對外系統
2. 更新與關閉多餘入口
3. 後台加多重驗證
4. 備份與留紀錄
5. 授權範圍內掃描

掃出來的才是真問題

盤點，就是列出所有對外的網址、子網域、後台登入頁與第三方外掛，標上負責人與代管方。這正是 ARTEX 資產圖在做的事，防守方要比它早一步。

更新與關閉多餘入口，指的是把架站系統、外掛、伺服器套件更新到現行版本，把測試站、舊後台、預設路徑關掉或加上存取限制。多重驗證（MFA），是登入時除了密碼還要第二道確認，例如手機驗證碼；後台一律開啟，帳號不共用。

備份要能還原才算數，至少每月實際還原一次。存取紀錄要留下誰在什麼時間登入後台，出事時才查得到。韓文版另外整理了自主 AI 攻擊的偵測規則與強化檢查清單，有技術人員的團隊可以參考它的防禦視角（artex-ko）。

原版 ARTEX 已有疑似遭濫用的報導（經 README 轉述），防守方沒有理由再等。

我們的立場：工具已公開，沒做完盤點、更新、多重驗證、備份的公司，被掃到就是時間問題。

相關閱讀：AIRUN AEO，檢查 AI 回答客戶提問時怎麼描述你的公司。

本文來源：mhtsec/ARTEX、jiwoochris/artex-ko、GNU AGPL-3.0 全文、中華民國刑法第 358 條（全國法規資料庫）。法條內容請以連結原文為準。

常見問題

ARTEX 是什麼？

ARTEX 是開源的 AI 自主滲透測試系統，GitHub 專案頁自述為百度「agent+」攻防挑戰賽冠軍專案，採 AGPL-3.0 授權。它讓大型語言模型（LLM）指揮多個代理自己拆目標、執行工具、累積資產與漏洞圖譜。原始倉庫已失聯，目前流通的是備份與衍生版。

中小企業可以用 ARTEX 掃自己的官網嗎？

可以，但只限自己擁有或取得書面授權的系統；網站放在主機商、架站平台或外包商代管的，還要先取得對方同意。建議先在隔離的測試複本上跑。執行需要 PostgreSQL、Docker 或 Go 編譯環境，以及 LLM 的 API 金鑰，會持續產生用量費用。沒有技術人員的公司，比較實際的做法是先補基本防線，再找業者在授權範圍內檢測。

拿 ARTEX 改一改做成線上掃描服務，可以嗎？

AGPL-3.0 允許商用，但第 13 條規定，修改後的程式只要讓使用者透過網路互動，就必須向這些使用者提供修改後的原始碼。想做成封閉的 SaaS（讓客戶上網租用的軟體服務）會碰到這條限制；沒修改原始碼、或願意公開修改版，就沒有這個問題。內部使用工具、交付人工報告則是另一種情境，簽約前請律師確認。

沒有授權就用 AI 工具掃別人的網站，會違法嗎？

會有很高的法律風險。台灣刑法第 358 條處罰無故利用電腦系統漏洞入侵他人電腦，工具是否開源不影響責任。韓文版 ARTEX 也明確要求只能用在自己擁有或取得書面明確授權的對象。任何檢測都應先簽好範圍與時間窗。

官網上線前最低限度要做哪幾件事？

五件事依序做：盤點對外系統、更新軟體並關閉多餘入口、後台加多重驗證、做好備份與存取紀錄，最後才在授權範圍內掃描。前四件多半不需要額外採購工具，主要是工時；做完之後再掃，報告裡留下的才是真正需要專業處理的問題。