Secur0 Cna

Improper Handling of Highly Compressed Data (CWE-409) in the ZIP loader of whatstk from 0.7.0 before 0.9.0 allows a party that supplies a chat export to exhaust the memory and the disk of the process that parses it, because str from file() (whatstk/whatsapp/parser.py) calls zip ref.extractall() with no bound on the size of the members and no check of the compression ratio, then reads the extracted file in full with f.read(). The only guard on the archive counts the extracted files and raises when there is not exactly one, but it runs after extractall() has already written them, so it does not prevent the cost. clean text() then passes the whole text through unicodedata.normalize("NFKD", text), which holds a second copy, and the parse builds a list of regular expression matches and a DataFrame over it, so peak memory is a multiple of the decompressed text rather than of the archive. A ZIP is a documented input of WhatsAppChat.from source() and df from whatsapp(), and is the form in which WhatsApp exports a chat on iOS, so the attacker supplies the whole file. This results in a small upload costing hundreds of megabytes of memory and of disk, and in the process being killed where that exceeds what is available.

Inefficient Regular Expression Complexity (CWE-1333) in generate regex() (whatstk/whatsapp/parser.py) in whatstk from 0.2.0 before 0.9.0 allows a party that supplies a chat export to consume the CPU of the process that parses it for an unbounded time, because the function builds the header regular expression by replacing each %x code with its named capture group and leaves every other character of the header format in the pattern unescaped. A header whose date separator is a regular expression metacharacter therefore alters the pattern instead of matching itself: a separator of + quantifies the preceding capture group, giving (?P<day>d{1,2})+(?P<month>d{1,2})+(?P<year>d{2,4}), and a run of digits that cannot complete the header then makes the engine try every way of partitioning that run. Header auto detection is enabled by default and derives the format from the text of the file, so the separator is taken from the export itself and no header format has to be passed by the caller. Separators of (, ) and instead raise re.PatternError, separators of *, | and ? raise TypeError, and separators of ^ and $ raise KeyError, none of which the library catches. This results in the parse of a file of a few hundred bytes consuming CPU without completing, or in an uncaught exception in the calling program.

Incomplete Comparison with Missing Factors (CWE-1023) in merge chats() (whatstk/utils/chat merge.py), reached from BaseChat.merge(), in whatstk from 0.3.0 before 0.9.0 allows a party that supplies the chat exports to cause messages to be absent from the merged output with no indication that anything was removed, because the merge keeps whole the chat whose first message is oldest and appends from the other only the messages that are strictly newer than the last message of the first. Every message of the second chat that falls inside the date range already covered by the first is therefore discarded. The two chats are compared on their date ranges and not on the identity of the individual messages, so a message held by only one of the two exports is dropped whenever its date falls inside the range of the other, and both branches of merge two chats() behave this way. The merged result is returned without a warning and without a count of what was removed. This results in a merged chat that omits messages the inputs contain, in a library whose documented uses include forensic review and the generation of training data.

An authorization bypass exists in the cart and wishlist repositories. Authenticated users can delete or modify cart and wishlist entries belonging to other users. This occurs because the functions `cartRepository.delete()`, `cartRepository.updateQuantityInternal()`, and `wishlistRepository.delete()` match rows using only the primary key without verifying the owning user. While the system implements PostgreSQL row level security (RLS)—a security feature that restricts which rows a user can see or modify based on a policy—the policies are not applied because the application connects to the database using the same role that owns the tables. Since PostgreSQL does not apply RLS policies to the table owner by default, the restrictions are bypassed. Additionally, the use of sequential `bigserial` values for `cart items.id` and `wishlist.id` allows attackers to enumerate identifiers of other users' data.

An authorization flaw in the user API allows a user with a basic role to access accounts of other users within the same company, including those with higher privileges. In versions 3.5.0 and later, this also allows the deletion of such accounts. The issue exists because the endpoints 'GET /api/user/{id}' and 'DELETE /api/user/{id}' only verify the validity of a JSON Web Token via the `auth:api` middleware without checking specific permissions, policies, or roles in the `UserReadController::read()` and `UserDeleteController::delete()` functions. While access is generally scoped by company, the deletion process bypasses company verification if the authenticated user belongs to `Company::DEFAULT COMPANY`, enabling a basic user in that company to delete any account across the entire installation. This can lead to the exposure of personal data, such as email addresses, telephone numbers, postal addresses, and IBANs, and the potential removal of the last administrative account of a company.

