CVE-2026-103022: Denial of Service via Unhandled Unicode Exception and File Descriptor Leak in Urwid Web Display

Urwid is a widely used Python library for building console and terminal user interfaces. In addition to standard terminal rendering backends such as curses and raw terminal modes, Urwid includes an optional web display module (urwid/display/web.py). This module allows terminal applications to be rendered interactively within a web browser by acting as a Common Gateway Interface (CGI) bridge between HTTP clients and a backend Python application process.

The web display architecture relies on inter-process communication (IPC) mechanisms stored in a temporary directory (_prefs.pipe_dir). Specifically, the CGI script processes short-lived HTTP requests via the handle_short_request() function to forward user keystrokes into a named pipe (FIFO) and poll screen updates from a Unix domain socket. Because this handler directly parses network-supplied HTTP request bodies and environment variables, it serves as the primary network attack surface for deployments utilizing Urwid's web display feature.

In Urwid versions prior to 4.0.7, handle_short_request() contains three related defects mapped to CWE-116 (Improper Encoding or Escaping of Output), CWE-248 (Uncaught Exception), and CWE-775 (Missing Release of File Descriptor or Handle after Effective Lifetime). When processing user input or polling updates, the function fails to handle character encoding mismatches and omits resource cleanup blocks.

An attacker who obtains a valid X-Urwid-ID session identifier can send non-ASCII characters in HTTP POST requests to trigger an uncaught UnicodeEncodeError. In persistent execution environments such as FastCGI, SCGI, or custom WSGI wrappers, each unhandled exception bypasses the os.close() call for the underlying FIFO pipe. Repeated requests exhaust available operating system file descriptors, causing the application to fail with EMFILE (Too many open files) and denying service to legitimate users.

The root cause of CVE-2026-103022 lies in improper exception handling and deterministic resource management across two distinct execution paths inside urwid/display/web.py: the keyboard input path and the screen update polling path.

In the keyboard input path, the handler opens a write-only file descriptor (fd) pointing to /tmp/urwid_<id>.input using os.open(). Immediately following this operation, the function reads up to MAX_READ characters from sys.stdin and calls keydata.encode("ascii") directly inside the os.write() argument list. Because Python 3 defaults sys.stdin to UTF-8 in most server environments, reading multibyte UTF-8 characters succeeds, producing a Python str containing non-ASCII code points. Passing this string to .encode("ascii") raises a UnicodeEncodeError whenever any character falls outside the 7-bit ASCII range (0x00–0x7F).

Because the os.open() call and the subsequent os.close(fd) call are not enclosed within a try...finally block, the raised UnicodeEncodeError unwinds the call stack immediately. The os.close(fd) statement becomes unreachable. While standard single-shot CGI scripts terminate the OS process upon completion—allowing the kernel to reclaim the leaked descriptor—persistent CGI runners, FastCGI daemons, or embedded HTTP servers retain the leaked descriptor inside the worker process table indefinitely.

A secondary defect exists in the screen update polling path, triggered when the HTTP_X_URWID_METHOD environment variable is set to "polling". The function instantiates an AF_UNIX stream socket and enters a while loop calling s.recv(BUF_SZ).decode("utf-8"). This implementation contains two flaws: first, s.recv(BUF_SZ) reads arbitrary byte chunks from the stream, meaning a multibyte UTF-8 character split across two BUF_SZ boundaries will fail to decode and raise UnicodeDecodeError. Second, the surrounding try...except block only catches OSError, leaving UnicodeDecodeError uncaught and failing to close the socket s via a context manager or finally clause.

