The SSRF guard shared by PraisonAI's web tools ("SpiderTools._validate_url" → "_host_is_blocked" in "praisonaiagents/tools/spider_tools.py") inspects only literal IP-address encodings of the URL host. It never resolves DNS names. Any hostname whose A/AAAA record points at an internal, loopback, link-local, or cloud-metadata address passes validation and the request is issued to that target. A static internal A record is sufficient — no DNS-rebinding race is required. The guard's own docstring claims it returns "True" "when hostname resolves to loopback/private/internal targets," but no resolution is performed. The fix for CVE-2026-47390 added more encodings of literal IPs (decimal integer, "0x" hex, "inet_aton"); it did not address the class "host is a name that resolves to a forbidden address." The same guard is reached through two tool surfaces: - "scrape_page" / "crawl" / "extract_links" / "extract_text" (spider tools) - the "@url" mention fetch in "praisonaiagents/tools/mentions.py" (which calls the identical "SpiderTools._validate_url" then "urllib.request.urlopen") The correct pattern already exists in the same package: "file_tools.py" resolves the host with "socket.getaddrinfo" and checks each resolved address before fetching. "spider_tools" / "mentions" do not.