PHP 的 CVE-2026-109618 洩漏事件在 Hacker News 鬧得沸沸揚揚，一個開發者因為「不知道有封鎖期」提前公開了遠端代碼執行漏洞。這聽起來像是一場技術圈的公關災難，但對我們這些天天對著 Grok 或 ChatGPT 敲指令的人來說，這暴露了一個極其危險的技術斷層：當安全專家還在討論協同披露的時間表時，AI 早就把這些漏洞資訊吃進去，甚至開始教人怎麼寫 PoC 了。這不是假設，這是現在進行式。
我們在處理這類高風險漏洞時，最怕的就是這種「資訊不對稱」。當事人在論壇上發道歉信，說他聽信了聯絡人的話，以為沒有封鎖期（Embargo）。這種溝通鏈的斷裂，在傳統社群是負擔，在 AI 時代則是災難。如果你現在去問 Grok 關於這兩個 CVE 的細節，它會根據 X 上的實時討論給你一個似是非是的答案。這種實時性是 xAI 的招牌，但也可能是安全防線的破口。馬斯克追求的 Truth 往往走在安全規程的前面，這讓 Grok 在處理未公開漏洞時，顯得比其他三家更像個沒保險栓的火藥桶。
ChatGPT 的做法則完全相反。OpenAI 的對齊團隊（Alignment Team）顯然給它灌了大量的安全守則。如果你嘗試讓它分析這類剛爆出來、還處於封鎖期的 RCE 漏洞，它會開始跟你繞圈子，吐出一堆「我無法提供未經證實的安全漏洞細節」之類的廢話。這種過度保護在技術研究員眼中簡直是浪費時間。明明漏洞已經在 AWS 的安全部落格上被點名正在被利用，ChatGPT 卻還在那裡假裝歲月靜好。這種時差感，讓它在應對零日攻擊（0-day）的預警任務中幾乎處於半殘狀態。
相較於 DeepSeek，xAI 在處理即時安全威脅時的動態抓取邏輯顯然更激進。Gemini 在這方面的表現則介於兩者之間，Google 擁有全球最大的漏洞掃描索引，它對 CVE 的理解通常比其他模型更深。但問題在於，Gemini 的過濾器（Safety Filter）有時候會出現莫名其妙的幻覺，它會把已知的補丁細節跟過時的 PHP 版本混為一談。在 PHP 這種有著固定四週發布週期的生態系裡，任何一點版本號的錯位，都可能導致開發者誤判風險。
這場 RCE 洩漏事件中最刺眼的一點是，當事人 Pete 提到他自己編譯 PHP 原始碼，並追蹤發布週期，這種硬核的開發者行為，本應是安全社群的最後一道防線。然而，當 AI 模型開始介入這個過程時，我們發現規則變了。Claude 在處理長文本的技術細節上確實有優勢，如果你把 PHP 的原始碼變更（Diff）丟給它，它能比 GPT-4o 更精準地指出潛在的記憶體溢位點。但在面對「封鎖期」這種人類社會的潛規則時，Claude 表現得像個只會讀說明書的機器人。它不懂什麼叫「協同披露」，它只知道你給它的文本裡有沒有漏洞。
這引發了一個更深層的技術焦慮。如果一個漏洞已經在特定市場或某些非公開管道流傳，而我們的 AI 助手卻因為所謂的「安全協議」拒絕向防守方提供分析，這是不是在變相幫助攻擊者？攻擊者可不會管什麼封鎖期，他們會利用一切工具，包括那些沒有限制的模型來自動化尋找利用點。我們現在面臨的情況是：防守方在用帶著鐐銬的 ChatGPT，而洩漏資訊的人（不論是有意還是無意）已經在 X 或論壇上把數據餵給了那些抓取速度極快的模型。
大家都在談 AI 安全，但沒人在談「AI 的安全時差」。當一個漏洞已經在 AWS 的威脅情報中出現，卻因為 PHP 官方還沒正式發布補丁，AI 到底該選擇告訴你真相，還是選擇遵守那個已經崩潰的封鎖協議？這不是一個簡單的技術問題，這涉及到模型對「事實」與「合規」的權重分配。
如果下次再發生類似的 Embargo 破裂，我們是該責怪那個發帖的開發者，還是該問問：為什麼我們的 AI 助手在關鍵時刻，總是比漏洞利用程式慢了半拍？如果 AI 的知識庫永遠存在這幾天的「道德緩衝期」，那麼在真正的網路戰爭面前，這點緩衝期到底是在保護誰？