Home / Security / Advisories / NTAP-20260930-0002

NTAP-20260930-0002 — CVE-2026-18401 jackson-core Vulnerability in NetApp Products

Published 2026-09-30 · Updated 2026-09-30 · Status: Interim · Exploitation: Public · Severity: MEDIUM 6.9 · ONTAP affected: Yes

Official advisory: NTAP-20260930-0002 on security.netapp.com ↗. Affected versions, fixed releases, and workarounds live there — this page is a summary.

Product family: Active IQ Unified Manager · E-Series / SANtricity · NetApp Console / BlueXP · SolidFire / NetApp HCI · ONTAP · SnapCenter | ONTAP-relevant | highest CVSS: 6.9

CVEs in this advisory

CVE-2026-18401 — MEDIUM · CVSS 6.9 · site index

What the CVE records say

CVE-2026-18401 — The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.

Impact

Successful exploitation of this vulnerability could lead to Denial of Service (DoS).

Affected products

Active IQ Unified Manager for Linux
Active IQ Unified Manager for Microsoft Windows
Active IQ Unified Manager for VMware vSphere
E-Series SANtricity Unified Manager and Web Services Proxy
NetApp Console Agent Container (docker_occm)
NetApp SolidFire & HCI Management Node
NetApp SolidFire & HCI Storage Node (Element Software)
ONTAP tools for VMware vSphere 10
SnapCenter Plug-in for VMware vSphere

References

https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq ↗

What to do

Check the affected products listed above against the official advisory's affected-versions table — that is where the exact ONTAP 9 release, ONTAP tool, or management product versions are named.
If affected and a fixed release exists, plan the upgrade — see the ONTAP upgrade runbook.
If exploitation is listed as "active", treat remediation as urgent and review exposure (management LIFs, ONTAP S3, SnapMirror endpoints).
Harden in parallel: security hardening baseline and ransomware protection on ONTAP.