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

  - StreamReadConstraints.maxNameLength （預設值為 50,000 個字元） 旨在限制單一 JSON 物件屬性名稱在剖析時可以耗用的記憶體量，與限制一般字串值的較大 maxStringLength （預設值為 100,000,000 個字元） 無關。對於在字元輸入 Reader、String 或 char[] 來源上建置的剖析器，所有由 ReaderBasedJsonParser 提供，在累積名稱時不會套用該繫結。程式碼路徑會改用字串值長度檢查，預設情況下大約大 2000 倍。在字元輸入慢速路徑中，ReaderBasedJsonParser._parseName2（） 會將名稱累積到 TextBuffer 中，當區段填滿時，會呼叫 TextBuffer.finishCurrentSegment（），這只會驗證 maxStringLength。一旦將整個名稱掃描到其右引號，之後就會在 CharsToNameCanonicalizer.findSymbol（） 中達到正確的檢查 StreamReadConstraints.validateNameLength（int）。到那時，maxStringLength 字元的完整名稱已經緩衝在記憶體中。遠端攻擊者如果可以透過此路徑剖析單一足夠長的 JSON 物件屬性名稱，就可以在擲回任何 StreamConstraintsException 之前強制分配 100,000,000 個字元 （大約 200 MB，區段簿記會將實際尖峰使用量推得更高），而不是大約 50,000 個字元 （約 100 KB） 的 API 承諾繫結。在並行要求中重複此動作可能會耗盡堆積並使處理程序損毀。不需要驗證或使用者互動。
    由於預設情況下停用 StreamReadConstraints.maxDocumentLength （-1），因此沒有其他任何內容會先限制權杖，因此在預設設定下可利用此問題。位元組輸入剖析器不受影響：
    UTF8StreamJsonParser、UTF8DataInputJsonParser 和非封鎖 （非同步） 剖析器會透過 ParserBase._growNameDecodeBuffer（） 在名稱解碼緩衝區的每次成長時重新驗證 maxNameLength，在僅配置數十 KB 後拒絕過大的名稱。當從 String、Reader 或 char[] 剖析不受信任的 JSON 時，應用程式會公開，例如已讀取到 String 中的 HTTP 要求內文，而不是從原始 UTF-8 位元組讀取。此問題會影響 com.fasterxml.jackson.core：jackson-core 和 2.16.0 tools.jackson.core：jackson-core 3.0.0from 。之前 2.16.0 的版本不受影響，因為 StreamReadConstraints.maxNameLength 最初是在 jackson-core 2.16.0中引入的。（CVE-2026-68498）

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

偵測

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

high Nessus Plugin ID 366852

版本 1.12