CVE-2026-3386: 
Homebrew vulnerability analysis and mitigation

CVE-2026-3386 is a global buffer overflow (out-of-bounds read) vulnerability in the wren-lang Wren scripting language affecting all versions up to and including 0.4.0. The flaw resides in the emitOp function within src/vm/wren_compiler.c, where an invalid opcode index causes a read 4 bytes past the end of the global stackEffects array. The vulnerability was reported via a GitHub issue on January 22, 2026, and publicly disclosed on March 1, 2026, with no vendor response or patch released as of the time of writing. It carries a CVSS v3.1 base score of 7.1 (High) and a CVSS v4.0 base score of 1.9 (Low), reflecting its local-only attack vector (Feedly, GitHub Issue).

The root cause is classified as CWE-125 (Out-of-bounds Read) and CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer). The emitOp function in src/vm/wren_compiler.c (line 1329) uses an opcode value as a direct index into the global stackEffects array (308 bytes, defined at line 414); when compiling a subscript or method call requiring a 16-bit argument (Extended Opcode), the opcode calculation produces an index one slot past the valid range, triggering a 4-byte read beyond the array boundary. The call chain leading to the crash is: subscript → callSignature → emitShortArg → emitOp. A proof-of-concept reproducer file and harness code have been publicly published, confirmed via AddressSanitizer (ASan) reporting a global-buffer-overflow (GitHub Issue, PoC Repo).

Successful exploitation causes a denial-of-service condition by crashing the Wren VM process due to the out-of-bounds memory read. Confidentiality and integrity are not directly impacted under the CVSS v4.0 assessment, though the CVSS v3.1 scoring notes a high confidentiality impact, reflecting the potential for memory disclosure from adjacent global memory regions. Because Wren is designed as an embeddable scripting language, applications embedding the Wren VM may be crashed or destabilized by processing attacker-controlled Wren scripts (Feedly, GitHub Issue).

A public proof-of-concept reproducer is available in a GitHub repository and was referenced in the original bug report (PoC Repo). Exploitation requires local access and low privileges, with no user interaction needed. There is no evidence of in-the-wild exploitation or threat actor attribution at this time. The EPSS score is approximately 0.013% (0.000130), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Feedly).

1. Prepare the environment: Obtain a system with wren-lang Wren version 0.4.0 or earlier installed, or build a harness application that embeds the Wren VM using the C API (wrenInterpret).
2. Craft a malicious Wren script: Create a Wren source file containing a subscript/method call expression that triggers the extended opcode path in the compiler. The published PoC uses a construct similar to: cccclassBTestSyst= [,,,,,,,myieldporz[1, 2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,l,,,,inue&,,,,l,,.,inue&&Im.p (PoC Repo).
3. Feed the script to the Wren VM: Pass the crafted file to the Wren interpreter or embedding harness (e.g., ./bin/harness repro), causing the compiler to process the malformed subscript expression.
4. Trigger the out-of-bounds read: The compiler's subscript → callSignature → emitShortArg → emitOp call chain computes an out-of-range opcode index and reads 4 bytes past the end of the stackEffects global array at src/vm/wren_compiler.c:1329, resulting in a crash (SIGABRT under ASan, or undefined behavior in production builds) (GitHub Issue).

• Process: Unexpected crash or abort of the Wren VM process or any application embedding Wren, particularly when processing externally supplied .wren script files.
• Logs: AddressSanitizer output containing global-buffer-overflow referencing wren_compiler.c:1329 and the stackEffects global variable; crash dumps or core files from the Wren host process.
• File System: Presence of unusual or malformed .wren script files in directories processed by the application, particularly files containing deeply nested subscript expressions or large comma-separated list literals.
• Process: Abnormal termination signals (SIGABRT, SIGSEGV) originating from the Wren VM's compiler phase rather than the runtime execution phase (GitHub Issue).

No official patch has been released by the wren-lang project as of the disclosure date, despite early notification via the GitHub issue (GitHub Issue). Recommended interim mitigations include: (1) restricting local access to systems running Wren to trusted users only; (2) avoiding processing untrusted or externally supplied Wren scripts; (3) applying the principle of least privilege to accounts running Wren-based applications; (4) monitoring for unexpected crashes in Wren-embedding applications; and (5) tracking the upstream repository for any future patch releases (Feedly).

The vulnerability received limited public attention, with automated CVE tracking services (VulDB, Vulners, CIRCL) and social media bots (Bluesky CVE feed) noting the disclosure shortly after publication. Red Hat registered the CVE in their security advisory database. The wren-lang project had not publicly responded to the issue report as of the disclosure date (GitHub Issue, Feedly).