CVE-2026-84366: 
Python vulnerability analysis and mitigation

CVE-2026-84366 is a cleartext transmission vulnerability in Scrapy's S3DownloadHandler that causes signed S3 requests to be sent over plaintext HTTP by default, exposing AWS credentials and S3 content to network attackers. It affects all Scrapy versions prior to 2.17.0 (i.e., <= 2.16). The vulnerability was disclosed on July 7, 2026 via a GitHub Security Advisory and assigned a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory).

The root cause is classified as CWE-319 (Cleartext Transmission of Sensitive Information). In scrapy/core/downloader/handlers/s3.py, the S3DownloadHandler converts s3://bucket/key URIs into http://bucket.s3.amazonaws.com/key unless request.meta["is_secure"] is explicitly set to a truthy value — a non-secure default. The signed request (including the AWS Authorization header and optionally X-Amz-Security-Token for temporary credentials) is then transmitted over this unencrypted channel. The fix, introduced in commit 9523e1e, inverts the logic so HTTPS is used by default and HTTP is only used when request.meta["is_secure"] is explicitly set to False (GitHub Advisory, Fix Commit).

A passive network attacker (e.g., on a public Wi-Fi network, compromised router, or via ARP spoofing) can intercept the plaintext traffic to read the S3 bucket/key path, AWS Authorization header, X-Amz-Security-Token (when temporary credentials are in use), S3 object contents, and S3 response headers. An active man-in-the-middle attacker can additionally tamper with S3 response bodies, status codes, and headers, leading to scraped-data poisoning, poisoned exports, HTTP cache poisoning (when caching is enabled), and manipulation of future crawl targets via forged redirects or injected links. The confidentiality and integrity impacts are both rated High, with no availability impact (GitHub Advisory).

No public exploit code or in-the-wild exploitation has been reported as of the disclosure date. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a network-level attacker positioned to observe or intercept traffic between the Scrapy instance and AWS S3 endpoints, making it a High attack complexity scenario. The vulnerability only affects users who make s3:// scheme requests with AWS credentials configured (GitHub Advisory).

1. Positioning: Gain a network vantage point between the Scrapy host and AWS S3 endpoints — e.g., via ARP spoofing on a local network, a compromised router, or an ISP-level interception point.
2. Traffic capture: Use a packet capture tool (e.g., tcpdump, Wireshark) to monitor plaintext HTTP traffic on port 80 destined for *.s3.amazonaws.com.
3. Credential harvesting (passive): Extract the Authorization header (AWS Signature) and X-Amz-Security-Token (if present) from captured HTTP requests, along with the S3 bucket name, key path, and object contents.
4. Response tampering (active MITM): Intercept the plaintext HTTP response from S3 and modify the response body, status code, or headers before forwarding to the Scrapy client — injecting malicious links, poisoning cached data, or triggering forged redirects to influence subsequent crawl behavior (GitHub Advisory).

• Network: Outbound HTTP (port 80) connections from the Scrapy host to *.s3.amazonaws.com — legitimate Scrapy S3 traffic post-patch should use HTTPS (port 443); plaintext S3 traffic is anomalous on patched systems.
• Network: Unexpected ARP replies or gratuitous ARP packets on the local network segment hosting the Scrapy instance, which may indicate ARP spoofing by a MITM attacker.
• Logs: Scrapy request logs showing http:// scheme URLs for s3:// requests (e.g., http://bucket.s3.amazonaws.com/key) on unpatched versions.
• Data: Unexpected or malformed content returned from S3 requests; scraped data containing injected links or unexpected redirects not present in the original S3 objects.

Upgrade Scrapy to version 2.17.0 or later, which changes the default scheme for S3 requests from HTTP to HTTPS (Scrapy Release, Fix Commit). As a short-term workaround on unpatched versions, explicitly set request.meta["is_secure"] = True on all s3:// requests to force HTTPS. After upgrading, the previous insecure behavior can be restored per-request by setting request.meta["is_secure"] = False, though this is not recommended.

The vulnerability was reported by researcher syncrain and published by AdrianAtZyte of Zyte via the GitHub Security Advisory program on July 7, 2026. No significant broader media coverage or notable community commentary beyond the advisory itself has been identified at this time (GitHub Advisory).