plaincve:~$

// 威脅簡報

CVE-2026-111322

Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理

CVSS
9.3 CRITICAL
CISA KEV
未列入
弱點類型
CWE-306
主題
AI 安全

PlainCVE 團隊 · 發布 2026-10-20 · AI 輔助 · 媒體簡報 ↓

AI 審稿 2026-10-20(未經人工)指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

Archon 0.2.13 到 0.11.1 的 /api/* 控制 API 預設監聽所有網路介面且不需登入,能連到的人都能操控 AI 代理;目前沒有官方修補,2026-10-17 發布的 0.12.x 預設行為也沒有改。

誰會中執行 Archon 0.2.13 到 0.11.1(含)、沒有開啟網頁認證(預設就是關閉),而且伺服器埠可從其他主機連到的使用者。
後果能連到伺服器埠的人不需任何帳號,就能啟動與執行工作流程、對 AI 代理注入訊息,以及核准或取消代理待確認的動作。VulnCheck 說這能以 Archon 使用者身分在主機上執行指令,但據某新聞文章(該頁含攻擊程式,本站不連結)引述,原研究者表示這不是主機上的遠端程式碼執行,兩方說法不一致。
現在該做什麼目前沒有官方修補,升級到 0.12.x 也不會改變預設值。先把 HOST 設為 127.0.0.1 只讓本機連線,或用防火牆擋住 /api/*;要對外開放時,依 Archon 的 SECURITY.md(公開部署時應使用帶認證的 Caddy 反向代理),放在有認證的 Caddy 反向代理後面。
受影響版本0.2.13 到 0.11.1(含)
修好的版本沒有官方修補。CVE 紀錄沒有列修補版本;2026-10-17 發布的 v0.12.0、v0.12.1 版本說明沒有提到這個問題,v0.12.1 的程式碼仍預設綁定 0.0.0.0、網頁認證關閉時 /api/* 關卡也關閉。OSV 列的 fixed commit aa095446 其實是 v0.11.1 的發布 commit(Release 0.11.1),不是修補。
CVSS 向量
顯示完整向量CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
時間點
  • 首次公開 2026-10-15

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?
  1. 01確認版本是否落在受影響範圍

    在你從 git 原始碼安裝 Archon 的那台主機、把 /path/to/Archon 換成原始碼目錄後執行,查看目前的發布標籤。CVE 紀錄列的範圍是 0.2.13 到 0.11.1(含)。注意:2026-10-17 發布的 0.12.0、0.12.1 不在 CVE 範圍內,但沒有修補這個問題,v0.12.1 的程式碼仍預設綁定 0.0.0.0、認證關閉時關卡也關閉;版本是 0.12.x 也不代表安全,仍要做下面兩項檢查。

    唯讀查詢
    git -C /path/to/Archon describe --tags
  2. 02確認伺服器是否監聽所有介面

    在執行 Archon 的 Linux 主機上執行,只列出預設埠 3090(依專案 .env.example;若你改過 PORT,請換成你的埠)的監聽位址。若顯示 0.0.0.0:3090 或 *:3090,代表其他主機可能連得到;顯示 127.0.0.1:3090 代表只有本機。macOS 沒有 ss,可改在該主機執行 lsof -nP -iTCP:3090 -sTCP:LISTEN。

    唯讀查詢
    ss -ltn 'sport = :3090'
    步驟 1
  3. 03確認網頁認證有沒有開

    依專案程式碼,只有同時設定 Postgres 的 DATABASE_URL 與 BETTER_AUTH_SECRET 才會開啟認證;若設了 ARCHON_WEB_AUTH_REQUIRED=false,/api/* 關卡也會關閉。請在執行 Archon 的主機上、你的 Archon 實際使用的 .env 所在目錄執行;下列指令只印出變數名稱與 DATABASE_URL 的開頭(看得出是不是 postgresql),不印出密碼或密鑰值。PlainCVE 的提醒:設定也可能來自 shell 環境變數、systemd 或 docker-compose,而 v0.12.1 版本說明提到發布版執行檔不再從工作目錄讀 .env,所以這裡找不到不代表沒有設定,請一併檢查你實際的啟動設定。

    唯讀查詢
    grep -E '^(HOST|ARCHON_WEB_AUTH_REQUIRED)=' .env; grep -oE '^DATABASE_URL=[a-z]+:' .env; grep -oE '^BETTER_AUTH_SECRET=' .env
    步驟 2
MITIGATE修補 / 緩解先修補;還不能修補時先擋住
  1. 01只讓本機連線

    專案的 .env.example 寫著 HOST 預設為 0.0.0.0,設為 127.0.0.1 就只允許本機連線。

    步驟 1
  2. 02用防火牆或網段隔離擋住 /api/*

    第三方威脅情資建議,在有修補之前限制對 /api/* 控制 API 的網路存取。

    步驟 1
  3. 03開啟網頁認證

    依專案程式碼,同時設定 Postgres 的 DATABASE_URL 與 BETTER_AUTH_SECRET 才會開啟認證,開啟後 /api/* 關卡預設啟用;不要設 ARCHON_WEB_AUTH_REQUIRED=false。限制(出自專案程式碼 v0.12.1 的 api.ts 與 index.ts):關卡會接受可信代理標頭 X-Archon-User 當身分,網頁認證開啟時這個標頭仍是備援;index.ts 的註解說,這個標頭只有在 Archon 只能經由會認證並設定標頭的反向代理連到(綁定 loopback)時才可信,綁在非 loopback 時任何能連到埠的人都能偽造它;所以需由會認證的反向代理轉入並綁定 127.0.0.1。PR #3147 另提到代理部署需明確移除該標頭或綁定本機。

    步驟 2
  4. 04對外部署時加上有認證的反向代理

    Archon 的 SECURITY.md 寫道:公開部署時應使用帶認證的 Caddy 反向代理(見 deploy/docker-compose.yml)。

    步驟 1步驟 2步驟 3
RESPOND應變發現入侵跡象時
  1. 01檢查是否有不明的代理活動

    PlainCVE 的建議(我們沒有找到專案提供的偵測指引):若伺服器曾對外開放,檢查有沒有你沒建立的工作流程、不明的對話訊息,或不是你核准/取消的待確認動作,並檢查代理能碰到的程式庫與檔案有沒有異常變更。

    步驟 3步驟 4
  2. 02追蹤修補狀態

    依專案的 GitHub 發布紀錄,2026-10-17 發布了 v0.12.0 與 v0.12.1,版本說明都沒有提到這個 CVE 或綁定、認證預設的變更;v0.12.1 的程式碼仍預設綁定 0.0.0.0、認證關閉時關卡也關閉。目前沒有官方修補,在專案公告修補前,維持上述網路限制。

HARDEN強化長期避免同類問題
  1. 01不要依賴預設值保護 AI 代理

    維護者的 PR #3147 刻意讓沒有開認證的單人與 SQLite 安裝維持開放行為,所以自己要負責網路邊界。

    步驟 1步驟 2
  2. 02限縮代理與工作流程的權限

    PlainCVE 的判斷:被劫持的執行能造成多大損害,可能取決於工作流程與代理的權限。用低權限帳號執行,只給必要的存取。

    步驟 4
完整修復步驟與說明

目前沒有官方修補,所以重點是讓控制 API 不被其他主機連到。

  • 沒有修補版本。 CVE 紀錄沒有列修補版本。專案的 GitHub 發布紀錄顯示,2026-10-17 發布了 v0.12.0 與 v0.12.1,版本說明都沒有提到這個 CVE 或綁定、認證預設的變更;v0.12.1 的程式碼仍是 HOST 未設定時綁定 0.0.0.0,/api/* 關卡也只在網頁認證開啟時才啟用。升級到 0.12.x 不會解決這個問題。
  • OSV 的「fixed」是誤列。 OSV 自動產生的紀錄列了一個「已修補」的 git commit(aa095446…),但這個 commit 就是 2026-09-25 的「Release 0.11.1 (#3523)」發布 commit,沒有改認證、/api/* 關卡或預設綁定,而 0.11.1 本身是受影響版本。不要因為 OSV 的紀錄就假設升級即可解決。
  • 設定順序。 先限制網路(HOST 設為 127.0.0.1 或防火牆),再調整認證設定;改完後重新啟動,在該主機用 ss -ltn 'sport = :3090'(macOS 用 lsof -nP -iTCP:3090 -sTCP:LISTEN)確認不再監聽 0.0.0.0。
  • 開認證時注意。 依專案程式碼,DATABASE_URL 必須是 Postgres,且要同時設定 BETTER_AUTH_SECRET;只設其中一個不會開啟認證。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

由上到下是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理: 1. 連到對外開放的 Archon 伺服器埠 → 2. /api/* 的認證關卡直接放行 → 3. 對 AI 寫程式代理下指令 → 4. 代理照著工作流程與權限行動CVE-2026-111322 · Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理攻擊者你的系統連到對外開放的 Archon 伺服器埠 — 控制 API 預設綁定 0.0.0.0,也就是所有網路介面,所以同網路、甚至網際網路上的主機都可能連得到。 1連到對外開放的Archon 伺服器埠/api/* 的認證關卡直接放行 — 網頁認證預設關閉;只有同時設定 Postgres 的 DATABASE_URL 與 BETTER_AUTH_SECRET 才會開啟。預設安裝用 SQLite、沒設密鑰,所以每個請求都通過,不需要任何帳號。 2/api/* 的認證關卡直接放行對 AI 寫程式代理下指令 — 攻擊者可以建立並執行工作流程、注入對話訊息,也能核准或取消代理待確認的動作。 3對 AI 寫程式代理下指令代理照著工作流程與權限行動 — VulnCheck 說代理以 bypassPermissions 執行,攻擊者能以 Archon 使用者身分在主機上執行指令;某新聞文章(該頁含攻擊程式,本站不連結)引述研究者表示這不是主機上的遠端程式碼執行。PlainCVE 的判斷:實際損害可能取決於你的工作流程與代理被允許做什麼,這點尚未有人實測確認。 4代理照著工作流程與權限行動攻擊路徑可在此擋下PlainCVE · plaincve.date/vulns/cve-2026-111322-archon-api-missing-auth · CC BY 4.0
Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理: 1. 連到對外開放的 Archon 伺服器埠 → 2. /api/* 的認證關卡直接放行 → 3. 對 AI 寫程式代理下指令 → 4. 代理照著工作流程與權限行動CVE-2026-111322 · Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理連到對外開放的 Archon 伺服器埠 — 控制 API 預設綁定 0.0.0.0,也就是所有網路介面,所以同網路、甚至網際網路上的主機都可能連得到。 1攻擊者連到對外開放的 Archon 伺服器埠/api/* 的認證關卡直接放行 — 網頁認證預設關閉;只有同時設定 Postgres 的 DATABASE_URL 與 BETTER_AUTH_SECRET 才會開啟。預設安裝用 SQLite、沒設密鑰,所以每個請求都通過,不需要任何帳號。 2你的系統/api/* 的認證關卡直接放行對 AI 寫程式代理下指令 — 攻擊者可以建立並執行工作流程、注入對話訊息,也能核准或取消代理待確認的動作。 3攻擊者對 AI 寫程式代理下指令代理照著工作流程與權限行動 — VulnCheck 說代理以 bypassPermissions 執行,攻擊者能以 Archon 使用者身分在主機上執行指令;某新聞文章(該頁含攻擊程式,本站不連結)引述研究者表示這不是主機上的遠端程式碼執行。PlainCVE 的判斷:實際損害可能取決於你的工作流程與代理被允許做什麼,這點尚未有人實測確認。 4你的系統代理照著工作流程與權限行動攻擊路徑可在此擋下PlainCVE · CC BY 4.0plaincve.date/vulns/cve-2026-111322-archon-api-missing-auth
圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。
  1. 攻擊者

    連到對外開放的 Archon 伺服器埠

    控制 API 預設綁定 0.0.0.0,也就是所有網路介面,所以同網路、甚至網際網路上的主機都可能連得到。

    防禦: 把 HOST 設為 127.0.0.1 只允許本機連線,或用防火牆/網段隔離限制誰能連到 /api/*。

  2. 你的系統

    /api/* 的認證關卡直接放行

    網頁認證預設關閉;只有同時設定 Postgres 的 DATABASE_URL 與 BETTER_AUTH_SECRET 才會開啟。預設安裝用 SQLite、沒設密鑰,所以每個請求都通過,不需要任何帳號。

    防禦: 依專案程式碼,開啟網頁認證後關卡預設啟用;不要設定 ARCHON_WEB_AUTH_REQUIRED=false。注意(出自專案程式碼):關卡會把可信反向代理標頭 X-Archon-User 當成身分,index.ts 的程式碼註解說,這個標頭只有在 Archon 只能經由會認證並設定標頭的反向代理連到(綁定 loopback)時才可信,綁在非 loopback 時任何能連到埠的人都能偽造它。因此應由會認證的反向代理轉入並綁定 127.0.0.1;PR #3147 的說明另提到代理部署需明確移除該標頭或綁定本機(出自 PR #3147,不是程式碼註解)。

  3. 攻擊者

    對 AI 寫程式代理下指令

    攻擊者可以建立並執行工作流程、注入對話訊息,也能核准或取消代理待確認的動作。

    防禦: 對外部署時放在有認證的 Caddy 反向代理後面(出自 Archon 的 SECURITY.md)。

  4. 你的系統

    代理照著工作流程與權限行動

    VulnCheck 說代理以 bypassPermissions 執行,攻擊者能以 Archon 使用者身分在主機上執行指令;某新聞文章(該頁含攻擊程式,本站不連結)引述研究者表示這不是主機上的遠端程式碼執行。PlainCVE 的判斷:實際損害可能取決於你的工作流程與代理被允許做什麼,這點尚未有人實測確認。

    防禦: 讓 Archon 用低權限帳號執行,工作流程只給必要的能力。

影響範圍

條件是否受影響
Archon 0.2.13 到 0.11.1 + 網頁認證關閉(預設)+ 伺服器埠可從其他主機連到受影響
同上版本,但 HOST 設為 127.0.0.1只有本機能連,其他主機連不到
已開啟網頁認證,但設了 ARCHON_WEB_AUTH_REQUIRED=false/api/* 關卡仍然關閉,受影響
0.2.13 以前不在 CVE 列出的範圍內
0.12.0、0.12.1(2026-10-17 發布)不在 CVE 列出的範圍內,但沒有修補:v0.12.1 的程式碼仍預設綁定 0.0.0.0、認證關閉時關卡也關閉,條件相同時請比照上面幾列檢查
修補版本目前沒有(見下方)

這裡的「研究者」指發現者 hieuPenguinnn 的研究文章(該頁含攻擊程式,本站不連結)。研究者表示,這個漏洞和 CVE-2025-69443 不同;後者影響的是已封存的 Python 後端。

原理

Archon 是一套 AI 寫程式代理工具,伺服器提供一組 /api/* 控制 API(讓其他程式透過網路下指令的介面),用來建立工作流程、傳訊息給代理、核准或取消代理待確認的動作。

問題出在兩個預設值疊在一起:

  1. 監聽所有網路介面。 控制 API 預設綁定 0.0.0.0,所以不只本機,其他能連到這台主機的電腦也連得到。
  2. 認證預設關閉。 依專案在 v0.11.1 的程式碼,網頁認證只有在同時設定 Postgres 的 DATABASE_URL 與 BETTER_AUTH_SECRET 時才會開啟。研究者指出,預設安裝用 SQLite、沒設密鑰,認證關卡就讓每個請求通過,不確認是誰發的。

結果是:能連到伺服器埠的人不需要帳號,就能驅動 AI 代理。這對應 CWE-306(關鍵功能缺少認證)。維護者的 PR #3147 則明確寫著,沒開認證的單人與 SQLite 安裝會維持現在的開放行為,也就是說這在一定程度上是刻意的設計。

有問題的思路(PlainCVE 的概念示意,不是原始程式碼):

展開程式碼範例(ts)
// 沒設定認證 → 直接放行所有 /api/* 請求
if (!authConfigured) return next();

較安全的思路(PlainCVE 的概念示意,不是專案實際的修補):

展開程式碼範例(ts)
// 沒設定認證時,只接受本機連線;其他一律拒絕
if (!authConfigured && !isLoopback(req)) return reject(401);

能造成多大損害,來源說法不一。 VulnCheck 說代理以 bypassPermissions 執行,攻擊者能以 Archon 使用者身分在主機上執行指令;但某新聞文章(該頁含攻擊程式,本站不連結)引述原研究者的說法,表示這不是主機上的遠端程式碼執行。PlainCVE 的判斷:被劫持的執行能做到什麼,可能取決於你的工作流程與代理被允許做什麼,這點目前沒有人在實際環境中確認。研究者本身也只讀了 v0.11.1 的原始碼,沒有做實際執行驗證。

時間軸

日期事件
2026-09-02維護者 PR #3147 公開(主題是對話歸屬的存取控制),寫明未開認證的單人/SQLite 安裝維持開放行為;沒有提到預設綁定 0.0.0.0,也沒有把它當成這個 CVE 的問題。首次公開仍以 2026-10-15 的 CVE 紀錄為準
2026-09-25v0.11.1 發布,研究者以此版本檢視原始碼
2026-10-15CVE 由 VulnCheck 預留並公開
2026-10-16某新聞文章(該頁含攻擊程式,本站不連結)指出當時最新版仍是 0.11.1,沒有公開的修補或公告
2026-10-17v0.12.0、v0.12.1 發布,版本說明沒有提到這個問題,預設綁定與認證關卡沒有改(依發布紀錄與 v0.12.1 程式碼)
2026-10-18仍未列入 CISA KEV

延伸閱讀

  • 評分差異: VulnCheck(CNA)給 CVSS 4.0 9.3、CVSS 3.1 9.8,都屬「嚴重」;研究者自己的報告則標為「高」。NVD 的分析狀態是「Deferred」(延後)。
  • 編號者: CVE 由 VulnCheck 發放,不是 Archon 專案;GitHub Advisory Database 列為 GHSA-3q7p-hhhj-qh4p,但 GitHub 尚未審核。
  • 利用狀況: 未列入 CISA KEV,也沒有實際遭利用或零時差攻擊的證據。CISA 的 SSVC 把利用狀態標為「poc」(有概念驗證),但某新聞文章(該頁含攻擊程式,本站不連結)說截至 10 月 16 日沒有公開 PoC,研究者的範例請求也沒有在實機上執行過。EPSS 估計約 0.69%(第 51.9 百分位)。
  • 在我們檢視的資料中沒有看到專案發布的安全公告或修補,目前看到的專案議題、PR 與 0.12.x 版本說明也沒有提到這個 CVE。
  • 發現者:hieuPenguinnn。

驗證紀錄 AI 依審稿規則逐項核對來源,全部通過;未經人工審稿,也尚未在我們的環境重現

AI 審稿2026-10-20 · 審稿規則

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見 政策.

來源

  1. CVE / NVD / OSVCVE-2026-111322 Record (CVE Services API) · CVE Program / VulnCheck (CNA), 2026-10-15 · 查閱 2026-10-18
  2. CVE / NVD / OSVNVD - CVE-2026-111322 · NIST · 查閱 2026-10-18
  3. 安全公告Archon 0.2.13 through 0.11.1 Missing Authentication via /api/* Control API · VulnCheck · 查閱 2026-10-18
  4. 安全公告GitHub Advisory Database entry GHSA-3q7p-hhhj-qh4p (unreviewed) · GitHub · 查閱 2026-10-18
  5. 其他OSV - CVE-2026-111322 · OSV · 查閱 2026-10-18
  6. 廠商說明Archon releases (GitHub) · coleam00/Archon (GitHub) · 查閱 2026-10-18
  7. 廠商說明Archon commit aa095446 (Release 0.11.1) · coleam00/Archon (GitHub) · 查閱 2026-10-18
  8. 廠商說明Archon server entry at v0.12.1 (packages/server/src/index.ts) · coleam00/Archon (GitHub) · 查閱 2026-10-18
  9. 廠商說明Archon API routes at v0.12.1 (packages/server/src/routes/api.ts) · coleam00/Archon (GitHub) · 查閱 2026-10-20
  10. 廠商說明Archon auth config at v0.12.1 (packages/server/src/auth/config.ts) · coleam00/Archon (GitHub) · 查閱 2026-10-18
  11. 廠商說明Archon .env.example at v0.11.1 · coleam00/Archon (GitHub) · 查閱 2026-10-18
  12. 廠商說明Archon auth config at v0.11.1 (packages/server/src/auth/config.ts) · coleam00/Archon (GitHub) · 查閱 2026-10-18
  13. 廠商說明Archon PR #3147 · coleam00/Archon (GitHub) · 查閱 2026-10-18
  14. 廠商說明Archon SECURITY.md at v0.11.1 · coleam00/Archon (GitHub) · 查閱 2026-10-20
  15. 其他CVE-2026-111322: Missing Authentication for Critical Function in coleam00 Archon · OffSeq Radar · 查閱 2026-10-18

媒體簡報

一句話

Archon 是一套開源的 AI 寫程式代理工具。它的 /api/* 控制 API 在 0.2.13 到 0.11.1 版預設不需要登入,而且監聽所有網路介面,能連到伺服器的人就能指揮 AI 代理。CVE 於 2026 年 10 月 15 日公開,由 VulnCheck 編號並給予 CVSS 4.0 9.3 分。目前沒有官方修補:10 月 17 日發布的 0.12.0、0.12.1 版本說明沒有提到這個問題,預設值也沒有改。目前沒有被列入 CISA 已知遭利用漏洞清單,也沒有實際遭利用的證據。

關鍵數字

受影響版本
0.2.13 到 0.11.1(含) cveawg.mitre.org
嚴重度
CVSS 4.0 9.3、CVSS 3.1 9.8(VulnCheck,CNA) cveawg.mitre.org
公開日期
2026-10-15 cveawg.mitre.org
發現者
hieuPenguinnn vulncheck.com
修補狀態
沒有官方修補;最新版 v0.12.1(2026-10-17)的版本說明沒有提到此問題 github.com
v0.12.1 預設值
v0.12.1 程式碼仍預設綁定 0.0.0.0(HOST 未設定時) raw.githubusercontent.com
EPSS
約 0.69%(第 51.9 百分位) api.github.com

已確認

  • 0.2.13 到 0.11.1 的 /api/* 控制 API 缺少認證,且預設綁定 0.0.0.0。
  • 依專案程式碼,網頁認證預設關閉,只有同時設定 Postgres DATABASE_URL 與 BETTER_AUTH_SECRET 才開啟。
  • 截至 2026-10-18 未列入 CISA KEV。
  • 沒有官方修補:CVE 紀錄沒有修補版本;OSV 列為 fixed 的 commit aa095446 是 v0.11.1 的發布 commit;v0.12.1 的程式碼仍預設綁定 0.0.0.0、認證關閉時 /api/* 關卡也關閉。

尚未確認 / 說法不一

  • 能否在主機上執行指令:VulnCheck 說可以;某新聞文章(該頁含攻擊程式,本站不連結)引述研究者說這不是主機上的遠端程式碼執行。
  • 是否有公開概念驗證:CISA 的 SSVC 標為「poc」,某新聞文章(該頁含攻擊程式,本站不連結)說截至 10 月 16 日沒有公開 PoC,研究者的範例也沒在實機上跑過。
  • 研究者只讀過原始碼,沒有在實際執行環境驗證;也沒有實際遭利用的證據。

可引用的一句話

當 AI 代理的遙控器預設放在公開的桌上,問題就不只是程式碼,而是誰都能按下按鈕。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。 完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理》。PlainCVE。https://plaincve.date/vulns/cve-2026-111322-archon-api-missing-auth(查閱日期:YYYY-MM-DD)
BibTeX
@misc{cve2026111322archonapimissingauth2026,
  title  = {Archon 控制 API 預設不需登入:同網路的人都能操控 AI 寫程式代理},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-111322-archon-api-missing-auth},
  note   = {更新於 2026-10-20}
}