As of May 3, 2026, CVE-2026-5520 is not publicly indexed, but DID resolver flaws still expose SSRF, cache poisoning, and trust failures. Full breakdown.
What a DID resolver actually does
A decentralized identifier (DID) is a URI that points at a document describing keys, endpoints, and verification methods. A DID resolver is the component that turns that URI into a document you can trust enough to authenticate a peer, open a connection, or accept a credential. That hop is not cosmetic. It usually involves parsing a method-specific string, fetching or computing a document, applying caching rules, and handing the result to application code that treats it as authoritative.
CVE-2026-5520 is not publicly indexed as of May 3, 2026. That absence does not make resolver risk theoretical. The failure modes below show up whenever resolution is treated as a simple HTTP get with a blob of JSON on the other side. If your stack resolves DIDs for login, agent identity, or cross-service trust, the resolver is part of your attack surface whether or not a CVE ID is listed yet.
SSRF: resolution as an open proxy
Server-side request forgery (SSRF) is the most common resolver footgun. Method handlers often construct a URL from untrusted DID parts or from service endpoints inside a resolved document, then fetch it from the server. Without strict allowlists, scheme checks, and private-network blocking, an attacker can aim resolution at internal metadata endpoints, admin APIs, or cloud instance services that only the server can reach.
Defenses are mechanical. Resolve only over allowed schemes and hosts. Block loopback, link-local, and private ranges after DNS resolution, not only before. Cap redirects, enforce timeouts, and never follow a second hop into a URL the client fully controls. Treat any document field that becomes a fetch target as untrusted input, not as configuration.
Cache poisoning and trust failure
Resolvers cache for latency and rate limits. Cache poisoning turns that optimization into a trust failure: a bad document or a bad mapping for a DID is stored and served to later callers as if it were fresh and authentic. Poisoning can come from a compromised method endpoint, a race between concurrent resolvers, or accepting a response without binding it tightly to the DID that was requested.
- Key cache entries on the full DID method and identifier, not on a shortened host or path alone.
- Validate document structure and that the document’s subject matches the DID you asked for before storing anything.
- Prefer short TTLs for high-value identities, and support forced refresh on security-sensitive paths such as key rotation or credential presentation.
- Isolate caches per tenant or environment so one caller cannot prime shared state used by another.
Trust failure is broader than a single poisoned entry. Applications often assume that “resolved” means “verified.” Resolution only retrieves a candidate document. Verification still requires checking signatures, controller relationships, and that the keys in the document are the ones your protocol actually uses. Skipping that step converts every resolver bug into an authentication bug.
Practical hardening without a public CVE write-up
Until CVE-2026-5520 is indexed and method-specific patches land, treat DID resolution as a security boundary you own. Pin resolver libraries and method plugins; review which methods you enable and disable the rest. Log every external fetch with the DID, target URL after normalization, status, and cache hit or miss. Add integration tests that feed internal IPs, unexpected schemes, oversized documents, and documents whose subject does not match the DID.
Operationally, separate resolution from authorization. Resolution should return a document or a typed error. Authorization should decide whether that document is acceptable for the action at hand. That split keeps SSRF, cache, and trust issues from collapsing into a single silent accept. When the CVE becomes public, map its root cause onto this model: which stage failed—fetch, cache, or trust—and fix that stage first rather than only bumping a dependency and hoping the rest of the pipeline is sound.