CVE-2026-10267
Out-of-Bounds Read in Janet Programming Language
Publication date: 2026-06-01
Last updated on: 2026-06-01
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| janet-lang | janet | to 1.41.0 (inc) |
| janet-lang | janet | 1.41.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-125 | The product reads data past the end, or before the beginning, of the intended buffer. |
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-10267 is a heap out-of-bounds read vulnerability that can lead to information disclosure by exposing arbitrary heap memory adjacent to the fiber's stack. This type of vulnerability could potentially result in unauthorized access to sensitive data if exploited.
Such unauthorized data exposure may impact compliance with data protection regulations like GDPR or HIPAA, which require safeguarding personal and sensitive information against unauthorized access or leaks.
However, the vulnerability requires local attack conditions and exploitation through unmarshalling untrusted data followed by debug/stack inspection, which may limit its practical impact depending on the deployment context and existing security controls.
No explicit information is provided in the available resources about direct compliance implications or mitigation guidance related to these standards.
Can you explain this vulnerability to me?
CVE-2026-10267 is a heap out-of-bounds read vulnerability in the Janet programming language up to version 1.41.0. It occurs in the debug/stack functionality, specifically in the doframe function of the file src/core/debug.c. The vulnerability arises when a crafted symbolmap containing an attacker-controlled slot_index is unmarshalled into a fiber. The code reads stack[jsm.slot_index] without validating that slot_index is within the bounds of the stack frame's slotcount, allowing reads beyond the allocated stack memory into adjacent heap memory.
This unchecked access is due to the slot_index being derived from untrusted serialized data, which can contain any uint32_t value without validation. As a result, an attacker can cause the program to read arbitrary heap memory or potentially cause a denial-of-service by accessing unmapped memory.
How can this vulnerability impact me? :
This vulnerability can lead to information disclosure by exposing arbitrary heap memory adjacent to the fiber's stack, which may contain sensitive data.
Additionally, it can cause a denial-of-service if the program attempts to read unmapped memory, potentially crashing the application.
Exploitation requires local access and the ability to provide crafted serialized data that is unmarshalled and inspected using the debug/stack functionality, such as in error handlers.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves a heap out-of-bounds read triggered locally by unmarshalling crafted symbolmap data in the Janet language's debug/stack functionality. Detection involves identifying if your system is running a vulnerable version of janet-lang janet up to 1.41.0 and if untrusted data is being unmarshalled and inspected via debug/stack.
Since the exploit requires local access and manipulation of the debug stack, network detection is unlikely. Instead, detection can focus on verifying the janet-lang version and monitoring for suspicious local usage of the debug/stack feature with untrusted data.
Suggested commands to detect the vulnerable version or presence of the vulnerable code include:
- Check janet-lang version installed: `janet --version` or check the package manager version.
- Search for the vulnerable debug.c file and verify if it contains the patched commit ed17dd2c5913a23fb1107251e44a9410a3c30cf5 by running: `git log -p -1 ed17dd2c5913a23fb1107251e44a9410a3c30cf5` in the janet-lang source directory.
- Monitor local application logs or error handlers that use janet debug/stack functionality for unusual or malformed symbolmap data processing.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to update janet-lang janet to a version that includes the patch identified by commit ed17dd2c5913a23fb1107251e44a9410a3c30cf5, which adds runtime checks to prevent out-of-bounds reads in the debug/stack functionality.
Additional immediate steps include:
- Avoid unmarshalling untrusted or unauthenticated data that could contain malicious symbolmap entries.
- Restrict local access to systems running vulnerable janet-lang versions to trusted users only, since the exploit requires local access.
- If possible, disable or limit the use of debug/stack inspection features in production or sensitive environments.
- Apply the patch from the janet-lang repository commit ed17dd2c5913a23fb1107251e44a9410a3c30cf5 as soon as possible.