CVE-2026-2655
Use-After-Free in ChaiScript str_less::operator Function
Publication date: 2026-02-18
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| chaiscript | chaiscript | to 6.1.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| 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. |
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-2655 is a heap-use-after-free vulnerability in the ChaiScript engine, specifically in the function chaiscript::str_less::operator() located in chaiscript_defines.hpp. The issue arises due to a race condition between threads: when the main thread is shutting down the engine and deleting a shared std::map (likely the function dispatch table or variable scope), an asynchronous or detached thread continues to access this map concurrently. This leads to the worker thread reading memory that has already been freed, causing a use-after-free error.
The vulnerability is triggered by asynchronous threads performing repeated lookups on an undefined variable, causing continuous access to the shared symbol table while the main thread frees it during shutdown. This concurrency flaw results in unsafe memory access, potential crashes, and memory corruption.
How can this vulnerability impact me? :
This vulnerability can cause program crashes or memory corruption due to use-after-free errors when asynchronous threads access freed memory during engine shutdown.
While the exploitability is considered difficult and requires local access with a high level of complexity, a proof-of-concept exploit is publicly available, meaning attackers with local access could potentially trigger the vulnerability.
The primary impact is on software availability, as the use-after-free can lead to crashes. There is also a theoretical risk of arbitrary code execution, although this is not confirmed.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by reproducing the heap-use-after-free condition using a proof-of-concept (PoC) script that launches asynchronous threads performing repeated lookups on an undefined variable, triggering concurrent access to a shared std::map during engine shutdown.
To detect the issue on a system, build ChaiScript from the develop branch with Release optimization and AddressSanitizer (ASan) enabled, then run the PoC script (e.g., crash.chai) which performs repeated asynchronous accesses to an undefined variable. The ASan report will show a read violation indicating the use-after-free.
No specific network detection commands are applicable since the attack requires local access and is related to concurrency in the ChaiScript engine.
- Build ChaiScript with ASan enabled: use Clang compiler with Release mode and ASan flags.
- Run the PoC script that launches multiple asynchronous threads accessing an undefined variable repeatedly.
- Monitor the program output for ASan error reports indicating heap-use-after-free in chaiscript::str_less::operator.
What immediate steps should I take to mitigate this vulnerability?
Currently, no official mitigation or patch has been provided by the ChaiScript project as they have not responded to the issue report.
Immediate steps include avoiding the use of ChaiScript versions up to 6.1.0 in environments where asynchronous threads may outlive engine shutdown, as the vulnerability requires local access and concurrency conditions.
Consider using alternative scripting engines or products until a fix is released.
If continuing to use ChaiScript, ensure that asynchronous threads are properly synchronized and terminated before engine shutdown to prevent concurrent access to shared data structures.