Raphael Vinot

Lookyloo did not enforce limits on the decompressed size of uploaded capture archives and compressed HAR files. An attacker could submit a specially crafted ZIP, gzip, or zlib-compressed capture containing data that expands to a very large size during processing. Because the application decompressed this content directly in memory without first limiting the output size, processing the malicious capture could exhaust available memory, terminate a web or worker process, or make the Lookyloo instance unavailable. The vulnerability affects both full Lookyloo capture archive imports and API submissions containing gzip-compressed HAR data. Repeated exploitation could cause a persistent denial-of-service condition until the affected processes or instance are restarted. The patch introduces: * A 1 GB cumulative uncompressed-size limit for imported capture archives. * Size-limited gzip and zlib decompression for compressed HAR files. * Explicit detection and handling of suspected zip bombs. * An HTTP 400 response when an oversized compressed HAR file is submitted through the API.

A stored cross-site scripting vulnerability existed in the capture tree visualization page. The application embedded the serialized capture tree directly into an inline JavaScript block using the Jinja safe filter. Because the tree data can contain values derived from captured and potentially attacker-controlled web content, a specially crafted value could prematurely terminate the surrounding <script> element and inject arbitrary HTML or JavaScript. The malicious code would execute in the browser of a user viewing the affected capture tree. Successful exploitation could allow an attacker to perform actions using the victim’s authenticated session, access information available to the victim, or modify application data within the permissions of the affected user. The patch removes the JSON data from the HTML document and retrieves it through a dedicated API endpoint. The client then processes the response using response.json(), preventing capture data from being interpreted as executable content within the original page’s HTML or JavaScript context.

**Name of the Vulnerable Software and Affected Versions** PlaywrightCapture (affected versions not specified) **Description** PlaywrightCapture stored configuration and runtime data as mutable class-level variables instead of instance-level variables. This allows multiple Capture objects within the same Python process to share state, including HTTP headers, cookies, browser storage, HTTP credentials, proxy configuration, user-agent settings, geolocation information, and captured request data. In concurrent or multi-user deployments, data from one capture can persist and be reused by others, potentially leading to the disclosure of authentication cookies, credentials, or browser storage. This may also allow requests to be executed using another capture's authentication context or proxy configuration, enabling unauthorized access to remote resources. **Recommendations** Initialize all capture-specific settings and request data as instance variables in the Capture constructor to ensure state isolation between operations.