CVE-2025-49128

What it actually does

In jackson-core versions 2.0.0 through versions before 2.13.0, JsonLocation._appendSourceDesc can include bytes outside the intended JSON slice when constructing parser exception messages. When an application parses JSON from a byte array using an offset and length, the exception source description may read from the beginning of the backing array instead of the logical payload start. In applications that reuse or pool buffers, such as Netty- or Vert.x-based services, this can expose up to approximately 500 bytes of adjacent or previously used buffer content in exception text. The flaw does not directly allow code execution, data modification, or service disruption; the impact is unintended information disclosure when those exception messages are returned to clients, written to logs, or otherwise exposed.

Why it matters to the business

Affected applications may accidentally disclose fragments of sensitive data such as request bodies, headers, tokens, identifiers, or other users’ payloads through JSON parse error messages. The practical risk depends heavily on whether malformed JSON errors are exposed externally or logs are accessible to users, support personnel, vendors, or attackers. EPSS is low, the issue is not in CISA KEV, and no mature public exploitation is indicated, so this is generally a lower-urgency confidentiality issue; however, internet-facing APIs, multi-tenant systems, and services using pooled buffers should treat it as a meaningful data leakage risk. Jackson-core is widely embedded as a transitive dependency, so exposure may exist indirectly through frameworks and libraries even where the application does not declare jackson-core directly.

How an attack unfolds

An attacker identifies an endpoint or service that accepts JSON and uses a vulnerable jackson-core version to parse input from byte arrays with offsets, commonly through web frameworks or reactive/networking stacks that use pooled buffers. The attacker sends intentionally malformed JSON to force Jackson to throw a parsing exception. During exception construction, the vulnerable source-description logic may include bytes from the backing array before the logical start of the attacker’s payload. If the application returns raw exception messages in HTTP responses, exposes detailed API errors, or stores those messages in logs the attacker can access, the attacker can read the leaked byte fragments. By repeating malformed requests and varying timing, payload size, or connection behavior, the attacker may collect multiple fragments of stale or adjacent buffer data. Exploitation requires an exposure path for exception text; systems that suppress detailed parser exceptions from clients and restrict log access have substantially reduced practical risk.

How to fix it

Upgrade jackson-core to version 2.13.0 or later. The upstream fix is associated with commit 03add30680331fd88a8ef474cbd5bc0a65e57eb8. Because jackson-core is often transitive, update dependency management, BOMs, framework versions, and shaded or bundled copies, then rebuild and redeploy affected applications. For Ubuntu 22.04 systems carrying the listed linux-oem-6.1 package, apply the vendor-fixed package version 6.1.0-1016.16 where relevant. If immediate upgrade is not possible, prevent exposure by disabling source inclusion in Jackson exception locations, for example by disabling INCLUDE_SOURCE_IN_LOCATION on the configured JsonFactory/JsonMapper where supported, and ensure applications never return raw parser exception messages to clients. Replace detailed parse failures with generic client-facing errors such as 'invalid JSON' and restrict detailed exception logs to protected operational logging systems.

How to confirm the fix worked

Confirm through software composition analysis, build manifests, dependency trees, and runtime classpath inspection that all deployed applications use jackson-core 2.13.0 or later, or a vendor-patched build containing the upstream fix. Check both direct and transitive dependencies, including shaded JARs and framework-provided versions. Exercise representative JSON endpoints with malformed JSON and verify responses do not include Jackson exception internals, source snippets, request fragments, or '[Source: ...]' location text. Review application configuration to confirm source inclusion in exception locations is disabled where mitigation is required. Validate that logs containing parsing exceptions are access-controlled and that log redaction prevents sensitive request content from being stored. For vendor packages, confirm the installed fixed package version, such as linux-oem-6.1 6.1.0-1016.16 on applicable Ubuntu 22.04 systems.

Typical attack path

1. Find a JSON-consuming endpoint or message-processing path that uses jackson-core before 2.13.0, directly or transitively.
2. Send malformed JSON designed to trigger a JsonParseException or related Jackson parsing exception.
3. Cause Jackson to include a source description in the exception location details.
4. Observe whether the application returns the exception text in the HTTP response, API error body, debug page, gateway response, or accessible logs.
5. Extract unintended bytes embedded in the exception source snippet, potentially including stale pooled-buffer content.
6. Repeat requests to attempt to collect additional leaked fragments from reused buffers.

How to detect it

Look for evidence that malformed JSON parsing errors were exposed or logged with embedded source content. Useful sources include application logs, API gateway logs, web server access/error logs, APM traces, centralized logging platforms, exception tracking systems, support/debug logs, and HTTP response capture from WAF or observability tooling. Focus on JsonParseException, StreamReadException, or Jackson exception messages that contain '[Source:' and byte-array source snippets. Review whether those errors were returned with 4xx or 5xx responses to external clients, especially on JSON endpoints. Investigate repeated malformed JSON requests from the same IP, account, session, API key, or user agent followed by responses with unusually large error bodies. Because this flaw leaks data through exception text rather than creating a distinctive payload, there may be no reliable network IOC; detection is primarily based on vulnerable version presence plus historical evidence of detailed Jackson parse errors being exposed. If such logs contain snippets of tokens, credentials, personal data, request headers, or other users’ payloads, treat them as potential data exposure artifacts.

• com.fasterxml.jackson.core.JsonParseException
• com.fasterxml.jackson.core.exc.StreamReadException
• JsonParseException
• StreamReadException
• at [Source: (byte[])"
• [Source: (byte[])"
• JsonLocation._appendSourceDesc
• INCLUDE_SOURCE_IN_LOCATION
• Unexpected character (
• Unexpected end-of-input
• was expecting double-quote to start field name
• Unrecognized token
• Illegal unquoted character

What your security team should do

• Inventory jackson-core usage across applications, including transitive dependencies, shaded artifacts, containers, and framework-managed versions.
• Prioritize remediation for internet-facing APIs, multi-tenant services, authentication/identity flows, payment or personal-data processing services, and applications using Netty, Vert.x, or other pooled-buffer stacks.
• Upgrade jackson-core to 2.13.0 or later and standardize this minimum version in dependency-management policy or software composition controls.
• Disable Jackson source inclusion in exception locations and suppress raw exception messages in all client-facing error responses.
• Search logs and API telemetry for Jackson parsing exceptions that include source snippets to determine whether sensitive data may already have been exposed.
• Restrict access to historical application logs that may contain leaked snippets and assess whether retention, redaction, or incident review is warranted.
• Add regression tests that send malformed JSON and fail the build if detailed parser exception text or source snippets are returned externally.