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，段簿记会将实际峰值使用率推高），而不是 API 承诺的约 50,000 个字符（约 100 KB）绑定。在并发请求中重复此步骤可耗尽堆并使进程崩溃。无需身份验证或用户交互。
    由于 StreamReadConstraints.maxDocumentLength 默认禁用 （-1），没有其他任何东西首先限制标记，因此在默认配置下可利用此问题。字节输入解析器不受影响：
    UTF8StreamJsonParser、UTF8DataInputJsonParser 和非阻塞 （async） 解析器通过 ParserBase._growNameDecodeBuffer（） 在名称解码缓冲区的每次增长时重新验证 maxNameLength，从而在仅分配数十 KB 后拒绝超大名称。例如，从字符串、阅读器或 char[] 解析不受信任的 JSON 时，会暴露应用程序，例如已读入字符串而非读取原始 UTF-8 字节的 HTTP 请求正文。此问题影响 com.fasterxml.jackson.core：jackson-core 2.16.0 from 和 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 插件 ID 366852

版本 1.12