CVE-2026-84366 in Scrapy
Summary
by MITRE • 09/02/2026
Scrapy is a high-level web crawling and scraping framework for Python. Prior to 2.17.0, in scrapy/core/downloader/handlers/s3.py, Scrapy's S3DownloadHandler converts an S3-scheme bucket and key request into a plaintext HTTP request to the corresponding S3 endpoint unless request.meta["is_secure"] is explicitly enabled, then signs and sends the plaintext request with configured AWS credentials. A network attacker who can observe traffic between Scrapy and S3 can read the bucket and key path, AWS Authorization header, X-Amz-Security-Token when temporary credentials are used, S3 object contents, and S3 response headers. An active man-in-the-middle attacker can also modify the plaintext S3 response body, status code, and headers before Scrapy processes them, causing scraped-data poisoning, poisoned exports, HTTP cache poisoning when caching is enabled, or influence over later crawl targets through forged redirects or attacker-controlled links. Users making S3-scheme requests with AWS credentials are affected. This issue is fixed in version 2.17.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in Scrapy versions prior to 2.17.0 represents a critical failure in transport layer security configuration for Amazon S3 operations, specifically within the S3DownloadHandler component of the scrapy/core/downloader/handlers/s3.py module. This flaw stems from an incorrect default behavior where requests targeting S3-scheme buckets and keys are transmitted as plaintext HTTP traffic rather than encrypted HTTPS connections. The logic governing this decision relies on a specific meta key named is_secure, which must be explicitly enabled by the developer to trigger secure transmission protocols. In typical usage scenarios where developers rely on standard Scrapy configurations without manually injecting security flags into request metadata, the framework defaults to sending sensitive data over unencrypted channels. This design oversight effectively negates the confidentiality and integrity guarantees provided by TLS/SSL encryption for all S3 interactions unless explicitly overridden, exposing a significant attack surface in environments where secure-by-default practices are expected.
The operational impact of this vulnerability is severe due to the nature of the data being transmitted. Because the communication occurs over plaintext HTTP, any network attacker positioned between the Scrapy instance and the AWS S3 endpoint can perform passive eavesdropping to intercept sensitive information. This includes the full bucket name and object key path, which may reveal proprietary project structures or internal file organization schemes. More critically, the attack allows for the interception of AWS Authorization headers containing access keys and signatures, as well as X-Amz-Security-Token values when temporary credentials are utilized. These credentials provide direct authentication to AWS services, meaning their exposure can lead to unauthorized access to cloud resources. Furthermore, since the S3 object contents themselves are transmitted in plaintext, attackers can read sensitive data stored within those objects, such as personal identifiable information, proprietary code, or confidential business documents. The interception of response headers further aids reconnaissance efforts by revealing server configurations and internal routing details.
Beyond passive eavesdropping, an active man-in-the-middle attacker possesses the capability to perform sophisticated injection attacks against the scraping pipeline. By intercepting the plaintext S3 responses, the attacker can modify the response body, status codes, and headers before they are processed by Scrapy. This manipulation leads directly to scraped-data poisoning, where the integrity of collected data is compromised, potentially leading to corrupted exports or flawed analytics derived from tainted datasets. If HTTP caching mechanisms are enabled within the scraping workflow, this vulnerability facilitates cache poisoning attacks, causing subsequent requests for legitimate resources to return attacker-controlled content without re-fetching it from S3. Additionally, attackers can forge redirects or inject malicious links into the scraped data, influencing later crawl targets and potentially leading users or automated systems to compromised websites. This chain of exploitation transforms a simple network sniffing vulnerability into a vector for supply chain attacks within the scraping ecosystem, affecting downstream consumers of the harvested data.
From a classification perspective, this issue aligns with CWE-319, which describes cleartext transmission of sensitive information over an exposed channel, and CWE-601, URL redirection to untrusted site. The attack vector corresponds to MITRE ATT&CK technique T1557, Adversary-in-the-Middle, specifically involving the interception and modification of network traffic between two trusted parties. To mitigate this vulnerability, organizations must immediately upgrade Scrapy to version 2.17.0 or later, where the default behavior has been corrected to enforce secure connections for S3 requests. For environments that cannot yet upgrade, developers should ensure that request.meta["is_secure"] is explicitly set to True for all S3-related requests as a temporary workaround. Furthermore, implementing strict network segmentation and monitoring can help detect anomalous traffic patterns indicative of man-in-the-middle attacks, although upgrading the software remains the only definitive remediation strategy.