CVE-2026-34515

What it actually does

In affected aiohttp versions before 3.13.4, the static resource handler on Windows can mishandle paths in a way that exposes information associated with an NTLMv2 remote path. In practical terms, a remote unauthenticated attacker may be able to submit crafted HTTP requests that cause the Windows-hosted aiohttp application to process or reveal details tied to UNC/NTLM-style network paths. The primary impact is confidentiality loss, including possible exposure of path information and, depending on deployment behavior and network controls, risk of outbound Windows authentication attempts to attacker-controlled infrastructure.

Why it matters to the business

Organizations running aiohttp-based services on Windows may unintentionally disclose sensitive network path information or create opportunities for credential-related reconnaissance. While there is no current evidence of active exploitation, the issue is network-accessible, requires no authentication, and has a high confidentiality impact, so exposed Windows deployments should be upgraded promptly to reduce the risk of information leakage and follow-on intrusion attempts.

How an attack unfolds

An attacker first identifies an aiohttp application that serves static resources from a Windows host. They then send specially crafted HTTP requests targeting the static resource handler with path forms that resemble or encode Windows remote paths, such as UNC-style paths. If the application is running a vulnerable aiohttp version, the handler may process the path incorrectly and disclose information about the NTLMv2 remote path or potentially trigger Windows network authentication behavior. The attacker can use the returned response, error behavior, access logs, timing, or any observed inbound SMB/NTLM interaction to learn about internal path handling and potentially support subsequent credential relay, password-cracking, or lateral-movement preparation, depending on environmental controls.

How to fix it

Upgrade aiohttp to version 3.13.4 or later wherever it is used, especially on Windows systems serving static resources. If an immediate upgrade is not possible, reduce exposure by disabling or restricting static file serving in aiohttp, validating and normalizing requested paths before they reach static handlers, rejecting requests containing backslashes or UNC-style path syntax, and blocking outbound SMB/NetBIOS traffic from application servers to untrusted networks. Review application dependencies to ensure transitive aiohttp installations are also updated. Harden Windows authentication by disabling NTLM where feasible, enforcing SMB signing, and preventing outbound authentication to the internet.

How to confirm the fix worked

Confirm the installed aiohttp package version is 3.13.4 or later using package inventory, lockfiles, container manifests, or runtime checks such as `python -m pip show aiohttp`. Verify that no deployed Windows aiohttp service uses a vulnerable aiohttp version for static resource handling. Test that requests containing encoded or literal Windows UNC-style path separators are rejected, normalized safely, or return generic errors without disclosing path details. Confirm outbound SMB/NetBIOS connections from application servers to untrusted destinations are blocked by host firewall, network firewall, or egress controls.

Typical attack path

1. Identify internet-facing or internally reachable Python aiohttp services, especially those hosted on Windows.
2. Determine whether the application exposes aiohttp static resource routes.
3. Send crafted HTTP requests containing Windows-style remote path patterns, backslashes, or encoded UNC path sequences.
4. Observe HTTP responses, error messages, timing differences, and any network callbacks to attacker-controlled SMB/NTLM infrastructure.
5. Use disclosed path information or captured authentication-related metadata for reconnaissance or follow-on attacks.
6. Attempt further exploitation only if additional weaknesses exist, such as permissive outbound SMB, weak NTLM controls, or credential relay exposure.

How to detect it

To determine whether exploitation was attempted or successful, review aiohttp access logs, reverse proxy logs, WAF logs, EDR telemetry, Windows event logs, DNS logs, and firewall/netflow records. Look for HTTP requests to static-resource paths containing literal or encoded backslashes, UNC path prefixes, hostnames embedded in paths, or repeated malformed static-file requests. Correlate those requests with outbound connections from the same server to TCP ports 445 or 139, UDP ports 137 or 138, or DNS lookups for attacker-controlled hostnames shortly after the request. On Windows, examine authentication telemetry for NTLM activity that coincides with suspicious HTTP requests, including failed or outbound NTLM authentication attempts. In EDR, look for `python.exe` or the service wrapper process initiating SMB connections, which is atypical for many web applications.

• \\\\
• %5c%5c
• %5C%5C
• %255c%255c
• %255C%255C
• /static/\\
• /static/%5c%5c
• /static/%5C%5C
• UNC path
• NTLMSSP
• python.exe outbound TCP/445
• python.exe outbound TCP/139
• python.exe outbound UDP/137
• python.exe outbound UDP/138
• DestinationPort=445
• DestinationPort=139
• EventCode=8004 NTLM
• Microsoft-Windows-NTLM/Operational

What your security team should do

• Prioritize upgrading aiohttp to 3.13.4 or later on all Windows-hosted services that expose static resources.
• Inventory Python applications, containers, virtual environments, and dependency lockfiles for aiohttp versions earlier than 3.13.4.
• Add HTTP request filtering for UNC-style path patterns, encoded backslashes, and suspicious static-file traversal attempts.
• Block outbound SMB/NetBIOS traffic from application servers to the internet and other untrusted networks.
• Review Windows NTLM hardening posture, including NTLM restriction policies and SMB signing requirements.
• Search historical web, application, proxy, DNS, and firewall logs for suspicious UNC-path probes and outbound SMB activity from aiohttp hosts.
• Because EPSS is currently low and the issue is not in CISA KEV, handle as a prompt patching priority rather than an emergency internet-wide response unless exposed Windows services or outbound SMB are present.