highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.DNS + host providerWhere it livesImplementationThis fix is applied in: DNS + host provider. That's the surface you'll edit, DNS, response headers, or a static file.~15 minTime to fixEffortRoughly 15 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Subdomain takeover: close the dangling record before someone claims it

Remove the dangling DNS record or reclaim the service before an attacker hosts content on your subdomain

The threat

One of your subdomains (say blog.yourdomain.com or status.yourdomain.com) has a DNSDNSInfrastructureThe Domain Name System, the internet's address book. It's also where you publish the SPF, DKIM, DMARC and CAA records that secure your domain. record, usually a CNAME, pointing at a third-party service (a hosting platform, a CDN, a docs or status-page provider) that no longer has anything set up on the other end. The service was decommissioned or the account closed, but the DNS record was left behind, dangling.

That gap is claimable. Because the platform sees an unclaimed target, whoever registers that same name on that platform gets served under your subdomain. From there they can host whatever they like (a phishing copy of your login, malware, a fake “we have moved” page) on an address that genuinely ends in yourdomain.com, borrowing every bit of trust your domain has earned. Cookies scoped to the parent domain and email or DNS-based verifications can be dragged in too.

The exact fix

The clock matters here, so do the fast, safe thing first.

1. Right now: remove the dangling DNS record. In your DNS provider, find the CNAME (or A / ALIAS) for the flagged subdomain and delete it if that subdomain is no longer in use. A record pointing at nothing you control is the whole vulnerability, and removing it closes the door immediately.

Check what it points at first:

dig +short CNAME blog.yourdomain.com
# e.g. some-old-app.example.com.  (a target you no longer own)

2. Or reclaim the service if you still need that subdomain. Go to the provider the record points at and re-create the resource (re-add the custom domain, re-provision the site) so you own the target again before anyone else can. Only keep the DNS record if you have reclaimed the other end.

Do the two in the right order. Either delete the record, or reclaim the resource and then keep the record. The one thing you must not do is leave a live record aimed at something you do not control. When in doubt, delete now and re-add later once the service is genuinely back.

3. Prevent the next one: when you tear down a site, service, or app, remove its DNS records in the same change. Keep a short inventory of which subdomain points at which provider, and periodically list your records and confirm each target still resolves to something you own.

Verify it

dig +short blog.yourdomain.com

For a subdomain you retired, the fix is correct when this returns nothing, meaning the record is gone. For one you reclaimed, it should resolve to your service and load your content, not the provider’s “no such app” or “domain not found” page.

Proof

The ApeCyber scanner catches this passively, from the outside, by resolving your public DNS and noticing a record aimed at a third-party target with nothing claimed on it, touching nothing. Confirming control by actually claiming the service is only ever done later, with your written consent, under the authorization-gated demonstration protocol, never as part of the passive scan. Close the dangling record and it clears, a clean −20 off your posture score.