目前位置： 正文

NGINX njs 1.0.1 修補三項漏洞：先確認網站是否使用 JavaScript 模組

2026-09-03 精品教程 0 0

NGINX 在 2026 年 9 月 2 日釋出 njs 1.0.1，修補三項與 JavaScript 模組相關的漏洞。主機有安裝 NGINX，並不表示一定進入這些受影響路徑；先確認設定是否載入 njs，以及腳本實際使用哪些功能。

三項漏洞各有適用範圍

CVE-2026-18329 是 js_access 的存取控制繞過，影響 njs 0.9.9 至 1.0.0；CVE-2026-78222 涉及 ngx.fetch()，可能使 worker 程序崩潰，影響 0.5.1 至 1.0.0；CVE-2026-78689 則是 xml.exclusiveC14n() 的 heap 緩衝區溢位，影響 0.7.10 至 1.0.0。這一組問題的修補門檻都是 njs 1.0.1。

先查腳本，再查主程式版本

njs 是獨立元件，不能只看 nginx -v 的主程式版本便結案。請維護者核對安裝的 njs 套件、載入模組、js_import 指令，以及腳本是否使用上述功能。官方威脅模型指出，未配置 js_import 的 NGINX 不受 JavaScript 相關漏洞影響；這不等於整台主機沒有其他漏洞。

更新後檢查原有驗證流程

更新相關模組後，先檢查設定語法，再按主機的部署方式重新載入或啟動服務。特別測試依賴 js_access 的權限限制、外部請求失敗時的處理，以及 XML 簽章流程。自訂腳本與設定檔要有版本備份，避免更新時遺失原有驗證邏輯。

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

參考資料

原文鏈接：https://wntheme.com/nginx-njs-security-september/，轉載請註明出處。
0

猜妳喜歡

Bash 迴圈計數後又變 0：把 while read 從管線移出來
精品教程
Bash

Bash 的 while read 迴圈明明累加了兩筆，外面卻還是 0？用輸入重導向與程序替換保留計數，並處理檔尾沒有換行的情況。
2026-11-02 0 0
2026-11-02
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
curl HTTP/2 上傳漏洞：不只命令列，網站依賴的 libcurl 也要核對
精品教程
網站安全

curl 於 2026 年 10 月 14 日公開 CVE-2026-92392，並在 8.23.0 修補 HTTP/2 上傳流程的 use-after-free。
2026-10-15 0 0
2026-10-15
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
顯示驗證碼
沒有帳號？註冊  忘記密碼？