CVE Watch28 sept 2026

CVE-2026-81883

radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's Lua 5.3 bytecode function parser wa

CVSS

3.3

Bajo

EPSS

0.2%

KEV

—

Exploit Today

0-100

Publicado: 22 sept 2026 · Última mod.: 28 sept 2026 · CWE-125

EPSS · 30d

0.2%EPSS · 30 días0.2%

2026-09-232026-10-19

Descripción técnica

radare2 is a UNIX-like reverse engineering framework and command-line toolset. Prior to 6.2.0, radare2's Lua 5.3 bytecode function parser was vulnerable because the Lua 5.3 bytecode function parser read fixed function-metadata fields immediately after a function-name string without checking the remaining buffer length. The vulnerability is triggered by opening or inspecting a crafted Lua 5.3 bytecode file whose function-name string ends at the input-buffer boundary. The parser read two integers and three one-byte fields beyond the allocated input buffer. This can cause invalid parser results or process termination; no attacker-observable memory disclosure has been demonstrated. This issue is fixed in version 6.2.0.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-96402—

—

———A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page.2h CVE-2026-95111—

—

———A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes. The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied. A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode — `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back.2h CVE-2026-924546.1 MED

—

———The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which `GX_SOFTWARE_DECODER_SUPPORT` is enabled.2h CVE-2026-92446—

—

———`gx_binres_theme_load()` and `gx_binres_font_load()` take the resource as a bare `GX_UBYTE *` with no length, and `GX_BINRES_DATA_INFO` has no field to carry one. Every read is therefore performed at an offset the file itself chose, against a buffer whose extent the loader does not know. A resource that declares more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded. This is a distinct defect from GHSA-hgcj-22cg-4hfv, which was an underflowed glyph count. It needs no underflow and no wrapped multiply: a perfectly well-formed, narrow glyph range reaches it.2h CVE-2026-91186—

—

———The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time. A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth *after* the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it. The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.2h CVE-2026-91059—

—

———The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second `SOF0` frame header after `SOS` re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns `GX_SUCCESS` and publishes a `GX_PIXELMAP` whose reported dimensions and `data_size` exceed the allocation behind it. Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path. Reproduces in the shipped default configuration; `GX_SOFTWARE_DECODER_SUPPORT` is enabled by default.2h