僅僅一個(gè)不起眼的分號(hào)，就能讓任何擁有倉(cāng)庫(kù)推送權(quán)限的GitHub用戶，在服務(wù)端執(zhí)行任意指令。這次漏洞撕開的不只是一處輸入校驗(yàn)的疏漏，更是多租戶云平臺(tái)延續(xù)多年的內(nèi)部信任假設(shè)。

2026年3月4日，安全公司W(wǎng)iz通過(guò)漏洞賞金計(jì)劃向GitHub提交了一份漏洞報(bào)告，這個(gè)漏洞的攻擊入口簡(jiǎn)單到出人意料：

一次構(gòu)造過(guò)的git推送，只需要在推送選項(xiàng)的值中藏入一個(gè)分號(hào)。

GitHub內(nèi)部?jī)H用40分鐘就復(fù)現(xiàn)了漏洞，從確認(rèn)根因到完成云端修復(fù)上線總共只用了75分鐘，全程不到兩小時(shí)。

從理論上來(lái)說(shuō)，任何對(duì)目標(biāo)倉(cāng)庫(kù)擁有推送權(quán)限的已認(rèn)證用戶，都可以借助這個(gè)漏洞在處理推送請(qǐng)求的GitHub/GHES后端服務(wù)器上執(zhí)行任意命令。

盡管GitHub官方博客明確聲明「沒(méi)有任何客戶數(shù)據(jù)被訪問(wèn)、修改或泄露」，并且根據(jù)漏洞利用鏈的特征，該漏洞只會(huì)觸發(fā)正常GitHub運(yùn)營(yíng)流程不會(huì)走到的異常代碼路徑，GitHub查詢遙測(cè)數(shù)據(jù)后，確認(rèn)除了Wiz的測(cè)試之外，沒(méi)有發(fā)現(xiàn)該漏洞被實(shí)際利用的記錄。Wiz也公開表示「我們沒(méi)有訪問(wèn)任何其他租戶的倉(cāng)庫(kù)內(nèi)容」。

但這場(chǎng)風(fēng)波，還是撬開了那個(gè)被業(yè)內(nèi)信任了多年的內(nèi)部信任假設(shè)。

一個(gè)分號(hào)擊穿三層內(nèi)部信任

想要理清這個(gè)漏洞的完整攻擊鏈，需要先了解GitHub內(nèi)部git推送流水線的運(yùn)行邏輯：

當(dāng)你執(zhí)行g(shù)it push推送代碼后，請(qǐng)求進(jìn)入GitHub內(nèi)部的第一個(gè)節(jié)點(diǎn)是babeld——這是GitHub自研的git代理，負(fù)責(zé)把用戶連接轉(zhuǎn)發(fā)給下游服務(wù)。

babeld首先會(huì)向gitauth詢問(wèn)：請(qǐng)求推送的用戶有沒(méi)有對(duì)應(yīng)權(quán)限，這次推送需要遵守哪些規(guī)則？gitauth會(huì)返回一份規(guī)則清單，包含文件大小上限、分支命名規(guī)則、鉤子配置等信息。

babeld會(huì)把這份規(guī)則清單打包進(jìn)名為X-Stat的內(nèi)部請(qǐng)求頭，轉(zhuǎn)發(fā)給下游的gitrpcd服務(wù)。

gitrpcd是GitHub內(nèi)部的RPC服務(wù)，它只認(rèn)X-Stat這個(gè)請(qǐng)求頭，并且完全信任請(qǐng)求頭里的所有內(nèi)容。

最后，負(fù)責(zé)推送前最終檢查的pre-receive鉤子拿到X-Stat，再?zèng)Q定這次推送是否允許通過(guò)。

整條流水線中，X-Stat頭就是通行無(wú)阻的通行證。

GitHub內(nèi)部git push流水線：babeld → gitauth → gitrpcd → pre-receive hook

這個(gè)X-Stat頭的格式是一串用分號(hào)分隔的key=value鍵值對(duì)，比如a=1；b=2；c=3。解析時(shí)會(huì)把所有鍵值對(duì)依次存入字典，如果同一個(gè)key出現(xiàn)多次，后出現(xiàn)的值會(huì)默認(rèn)覆蓋掉之前的值。