The vulnerability was remediated in commit b79d9a96843a6f5950bb2bfab5d059bdc61c538b (Pull Request #1201). Comparing the vulnerable implementation with the patched implementation demonstrates how both the encoding assumptions and resource leaks were resolved.

In the vulnerable version of urwid/display/web.py, the polling and keyboard input paths were implemented as follows:

    if os.environ.get("HTTP_X_URWID_METHOD", None) == "polling":
        # Vulnerable: Socket is not opened in a context manager
        s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
        try:
            s.connect(os.path.join(_prefs.pipe_dir, f"urwid_{urwid_id}.update"))
            # Vulnerable: Iterative UTF-8 decoding fails on split multibyte sequences
            data = f"Content-type: text/plain\r\n\r\n{s.recv(BUF_SZ).decode('utf-8')}"
            while data:
                sys.stdout.write(data)
                data = s.recv(BUF_SZ).decode("utf-8")
        except OSError:
            # Vulnerable: Does not catch UnicodeDecodeError or close socket 's'
            sys.stdout.write("Status: 404 Not Found\r\n\r\n")
            return True
 
    # Keyboard input request
    fd = os.open(os.path.join(_prefs.pipe_dir, f"urwid_{urwid_id}.input"), os.O_WRONLY)
    if fd < 0:
        sys.stdout.write("Status: 404 Not Found\r\n\r\n")
        return True
 
    # FIXME: use the correct encoding based on the request
    keydata = sys.stdin.read(MAX_READ)
    # Vulnerable: Hardcoded ASCII encoding without exception handling or finally block
    os.write(fd, keydata.encode("ascii"))
    os.close(fd)

The patch introduces a helper function _request_charset() utilizing Python's email.message.Message parser to extract the charset parameter from the CONTENT_TYPE environment variable, defaulting to utf-8 if unspecified. It also restructures both the socket and file descriptor lifecycles:

def _request_charset() -> str:
    content_type = Message()
    content_type["content-type"] = os.environ.get("CONTENT_TYPE", "")
    return content_type.get_content_charset() or "utf-8"

Within handle_short_request(), the patch modifies the polling and input logic to enforce deterministic cleanup and catch encoding exceptions:

    if os.environ.get("HTTP_X_URWID_METHOD", None) == "polling":
        try:
            # Fix: Context manager guarantees socket closure on exit
            with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as s:
                s.connect(os.path.join(_prefs.pipe_dir, f"urwid_{urwid_id}.update"))
                chunks = []
                # Fix: Accumulate raw bytes before decoding to prevent split multibyte errors
                while data := s.recv(BUF_SZ):
                    chunks.append(data)
        except OSError:
            sys.stdout.write("Status: 404 Not Found\r\n\r\n")
            return True
 
        try:
            decoded = b"".join(chunks).decode("utf-8")
        except UnicodeDecodeError:
            # Fix: Catch invalid UTF-8 and return 502 Bad Gateway
            sys.stdout.write("Status: 502 Bad Gateway\r\n\r\n")
            return True
 
        sys.stdout.write(f"Content-type: text/plain; charset=utf-8\r\n\r\n{decoded}")
        return True
 
    # Keyboard input request
    fd = os.open(os.path.join(_prefs.pipe_dir, f"urwid_{urwid_id}.input"), os.O_WRONLY)
    if fd < 0:
        sys.stdout.write("Status: 404 Not Found\r\n\r\n")
        return True
 
    try:
        try:
            keydata = sys.stdin.read(MAX_READ)
            # Fix: Encode using client-specified charset or UTF-8 fallback
            encoded_keydata = keydata.encode(_request_charset())
        except (LookupError, UnicodeError):
            # Fix: Catch unknown charsets (LookupError) and encoding failures (UnicodeError)
            sys.stdout.write("Status: 400 Bad Request\r\n\r\n")
            return True
        os.write(fd, encoded_keydata)
    finally:
        # Fix: Guarantee file descriptor release even when returning early or raising
        with suppress(OSError):
            os.close(fd)

The fix is complete with respect to both exception handling and descriptor lifecycle management. By catching (LookupError, UnicodeError), the code prevents attacker-controlled Content-Type headers (e.g., Content-Type: text/plain; charset=invalid-codec) from raising an uncaught LookupError during the .encode() call. Furthermore, wrapping os.close(fd) inside finally: with contextlib.suppress(OSError) guarantees that the file descriptor is closed regardless of whether the inner block returns early on a 400 Bad Request or raises an unexpected OSError during os.write().

Exploiting CVE-2026-103022 requires network access to an HTTP server exposing an Urwid application via urwid/display/web.py, along with a valid X-Urwid-ID session token. Before reaching the vulnerable code path, handle_short_request() validates that the HTTP_X_URWID_ID environment variable consists strictly of alphanumeric characters (urwid_id.isalnum()) and corresponds to an existing session pipe in _prefs.pipe_dir. If the web display interface allows unauthenticated users to initialize a session, an attacker can obtain a valid X-Urwid-ID directly by loading the initial web page.

Once a valid session ID is acquired, the attacker sends an HTTP POST request containing non-ASCII bytes in the request body without setting the X-Urwid-Method: polling header. For example, transmitting the two-byte UTF-8 sequence \xc3\xa9 (representing é) triggers the flaw:

POST /cgi-bin/urwid_web.cgi HTTP/1.1
Host: target.example.com
X-Urwid-ID: 482910492819
Content-Type: text/plain; charset=utf-8
Content-Length: 2
 
ƒ)

