目前位置： 正文

curl HTTP/2 上傳漏洞：不只命令列，網站依賴的 libcurl 也要核對

2026-10-15 精品教程 0 0

curl 於 2026 年 10 月 14 日公開 CVE-2026-92392，並在 8.23.0 修補 HTTP/2 上傳流程的 use-after-free。網站透過 libcurl 連外上傳資料，也可能用到相同程式庫，不能只盤點管理員手動執行的 curl 命令。

惡意伺服器回應是關鍵條件

問題涉及上傳時處理特定 HTTP/2 RST_STREAM。官方將風險列為 High，並指出在符合多項版本、記憶體配置及時序條件時，可轉成遠端程式碼執行。這不是任何 HTTP/2 連線都必然觸發，也不能省略遠端伺服器及執行環境的限制。

受影響版本與修補方式

一般受影響範圍是 curl 8.12.0 至 8.22.0，8.23.0 已修補；供應商維護分支另有回移版本。可更新套件、套用正式修補，或在受影響流程暫不使用 HTTP/2。若採用回移修補，應保留供應商依據，而不是只用主版本字串判斷。

PHP 或其他應用自帶的 libcurl 也要查

系統命令列、PHP cURL 擴充與容器可能使用不同 libcurl。請維護者查明上傳整合實際載入哪一套，更新後重新啟動相關程序，並測試自有上傳服務。正式憑證與使用者資料不應送往陌生測試端點；可在自有測試環境核對協定與版本。

事件公告日期：2026-10-14。依公告翌日編入事件時間線，於 2026 年 11 月 1 日補錄；本文按歸檔日已公開資訊整理。封面為 AI 生成的概念插畫。

參考資料

原文鏈接：https://wntheme.com/curl-http2-upload-cve-2026-92392/，轉載請註明出處。
0

猜妳喜歡

Bash前段指令失敗卻回傳0：用pipefail檢查管線
精品教程
Bashpipefail退出狀態

一段檢查或處理資料的指令，用豎線接到下一段後，前段明明失敗，整條管線卻回傳0。若你用這個結果決定是否繼續備份、部署或匯入，可能漏掉前面的錯誤。Bash一般以管線最後一段的退出狀態作為整體結果；啟用pipefail後，才會把前段的非零狀態納入判斷。 先重現：前段失敗，最後一段仍成功 以下用false刻意回傳1、true回傳0，方便觀察規則，不會處理檔案。請存成.sh檔並用bash 檔名.sh執行；範例使用Bash，不能假設所有以sh執行的環境都有相同選項。 #!/usr/bin/env bash set +o pipefail false | true rc=$? printf 'pipeline status=%s\n' "$rc" # pipeline status=0 set -o pipefail false | true rc=$? printf 'pipeline status=%s\n' "$rc" # pipeline status=1 第一組關閉pipefail，管線狀態取自最後的true，所以是0。第二組啟用後，前段false的1成為整條管線的狀態。若所有段落都回傳0，啟用pipefail後的整體結果仍是0。 rc=$?要緊接管線。若先執行echo或另一條指令，$?就會變成那條指令的狀態；上面的printf是在保存rc之後才顯示結果。 多段都失敗時，取最右側的非零狀態 #!/usr/bin/env bash set -o pipefail (exit 7) | (exit 3) | true rc=$? printf 'pipeline status=%s\n' "$rc" # pipeline status=3 結果是3，不是7，也不是最後一段true的0。pipefail取管線位置最右側、且退出狀態非零的那一段；不是取最大的數字，也不是取最後完成執行的程序。括號裡的exit只結束該子shell，不會直接結束外層腳本。 取得失敗狀態後，還要決定下一步 pipefail本身不等於「出錯立即停止」。前面的第二組範例中，管線回傳1後，printf仍會執行。若這個步驟失敗就必須停止，請明確寫出分支，並保留原來的狀態。 #!/usr/bin/env bash set -o pipefail if false | true; then printf '檢查完成，繼續下一步\n' else rc=$? printf '管線未通過，status=%s\n' "$rc" >&2 exit "$rc"...
2026-10-22 73 0
文尼先生 2026-10-22
Linux目錄明明很大卻算不出來？du別只看星號展開的檔案
精品教程
duLinux磁碟用量