問(wèn)題到底出在哪？

git推送本身有一個(gè)正常功能叫push option，允許用戶推送代碼時(shí)附帶傳遞自定義字符串給服務(wù)端。babeld會(huì)把這些自定義字符串原樣打包進(jìn)X-Stat頭，格式為push_option_0=用戶內(nèi)容；push_option_1=用戶內(nèi)容。但babeld漏掉了最關(guān)鍵的一步：沒(méi)有對(duì)用戶傳入的內(nèi)容過(guò)濾分號(hào)。

X-Stat原本有一個(gè)控制文件大小限制開關(guān)的字段，名為large_blob_rejection_enabled，默認(rèn)值為true，也就是開啟限制。攻擊者只需要構(gòu)造一個(gè)push option，在值里先插入一個(gè)分號(hào)，再跟上large_blob_rejection_enabled=bool:false，babeld就會(huì)把這段內(nèi)容原樣寫入X-Stat頭，導(dǎo)致同一個(gè)key在頭里出現(xiàn)了兩次。

X-Stat字段注入示意：攻擊者構(gòu)造的push option覆蓋合法字段的過(guò)程

解析時(shí)后寫入的攻擊者值覆蓋了原本的合法值，文件大小限制就這么被輕松關(guān)閉了。整個(gè)攻擊的起點(diǎn)，就是babeld少寫的那一行過(guò)濾分號(hào)的代碼。

其實(shí)這個(gè)漏洞背后的邏輯，在很多系統(tǒng)中都普遍存在：多個(gè)服務(wù)串聯(lián)成一條流水線，每個(gè)節(jié)點(diǎn)只負(fù)責(zé)完成自己的任務(wù)，默認(rèn)相信上游傳遞來(lái)的數(shù)據(jù)是干凈安全的，全程沒(méi)有任何節(jié)點(diǎn)做二次校驗(yàn)。

babeld沒(méi)攔住惡意分號(hào)，gitrpcd收到數(shù)據(jù)不做驗(yàn)證，pre-receive鉤子拿到字段直接使用，每一站都默認(rèn)上游傳來(lái)的內(nèi)容可信，三層信任疊在一起，被一個(gè)分號(hào)全部擊穿。

三步注入拿到服務(wù)器權(quán)限，GitHub公共版也被攻破

繞過(guò)文件大小限制，只是Wiz用來(lái)驗(yàn)證注入可行性的第一步測(cè)試，攻擊的真正目標(biāo)是拿到后端服務(wù)器的執(zhí)行權(quán)限。

第一步攻擊者先注入字段關(guān)閉沙箱：GHES（GitHub Enterprise Server，GitHub企業(yè)自建版）允許管理員自定義鉤子腳本，在代碼推送前自動(dòng)運(yùn)行，這些腳本默認(rèn)在權(quán)限受限的沙箱中運(yùn)行。但Wiz逆向分析后發(fā)現(xiàn)，沙箱是否啟用由X-Stat頭中的rails_env字段控制：值為production就進(jìn)入沙箱，填其他任何值都會(huì)直接以git服務(wù)賬戶的身份運(yùn)行腳本，沒(méi)有任何隔離。而這個(gè)字段可以通過(guò)剛才的注入方法覆蓋修改。

第二步注入custom_hooks_dir字段，把系統(tǒng)查找鉤子腳本的根目錄，從默認(rèn)位置改成攻擊者可以控制的路徑。

第三步注入repo_pre_receive_hooks字段，填入路徑穿越字符串，讓系統(tǒng)跳出默認(rèn)目錄范圍，去執(zhí)行服務(wù)器上任意一個(gè)二進(jìn)制文件。

三步串聯(lián)完成后，GHES服務(wù)器返回了這樣一行輸出：remote: uid=500(git) gid=500(git) groups=500(git)，這意味著攻擊者已經(jīng)成功以git服務(wù)賬戶的身份在GHES服務(wù)器上執(zhí)行了代碼。

