Subdomain Takeover Checker

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 4:11 AM UTC
• Version: 1.0.0

Overview

This is a straightforward subdomain-takeover checker, but active scans make DNS and HTTP requests, so users should run it only on authorized domain lists.

Install only if you intend to perform authorized subdomain-takeover checks. Prefer --passive for untrusted lists, and use active mode only for domains you control or are permitted to test; be aware that the metadata does not list curl even though the script uses it.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/check-takeover.sh:103

Finding

Blind Server-Side Request Forgery Through Unvalidated Domain Resolution

Content

View full analysis

Vulnerability Details

File Location: scripts/check-takeover.sh, lines 103-114
Vulnerability Type: Blind Server-Side Request Forgery (SSRF)
Risk Level: Medium

bash

# Check against vulnerable patterns
for pattern_entry in "${VULN_PATTERNS[@]}"; do
    local pattern="${pattern_entry%%:*}"
    local service="${pattern_entry##*:}"
    if [[ "$cname" == *"$pattern"* ]]; then
        if [ "$PASSIVE" = "0" ]; then
            # Verify with HTTP check — NXDOMAIN or error page = vulnerable
            local http_code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "http://$domain" 2>/dev/null || echo "000")
            if [ "$http_code" = "404" ] || [ "$http_code" = "000" ]; then
                VULN_COUNT=$((VULN_COUNT + 1))
                RESULTS+="⚠️  $domain → $cname ($service — potentially claimable)\n"
                return
            fi

Technical Analysis

The script accepts domains from a user-controlled command-line argument or input file and issues an HTTP request to each qualifying domain. Before invoking curl, it does not resolve and reject loopback, private, link-local, reserved, multicast, or cloud metadata addresses.

The CNAME allowlist check does not adequately mitigate this behavior because it performs loose substring matching:

bash

if [[ "$cname" == *"$pattern"* ]]; then

Consequently, an attacker-controlled CNAME such as github.io.attacker.example can satisfy the github.io pattern without being part of the legitimate github.io DNS namespace. The attacker can configure that hostname to resolve to an internal address. DNS rebinding can also change the resolved address between the script's dig operation and the subsequent curl request.

The response body is discarded, but the resulting HTTP status influences the reported result. The vulnerability therefore provides a blind SSRF and network-probing primitive rather than direct response-content dis ...[truncated 1583 chars]

Remediation

View remediation

Remediation Suggestions

1. Require users to provide an explicit, authorized domain scope and reject inputs outside that scope.
2. Validate each input as a hostname before passing it to DNS tools or curl.
3. Replace substring matching with DNS-label-aware suffix matching. A provider pattern should match only the exact provider domain or a genuine subdomain separated by a dot.
4. Resolve the destination before making an HTTP request and reject every returned IPv4 and IPv6 address belonging to loopback, private, link-local, multicast, reserved, documentation, unspecified, carrier-grade NAT, and cloud metadata ranges.
5. Protect against DNS rebinding by pinning curl to the previously validated address, for example with an appropriately constructed --resolve entry. Revalidate every address in the DNS response and do not follow redirects to unvalidated destinations.
6. Disable redirects unless necessary. If redirects are enabled later, validate the scheme, hostname, port, and resolved addresses at every redirect.
7. Permit only http and https, restrict destination ports to those genuinely required, and apply network-level egress controls so the process cannot access internal or metadata networks.
8. Treat HTTP status codes and transport failures only as signals for manual review. A 404 or 000 response alone does not establish that a hosted resource is claimable.

SkillSpector

Vulnerability Patterns

• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (1)

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 70% confidence

Finding

Without declared permissions the skill's intent is opaque and cannot be validated.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.