CVE-2026-115411 in crawlseo
Summary
by MITRE • 10/22/2026
crawlseo before version 0.2.4 contains a server-side request forgery vulnerability in its crawler engine where isPrivateIp() fails to block reserved IP ranges such as RFC 6598 Carrier-Grade NAT, RFC 6890, TEST-NET ranges and certain IPv6 addresses, and additionally fails to pin the validated address for the actual outbound connection, allowing a TOCTOU DNS rebinding bypass. An authenticated attacker can add a malicious domain that resolves to an internal or restricted address, trigger a crawl to reach internal services or cloud metadata endpoints like 169.254.169.254, and retrieve the fetched page's title, description, headings, status code and links through the crawl results API, enabling internal network reconnaissance.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in crawlseo versions prior to 0.2.4 represents a critical server-side request forgery flaw rooted in insufficient input validation within its crawler engine. The core technical deficiency lies in the implementation of the isPrivateIp() function, which is designed to prevent the application from making outbound requests to internal or reserved network addresses. However, this check fails to adequately filter out several categories of restricted IP ranges, including those defined by RFC 6598 for Carrier-Grade NAT, various TEST-NET ranges specified in RFC 6890, and specific IPv6 address blocks that are intended for local communication or documentation purposes. This oversight allows an attacker to bypass the initial security controls by targeting these unblocked reserved addresses, effectively turning a protective mechanism into a vector for unauthorized network access.
Beyond the static IP filtering failure, the vulnerability is exacerbated by a Time-of-Check to Time-of-Use race condition related to DNS resolution and connection pinning. The application validates that an input domain resolves to a safe public IP address before initiating the crawl request. However, it fails to pin this validated IP address for the duration of the actual outbound HTTP connection. This architectural flaw enables a classic DNS rebinding attack where an attacker controls a malicious domain configured with a very short Time-to-Live value. The application initially checks the domain and sees a public IP, passing validation. Before the crawler establishes the TCP connection to fetch the page content, the DNS record for that domain is updated by the attacker to resolve to an internal or restricted private IP address. Consequently, the outbound request is redirected from the intended safe target to an internal service, completely bypassing the initial security check due to the temporal gap between validation and execution.
The operational impact of this vulnerability is significant for organizations utilizing crawlseo in environments with sensitive internal infrastructure or cloud deployments. An authenticated attacker can exploit this flaw by adding a malicious domain that resolves via DNS rebinding to critical internal endpoints. A primary target is often the cloud metadata endpoint, such as 169.254.169.254 commonly found in AWS and other cloud environments, which stores instance identity documents, temporary credentials, and configuration data. By successfully reaching these internal services, the attacker can retrieve sensitive information exposed through the crawl results API. The application returns fetched page metadata including titles, descriptions, headings, HTTP status codes, and hyperlinks. This capability transforms a simple web crawling tool into a powerful reconnaissance instrument, allowing attackers to map internal network topologies, discover hidden administrative interfaces, and potentially escalate privileges by harvesting cloud credentials or sensitive configuration data from internal APIs that are not intended for external access.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically involving the failure to restrict outbound connections to authorized destinations. The DNS rebinding aspect further correlates with CWE-20 Improper Input Validation and CWE-367 Time-of-check Time-of-use Race Condition. In terms of offensive security tactics, this exploit maps directly to MITRE ATT&CK technique T1557 Adversary-in-the-Middle, specifically the sub-technique for DNS rebinding used to bypass network controls. It also relates to T1046 Network Service Discovery as the attacker uses the SSRF capability to probe internal services and gather information about the target environment without direct external access.
Mitigation strategies must address both the static filtering logic and the dynamic resolution behavior. The most effective immediate mitigation is upgrading crawlseo to version 0.2.4 or later, where these validation checks have been hardened to include all relevant RFC-defined reserved ranges and IPv6 restrictions. For environments unable to upgrade immediately, network-level controls such as egress firewalls should be configured to block outbound traffic from the application server to known internal IP ranges and cloud metadata endpoints like 169.254.169.254 regardless of DNS resolution results. Additionally, implementing strict DNS validation at the operating system level or using a dedicated proxy that pins IPs after initial lookup can help mitigate TOCTOU risks. Application developers should also consider validating IP addresses immediately before each network operation rather than relying solely on pre-request checks, ensuring that the destination address remains consistent with the validated state throughout the request lifecycle.