URLDNS is a Java deserialisation gadget used to trigger an outbound DNS lookup through a crafted object, without needing full code execution. It is commonly used to test whether an application deserialises attacker-controlled data and can reach external network resources.
How URLDNS works
URLDNS is a Java deserialisation gadget that turns object handling into an outbound DNS query. The key behaviour is not code execution, but controlled network resolution, which makes the gadget useful for testing whether deserialisation paths are reachable and whether the application can be induced to contact external infrastructure.
Because the lookup can occur before a full exploit chain is visible, URLDNS is often used as a low-noise probe. If the application resolves attacker-influenced names, that can confirm both unsafe deserialisation handling and the presence of egress paths that may support later-stage exploitation.
Why URLDNS is dangerous
The risk is that a seemingly harmless object can still trigger a security-relevant side effect. In a vulnerable Java application, deserialisation may happen deep inside middleware, frameworks, or custom message handlers, so the observable impact can be an outbound DNS request even when the attacker does not yet have code execution.
That matters because DNS is frequently allowed through network controls and may not be scrutinised as closely as HTTP or direct socket traffic. A single lookup can therefore reveal that untrusted input reached a deserialisation sink, and it can also create a foothold for further payload delivery or environment discovery.
What organisations should check
Exposure review starts with identifying every place where the application accepts or processes serialised Java objects, including APIs, message queues, integration points, and legacy components. Teams should then determine whether those code paths can be reached from untrusted users or from lower-trust internal systems.
It is also important to verify whether the application can make outbound DNS requests and whether egress filtering, DNS logging, or proxy controls will surface unexpected lookups. Vendor advisories and the CISA Known Exploited Vulnerabilities catalogue remain the authoritative sources for version-specific exposure and patch guidance when a concrete CVE is involved.
Remediation and verification after patching
Preferred remediation is to remove unsafe Java deserialisation wherever possible and replace it with safer data formats or strict allowlists. Where that is not immediately possible, compensating controls should focus on reducing reachability, constraining egress, and limiting which components can touch deserialisation inputs.
After changes are applied, organisations should re-test the affected paths to confirm that the gadget no longer produces an outbound lookup. If exploitation was suspected, review DNS telemetry, application logs, and surrounding host activity for signs that the lookup was used as a reconnaissance or staging step.
Risk and Threat Considerations
URLDNS is valuable to attackers and testers because it provides a stealthy validation channel. The main concern is not the DNS query itself, but the fact that it proves control over a deserialisation path and can expose network reachability that should not exist for attacker-controlled input.
Failure mechanism: A crafted object reaches a deserialisation sink, triggers name resolution during object processing, and creates an outbound DNS request that reveals exploitable trust boundaries or egress access.
Impact: Even without code execution, the lookup can confirm vulnerability, enable environment mapping, and support follow-on exploitation where deserialisation, network access, and downstream payload delivery are chained together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Input Validation | URLDNS exploits unsafe object handling through attacker-controlled input. |
| SC-7 — Boundary Protection | The gadget depends on unwanted outbound network reachability from a trusted application. | |
| Recommendation — Validate and restrict deserialised data so untrusted objects cannot reach sensitive processing paths. Constrain egress paths so unexpected DNS lookups cannot leave the environment. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | DNS-based probing is only visible if outbound traffic is monitored and reviewed. |
| Recommendation — Log and review DNS egress to detect deserialisation probes and follow-on activity. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Unsafe deserialisation is an application design flaw that ASVS addresses through secure architecture. |
| Recommendation — Eliminate unsafe deserialisation patterns and use safer data handling designs. | ||
| MITRE ATT&CK | T1048 — Exfiltration Over Alternative Protocol | DNS can serve as a low-friction channel for observable outbound activity. |
| Recommendation — Map suspicious DNS-based activity to alternative-protocol abuse and investigate the originating process. | ||
Practitioner Guidance
Why practitioners should care: URLDNS is a warning sign that a Java application may be deserialising untrusted data in a way that can be externally observed. That makes it useful for both vulnerability validation and defensive assurance.
What to watch for: Treat unexpected outbound DNS activity from Java services as a signal worth investigating, especially when it aligns with recent input handling changes, new integrations, or legacy deserialisation code paths.
Practitioner takeaway: If a simple DNS lookup can be triggered through object processing, the application should be treated as having an unsafe trust boundary until the deserialisation path is removed or tightly constrained.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org