Luajit
CVE-2019-19391
CRITICAL
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
1DescriptionNVD
In LuaJIT through 2.0.5, as used in Moonjit before 2.1.2 and other products, debug.getinfo has a type confusion issue that leads to arbitrary memory write or read operations, because certain cases involving valid stack levels and > options are mishandled. NOTE: The LuaJIT project owner states that the debug libary is unsafe by definition and that this is not a vulnerability. When LuaJIT was originally developed, the expectation was that the entire debug library had no security guarantees and thus it made no sense to assign CVEs. However, not all users of later LuaJIT derivatives share this perspective
AnalysisAI
In LuaJIT through 2.0.5, as used in Moonjit before 2.1.2 and other products, debug.getinfo has a type confusion issue that leads to arbitrary memory write or read operations, because certain cases. Rated critical severity (CVSS 9.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Access of Resource Using Incompatible Type (Type Confusion) vulnerability could allow attackers to execute arbitrary code by exploiting type confusion in the application.
Technical ContextAI
This vulnerability is classified as Access of Resource Using Incompatible Type (Type Confusion) (CWE-843), which allows attackers to execute arbitrary code by exploiting type confusion in the application. In LuaJIT through 2.0.5, as used in Moonjit before 2.1.2 and other products, debug.getinfo has a type confusion issue that leads to arbitrary memory write or read operations, because certain cases involving valid stack levels and > options are mishandled. NOTE: The LuaJIT project owner states that the debug libary is unsafe by definition and that this is not a vulnerability. When LuaJIT was originally developed, the expectation was that the entire debug library had no security guarantees and thus it made no sense to assign CVEs. However, not all users of later LuaJIT derivatives share this perspective Affected products include: Luajit, Moonjit Project Moonjit. Version information: through 2.0.5.
RemediationAI
A vendor patch is available. Apply the latest security update as soon as possible. Enforce strict type checking, use type-safe languages, validate object types before operations.
LuaJIT through 2.1 and OpenRusty luajit2 before v2.1-20240626 have a stack-buffer-overflow in lj_strfmt_wfnum in lj_strf
LuaJIT through 2.1 and OpenRusty luajit2 before v2.1-20240314 have an out-of-bounds read in the stack-overflow handler i
LuaJIT through 2.1 and OpenRusty luajit2 before v2.1-20240314 have an unsinking of IR_FSTORE for NULL metatable, which l
LuaJIT through 2.1.0-beta3 has an out-of-bounds read in lj_err_run in lj_err.c. Rated high severity (CVSS 7.5), this vul
LuaJit through 2.1.0-beta3 has an out-of-bounds read because __gc handler frame traversal is mishandled. Rated high seve
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today