URLDNS payload is a deserialisation test payload that stores a URL in a Java object so a network lookup occurs when the object is processed. The outbound DNS request provides an out of band signal that deserialisation happened, even if the application does not return visible output.
How URLDNS Payloads Work
A URLDNS payload is designed to trigger a DNS lookup during Java object deserialisation. The payload usually embeds a URL inside an object graph so that, when the object is processed, the runtime resolves the hostname and generates a visible out-of-band signal. That makes it a low-noise way to confirm that deserialisation occurred.
The key idea is that the network lookup happens as a side effect of object handling, not as an explicit application response. That is why URLDNS payloads are so widely used in testing: they can reveal a deserialisation path even when the application suppresses errors, returns no content, or hides the execution path from the tester.
Why URLDNS Payloads Matter in Deserialisation Testing
URLDNS payloads matter because deserialisation bugs are often difficult to observe directly. A benign-looking object may still cause the application to resolve an attacker-controlled or tester-controlled domain, proving that untrusted data reached a dangerous processing step. In practice, this helps security teams validate whether a sink is reachable before attempting a more intrusive proof of impact.
They are especially useful in black-box or partially observable assessments. Instead of relying on application output, the tester watches for DNS activity as a confirmation channel. That makes the technique valuable for discovering hidden deserialisation behaviour, confirming exploitability, and separating mere parsing from actual object instantiation and processing.
Security Implications of Out-of-Band Lookups
DNS-based signalling is powerful because it turns a local parsing event into an externally observable action. If an application processes attacker-controlled serialized data, the same pattern can sometimes be extended from harmless DNS resolution to more serious abuse, depending on the classes available, the runtime behaviour, and the surrounding trust boundaries.
Even when the payload itself is intentionally non-destructive, the lookup can still expose network egress, resolver behaviour, proxy policy, and the fact that the application is willing to act on attacker-supplied object content. That visibility is useful for defenders too, because unexpected DNS requests from application servers can be a clue that deserialisation is being abused or that a test has reached a reachable sink.
How Defenders Use It Safely
In assessment work, URLDNS payloads are usually a confirmation step, not the end goal. They help confirm that a suspected deserialisation path exists before further validation. In defensive engineering, the broader lesson is to treat untrusted deserialisation as dangerous even when the application appears not to execute code immediately, because a side effect can still prove reachable processing and enable deeper exploitation chains.
Teams should pair this kind of testing with careful monitoring of application egress and with review of any deserialisation libraries or custom object-handling code that may permit attacker-controlled data to influence runtime behaviour. When a URLDNS test succeeds, it is a strong sign that the application deserves closer inspection for unsafe object processing.
Risk and Threat Considerations
URLDNS payloads are dangerous because they convert deserialisation into an externally visible interaction. A successful lookup can confirm that untrusted input has reached object-processing logic, which may indicate a path to broader deserialisation abuse, data exposure, or code-execution conditions if the environment contains exploitable gadget behaviour.
Failure mechanism: the application processes a crafted object and performs a DNS resolution as a side effect, giving the tester or attacker confirmation that the sink is reachable even when normal output is absent.
Impact: defenders may miss an active deserialisation path unless they monitor outbound DNS, and attackers can use the same mechanism to validate exploitation, map egress controls, and stage follow-on abuse.
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 — Information Input Validation | Covers protecting deserialisation sinks from untrusted input handling. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports reviewing suspicious outbound DNS and deserialisation indicators. | |
| Recommendation — Validate and constrain serialized input before it reaches object-processing logic. Review logs for unexpected DNS lookups tied to object-processing events. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Addresses monitoring egress and unusual DNS activity that exposes deserialisation testing or abuse. |
| Recommendation — Monitor outbound DNS and alert on anomalous application-host lookups. | ||
| OWASP ASVS | V5 — File Handling | Covers safe handling of untrusted serialized or file-like inputs that can trigger object processing. |
| Recommendation — Ensure untrusted data cannot trigger unsafe object deserialisation paths. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Relevant when deserialisation abuse leads to code execution chains in post-exploitation paths. |
| Recommendation — Map any follow-on execution path from deserialisation abuse into ATT&CK hunting. | ||
Practitioner Guidance
What to watch for: treat unexpected DNS queries from application hosts as a meaningful signal during testing and incident review, especially when they align with recent deserialisation attempts or unexplained object-handling errors.
Governance implication: security owners should require code review and runtime monitoring for any component that accepts serialized input, because the absence of visible application output does not mean the input was harmless.
Related resources from NHI Mgmt Group
- What breaks when email security tools cannot see the full rendered payload?
- Why do traditional email security tools miss payload-less BEC attacks?
- Why do technique-based controls work better than payload filters for modern exploits?
- What should teams do when cloud traffic is encrypted and payload inspection is limited?
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 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org