全球超過4億臺(tái)服務(wù)器在用的NGINX，被一個(gè)視頻文件攻破了。CVE-2026-32647，CVSS v4.0評(píng)分8.5——這是今年開年以來Web服務(wù)器領(lǐng)域最嚴(yán)重的本地提權(quán)漏洞之一。

F5安全公告里的措辭很克制："允許本地認(rèn)證攻擊者觸發(fā)拒絕服務(wù)或潛在執(zhí)行任意代碼。"翻譯成人話：如果你有服務(wù)器賬號(hào)，上傳一個(gè)精心構(gòu)造的MP4，就能讓NGINX worker進(jìn)程崩潰，甚至拿到shell。

漏洞藏在最不起眼的模塊里

出問題的是ngx_http_mp4_module，一個(gè)處理MP4流媒體的老模塊。這個(gè)模塊從NGINX 1.1.19版本就存在，至今已經(jīng)14年。

漏洞類型是CWE-125，越界讀取。攻擊者構(gòu)造的惡意MP4會(huì)讓worker進(jìn)程在解析時(shí)發(fā)生緩沖區(qū)溢出或下溢，進(jìn)程直接被系統(tǒng)殺死。NGINX主進(jìn)程會(huì)嘗試重啟worker，但在此期間，活躍連接全部中斷。

更麻煩的是內(nèi)存損壞的連鎖反應(yīng)。安全研究者Xint Code和Pavel Kohout來自Aisle Research，他們?cè)趨f(xié)調(diào)披露時(shí)發(fā)現(xiàn)：這個(gè)內(nèi)存破壞點(diǎn)理論上可以被利用來執(zhí)行遠(yuǎn)程代碼。雖然F5公告里用了"潛在"這種模糊詞，但8.5的CVSS評(píng)分已經(jīng)說明問題嚴(yán)重性。

影響范圍劃得很清楚：NGINX Plus R32到R36全中，NGINX開源版1.1.19到1.29.6全中。修復(fù)版本分別是R36 P3、R35 P2、R32 P5，以及開源版的1.28.3和1.29.7。

有個(gè)細(xì)節(jié)很多人沒注意：NGINX Plus默認(rèn)打包了這個(gè)模塊，開箱即用即風(fēng)險(xiǎn)。開源版用戶相對(duì)安全——除非你手動(dòng)編譯時(shí)加了--with-http_mp4_module，并且在配置文件里寫了mp4指令。

攻擊面比想象中窄，但剛好打在痛點(diǎn)上

這個(gè)漏洞的利用條件有三層：本地訪問、認(rèn)證賬號(hào)、目標(biāo)服務(wù)器啟用了MP4模塊?？雌饋黹T檻很高，但恰好命中一類特殊場(chǎng)景。

內(nèi)容分發(fā)網(wǎng)絡(luò)、視頻網(wǎng)站、在線教育平臺(tái)——這些地方的運(yùn)維人員往往有服務(wù)器賬號(hào)，而業(yè)務(wù)又重度依賴MP4切片。攻擊者不需要外部滲透，內(nèi)部一個(gè)被控制的賬號(hào)就能觸發(fā)。

F5的緩解方案分兩種。能立即打補(bǔ)丁的，直接升級(jí)。不能立即升級(jí)的，手動(dòng)注釋掉所有mp4指令，然后nginx -t檢查語(yǔ)法，最后reload。

這里有個(gè)坑：很多管理員以為reload是熱更新，不會(huì)斷連接。但在這個(gè)場(chǎng)景下，reload本身就會(huì)觸發(fā)worker重啟，短暫中斷不可避免。高并發(fā)業(yè)務(wù)需要評(píng)估窗口期。

BIG-IP、BIG-IQ、F5OS、F5 Distributed Cloud用戶可以放心——公告明確說這些產(chǎn)品線完全不受影響。漏洞被隔離在NGINX的數(shù)據(jù)平面，控制平面沒有暴露。

14年老代碼的遺產(chǎn)問題

ngx_http_mp4_module的代碼最后一次大規(guī)模重構(gòu)是什么時(shí)候？查提交記錄會(huì)發(fā)現(xiàn)，核心解析邏輯多年未動(dòng)。MP4格式本身復(fù)雜，box嵌套、版本差異、廠商擴(kuò)展，解析器很容易在邊界處理上栽跟頭。

這次漏洞的深層啟示是：NGINX的模塊化架構(gòu)既是優(yōu)勢(shì)也是負(fù)債。mp4模塊不是默認(rèn)啟用，但一旦啟用就深度集成在worker進(jìn)程里。一個(gè)模塊的內(nèi)存安全問題，能直接拉垮整個(gè)請(qǐng)求處理流水線。

對(duì)比Apache的MP4處理方案，NGINX選擇把解析邏輯放在worker內(nèi)部而非獨(dú)立進(jìn)程。性能上贏了，隔離性上輸了。這是架構(gòu)層面的trade-off，14年前沒人覺得有問題。

Aisle Research的兩位研究者值得注意。Xint Code這個(gè)名字在2024年的CVE記錄里出現(xiàn)過兩次，都是內(nèi)存安全方向。Pavel Kohout的背景更偏向二進(jìn)制分析。他們的組合技：Code負(fù)責(zé)構(gòu)造觸發(fā)樣本，Kohout負(fù)責(zé)分析利用路徑。

F5的致謝名單里還有協(xié)調(diào)披露的時(shí)間線。從報(bào)告到補(bǔ)丁發(fā)布，典型的90天周期。這期間受影響用戶沒有公開信息，全靠廠商私下通知。這種披露模式的安全性和透明性，業(yè)內(nèi)爭(zhēng)論了十幾年。

補(bǔ)丁之外的長(zhǎng)尾問題

升級(jí)容易，驗(yàn)證難。很多生產(chǎn)環(huán)境的NGINX是發(fā)行版自帶的，比如Ubuntu LTS、RHEL EPEL。這些渠道的補(bǔ)丁往往滯后上游數(shù)周甚至數(shù)月。

更隱蔽的是配置漂移。十年前某個(gè)工程師加了mp4指令，后來人走茶涼，配置沒人敢動(dòng)?，F(xiàn)在安全團(tuán)隊(duì)掃描漏洞，發(fā)現(xiàn)版本號(hào)在受影響范圍內(nèi)，但根本沒人記得哪個(gè)location在用MP4功能。

云廠商的托管NGINX服務(wù)是另一片盲區(qū)。AWS ALB、Azure Front Door、Cloudflare的底層是不是NGINX？是不是用了mp4模塊？這些細(xì)節(jié)不會(huì)寫在文檔里。用戶只能等廠商公告，或者主動(dòng)開ticket追問。

開源版的版本號(hào)管理也是個(gè)歷史包袱。1.28.x是穩(wěn)定分支，1.29.x是主線分支，兩個(gè)分支同時(shí)維護(hù)。這次補(bǔ)丁1.28.3和1.29.7一起發(fā)，但很多自動(dòng)化腳本只跟蹤主線，穩(wěn)定分支用戶反而漏掉更新。

最后問一句：你的NGINX配置里，有沒有一行被遺忘的mp4指令？檢查/etc/nginx/nginx.conf和所有include文件，成本不到五分鐘。但如果被攻擊者先找到，成本就是一次P0級(jí)事故復(fù)盤。