CVE-2026-111748 in aiohttp
Summary
by MITRE • 10/19/2026
AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.4, an attacker can send an absolute-form request that causes Request.scheme to use attacker-controlled request-target scheme data instead of the connection protocol. Applications that use Request.scheme for security decisions can consequently be tricked into treating an unencrypted connection as encrypted or an encrypted connection as unencrypted. This issue is fixed in version 3.14.4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in AIOHTTP, a widely used asynchronous HTTP client and server framework for Python's asyncio ecosystem, represents a critical flaw in how the library handles request parsing and scheme determination. Prior to version 3.14.4, the framework failed to properly validate or isolate the protocol scheme derived from an absolute-form URI within an HTTP request against the actual underlying connection protocol. This architectural oversight allows an attacker who can inject or manipulate the initial HTTP request line to force the Request.scheme attribute to reflect a value controlled by the attacker rather than the true transport-layer security state of the connection. In standard HTTP/1.1 and HTTP/2 specifications, absolute-form requests include the full URI including the scheme, which is typically used for proxying purposes. However, when this framework processes such requests without strict validation against the actual socket or TLS context, it creates a discrepancy between the perceived security level of the connection and its reality.
This technical flaw falls under CWE-20: Improper Input Validation, specifically relating to the failure to validate that input data conforms to expected constraints relative to the execution environment. Furthermore, this vulnerability aligns with MITRE ATT&CK technique T1583.004: Domains, as it involves manipulating network protocol fields to misrepresent security properties, and can be leveraged in conjunction with T1072: Software Deployment Tools if used for lateral movement or phishing campaigns where the visual representation of a secure connection is manipulated. The core issue lies in the assumption that the scheme provided in the request URI matches the actual encryption status of the transport layer. In many modern web applications and API gateways, developers rely on Request.scheme to make critical security decisions, such as enforcing HTTPS-only cookies, redirecting HTTP traffic to HTTPS, or determining whether sensitive data should be transmitted over a secure channel.
The operational impact of this vulnerability is severe for any application that utilizes AIOHTTP and relies on the scheme attribute for access control or security policy enforcement. An attacker can craft an absolute-form request with a target URI specifying https as the scheme while sending it over a plain HTTP connection, or vice versa. If the application trusts Request.scheme to indicate encryption status, it may incorrectly treat an unencrypted plaintext transmission as secure. This leads directly to CWE-319: Cleartext Transmission of Sensitive Information, where authentication tokens, session cookies, personal identifiable information, and other sensitive payloads are exposed in transit without encryption. Conversely, if the application treats a plain connection as encrypted due to this manipulation, it might skip necessary security checks or logging mechanisms that rely on secure channel detection, thereby weakening the overall defense-in-depth posture of the system.
Mitigation strategies must focus on immediate version upgrades and defensive coding practices. The primary remediation is to upgrade AIOHTTP to version 3.14.4 or later, where this logic has been corrected to ensure that Request.scheme accurately reflects the actual connection protocol rather than trusting the potentially malicious scheme component of an absolute-form request URI. For applications unable to immediately patch, developers should implement explicit validation layers that cross-reference the incoming request's scheme with the underlying transport security status provided by the asyncio event loop or TLS context. It is crucial not to trust user-supplied scheme values for security-critical decisions without independent verification from the network layer. Additionally, implementing strict Content-Security-Policy headers and ensuring that cookies are marked as Secure and SameSite can provide a secondary defense-in-depth measure against session hijacking resulting from this vulnerability. Regular dependency auditing using tools like pip-audit or Snyk is recommended to detect such misconfigurations in third-party libraries before they can be exploited in production environments.