aiohttp Static Resource Path Traversal and Existence Oracle

CVE-2025-69226 affects aiohttp, a widely used asynchronous HTTP client/server framework for Python. The vulnerability resides specifically in the UrlDispatcher.add_static method and the associated StaticResource class, which are responsible for serving static files from a designated directory.

In versions 3.13.2 and prior, the routing logic allows requests with traversal sequences (e.g., /static/../../etc/passwd) to pass the initial URL matching phase. Although the subsequent file handling logic blocks access to the file content, it inadvertently leaks information about the file's existence. When an attacker requests a file that exists outside the static root, the server responds with 403 Forbidden. Conversely, if the file does not exist, the server responds with 404 Not Found.

This behavior classifies the issue as an Existence Oracle (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor) facilitated by Path Traversal (CWE-22). While it does not permit arbitrary file read (Confidentiality impact is Low), it enables attackers to brute-force directory structures and identify the presence of sensitive files, config files, or logs on the host system.

The root cause lies in a logical discrepancy between the routing phase (resolve) and the handling phase (_handle) of a request.

The StaticResource class in aiohttp determines if a request matches a defined static route. In vulnerable versions, the resolve method simply checked if the raw requested URL path started with the configured static prefix (e.g., /static/). It did not normalize the path before this check. Consequently, a request for /static/../secret would satisfy the prefix check (/static/) and be routed to the static file handler.

Once the request reached the handler, aiohttp performed security checks to ensure the resolved path did not escape the root directory. If the path resolved to a file outside the root, the handler raised an HTTPForbidden (403) exception. If the path did not resolve to a file at all, the standard behavior for a static handler is to return HTTPNotFound (404).

This separation of concerns created the oracle: the router was too permissive, accepting traversal paths that the handler would later reject for security reasons. The difference in rejection methods (403 for security violation vs. 404 for missing file) provided the side channel.

The fix was implemented in aiohttp/web_urldispatcher.py by introducing path normalization directly into the routing logic. This ensures that any path attempting to traverse out of the static prefix is detected before it is matched to the handler.

Below is the analysis of the patch in StaticResource.resolve:

# aiohttp/web_urldispatcher.py
 
async def resolve(self, request: Request) -> _Resolve:
    path = request.rel_url.path_safe
    method = request.method
    
    # [PATCH] Normalization added here
    # We normalise here to avoid matches that traverse below the static root.
    # e.g. /static/../../../../home/user/webapp/static/
    norm_path = os.path.normpath(path)
    if IS_WINDOWS:
        norm_path = norm_path.replace("\\", "/")
    
    # [PATCH] Check against normalized path instead of raw path
    # If the normalized path has traversed out (e.g., becomes "/etc/passwd"),
    # it will no longer start with "/static/", failing this check.
    if not norm_path.startswith(self._prefix2) and norm_path != self._prefix:
        return None, set()
        
    # ... rest of resolution logic

By normalizing path to norm_path using os.path.normpath, sequences like /static/../ are resolved immediately. If the resulting path does not start with the required prefix, the router returns None. This causes the server to return a 404 Not Found for the URL, making the response indistinguishable from a request for a non-existent page.

Exploiting this vulnerability requires sending HTTP GET requests to a known static file endpoint. The attacker does not need authentication. The goal is to identify if specific files exist on the server.

Scenario: A server has static files mapped to /static/.

Step 1: Probe for existing system file The attacker sends: GET /static/../../../../etc/passwd HTTP/1.1

• Vulnerable Server: Returns 403 Forbidden. This confirms /etc/passwd exists.
• Patched Server: Returns 404 Not Found. The server denies knowledge of this path.

Step 2: Probe for non-existent file The attacker sends: GET /static/../../../../etc/doesnotexist HTTP/1.1

• Vulnerable Server: Returns 404 Not Found.
• Patched Server: Returns 404 Not Found.

By automating these requests with a wordlist of common files (e.g., config files, source code, SSH keys), an attacker can map the directory structure. This information is valuable for chaining attacks, such as identifying the location of a configuration file to target with a separate local file inclusion (LFI) vulnerability.

The primary remediation is to upgrade the aiohttp library to version 3.13.3 or later. This version includes the patch that enforces path normalization within the StaticResource.resolve method.

Installation:

pip install aiohttp>=3.13.3

Configuration Best Practices: The aiohttp documentation and security advisories consistently recommend against using web.static() for serving static files in production environments. This feature is intended for development convenience.

For production deployments, static files should be served by a dedicated reverse proxy (such as Nginx or Apache) or a Content Delivery Network (CDN). These specialized servers have more robust, battle-tested path handling logic and performance optimizations. Moving static file serving to a reverse proxy effectively mitigates this class of vulnerability within the application layer.