When the target server processes this request, handle_short_request() opens /tmp/urwid_482910492819.input and reads the body from sys.stdin. The call to keydata.encode("ascii") immediately fails with:

UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 0: ordinal not in range(128)

To achieve a persistent Denial of Service in a multi-request worker process (such as FastCGI, uWSGI, or mod_python), the attacker repeats this POST request in a loop. Each iteration leaks one file descriptor pointing to the FIFO pipe. Once the worker process reaches the operating system's per-process file descriptor limit (RLIMIT_NOFILE, commonly 1024 on Linux systems), all subsequent calls to os.open() or socket.socket() within that worker process fail with OSError: [Errno 24] Too many open files. At this point, the web display interface cannot process further keystrokes or screen updates for any active user.

CVE-2026-103022 is rated at a CVSS v3.1 base score of 5.3 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. The vulnerability is exploitable over the network (AV:N) with low attack complexity (AC:L) and requires no user interaction (UI:N). Because session initialization in standard Urwid web deployments does not enforce authentication by default, privileges required is rated as None (PR:N).

The security impact is strictly confined to availability (C:N/I:N/A:L). The flaw does not permit memory corruption, arbitrary file read/write, or remote code execution. The availability impact is classified as Low (A:L) because applications using standard CGI execution models spawn a fresh OS process per HTTP request; in those configurations, the operating system kernel automatically closes leaked file descriptors when the crashed CGI process exits, limiting the impact to individual failed requests (HTTP 500 responses) rather than full system exhaustion.

However, in deployments where handle_short_request() is invoked repeatedly within a long-lived Python interpreter process, the availability impact escalates to a complete service outage for the affected worker pool. Furthermore, in the polling code path, reading buffered terminal output in fixed chunks (BUF_SZ) without reassembling byte streams prior to UTF-8 decoding causes intermittent crashes during normal usage whenever multibyte box-drawing characters or Unicode symbols straddle buffer boundaries.

According to threat intelligence metrics, CVE-2026-103022 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The Exploit Prediction Scoring System (EPSS) assigns this vulnerability a score of 0.00472 (0.472%), placing it in the 41.15th percentile. No public weaponized exploit modules or active exploitation campaigns have been recorded.

The primary remediation for CVE-2026-103022 is to upgrade the urwid package to version 4.0.7 or later. Version 4.0.7 incorporates commit b79d9a96843a6f5950bb2bfab5d059bdc61c538b, which replaces hardcoded ASCII encoding with dynamic charset resolution, buffers raw socket bytes prior to UTF-8 decoding, and wraps both file descriptors and Unix domain sockets in deterministic cleanup blocks.

Administrators and developers can apply the update using pip:

pip install --upgrade "urwid>=4.0.7"

> [!NOTE] > Applications that only use Urwid's standard console display modules (such as raw_display or curses_display) and do not expose urwid.display.web over an HTTP server are not reachable by this attack vector.

If an immediate upgrade to Urwid 4.0.7 is not possible, operators running urwid.display.web should implement compensating controls at the reverse proxy or Web Application Firewall (WAF) layer:

1. Input Filtering: Configure the reverse proxy or WAF to inspect POST request bodies sent to the CGI endpoint and reject requests containing byte values outside the 7-bit ASCII range (0x00–0x7F) with an HTTP 400 Bad Request status before they reach the Python handler.
2. Process Lifecycle Management: Ensure the CGI server executes urwid/display/web.py as a strict one-process-per-request CGI script rather than inside a persistent FastCGI or WSGI worker process, or configure aggressive worker recycling (max-requests) to reclaim leaked file descriptors periodically.
3. Access Control: Restrict access to the Urwid web display endpoint using HTTP authentication or mutual TLS so that unauthenticated actors cannot obtain valid X-Urwid-ID session identifiers.