An issue in the cart and checkout flow allows an authenticated user to be charged for one product while ordering another. The endpoint 'POST /api/user/cart' accepts `variantId` and `stripeId` as independent request body fields without verifying if the `stripeId` belongs to the specified `variantId`. Subsequently, the 'POST /api/stripe/payment' endpoint uses the stored `stripeId` to determine the charge amount. Finally, the checkout.session.completed webhook creates the order based on the `variantId`, resulting in orders for expensive items at the price of the cheapest item in the catalogue.

On Windows, a path traversal issue exists in the `execute obj()` function of the archive object viewer (`peach.pas`). An attacker can execute an arbitrary program already present on the victim's system by convincing them to preview a crafted archive entry using the "Preview with... -> Associated application" action (Shift+Ctrl+O). The issue occurs because the `checkfiledirname()` function in `list utils.pas` fails to perform a ".." path-containment check, allowing the `tempstring` variable—taken directly from the archive entry name—to escape the temporary extraction directory when concatenated with `outname`. This resolved path is then passed to `ShellExecuteW` via `cp open()`. Furthermore, the dangerous-extension confirmation prompt is missing from this specific preview route, allowing executables to run without warning. This behavior was confirmed across multiple archive formats, including .zip and .tar.

An issue exists in the archive object viewer within the `grid obj open` function of `peach.pas` on Windows. The software uses a hard-coded list called `SECEXTCONST` to determine if a confirmation dialog should be shown before running a file. Because this list is incomplete and relies on exact string comparisons, it fails to account for other shell-executable and scripting-host types handled by `ShellExecuteW`, such as `.url` and `.lnk` files. An attacker can exploit this by convincing a user to open a crafted archive containing a Windows Internet Shortcut (.url) or a shortcut (.lnk) targeting `cmd.exe` with arbitrary arguments. This allows the execution of programs or commands with the privileges of the user who opened the archive, without any confirmation prompt. The shell may also resolve attacker-named UNC paths, potentially allowing the targeting of remote payloads.

An out-of-bounds write exists in the PEA archive extraction routine within the `unpea procedure` function of the `pea.pas` file. The issue occurs when decompressing a PCOMPRESS1 stream, where the 32-bit compressed-block-size field of the first block (`compsize`) is read from the archive and used without validation as the length for a block read into the fixed-size global buffers `wbuf1` and `wbuf2` (1,114,112 bytes). This allows the first block to bypass the `compsize > WBUFSIZE` check, leading to an out-of-bounds read at an attacker-chosen offset via `wbuf1[compsize]`. Additionally, the copy loop uses the requested length instead of the actual bytes read and terminates on equality rather than an upper bound. This memory corruption can be triggered by opening or extracting a crafted .pea archive, potentially allowing arbitrary code execution as the user running the application across Windows, macOS, Linux, and BSD platforms.

Missing authentication in the product cache revalidation Server Action allows a remote, unauthenticated attacker to force the expiration of the entire storefront product cache. The function `revalidateProducts()` in `src/app/actions.ts` calls `updateTag("products")` without performing session or role checks. Because the file uses the "use server" directive, the function is compiled into a POST-invokable Server Action. The action ID is exposed in a public `/ next/static` chunk, which is not protected by the admin middleware in `proxy.ts`. When `cacheComponents` is enabled, the storefront relies on cached entries from `getAllProducts()`, `getCategoryProducts()`, and `getProduct()`. Repeatedly invoking the vulnerable action keeps the cache cold, forcing the application to read the full product catalog from the Postgres database for every request, which degrades storefront availability.

A Use After Free issue exists in the drag source path of the drag and drop protocol. A program writing to the terminal can cause the terminal to read from and write to freed heap memory. This occurs because the `drag remote file data()` function in `kitty/dnd.c` maintains a `DragRemoteItem` pointer to an array it does not own. When `toplevel data for drag()` or `subdir data for drag()` are called, they may trigger the `abrt()` macro via `add payload()` or `populate dir entries()`. The `abrt()` macro executes `cancel drag()`, which calls `drag free offer()` to free the array. Since the helper functions return void, the caller is unaware of the teardown and proceeds to call `all children complete()` using the freed pointer, leading to undefined behavior in the terminal process. This is reachable via the byte stream of any program running in the window.

An issue in the colour control escape code handler allows a program writing to the terminal to execute arbitrary commands in the user's shell. This occurs because the `color control()` function in `kitty/window.py` includes unrecognized field names in its reply, which the `write escape code to child()` function in `kitty/screen.c` then writes to the pseudoterminal master. Since the output is not neutralized for the shell, it is indistinguishable from user input. While payloads are reduced to printable ASCII and certain delimiters are consumed, enough characters survive to compose a shell command. Additionally, the `handle remote ssh()` function in `kitty/window.py` provides a newline via `get ssh data()` in `kittens/ssh/utils.py` before credentials are checked, facilitating the execution of attacker-chosen commands with the privileges of the user running the terminal.

