CVE-2026-34513

What it actually does

The vulnerability is an unauthenticated network-reachable denial-of-service condition in aiohttp versions prior to 3.13.4. aiohttp’s DNS cache can grow without an effective bound when the framework is caused to resolve many distinct hostnames. In applications that use aiohttp as an HTTP client, an attacker who can influence outbound request targets, redirects, proxy behavior, webhooks, URL fetch features, or other hostname resolution paths may force repeated resolution of unique domains. Over time, the process can consume excessive memory, leading to degraded performance, worker restarts, out-of-memory termination, or service unavailability. The issue affects availability only; it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Services built with vulnerable aiohttp versions may become unstable or unavailable if they are made to resolve large numbers of unique hostnames. This can disrupt API availability, background jobs, integrations, webhook processing, scraping/fetching services, proxy-like features, and any Python service that relies on aiohttp for outbound HTTP communication. Although EPSS is currently low and there is no known KEV listing or public exploit maturity, the flaw is easy to trigger in exposed application patterns and should be remediated during normal patch cycles, with higher urgency for internet-facing services that accept user-supplied URLs or follow redirects.

How an attack unfolds

An attacker first identifies an application behavior that causes the server-side aiohttp client to resolve hostnames, such as a URL preview feature, webhook callback, import-by-URL workflow, metadata fetcher, SSRF-like request primitive, open redirect chain, or API endpoint that accepts a destination URL. The attacker then submits many requests containing unique hostnames or causes aiohttp to follow redirects across many unique domains. Because vulnerable aiohttp versions do not sufficiently bound the DNS cache, each distinct hostname can add entries that remain resident in memory. Repeating this at scale gradually increases memory usage in the Python process. Once memory pressure becomes significant, the service may slow down, fail requests, restart under its supervisor, or be killed by the operating system or container runtime, resulting in denial of service.

How to fix it

Upgrade aiohttp to version 3.13.4 or later wherever it is used. Rebuild and redeploy applications, containers, virtual environments, and serverless artifacts that vendor or pin aiohttp. If immediate upgrade is not possible, reduce exposure by blocking or tightly validating user-supplied URLs, disabling unnecessary redirect following, applying strict allowlists for outbound destinations, setting resource limits for containers/processes, monitoring memory growth, and restarting affected workers proactively as a temporary containment measure. Review dependency lockfiles and transitive dependencies to ensure the runtime actually resolves to a fixed aiohttp release, not only the top-level manifest.

How to confirm the fix worked

Confirm that deployed Python environments report aiohttp version 3.13.4 or later using package inventory, software composition analysis, lockfile review, container image scanning, or commands such as `python -m pip show aiohttp` in the runtime image. Validate that no vulnerable aiohttp versions remain in virtual environments, build artifacts, containers, base images, or bundled application packages. Exercise representative application flows that perform outbound HTTP requests and verify normal memory behavior under repeated requests to many unique hostnames. Confirm runtime safeguards such as URL allowlists, redirect limits, request timeouts, and memory limits are active where applicable.

Typical attack path

1. Identify an application or service using aiohttp before version 3.13.4.
2. Find functionality that causes server-side HTTP requests or DNS lookups, especially features accepting user-controlled URLs or following redirects.
3. Generate or control a large number of unique hostnames, subdomains, or redirect targets.
4. Send repeated requests that force aiohttp to resolve those unique hostnames.
5. Cause the aiohttp DNS cache to grow without an effective bound.
6. Exhaust available memory or trigger memory pressure in the Python process, container, or host.
7. Observe degraded performance, worker crashes, restarts, or service unavailability.

How to detect it

Look for evidence of denial-of-service activity rather than a unique exploit payload. Relevant sources include application logs, reverse proxy logs, outbound HTTP client logs, DNS resolver logs, container orchestration events, operating system logs, process supervisor logs, and metrics from APM or infrastructure monitoring. Investigate unusual growth in memory usage by Python/aiohttp services, repeated worker restarts, out-of-memory kills, elevated garbage collection pressure, increased request latency, and bursts of outbound DNS queries to many unique or random-looking hostnames. In application and proxy logs, look for repeated requests to endpoints that accept URLs, webhook destinations, import links, redirect targets, preview links, or callback parameters. In DNS logs, look for high cardinality of queried hostnames from the same service identity, especially randomized subdomains or domains controlled by a single external actor. Correlate these events with 5xx spikes, readiness/liveness probe failures, container restarts, and memory limit breaches. Because this issue may leave no aiohttp-specific exploit marker, detection should focus on behavioral indicators: abnormal unique hostname resolution volume, steadily increasing resident memory, and service restarts following URL-driven traffic.

• aiohttp<3.13.4
• Killed process python
• Out of memory: Killed process
• Memory cgroup out of memory
• OOMKilled
• Exit Code 137
• exit code 137
• ContainerStatusUnknown
• Back-off restarting failed container
• CrashLoopBackOff
• MemoryError
• python -m pip show aiohttp
• Name: aiohttp
• aiohttp==3.13.3
• aiohttp==3.13.2
• aiohttp==3.13.1
• aiohttp==3.13.0

What your security team should do

• Inventory Python applications, containers, and serverless packages for aiohttp versions earlier than 3.13.4.
• Prioritize remediation for internet-facing services, URL fetchers, webhook processors, integrations, crawlers, preview generators, and any application that accepts user-controlled URLs.
• Upgrade aiohttp to 3.13.4 or later and redeploy all affected artifacts.
• Add or verify controls that restrict outbound HTTP destinations, validate URL inputs, limit redirect chains, and prevent untrusted users from forcing arbitrary DNS resolutions.
• Monitor vulnerable or recently patched services for abnormal memory growth, worker restarts, out-of-memory kills, and spikes in unique outbound DNS queries.
• Add dependency scanning gates to prevent reintroducing vulnerable aiohttp versions through lockfile drift or transitive dependency changes.
• If patching must be delayed, apply compensating controls such as memory limits, rate limiting, egress filtering, and temporary disabling of high-risk URL-fetch functionality.