crawlseo EUVD-2026-108164

Requires an authenticated crawlseo account with permission to add or edit a site/domain and trigger a crawl (PR:L); it is not exploitable by an unauthenticated outsider. No non-default configuration is needed - the flaw is in the default crawler engine's isPrivateIp() allowlisting, which failed to block RFC 6598 CGNAT, RFC 6890, TEST-NET-1/2/3 and several reserved IPv6 ranges, and in the engine not pinning the pre-flight-validated address for the outbound connection (enabling DNS rebinding). The attacker-controlled target must resolve to the desired internal/restricted address, and to reach cloud metadata the crawlseo instance must itself be deployed somewhere that can route to 169.254.169.254 or internal hosts. Limiting factors: required authentication, and the data returned to the attacker is restricted to the page's title, description, headings, status code and links rather than arbitrary response content.

This is a medium-severity SSRF (CVSS 4.0 base 5.3, vector AV:N/AC:L/AT:N/PR:L/UI:N) whose impact is confined to subsequent-system confidentiality (SC:L) with no integrity or availability effect (VI:N/VA:N/SI:N/SA:N) and no impact on the crawlseo host itself (VC:N). The attack vector is network and complexity is low, but PR:L means an attacker must first hold an authenticated application account that can add a site and trigger a crawl, which materially narrows the exposure versus an unauthenticated SSRF. No EPSS score was supplied, so exploitation probability cannot be quantified here, and the vulnerability is NOT present in the CISA KEV catalog, so there is no evidence of active exploitation; a public PoC reference exists (a gist) but it is not verified as working exploit code. The vendor-assigned priority is 'this_month' rather than act_now/emergency, which is consistent with a real-but-not-urgent issue. The genuine concern is reachability of cloud metadata (169.254.169.254) and internal services, which in some environments can expose credentials; however, the data returned to the attacker is limited to the fetched page's title, description, headings, status code and links, so exfiltration of raw metadata content is constrained by whatever the crawler's HTML parser extracts rather than returning arbitrary response bodies - defenders should weigh this limiting factor rather than treating it as a full read-anything SSRF. Net: a legitimate patch-this-cycle item for anyone running crawlseo with multi-tenant or lower-trust authenticated users, not a drop-everything emergency.

An authenticated crawlseo user registers a site whose domain resolves to an internal or restricted address (or uses DNS rebinding to flip the answer after validation), then triggers a crawl so the engine fetches a cloud metadata endpoint such as 169.254.169.254 or an internal service. The attacker then reads the harvested title, description, headings, status code and links through the crawl results API to perform internal reconnaissance. A public PoC reference (a gist) exists but is not verified as working exploit code.