Wiz研究員sagitz在X平臺(tái)展示的概念驗(yàn)證：普通的git push命令后，遠(yuǎn)端服務(wù)器返回uid=500(git)，證明代碼已經(jīng)以git服務(wù)賬戶身份在GitHub后端執(zhí)行

Wiz一開始把同樣的攻擊鏈用在GitHub公共版GitHub.com上沒(méi)有成功，推送完成后鉤子沒(méi)有觸發(fā)，服務(wù)器也沒(méi)有返回內(nèi)容。繼續(xù)逆向分析后才發(fā)現(xiàn)，X-Stat里還有一個(gè)標(biāo)志位控制服務(wù)器是否以「企業(yè)模式」運(yùn)行：GHES默認(rèn)開啟這個(gè)標(biāo)志，因此自定義鉤子可以正常運(yùn)行，而GitHub.com默認(rèn)關(guān)閉這個(gè)標(biāo)志，自定義鉤子根本不會(huì)被觸發(fā)。但這個(gè)標(biāo)志同樣存在X-Stat頭里，也可以通過(guò)注入覆蓋。補(bǔ)上這第四步之后，整條攻擊鏈徹底打通，Wiz在GitHub.com上成功執(zhí)行了hostname命令，服務(wù)器返回了一個(gè)以.github.net結(jié)尾的內(nèi)部主機(jī)名——攻擊成功進(jìn)入了GitHub公共版后端。

GitHub在事后博客中也承認(rèn)，那條非生產(chǎn)環(huán)境的執(zhí)行路徑本來(lái)就不應(yīng)該出現(xiàn)在GitHub.com的生產(chǎn)環(huán)境中：早期部署時(shí)曾經(jīng)專門把這段代碼排除在外，后來(lái)部署方式變更，排除代碼的邏輯沒(méi)有跟著遷移，這段廢棄代碼就悄悄留在了生產(chǎn)鏡像里，一直沒(méi)有人發(fā)現(xiàn)。漏洞利用能順利打通，恰恰就是因?yàn)檫@段「不該存在」的代碼偏偏留存在了生產(chǎn)環(huán)境中。

Wiz在測(cè)試中枚舉了兩臺(tái)被攻陷的節(jié)點(diǎn)，每臺(tái)節(jié)點(diǎn)上都能看到百萬(wàn)級(jí)其他用戶和組織的倉(cāng)庫(kù)索引項(xiàng)，他們公開說(shuō)明：

沒(méi)有讀取任何其他用戶的倉(cāng)庫(kù)內(nèi)容，只是用自己的測(cè)試賬戶確認(rèn)了一件事：git賬戶確實(shí)擁有訪問(wèn)這臺(tái)節(jié)點(diǎn)上所有倉(cāng)庫(kù)的權(quán)限。

GitHub的日志也印證了這一點(diǎn)：所有觸發(fā)異常代碼路徑的記錄全部來(lái)自Wiz的測(cè)試流量，沒(méi)有發(fā)現(xiàn)其他賬戶的觸發(fā)記錄。能訪問(wèn)和實(shí)際竊取數(shù)據(jù)是完全不同的兩件事，這次事件只停留在了可訪問(wèn)階段，沒(méi)有發(fā)生真實(shí)的數(shù)據(jù)泄露。但問(wèn)題的根源還是出在多租戶平臺(tái)的底層設(shè)計(jì)上：GitHub.com把大量用戶和組織的倉(cāng)庫(kù)放在同一批服務(wù)器上，統(tǒng)一交給同一個(gè)git服務(wù)賬戶管理——因?yàn)檫@個(gè)賬戶本來(lái)就需要處理所有用戶的數(shù)據(jù)。只要攻擊者拿到了這個(gè)賬戶的執(zhí)行權(quán)限，該節(jié)點(diǎn)上的所有倉(cāng)庫(kù)都會(huì)對(duì)攻擊者開放，共享架構(gòu)帶來(lái)了運(yùn)營(yíng)效率，也留下了這個(gè)無(wú)法徹底消除的結(jié)構(gòu)性弱點(diǎn)。

