CVE-2026-54514

What it actually does

The flaw causes Jackson Databind to resolve attacker-supplied hostnames while deserializing JSON into Java types that include an InetSocketAddress field. Because affected versions construct InetSocketAddress with eager DNS resolution, a simple readValue operation can trigger an outbound DNS lookup before the application performs validation, authorization, or any intended network connection logic. The practical impact is DNS-based SSRF/out-of-band interaction: an unauthenticated remote attacker may cause the application or its resolver infrastructure to query attacker-controlled domains, revealing that the vulnerable code path was reached and potentially exposing resolver/source-network metadata. It does not by itself create an HTTP/TCP connection or code execution condition.

Why it matters to the business

Applications that accept untrusted JSON and bind it to models containing InetSocketAddress may unintentionally make external DNS requests controlled by an attacker. This can expose internal network metadata, trigger security alerts, bypass assumptions about validation order, and provide attackers with a reliable way to confirm vulnerable endpoints. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but Jackson Databind is widely used across Java services, so organizations should prioritize inventory and patching where externally reachable APIs deserialize untrusted input.

How an attack unfolds

An attacker first identifies an application endpoint that accepts JSON and is processed by Jackson Databind. They then craft JSON for a request body, field, or nested object that maps to a Java property of type InetSocketAddress. The supplied hostname is set to a domain controlled by the attacker, often with a unique token as a subdomain. When the vulnerable application calls Jackson readValue or equivalent data-binding logic, the affected deserializer constructs the InetSocketAddress in a way that immediately performs DNS resolution. The application’s DNS resolver then sends a query for the attacker-controlled hostname before business logic can reject the value. The attacker observes the DNS query in authoritative DNS logs or an out-of-band interaction platform, confirming reachability of the vulnerable deserialization path and learning limited network/resolver metadata. Further exploitation is generally limited to forced DNS lookups unless the application later uses the deserialized address in separate connection logic.

How to fix it

Upgrade jackson-databind to a fixed version. Use 2.18.8 or later for the 2.18 line, 2.21.4 or later for the 2.21 line, and 3.1.4 or later for the 3.x line; where practical, upgrade to the latest supported Jackson Databind release available for the application stack. Ensure transitive dependencies are also updated by checking build output and dependency lockfiles for com.fasterxml.jackson.core:jackson-databind. If immediate upgrade is not possible, avoid binding untrusted JSON directly into types containing InetSocketAddress, bind host and port as plain validated strings/integers first, reject unexpected address fields, and only construct InetSocketAddress after explicit validation and at the point an actual connection is intended. Network controls should restrict outbound DNS to approved resolvers and monitor/block direct external DNS egress, but egress filtering should be treated as a compensating control rather than a code-level fix.

How to confirm the fix worked

Confirm that the deployed artifact resolves jackson-databind to a fixed version by inspecting Maven/Gradle dependency trees, SBOMs, container image contents, and runtime classpaths. For Maven, review dependency:tree output for com.fasterxml.jackson.core:jackson-databind; for Gradle, review dependencies or dependencyInsight output. Validate that no shaded, bundled, or framework-provided copy of an affected jackson-databind version remains. Functionally, in a controlled test environment, send a JSON payload to relevant endpoints using a unique domain under a test-controlled DNS zone in any field expected to bind to InetSocketAddress; after patching or mitigation, simple deserialization should not perform DNS resolution during parsing. Also verify application tests that cover request binding and object mapping for models containing InetSocketAddress.

Typical attack path

1. Find an internet-facing or reachable Java API that accepts JSON input.
2. Identify or fuzz for a JSON field that maps to an InetSocketAddress or an object containing one.
3. Send a crafted JSON payload where the hostname is an attacker-controlled domain, often using a unique subdomain token.
4. Trigger Jackson Databind deserialization through readValue, ObjectMapper binding, framework request binding, or similar processing.
5. Observe whether the target environment performs a DNS lookup for the attacker-controlled domain.
6. Use the DNS callback to confirm the vulnerable code path and infer resolver or egress characteristics.

How to detect it

To assess prior exploitation, focus on DNS telemetry and application request correlation rather than host artifacts. Review recursive resolver logs, authoritative DNS logs, network DNS sensors, EDR network events, and application/API gateway logs for DNS queries that occur at the same time as JSON POST/PUT/PATCH requests to endpoints using Jackson binding. Look for domains with unique tokens, random-looking subdomains, DNS canary or out-of-band testing domains, and queries from application subnets that are not expected to initiate name resolution during request parsing. Correlate suspicious DNS lookups with application logs showing deserialization, validation errors, 4xx responses, malformed JSON, unusual request bodies containing host/port/address fields, or probing activity. If request bodies are captured in WAF/API gateway logs, search for JSON keys or values resembling socket addresses, hostnames, ports, or nested objects intended to map to address fields. Absence of DNS logs may prevent definitive historical confirmation; in that case, use dependency inventory and controlled testing to determine exposure.

What your security team should do

• Inventory all Java services, libraries, and container images that include com.fasterxml.jackson.core:jackson-databind, including transitive and shaded copies.
• Prioritize externally reachable services and services that deserialize untrusted JSON into application models containing InetSocketAddress or generic object graphs.
• Upgrade jackson-databind to 2.18.8, 2.21.4, 3.1.4, or a later supported fixed release according to the application’s dependency line.
• Add static analysis or code review checks for direct binding of untrusted JSON into InetSocketAddress-containing models.
• Restrict outbound DNS so application workloads can only query approved internal resolvers, and alert on unexpected DNS queries from application networks.
• Search DNS logs for unusual, high-entropy, or newly observed domains queried immediately after API requests that may exercise JSON deserialization paths.
• Because the issue is not currently in CISA KEV and EPSS is low, handle as a broad dependency hygiene and exposure-reduction item, escalating priority for internet-facing services.