C4Sh3R

Out-of-bounds Write (CWE-787) in the PEA archive extraction routine (pea.pas, unpea procedure) of the first-party pea component in PeaZip 11.2.0 and earlier allows an attacker who convinces a victim to open or extract a crafted .pea archive to execute arbitrary code as the user running PeaZip. While decompressing a PCOMPRESS1 stream, the 32-bit compressed-block-size field of the first block (compsize) is read directly from the archive and used without validation as the length of a blockread into the fixed-size global buffers wbuf1/wbuf2 (1,114,112 bytes) and as the bound of the subsequent copy loop. The existing check "compsize > WBUFSIZE" is applied only to the size of each following block, so the first block escapes it; the same unvalidated value is also used to index wbuf1[compsize], an out-of-bounds read at an attacker-chosen offset. The copy loop additionally copies the requested length instead of the number of bytes actually read, and terminates on equality rather than on an upper bound. Because the project is built without range checking and no archive password, integrity tag or non-default configuration is required, the overflow overwrites adjacent global data; code execution was demonstrated by two independent researchers against the official Linux x86-64 and Windows x64 builds, and the denial-of-service and memory-corruption primitive is cross-platform (Windows, macOS, Linux, BSD).

**Name of the Vulnerable Software and Affected Versions** kitty versions 0.40.0 through 0.48.x **Description** An out-of-bounds write exists in the natural width branch of the text sizing protocol. The `screen handle multicell command()` function in `kitty/screen.c` appends each codepoint of a grapheme cluster using `lc.chars[lc.count++] = ch` without performing a capacity check. Because `lc` is declared as a four-element `char type` array via the `RAII ListOfChars` macro, an OSC 66 escape code containing a grapheme cluster longer than four codepoints writes beyond the buffer. If the cluster is preceded by a sequence causing an intermediate flush, the buffer is migrated to the heap by `ensure space for chars()`, and the write occurs past the heap allocation. This leads to the termination of the kitty process, including all associated windows, tabs, and child processes. **Recommendations** Update to version 0.49.0 or later.

Missing Authorization in the drop handling path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to obtain the contents of files dragged over the window even when the user never completes the drop, because drop enqueue request() in kitty/dnd.c serves a drag data request without first checking the drop state of the window, so a client that issues the request while a drag is merely hovering receives the data offered for the drag. In the same file, drop left child(), which runs when the drag leaves the window without a drop having occurred, releases the offered MIME list but retains the pending request state, the open file descriptor and its main loop transfer timer, the directory handles, the URI list and the pending MIME name, so a client can continue to read through a retained directory handle, and an in-flight file transfer continues to stream, when no drag is in progress. The file contents are read from the filesystem by the kitty process itself using the paths the drag source offered. This results in disclosure of the contents of files the user moved over the window without ever releasing them into it.