CVE-2026-111748: AIOHTTP: Absolute-form request targets can spoof Request.scheme

Published Oct 19, 2026
·
Updated

Summary

An attacker sending an absolute-form request can spoof the scheme used.

Impact

If user code depends on the Request.scheme attribute for anything security related, an attacker may be able to circumvent this logic, tricking the application into thinking a connection is encrypted when it is not, or vice versa.

Workaround

A WAF rule to reject absolute-form requests (legitimate requests should only use this form for proxies).

Other sources

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.

— Ubuntu

Affected Software

12 affected componentsFixes available
pypi/aiohttp<3.14.4
pip/aiohttp<=3.14.3
3.14.4
ubuntu/python-aiohttp*
ubuntu/python-aiohttp*
ubuntu/python-aiohttp*
ubuntu/python-aiohttp*
ubuntu/python-aiohttp*
ubuntu/python-aiohttp*
ubuntu/python-aiohttp*
debian/python-aiohttp<=3.8.4-1+deb12u1, <=3.11.16-1+deb13u1, <=3.14.3-1
IBM App Connect Operator<=CD: 12.1.0 - 12.21.0 12.0 LTS: 12.0.0 - 12.0.28 13 LTS: 13.0.0 - 13.6.0
IBM App Connect EnterpriseCertified Containers Operands<=CD: 12.0.11.1-r1 - 12.0.12.5-r1, 13.0.1.0-r1 - 13.0.6.2-r1 12.0 LTS: 12.0.12-r1 - 12.0.12-r28 13 LTS: 13.0.7.0-r1 - 13.0.9.0-r1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/aiohttp to a version that resolves this vulnerability.

    Fixed in 3.14.4
  2. Upgrade

    Upgrade AIOHTTP to a version that resolves this vulnerability.

    Fixed in 3.14.4
  3. Compensating control

    Configure a WAF rule to reject absolute-form requests; legitimate requests should only use absolute-form for proxies.

Event History

Oct 19, 2026
CVE Published
via Ubuntu·12:00 AM
Data Sourced
via Ubuntu·12:00 AM
RemedyDescriptionSeverityAffected Software
CVE Published
via MITRE·05:02 PM
Data Sourced
via MITRE·05:02 PM
DescriptionWeakness
Data Sourced
via OSV·05:02 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:17 PM
DescriptionSeverityWeakness
Oct 20, 2026
Advisory Published
via GitHub·08:01 PM
Data Sourced
via GitHub·08:01 PM
DescriptionWeaknessAffected Software
Oct 28, 2026
Data Sourced
via OSV·08:17 PM
Affected Software
Nov 9, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Frequently Asked Questions

1

Which deployments are exposed?

AIOHTTP deployments using versions before 3.14.4 are affected if their application makes security decisions based on Request.scheme. The issue can cause the application to misidentify whether a connection is encrypted.

2

Does an attacker need authentication or user interaction?

No. The CVSS vector indicates no privileges or user interaction are required, but exploitation requires sending an absolute-form HTTP request target.

3

What should be done if upgrading cannot happen immediately?

Avoid using Request.scheme as the basis for security decisions until AIOHTTP is updated. Security checks should not trust scheme data supplied through an absolute-form request target.

4

How can I determine whether an application is at risk?

Check whether it uses AIOHTTP before version 3.14.4 and whether application logic relies on Request.scheme for decisions such as treating a request as encrypted or unencrypted. Test handling of absolute-form requests to identify whether the reported scheme can differ from the connection protocol.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203