Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - jackson-core 中的非封鎖 （非同步） JSON 剖析器不會強制執行 StreamReadConstraints 中定義的 maxNumberLength 條件約束 （預設值：1000 個字元）。能夠將 JSON 提交給使用非同步剖析器 API 的應用程式的攻擊者可以提供任意長度的數字權杖，從而導致過多的記憶體配置和潛在的 CPU 耗盡，進而導致拒絕服務。同步剖析器會正確執行此限制，因此根據應用程式使用的剖析 API 而套用限制不一致。根本原因：NonBlockingUtf8JsonParserBase 和相關類別中的非同步剖析路徑永遠不會叫用數字長度驗證方法。
    數字剖析方法 （例如 _finishNumberIntegralPart（） ） 會將數字累積到 TextBuffer 中，而不進行任何長度檢查，然後呼叫 _valueComplete（） 來完成權杖。_valueComplete（） 不呼叫 resetInt（） 或 resetFloat（），這是 ParserBase 中執行 validateIntegerLength（） 和 validateFPLength（） 的方法。因為會略過該驗證步驟，所以絕不會在非同步程式碼路徑上強制執行 maxNumberLength。影響：攻擊者若使用非同步剖析器將包含任意長數字的 JSON 文件傳送至應用程式 （例如 Spring WebFlux 或其他反應式應用程式），可導致 TextBuffer 中出現無限分配，並造成 OutOfMemoryError。如果應用程式隨後呼叫 getBigIntegerValue（） 或 getDecimalValue（），則 JVM 可能還會被綁定在 O（n^2） BigInteger 剖析中，從而造成基於 CPU 的拒絕服務。除了提交資料進行剖析的能力之外，不需要任何權限或使用者互動。此問題會影響 com.fasterxml.jackson.core：jackson-core 從版本 2.15.0 到 2.18.5 和從 2.19.0 到 2.21.0，以及 tools.jackson.core：jackson-core 從 3.0.03.0.x到 。之前 2.15.0 的版本不會受到影響，因為定義 maxNumberLength 設定的 StreamReadConstraints 是首次在 jackson-core 2.15.0中引入的，因此在早期版本中不存在此類約束可以繞過。請注意，GHSA-qq72hv-8253-57 將受影響 2.x 範圍的下限記錄為 2.0.0。（CVE-2026-18401）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

偵測

Linux Distros 未修補弱點：CVE-2026-18401

medium Nessus Plugin ID 332069

版本 1.4