CVE-2025-69654: QuickJS Interpreter DOS Vulnerability

CVE-2025-69654 Overview

A denial of service vulnerability exists in QuickJS, an embeddable JavaScript engine. A crafted JavaScript input executed with the QuickJS release 2025-09-13 using the qjs interpreter with the -m option and a low memory limit can cause an out-of-memory condition followed by an assertion failure in JS_FreeRuntime (list_empty(&rt->gc_obj_list)) during runtime cleanup. Although the engine reports an OOM error, it subsequently aborts with SIGABRT because the GC object list is not fully released, resulting in a denial of service condition.

Critical Impact

Attackers can crash QuickJS interpreter instances by triggering memory exhaustion conditions that lead to improper runtime cleanup, causing service disruption for applications relying on this JavaScript engine.

Affected Products

• QuickJS release 2025-09-13 (prior to commit fcd33c1afa7b3028531f53cd1190a3877454f6b3)
• Applications embedding QuickJS with memory-constrained configurations
• Systems using qjs interpreter with the -m module option

Discovery Timeline

• 2025-12-11 - Fix committed in QuickJS repository (commit fcd33c1afa7b3028531f53cd1190a3877454f6b3)
• 2026-03-06 - CVE CVE-2025-69654 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2025-69654

Vulnerability Analysis

This vulnerability falls under CWE-400 (Uncontrolled Resource Consumption) and manifests as a resource exhaustion issue within the QuickJS JavaScript engine's garbage collection mechanism. When the interpreter encounters an out-of-memory condition during execution, the subsequent runtime cleanup process fails to properly release all objects from the garbage collection object list.

The core issue occurs during the JS_FreeRuntime function execution, where an assertion check verifies that the GC object list (rt->gc_obj_list) is empty before completing runtime cleanup. Under specific memory-constrained scenarios triggered by crafted JavaScript input, this assertion fails because memory exhaustion prevents the normal cleanup sequence from completing properly.

This vulnerability is exploitable over the network without authentication or user interaction, making it particularly concerning for server-side JavaScript execution environments or web applications that evaluate untrusted JavaScript code.

Root Cause

The root cause lies in QuickJS's improper handling of memory exhaustion scenarios during runtime cleanup. When an OOM (Out-of-Memory) condition occurs, the engine correctly detects and reports the error. However, the subsequent cleanup phase in JS_FreeRuntime expects the garbage collector object list to be fully cleared before the assertion check. Under memory pressure conditions, some objects remain on the GC list, causing the list_empty(&rt->gc_obj_list) assertion to fail and the process to abort with SIGABRT.

The vulnerability was specifically triggered when using the -m option (module mode) with a low memory limit configured, suggesting the module loading pathway has different memory allocation patterns that exacerbate the issue.

Attack Vector

The attack vector is network-based, allowing remote exploitation without requiring authentication or user interaction. An attacker can exploit this vulnerability by:

1. Crafting malicious JavaScript code designed to rapidly consume available memory
2. Targeting QuickJS instances configured with memory limits (a common security practice)
3. Sending the payload to any service that evaluates JavaScript using the vulnerable QuickJS version
4. Triggering the OOM condition followed by the assertion failure during cleanup

The vulnerability requires the target to be using the module execution mode (-m flag) and have memory constraints configured, which is paradoxically a security measure intended to limit resource usage.

For technical details on the vulnerability mechanism, see the GitHub Issue Discussion where the issue was reported and tracked.

Detection Methods for CVE-2025-69654

Indicators of Compromise

• Unexpected SIGABRT signals from QuickJS interpreter processes
• Process crash logs indicating assertion failures in JS_FreeRuntime function
• Application logs showing OOM errors immediately followed by process termination
• Core dump files containing list_empty(&rt->gc_obj_list) assertion messages

Detection Strategies

• Monitor for abnormal termination of QuickJS processes with SIGABRT exit codes
• Implement logging around JavaScript evaluation calls to capture pre-crash execution context
• Deploy application performance monitoring to detect memory exhaustion patterns
• Review system logs for repeated QuickJS crashes that may indicate exploitation attempts

Monitoring Recommendations

• Set up alerting for QuickJS process crashes with assertion failure signatures
• Monitor memory usage patterns of applications embedding QuickJS for unusual spikes
• Track the frequency of OOM events in JavaScript execution contexts
• Implement centralized logging for all QuickJS-related process terminations

How to Mitigate CVE-2025-69654

Immediate Actions Required

• Update QuickJS to a version containing commit fcd33c1afa7b3028531f53cd1190a3877454f6b3 or later
• Review applications that embed QuickJS and plan upgrade paths
• Consider implementing process isolation for JavaScript execution to contain crashes
• Evaluate input validation for JavaScript code submitted to QuickJS interpreters

Patch Information

The vulnerability was fixed in commit fcd33c1afa7b3028531f53cd1190a3877454f6b3 dated 2025-12-11. Organizations should update their QuickJS installations to any version released after this commit. The fix addresses the improper cleanup sequence in JS_FreeRuntime to ensure the garbage collection object list is properly handled even during memory exhaustion scenarios.

For additional details, refer to the QuickJS GitHub Issue #468.

Workarounds

• Run QuickJS interpreter processes in isolated containers or sandboxes to limit crash impact
• Implement process restart mechanisms to automatically recover from crashes
• Add rate limiting on JavaScript execution requests to reduce denial of service impact
• Consider using process pools to ensure service availability despite individual process crashes

# Configuration example: Running QuickJS in isolated container with auto-restart
# Docker compose configuration for resilient QuickJS deployment
# Ensure using patched version: commit fcd33c1afa7b3028531f53cd1190a3877454f6b3 or later
docker run --restart=unless-stopped \
  --memory=512m \
  --cpus=1 \
  quickjs-patched:latest