云端兩小時(shí)完成修復(fù)，自建實(shí)例多數(shù)仍未補(bǔ)丁

這次漏洞最難收尾的其實(shí)是用戶自建的GHES實(shí)例：在Wiz公開披露漏洞時(shí)，統(tǒng)計(jì)顯示有88%的GHES實(shí)例還沒(méi)有安裝修復(fù)補(bǔ)丁。

按照GitHub官方的修復(fù)建議和NVD的記錄，管理員需要升級(jí)到對(duì)應(yīng)受支持分支的最新補(bǔ)丁版本，目前公開的修復(fù)版本包括3.14.25、3.15.20、3.16.16、3.17.13、3.18.7、3.19.4，以及3.20.0或更高版本。GHES管理員需要做兩件事：立刻升級(jí)版本，然后查看/var/log/github-audit.log日志，搜索推送選項(xiàng)中包含分號(hào)的記錄，核查是否存在未授權(quán)的注入攻擊痕跡。

這個(gè)漏洞的觸發(fā)門檻并不高，只需要已認(rèn)證用戶對(duì)實(shí)例上任意倉(cāng)庫(kù)擁有推送權(quán)限即可：攻擊者只要拿到企業(yè)內(nèi)部一個(gè)普通員工的賬號(hào)，哪怕這個(gè)賬號(hào)只能推送一個(gè)不起眼的內(nèi)部項(xiàng)目，就能直接拿到整個(gè)GHES實(shí)例的服務(wù)器執(zhí)行權(quán)限。而GHES通常存儲(chǔ)著企業(yè)全部的代碼資產(chǎn)、CI配置、內(nèi)部憑證，一旦被攻破后果非常嚴(yán)重。并且這個(gè)漏洞也不是GHES管理員當(dāng)前需要修復(fù)的唯一高危漏洞。

GitHub Enterprise Server 3.19.5版本更新說(shuō)明，單個(gè)版本同期修復(fù)了四個(gè)高危漏洞，鏈接：https://docs.github.com/en/enterprise-server@3.19/admin/release-notes

僅看3.19.5這一個(gè)版本的更新說(shuō)明，同期修復(fù)的高危漏洞就還有四個(gè)：CVE-2026-5845、CVE-2026-5921、CVE-2026-4821、CVE-2026-4296。使用SaaS托管代碼，補(bǔ)丁打好之后會(huì)自動(dòng)生效，而自建GHES需要管理員手動(dòng)跟進(jìn)每一個(gè)補(bǔ)丁升級(jí)，很多企業(yè)的升級(jí)進(jìn)度都遠(yuǎn)遠(yuǎn)滯后。

AI降低逆向成本，閉源軟件的「安全護(hù)城河」正在消失

這次漏洞披露還有一個(gè)很容易被忽略的細(xì)節(jié)：Wiz在技術(shù)博客中專門解釋了這次能找到漏洞的原因。GitHub內(nèi)部的git流水線都是編譯后的閉源二進(jìn)制文件，之前不是沒(méi)人想過(guò)審計(jì)，但是人工逆向的成本太高，往往做到一半就放棄了。這次重新開展審計(jì)，是因?yàn)槟嫦蚬ぞ咭呀?jīng)變了。

過(guò)去很多閉源軟件所謂的「相對(duì)安全」，并不是代碼本身足夠嚴(yán)密，而是依賴逆向分析成本太高這個(gè)門檻，沒(méi)人愿意花大代價(jià)來(lái)審計(jì)挖掘漏洞。代碼不公開不代表不能被審計(jì)，只是過(guò)去審計(jì)閉源軟件在經(jīng)濟(jì)上不劃算，現(xiàn)在這筆賬的算法已經(jīng)徹底變了。

過(guò)去資深逆向工程師需要投入幾個(gè)月才能完成的工作，用AI工具組合只需要幾周就能完成一輪審計(jì)。Wiz也公開說(shuō)明，這次是他們公開記錄中，第一批依靠AI在閉源二進(jìn)制中找到關(guān)鍵級(jí)漏洞的案例，使用的組合是IDA Pro加MCP協(xié)議加大語(yǔ)言模型。

