CVE-2026-84366

Scrapy before 2.17.0 converts s3:// (S3-scheme) bucket/key requests into plaintext HTTP requests to the corresponding S3 endpoint unless request.meta["is_secure"] is explicitly enabled, then signs and sends them with the configured AWS credentials. The flaw is triggered whenever a crawl issues S3-scheme requests using AWS credentials over a network path that is not protected, because the request and response travel unencrypted. A passive network observer can read the bucket and key path, the AWS Authorization header, the X-Amz-Security-Token when temporary credentials are used, S3 object contents, and S3 response headers; an active man-in-the-middle can additionally modify the plaintext response body, status code, and headers, enabling scraped-data poisoning, poisoned exports, HTTP cache poisoning where caching is enabled, and influence over later crawl targets via forged redirects or attacker-controlled links. Only Scrapy users who make S3-scheme requests with AWS credentials are affected; ordinary HTTP/HTTPS crawls are not impacted. Exploitation is not currently known: there is no public proof-of-concept, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at about 0.2%.

What to do: Upgrade to Scrapy 2.17.0, which fixes the issue. As interim mitigations, explicitly set request.meta["is_secure"] = True on S3-scheme requests, or avoid crawling s3:// URLs with AWS credentials over untrusted networks (e.g., use a VPN or private connectivity to S3). If a network observer or tamperer was plausible, consider flushing Scrapy's HTTP cache and reviewing recently scraped S3 data and exports for signs of modification.