Crawlseo
Monthly
Anyone able to read crawlseo's backing Postgres database before version 0.2.5 can pull every registered user's Google access and refresh tokens in plaintext from the User.googleTokens column, then use the long-lived refresh tokens to retain indefinite access to those users' Google Search Console data. Version 0.2.5 closes the exposure by encrypting Google tokens at rest with the same key used for API keys (NEXTAUTH_SECRET or AUTH_SECRET). The weakness is a post-compromise confidentiality issue (CWE-312) that presupposes database-level access rather than a remotely triggerable flaw in the running app; no public exploit has been identified at time of analysis.
Server-side request forgery in crawlseo before 0.2.4 lets an authenticated user with site-edit and crawl-trigger permission point the crawler at internal services and cloud metadata endpoints by registering a domain whose DNS answer falls in a reserved range or is rebound after validation. The crawler's isPrivateIp() blocklist omits RFC 6598 CGNAT, RFC 6890, TEST-NET-1/2/3 and several reserved IPv6 ranges, and the pre-flight-validated address is not pinned to the outbound socket, so a TOCTOU DNS-rebinding answer is accepted at connect time. Exfiltration is constrained to what the crawl results API returns for the fetched page (title, description, headings, status code and links), making this a reconnaissance-grade leak of subsequent-system data with no integrity or availability impact; no confirmed working exploit code is public at time of analysis, though a researcher gist describing the issue is referenced.
Anyone able to read crawlseo's backing Postgres database before version 0.2.5 can pull every registered user's Google access and refresh tokens in plaintext from the User.googleTokens column, then use the long-lived refresh tokens to retain indefinite access to those users' Google Search Console data. Version 0.2.5 closes the exposure by encrypting Google tokens at rest with the same key used for API keys (NEXTAUTH_SECRET or AUTH_SECRET). The weakness is a post-compromise confidentiality issue (CWE-312) that presupposes database-level access rather than a remotely triggerable flaw in the running app; no public exploit has been identified at time of analysis.
Server-side request forgery in crawlseo before 0.2.4 lets an authenticated user with site-edit and crawl-trigger permission point the crawler at internal services and cloud metadata endpoints by registering a domain whose DNS answer falls in a reserved range or is rebound after validation. The crawler's isPrivateIp() blocklist omits RFC 6598 CGNAT, RFC 6890, TEST-NET-1/2/3 and several reserved IPv6 ranges, and the pre-flight-validated address is not pinned to the outbound socket, so a TOCTOU DNS-rebinding answer is accepted at connect time. Exfiltration is constrained to what the crawl results API returns for the fetched page (title, description, headings, status code and links), making this a reconnaissance-grade leak of subsequent-system data with no integrity or availability impact; no confirmed working exploit code is public at time of analysis, though a researcher gist describing the issue is referenced.