Missing authorization in the askpass escape code handler allows a local user to obtain text typed into a prompt displayed by the terminal. The `handle remote askpass()` function in `kitty/window.py` opens a POSIX shared memory object named in the escape code, parses a prompt definition, and writes the user's answer back into an object of the same name without verifying ownership or permissions. An attacker can create a shared memory object, trigger the victim's terminal to render a custom prompt (such as a masked password prompt) via a device control string, and subsequently read the typed secret. Additionally, the prompt text is passed to the display without control character sanitisation, allowing it to overwrite the warning line printed by the software.

Improper link resolution in the drag source staging path of the drag and drop protocol allows a program writing to the terminal to create files and directories outside the staging directory. This occurs because the `subdir data for drag()` function in `kitty/dnd.c` resolves descendants of the staged item tree by constructing a path string and opening it with `safe open(path, O DIRECTORY | O RDONLY, 0)` instead of walking the tree component by component. An attacker can declare two entries with the same name—first a symlink targeting an arbitrary absolute path and second a directory—causing `mkdirat()` to fail with EEXIST. The code ignores this failure, leading the subsequent path resolution to follow the symlink and return a directory descriptor outside the staging directory. This descriptor is then passed as the `dirfd` argument to `add payload()` and used for all subsequent create operations. While entry names are sanitized, symlink targets are not validated. Files are created with O CREAT | O WRONLY | O EXCL at mode 0644, preventing the overwriting of existing files, but directories are created with `mkdirat()` at mode 0755, allowing the creation of new intermediate directories at any path writable by the user running the application, provided the symlink target is an existing directory.

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.

An authorization flaw exists in the drag and drop protocol handling. A program writing to the terminal can obtain the contents of files dragged over the window even if the user does not complete the drop action. This occurs because the `drop enqueue request()` function in `kitty/dnd.c` serves drag data requests without verifying the drop state of the window, allowing a client to receive data while a drag is merely hovering. Additionally, the `drop left child()` function fails to clear the pending request state, open file descriptors, directory handles, and URI lists when a drag leaves the window. Consequently, a client can continue reading through a retained directory handle or maintain an active file transfer stream after the drag has ended. The kitty process reads the file contents directly from the filesystem using paths provided by the drag source, leading to unauthorized disclosure of file contents.

Missing authentication in the checkout session lookup handler allows a remote, unauthenticated attacker to retrieve full session objects. By providing a valid Stripe Checkout Session ID, an attacker can access sensitive buyer information, including name, email, phone number, billing address, amount paid, and internal `userId`. This occurs because the GET handler calls the `stripe.checkout.sessions.retrieve()` function and returns the data without verifying the user's authentication or ownership of the session. The session ID is often exposed in the browser URL after payment, making it susceptible to leakage via Referer headers, analytics tools, server access logs, and browser history. The affected API endpoint is GET '/api/stripe/checkout sessions'.

Cross-Site Request Forgery (CSRF) occurs in the `OrderConfirmController` at the 'GET /order/confirm/{order number}' endpoint. This issue arises because the `Route::get` declaration allows state-changing actions to bypass the `VerifyCsrfToken` middleware, which only enforces tokens on POST, PUT, PATCH, and DELETE requests. Since session cookies with `SameSite=Lax` are included in top-level cross-site navigation, an unauthenticated attacker can trick an authenticated user into clicking a crafted link to trigger the `confirm()` function. This transitions orders from pending to confirmed without authorization. Additionally, because the `order number` variable uses sequential integers, an attacker can enumerate and confirm all existing orders.

An unrestricted file upload issue exists in the product photo upload feature. An authenticated user with the create product permission, such as the Seller role, can execute arbitrary JavaScript within the application origin. The system validates files based on magic bytes (content signatures) and only rejects a specific list of PHP extensions. However, the `ProductSaveController::save()` function uses the client-supplied extension when saving the file to the public web root. Consequently, a file containing an image header but using an HTML extension can be uploaded to `public/asset/upload/product/` and served as `text/html`, resulting in stored cross-site scripting (XSS), where a malicious script is permanently stored on the server and executed in the browser of users who view the file.

An issue exists in the company logo upload feature where the system fails to restrict the upload of dangerous file types. An authenticated user with permissions to create or update companies can upload an SVG document containing an embedded script element, leading to the execution of arbitrary JavaScript within the application origin.