An AI-driven penetration testing agent, working during an authorized assessment, identified a critical authentication bypass on the live production website of a major insurer without human direction — a flaw in which a single login request could dictate where a one-time passcode (OTP) was sent, The Hacker News reported on 14 October. The vulnerability itself was mundane. The way it was found, and the difficulty of proving it safely, are what make the case worth the security community's attention.
The flaw: a controllable destination
As reported by The Hacker News, the defect was a logic error rather than a cryptographic one. Somewhere within the insurer's login flow, the field determining where the sign-in code was delivered — a phone number or email address — could be influenced from the client side. An attacker able to substitute their own destination would receive a legitimate, correctly issued code intended for someone else's account, and could then complete the sign-in. No code was cracked, no session hijacked by force; the system simply failed to check that whoever requested the code was entitled to say where it should go.
That failure mode matters for remediation. Hardening the OTP generation, shortening its expiry, or rate-limiting attempts would not close this gap. The fix is structural: OTP delivery must be bound server-side to the stored contact details of the authenticated user record, with the destination treated as read-only data that the client can display but never set.
Why the hunt was harder than the hack
The insurer's identity and the jurisdiction of the assessment were not disclosed, and the target is not a Hong Kong organisation. What makes the story broadly instructive is the combination of an unglamorous, years-old class of bug surviving on a system that had presumably already passed human review — and an autonomous agent finding it unprompted on a production environment.
The genuinely hard part, as reported, was not exploitation but verification. Demonstrating an authentication bypass on a live site without tripping fraud detection, disrupting genuine customers, or producing evidence that itself leaks user data remains a judgement call. That boundary — between AI-assisted testing, where a human drives and interprets, and fully AI-operated testing against production — is where governance still has to sit. It raises a practical question for any team deploying these tools: if an agent can surface a critical finding faster than your team can triage, validate, and responsibly disclose it, your response pipeline is now the bottleneck, not the scanner.
What to check this week
The defect is generic, and it converts into a short audit list for any organisation — and in Hong Kong, most of them — still leaning on SMS or email codes as the default second factor:
- Trace the origin of the OTP destination. If any request parameter, hidden field, or client-side state can change where the code goes, the flow is broken by design. Delivery should reference only server-held user data.
- Sweep the rest of the authentication path. "Resend code," contact-detail changes, password recovery, and step-up prompts are classic hiding places for client-controllable state. Flaws of this kind are rarely on the main login form; they live at the edges.
- Plan the exit from OTP. Every SMS or email code remains phishable by construction. Phishing-resistant options — passkeys, hardware-backed authenticators — belong on a funded roadmap rather than a wish list.
The lesson is not merely that AI found a bug. It is that an autonomous agent found a critical, unglamorous authorization flaw on a live system that humans had already reviewed — and that, given how widely this pattern is deployed, the useful window to fix it may now be bounded by how quickly such tools propagate.
Source: The Hacker News
據The Hacker News於10月14日報道，一個由AI驅動的滲透測試代理，在一次已授權的評估過程中，無需人為指示，便在一間大型保險公司的正式運作網站上識別出一個致命的身份驗證繞過漏洞——攻擊者只需一個登入請求，便能決定一次性密碼（OTP）發送到哪裡。漏洞本身其實平淡無奇；真正值得安全界關注的，是它被發現的方式，以及安全地證明該漏洞存在的難度。
漏洞：一個可被控制的目的地
據The Hacker News報道，該缺陷屬邏輯錯誤而非加密問題。在保險公司的登入流程中，決定登入驗證碼發送目的地（電話號碼或電郵地址）的欄位，可從用戶端（client side）被影響。攻擊者若能替換成自己的目的地，便會收到為他人帳戶合法發出的正確驗證碼，從而完成登入。沒有任何密碼被破解，也沒有會話被強行劫持；系統只是沒有檢查請求驗證碼的人是否有權指定發送目的地。
這種失效模式對修補工作至關重要。加強OTP生成機制、縮短其有效期，或對嘗試次數進行速率限制，都無法堵上這個漏洞。修復方案必須從架構入手：OTP的發送必須在伺服器端綁定至已認證用戶記錄中的聯絡資料，目的地應視為唯讀數據，用戶端可以顯示但絕不能設定。
為何搜尋比入侵更困難
保險公司的身份及評估所屬司法管轄區均未披露，目標亦非香港機構。這則新聞之所以具有廣泛的啟示意義，在於其組合：一個毫不起眼、存在多年的漏洞類別，存活在一個理應已通過人為審查的系統上——再加上一個自主代理在正式運作環境中主動發現了它。
據報道，真正困難的部分並非利用漏洞，而是驗證。如何在一個正式運作的網站上證明存在身份驗證繞過，同時又不觸發詐騙偵測、不影響真實客戶，亦不產生本身會洩露用戶數據的證據，至今仍需依靠判斷。在AI輔助測試（由人類主導和解讀）與完全由AI針對正式系統操作的測試之間，這條界線正是治理機制必須介入之處。這為所有部署此類工具的團隊提出了一個實際問題：如果一個代理能比你的團隊更快提出關鍵發現，而你的團隊尚未完成分類、驗證及負責任披露，那麼現在的瓶頸已不再是掃描器，而是你的回應流程。
本周應檢查的事項
該缺陷具有普遍性，可轉化為任何機構的簡短審計清單——在香港，大多數機構仍依賴SMS或電郵驗證碼作為預設的第二重驗證因素：
- 追查OTP目的地的來源。 如果任何請求參數、隱藏欄位或用戶端狀態能改變驗證碼的發送對象，則該流程在設計上已經失效。發送目的地只應引用伺服器持有的用戶數據。
- 全面檢查身份驗證路徑的其餘部分。 「重新發送驗證碼」、聯絡資料修改、密碼重設及步驟升級提示，都是用戶端可控狀態的典型藏身之處。此類漏洞很少出現在主要登入表格上；它們往往存在於邊緣位置。
- 規劃退出OTP的路線。 每一種SMS或電郵驗證碼在設計上都可被釣魚。具備釣魚防禦能力的選項——passkeys、以硬件為基礎的認證器——應納入有預算的發展路線圖，而非僅是願望清單。
教訓並非僅僅是AI發現了一個漏洞。真正的意義在於：一個人類已經審查過的正式運作系統上，一個自主代理發現了一個致命且不起眼的授權漏洞——而且，鑑於這種模式部署之廣泛，修復它的最佳時機窗口，可能已取決於此類工具傳播的速度。
資料來源：The Hacker News