Lesson: Vercel DEPLOYMENT_NOT_FOUND is a fingerprint, not a confirmed takeover - the team-verification gate decides claimability

Banked: 2026-06-12 Source: Elastic (HackerOne public bounty) passive subdomain-takeover recon, lane = web2-sprawl-enterprise Class: subdomain-takeover / SaaS-dangling-domain triage

The pattern (new, banked)

A subdomain CNAME'd to cname.vercel-dns.com (or A to a Vercel edge IP) that returns: - port 80: 308 Permanent Redirect, server: Vercel (Vercel recognizes the Host) - port 443: HTTP 404, server: Vercel, x-vercel-error: DEPLOYMENT_NOT_FOUND - frequently an EXPIRED Let's Encrypt cert (Vercel stops renewing once the deployment is deleted -> expiry date marks roughly when it was abandoned)

is the Vercel dangling-domain FINGERPRINT. It is necessary but NOT sufficient for takeover.

The claimability gate (the actual decision boundary)

Vercel only lets a new project attach a custom domain if that hostname (and/or its apex) is NOT already verified to another Vercel team. Two sub-cases:

1. CLAIMABLE: the deployment was deleted AND the domain/apex is no longer team-verified -> an attacker can add host as a custom domain to their own project and serve content. Real takeover.
2. NOT CLAIMABLE: the deployment was deleted BUT the apex (e.g. elastic.dev) is still verified to the owner's Vercel team -> Vercel rejects "domain already in use." Same DEPLOYMENT_NOT_FOUND page, but ZERO takeover. This is the common false-positive.

DEPLOYMENT_NOT_FOUND alone CANNOT distinguish these two. The expired-cert + DEPLOYMENT_NOT_FOUND combo is suggestive of abandonment but does not resolve the apex-verification question.

Rule

• STAGE a Vercel DEPLOYMENT_NOT_FOUND host as a CANDIDATE, never as a CONFIRMED finding, from passive recon alone.
• The claimability test (add the domain to your own Vercel project) is an ACTIVE step -> ROE-gated, operator per-send approval required, never auto-run.
• Differential control: fetch a claimed sibling on the same Vercel apex (e.g. docs.elastic.dev returned 401 deployment-protection = healthy). If a sibling is clearly claimed and healthy, the apex is plausibly still team-verified -> downgrade confidence on claimability.
• Severity weighting: brand/label matters. *.elastic.dev staging/docs path = Medium at most (phishing/content-injection under a trusted host). An auth/login/api/admin-labelled host on the same fingerprint would rank higher.

Cross-reference to existing banked rules

• Extends the Statuspage rule (x-statuspage-version present = claimed) and the Firebase rule (anycast + "Site Not Found" = candidate): same principle - the provider error page is a FINGERPRINT, and a second provider-specific gate (team-verification / project-attach) decides real claimability. Vercel's gate is apex team-verification.
• Reinforces banked thesis: takeover EV concentrates in acquired/peripheral brand paths of large multi-acquisition orgs. Here the only soft spot was on *.elastic.dev (dev/docs brand) staging, not the primary *.elastic.co product surface.

Negative results banked this cycle (avoid re-walking)

• NXDOMAIN host = zero surface (re-confirmed: bvans-staging.swiftype.com etc. are CT-log artifacts, not live).
• All 345 in-scope CNAME targets resolved -> NO NXDOMAIN-target CNAME takeovers existed. Dangling-CNAME-at-DNS-layer was a dead end here; the only unclaimed surface was provider-app-layer (Vercel). Lesson: in mature orgs, DNS-resolution-layer dangles are rare; app-layer provider-error fingerprints are where residual EV sits.
• Dangling A-record to a raw IP (demos.swiftype.com -> DigitalOcean IP, HTTP:000) is NOT a SaaS-claim vector (no provider to claim through). Note, do not stage as takeover.