Wiz Research博客認(rèn)為：AI增強(qiáng)的逆向工程工具，將會(huì)在發(fā)現(xiàn)需要深入跨組件分析的漏洞類型方面發(fā)揮越來(lái)越重要的作用，鏈接：https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854

現(xiàn)在AI不只是在幫助開發(fā)者寫代碼，也在幫助安全研究者拆代碼找漏洞。所有長(zhǎng)期靠「閉源沒(méi)人審」維持安全狀態(tài)的系統(tǒng)，都應(yīng)該重新評(píng)估自己真實(shí)的暴露風(fēng)險(xiǎn)了。

被分號(hào)撬開的信任假設(shè)，留下三個(gè)值得深思的問(wèn)題

回到這次漏洞事件本身，CVE-2026-3854披露后，GitHub的應(yīng)急響應(yīng)可以說(shuō)是教科書級(jí)別，補(bǔ)丁及時(shí)到位，也沒(méi)有發(fā)現(xiàn)已知的真實(shí)攻擊利用。但這件事還是留下了三個(gè)值得后端開發(fā)者認(rèn)真思考的結(jié)論：

第一，系統(tǒng)設(shè)計(jì)層面的隱患比單點(diǎn)漏洞更難察覺(jué)。分隔符協(xié)議、跨服務(wù)隱式信任、后寫入覆蓋先寫入的解析語(yǔ)義，這三個(gè)設(shè)計(jì)單獨(dú)存在都不是大問(wèn)題，組合在一起就是定時(shí)炸彈。任何使用分號(hào)、豎線或換行傳遞內(nèi)部元數(shù)據(jù)的系統(tǒng)，開發(fā)者今天就應(yīng)該去檢查一遍代碼。

第二，多租戶平臺(tái)的風(fēng)險(xiǎn)是結(jié)構(gòu)性的，這不只是GitHub一家的問(wèn)題。只要不同用戶的數(shù)據(jù)存放在同一臺(tái)機(jī)器上，由同一個(gè)服務(wù)賬戶管理，這個(gè)風(fēng)險(xiǎn)點(diǎn)就一直存在。攻擊者一旦拿到執(zhí)行權(quán)限，系統(tǒng)隔離能起到多少防護(hù)作用，完全取決于共享賬戶的權(quán)限邊界設(shè)計(jì)得夠不夠嚴(yán)謹(jǐn)。

第三，AI輔助逆向已經(jīng)重新改寫了攻防的成本平衡，AI輔助逆向正在改變攻防雙方的成本結(jié)構(gòu)，下一批被挖出大量關(guān)鍵漏洞的，大概率就是那些長(zhǎng)期靠「閉源沒(méi)人審」支撐的企業(yè)級(jí)軟件。

這次GitHub沒(méi)有發(fā)生真實(shí)的數(shù)據(jù)泄露，所以更值得我們認(rèn)真討論這件事：那個(gè)被信任了多年的X-Stat內(nèi)部頭，在一個(gè)小小的分號(hào)面前，沒(méi)有起到任何防護(hù)作用，原本牢不可破的內(nèi)部信任假設(shè)，就這樣被輕易擊穿。

參考資料：

https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854

https://x.com/sagitz_/status/2049153195243372569?s=20

本文來(lái)自微信公眾號(hào)“新智元”，作者：新智元，編輯：元宇，36氪經(jīng)授權(quán)發(fā)布。

本文僅代表作者觀點(diǎn)，版權(quán)歸原創(chuàng)者所有，如需轉(zhuǎn)載請(qǐng)?jiān)谖闹凶⒚鱽?lái)源及作者名字。

免責(zé)聲明：本文系轉(zhuǎn)載編輯文章，僅作分享之用。如分享內(nèi)容、圖片侵犯到您的版權(quán)或非授權(quán)發(fā)布，請(qǐng)及時(shí)與我們聯(lián)系進(jìn)行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com