網站目錄佔了不少空間，跑du -sh ./*卻只看到幾個小目錄？先別認定du算錯。在一般Bash設定下，星號展開不會包含名稱以點開頭的項目；像.cache、.git這些目錄，可能根本沒被交給du統計。 先看星號實際展開了什麼 到要檢查的目錄，先確認所在位置，再列出./*代表的路徑。下面只顯示位置與名稱，不會修改檔案。 pwd printf '%s\n' ./* 假設目錄裡有visible和.cache兩個子目錄，Bash未啟用dotglob時，這個星號通常只展開成./visible。接著執行du -sh -- ./*，du收到的也只有那個路徑。.cache沒有出現在結果中，不是du先讀取後把它排除，而是shell沒有把它列進參數。 不同shell或自訂設定可能改變展開結果；若星號沒有匹配到項目，顯示原樣或報錯也可能和設定有關。先看實際路徑，不要把某台主機的習慣當成所有Linux環境的固定行為。 要算整個目前目錄，就直接指定點 想知道目前目錄總共佔多少空間，不必把星號改成一長串隱藏檔案模式。直接把目前目錄.交給du： du -sh -- . -s彙總指定路徑，-h用容易閱讀的單位顯示。du會從這個目錄往下統計，名稱以點開頭的子目錄也在範圍內。輸出最後的點代表整個目前目錄，不是單獨一個普通檔案。 再找出哪一個子目錄較大 在提供GNU du的Linux環境，可把顯示層級限制在下一層。這條仍然以目前目錄為起點，而不是使用星號列出普通名稱。 du -h --max-depth=1 -- . 結果會列出第一層子目錄，以及最後的目前目錄總量；符合範圍的.cache也會顯示。--max-depth=1限制的是顯示深度，不代表只讀一層就能算完：子目錄裡的內容仍需要統計，大型目錄照樣可能花時間與I/O。 這個寫法不會替你把每個第一層普通檔案逐一列出。若某個大檔案直接放在目前目錄，總量會包含它，子目錄那幾行相加卻不一定等於總量。不要把這個差額全當成隱藏目錄。 用小例子對照兩種範圍 假設visible裡放一個4KiB檔案，.cache裡放一個1MiB檔案。一般Bash的./*只列visible，沿用它的du結果就不會反映那個1MiB隱藏檔案；改成du -sh -- .，總量會把兩邊都納入。再用上一節的層級顯示，就能看出.cache比visible大。 這裡的檔案大小只是示例，du通常顯示磁碟配置用量；目錄本身、檔案系統配置方式及工具的單位設定，都可能讓顯示值和檔案內容長度不同。重點是比較同一位置、同一工具下的統計範圍，而不是要求輸出剛好等於兩個數字相加。 數字還是對不上時 留意權限不足的錯誤，掃描期間檔案是否持續變動，以及目錄裡有沒有掛載其他檔案系統。上面的指令沒有要求停在同一檔案系統，不能直接拿它的總量和某一個掛載點的df數字畫等號。GNU選項也不保證適用於BusyBox或macOS的du。 找到大目錄後先確認用途和保留規則。快取、版本庫、上傳檔案或備份需要不同處理方式；名稱以點開頭不代表可以刪。這次先把統計範圍查清楚，再決定是否有需要安排清理。 參考資料 GNU Coreutils手冊：du統計與顯示深度 GNU Bash手冊：檔名展開與dotglob
2026-10-16 81 0
文尼先生 2026-10-16
NGINX 10 月修補五項漏洞：alias、HTTP/3 與 TLS ticket 的設定差異
精品教程
網站安全

NGINX 於 2026 年 10 月 14 日釋出 mainline 1.31.7 與 stable 1.30.6，修補五項漏洞。
2026-10-15 0 0
2026-10-15
Linux排程上一輪還沒跑完？用flock避免工作重疊
精品教程
flockLinux排程排查

匯入資料每分鐘啟動一次，但某一輪花了兩分鐘，下一輪又開始寫同一批檔案。排程準時啟動，不代表上一輪已經結束。若工作不能重疊，可以用Linux的flock把同一項工作包起來：只有拿到鎖的那一輪才執行。 先決定第二輪應該等待，還是跳過。flock預設會等鎖；加上-n則立即回報沒拿到，不會替你排隊補跑。這是工作流程的選擇，不能把「沒有執行」當成「已完成」。 先在兩個終端看見同一把鎖 在自己的Linux測試環境執行下面這行，它會建立一個獨立暫存目錄，並印出路徑。把實際印出的路徑複製給兩個終端的demo_dir；兩邊必須指向同一個目錄，別各自再跑一次mktemp。 mktemp -d /tmp/flock-demo.XXXXXX 先在終端A啟動一個只等待10秒的虛構工作。把路徑換成剛才的實際結果，不要使用別人的鎖檔，也不要拿正式匯入工作來試。 demo_dir=/tmp/flock-demo.實際結果 flock -n -E 75 "$demo_dir/job.lock" \ bash -c 'printf "A started\n"; sleep 10; printf "A finished\n"' 看到A started後，在10秒內從終端B執行： demo_dir=/tmp/flock-demo.實際結果 if flock -n -E 75 "$demo_dir/job.lock" \ bash -c 'printf "B started\n"'; then printf 'B completed\n' else rc=$? printf 'B did not succeed, exit=%s\n' "$rc" fi A仍持鎖時，B不會印出B started，會得到退出碼75。等A finished出現後，再跑同一段B，這次才會印出B started與B completed。鎖檔還在不影響重跑；檔案存在與鎖正在被持有是兩件事。 把沒拿到鎖和工作失敗分開記錄 -E 75指定的是鎖衝突的退出碼。若已拿到鎖且成功啟動子命令，flock會傳回子命令的退出碼。因此退出碼75也可能是你的工作自己回傳的75；不能只看這個數字，就斷言另一輪正在執行。 套到真實工作前，核對工作本身的返回值規則。若約定保留75給鎖衝突，工作就不應用同一個值表示其他失敗；若無法約定，紀錄還要能分辨是否已進入工作。工作返回非零時要保留原因，別用|| true讓呼叫者一律看見成功。 下面刻意讓拿到鎖的工作退出7。請在A結束後單獨執行，結果應是7，並非75： demo_dir=/tmp/flock-demo.實際結果 if flock -n -E 75 "$demo_dir/job.lock" bash -c 'exit 7'; then printf 'work succeeded\n'...
2026-10-10 92 0
文尼先生 2026-10-10
Linux shell變數在子程序不見：assignment與export
精品教程
BashLinux

在終端設了變數，接著啟動腳本卻讀不到，常見原因是你只做了shell變數賦值，沒有把它放進子程序的環境。assignment與export各有作用：前者讓目前shell保存一個值，後者把該變數標記為輸出，讓後續啟動的程序收到它。先分清誰設定、誰讀取，比反覆把值寫進不同設定檔更容易找到問題。 目前shell有值，子shell未必有 以下案例使用專屬變數WN_SAMPLE，避免改動PATH或其他既有設定。先unset清掉這個名字，建立目前shell的值，再啟動新的bash讀取。子shell的參數展開用單引號包住，確保它在子shell裡執行；若改用雙引號，外層shell可能先把值展開，輸出看似成功，實際並沒有證明子程序收到了環境變數。 unset WN_SAMPLE WN_SAMPLE=parent printf "parent-before=%s\n" "$WN_SAMPLE" bash -c 'printf "unexported-child=%s\n" "${WN_SAMPLE-unset}"' 在Ubuntu 24.04、GNU Bash 5.2.21的自有隔離案例中，目前shell輸出parent-before=parent，子shell輸出unexported-child=unset。這裡unset是取不到變數時由展開語法提供的文字，不是子shell真的建立了名為unset的值。新的bash沒有拿到尚未export的WN_SAMPLE，因此兩個結果可以同時成立。 export讓後續子程序收到環境值 export WN_SAMPLE bash -c 'printf "exported-child=%s\n" "$WN_SAMPLE"' 這次子shell輸出exported-child=parent，因為WN_SAMPLE已被標記輸出。你也可以用export WN_SAMPLE=parent一次設定並輸出，但不要把兩種寫法的差異誤認為字串值的差異。關鍵是export屬性，而不是變數剛好叫什麼名字。已經輸出的變數再賦新值，後續程序會收到新的值；已經啟動的程序則不是這次操作的接收對象。 程序啟動時收到一份環境，而不是持續連到父shell變數的共享欄位。父shell之後改值，不能因此推論先前啟動的服務已更新。若網站程式讀的是啟動時的環境，修改終端中的值與正式服務讀到的新值之間還有自己的啟動流程。本案例只啟動短生命週期的bash，沒有改服務設定、重啟程序或測試正式站。 子程序改值，不會回寫父shell bash -c 'WN_SAMPLE=child; printf "child-changed=%s\n" "$WN_SAMPLE"' printf "parent-after=%s\n" "$WN_SAMPLE" 隔離案例的輸出分別是child-changed=child、parent-after=parent。子shell可以改自己的變數，但它的修改不會回流成父shell的新值。export也不會改變這個方向：它負責提供啟動環境，不是雙向同步機制。如果腳本需要把計算結果交回呼叫者，必須另用輸出、檔案或你設計的通訊方式，而不是只在子shell裡賦值。 同樣地，子程序收到的環境不代表它會再次把所有新變數傳給更下一層程序。若在子shell裡建立了另一個未輸出的變數，仍需分清該子shell自己的變數與它輸出的環境。排查多層腳本時，每一層都看誰啟動誰、值在哪裡設定，以及該名字是否被export，不要把最外層設定成功當成所有層都一定收到。 只給一個指令的暫時值 WN_SAMPLE=temporary bash -c 'printf "one-command-child=%s\n" "$WN_SAMPLE"' printf "parent-final=%s\n" "$WN_SAMPLE" 這次one-command-child=temporary，但parent-final仍是parent。放在外部指令前面的賦值，可供該次指令使用，不必把父shell原值永久改成temporary。這很適合只想測一次程式對某個設定的反應。注意這裡接的是外部bash指令；shell特殊內建、函式或其他語法的環境與賦值規則不應一概套用。本篇只驗證所列的外部指令形式。 如果值含空白，仍要正確引用，例如WN_SAMPLE="two words" bash -c後面的指令。引用控制shell如何把文字分成參數，export控制變數是否進入環境，兩者處理不同問題。收到值卻因未引用而分裂成多個參數，與完全沒有收到環境值，是兩種不同故障。先印出限定變數的實際值與參數，再決定要修哪一層。 在真正啟動程式的位置檢查 互動終端、排程與服務可能由不同程序啟動。你在某個終端export成功，只能證明該shell之後啟動的子程序能收到值，不能保證另一個排程或服務也繼承同一份環境。先找出實際啟動鏈，再在自己的測試程序中讀取需要的名字。不要為了排查一個變數就把整份環境公開貼出，因為其他名字可能包含與本問題無關的資料。 Bash啟動檔也與登入、互動等模式有關。腳本用bash -c啟動與你開終端後手動操作不完全相同；不能假設某個互動啟動檔一定會被所有程序讀取。本篇用乾淨的專屬變數加明確賦值，讓結果來自assignment與export，而不是依賴使用者既有啟動檔。若自己的環境出現不同結果，先看是否有啟動檔或程式內部再次設定同名值。 不要把執行腳本與source混成同一件事 執行一支腳本通常由另一個shell程序處理，腳本裡改變自己的變數，不能直接改回呼叫它的父shell。Bash的source或點指令則是在目前shell環境中讀取檔案，作用範圍不同。若為了讓值留下來而把原本執行腳本改成source，檔案中的其他命令也會在目前shell生效，不能只把它當成export的另一種寫法。應先確認檔案就是設計成可被讀入的設定，再選擇這種方式。本例沒有讀入其他檔案，也沒有用source改父shell。 也要分清空字串與未設定。${WN_SAMPLE-unset}只有變數未設定時才用替代文字；若變數存在但值是空字串，輸出仍是空。另一種帶冒號的展開形式會把空值也納入替代條件，兩者不能在排查時隨意交換。若你的程式把空字串視為有效設定，就應保留這個差別。本案例先unset再賦非空字串，讓未輸出與已輸出的結果更容易辨認，沒有把所有空值處理策略套給應用程式。 最後，export清單只是目前shell的狀態。另開一個與它沒有父子啟動關係的終端，不會自動得到你剛剛修改的值。若需要長期固定設定，要放到實際啟動程序使用的設定來源，再按該環境的程序管理方式生效。這一步超出單次shell實驗的範圍；先確認傳遞機制，才決定適合自己的設定位置。 用小案例確認傳遞方向 完整案例按順序得到五個關鍵結果：未輸出的子shell取不到值、export後收到parent、子shell改成child、父shell仍保留parent、單次指令收到temporary而父shell最後仍是parent。所有操作在本地無網路隔離容器完成，容器已退出，沒有改系統全域設定。本案例版本是Bash 5.2.21，參考Bash文件來自官方5.2.37發行包；補丁版本不同已分開記錄。 遇到「腳本讀不到設定」時，可以先用這組小測試驗證你的啟動方式，再回到實際腳本。保留同一個專屬名字、明確的unset與限定輸出，容易看出值在哪一層消失。確定程序真的收到值後，才查程式是否使用另一個名字、是否有自己的預設值，或是否在啟動後把它覆蓋。這樣不必靠反覆修改全域設定檔猜原因。 參考資料GNU Bash 5.2.37官方發行包：Bash手冊POSIX：Shell Command LanguageLinux man-pages：environ，man7上游出版鏡像Linux man-pages：execve，man7上游出版鏡像POSIX：env
2026-10-05 50 0
文尼先生 2026-10-05
Linux curl遇到404仍回傳成功：傳輸成功與HTTP失敗怎麼分
精品教程
curlLinux

排程用curl下載API資料，伺服器明明回傳404，後面的工作卻照常執行。先別急著把錯誤歸到shell：curl預設把「完成HTTP交換」視為成功，資源不存在則是HTTP回應裡的另一層結果。兩者分開看，才能決定程式該停下來，還是保留錯誤內容供查閱。 先分清退出碼與HTTP狀態碼 shell讀到的退出碼是本次curl程序的結果；HTTP狀態碼由伺服器放在回應中。成功連線、送出請求並收到完整404回應，可以同時得到HTTP 404與程序退出碼0。這不表示檔案存在，也不表示API處理了你要做的事。 反過來，DNS解析失敗或連線中斷時，curl也可能根本沒拿到HTTP回應。把所有非零退出碼都寫成「API回傳404」，會把網路問題與應用程式錯誤混在一起。診斷時至少保留退出碼、HTTP狀態，以及適合公開的錯誤內容；不要把憑證或完整敏感回應直接印到共用紀錄。 同一個404，三種選項的結果不同 下面的對照使用curl 8.21.0與自有隔離Python HTTP服務。服務的/missing固定回傳404和一小段JSON，/ok則回傳200。服務沒有對外開放連接埠，也沒有操作真實API；這個案例只用來確認命令行的錯誤處理。 default HTTP 404 exit 0 保留錯誤正文 --fail HTTP 404 exit 22 不輸出錯誤正文 --fail-with-body HTTP 404 exit 22 保留錯誤正文 --fail-with-body HTTP 200 exit 0 保留成功正文 若後面的步驟只看退出碼，預設命令就會放行404。加入--fail後，這次404變成退出碼22；加入--fail-with-body也得到22，但仍可讀到伺服器傳回的錯誤說明。兩個選項解決的是不同需求，並不是正文越少就一定越安全。 --fail-with-body從curl 7.76.0加入，舊機器先跑curl --version核對。沒有這個選項時，不要直接照抄後宣稱相同效果；可以先用--fail，或另行保存HTTP狀態再依服務契約判斷。不同系統的curl可能帶不同版本，不能只靠作業系統名稱猜測。 需要錯誤JSON時，用fail-with-body並立即保存退出碼 若要在自己的開發環境重現，可先啟動下面這個Python測試服務，再從另一個終端執行curl。它只監聽本機位址；不要把示範服務放到正式網站，也不要改成對外監聽來方便測試。執行時保持服務終端開著，結束後用Ctrl+C停止。 from http.server import BaseHTTPRequestHandler, HTTPServer class Demo(BaseHTTPRequestHandler): def do_GET(self): ok = self.path == "/ok" body = (b'{"ok":true}\n' if ok else b'{"error":"not found"}\n') self.send_response(200 if ok else 404) self.send_header("Content-Type", "application/json") self.send_header("Content-Length", str(len(body))) self.end_headers() self.wfile.write(body) HTTPServer(("127.0.0.1", 8080), Demo).serve_forever() 把程式存成demo.py，用python3 demo.py執行。若連接埠已被自己的其他工作占用，就同時修改服務與curl網址的連接埠，不要停止用途不明的程序。先請求/ok確認回應200，再改成/missing。這樣能分清服務未啟動的連線失敗，與服務正常回覆的404。 示範沒有驗證身分、資料庫或第三方服務，狀態由路徑直接決定。它適合檢查下載腳本對HTTP錯誤的分支，卻不能證明你的正式API一定使用相同錯誤格式。移到真實服務時，仍要查它的文件：有些API回傳JSON錯誤，有些回傳HTML，直接把後者交給JSON解析器只會產生另一個錯誤。 url="http://127.0.0.1:8080/missing" curl...
2026-10-05 44 0
文尼先生 2026-10-05
顯示驗證碼
沒有帳號？註冊  忘記密碼？