ghsa

The safe API `array_queue::ArrayQueue::push_front` can lead to deallocating uninitialized memory if a panic occurs while invoking the `clone` method on the passed argument. Specifically, `push_front` receives an argument that is intended to be cloned and pushed, whose type implements the `Clone` trait. Furthermore, the method updates the queue's `start` index before initializing the slot for the newly pushed element. User-defined implementations of `Clone` may include a `clone` method that can panic. If such a panic occurs during initialization, the structure is left with an advanced `start` index pointing to an uninitialized slot. When `ArrayQueue` is later dropped, its destructor treats that slot as initialized and attempts to drop it, resulting in an attempt to free uninitialized memory. The bug was fixed in commit `728fe1b`.

### Impact A command injection vulnerability was discovered in the SonarQube Scan GitHub Action that allows untrusted input arguments to be processed without proper sanitization. Arguments sent to the action are treated as shell expressions, allowing potential execution of arbitrary commands. ### Patches A fix has been released in SonarQube Scan GitHub Action v5.3.1.

The crate has the following vulnerabilities: - The public trait `arenavec::common::AllocHandle` allows the return of raw pointers through its methods `allocate` and `allocate_or_extend`. However, the trait is not marked as unsafe, meaning users of the crate may implement it under the assumption that the library safely handles the returned raw pointers. These raw pointers can later be dereferenced within safe APIs of the crate-such as `arenavec::common::SliceVec::push`-potentially leading to arbitrary memory access. - The safe API `arenavec::common::SliceVec::reserve` can reach the private function `arenavec::common::allocate_inner`. Incorrect behavior in `allocate_inner` may result in a `SliceVec` with an increased capacity, even though the underlying memory has not actually been expanded. This mismatch between `SliceVec.capacity` and the actual reserved memory can lead to a heap buffer overflow. - The safe API `arenavec::common::SliceVec::split_off` can duplicate the ownership of t...

### Summary The GET /download/<filename> route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWD_DIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWD_DIR (e.g., .../downloads_bak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak. ### Details ``` def is_safe_path(safe_root, check_path): safe_root = os.path.realpath(os.path.normpath(safe_root)) check_path = os.path.realpath(os.path.normpath(check_path)) return os.path.commonprefix([check_path, safe_root]) == safe_root ``` commonprefix compares raw strings, not path components. For: ``` safe_root = /home/mobsf/.MobSF/downloads check_path = /home/mobsf/.MobSF/downloads_bak/test.txt ``` the function returns True, incorrectly treating downloads_bak as inside downloads. Download handler: ``` # MobSF/views/home.py @login_required def download(request): root = sett...

### Summary The vulnerability allows any user to overwrite any files available under the account privileges of the running process. ### Details As part of static analysis, iOS MobSF supports loading and parsing statically linked libraries `.a`. When parsing such archives, the code extracts the embedded objects to the file system in the working directory of the analysis. The problem is that the current implementation does not prohibit absolute file names inside `.a`. If an archive item has a name like /abs/path/to/file, the resulting path is constructed as Path(dst) /name; for absolute paths, this leads to a complete substitution of the destination directory: writing occurs directly to the specified absolute directory. the path (outside the working directory). Thus, an authenticated user who uploaded a specially prepared `.a`, can write arbitrary files to any directory writable by the user of the MobSF process (for example, `/tmp`, neighboring directories inside `~/.MobSF`, etc.). Th...

### Summary A denial-of-service / out-of-memory vulnerability exists in the `STATUS_SEND_PACKS` handling of `ResourcePackClientResponsePacket`. PocketMine-MP processes the `packIds` array without verifying that all entries are unique. A malicious (non-standard) Bedrock client can send multiple duplicate valid pack UUIDs in the same `STATUS_SEND_PACKS` packet, causing the server to send the same pack multiple times. This can quickly exhaust memory and crash the server. Severity: **High** — Remote DoS from an authenticated client. --- ### Details Relevant code (simplified): ```php case ResourcePackClientResponsePacket::STATUS_SEND_PACKS: foreach($packet->packIds as $uuid){ $splitPos = strpos($uuid, "_"); if($splitPos !== false){ $uuid = substr($uuid, 0, $splitPos); } $pack = $this->getPackById($uuid); if(!($pack instanceof ResourcePack)){ $this->disconnectWithError("Unknown pack $uuid requested..."); ret...

### Summary On the ESP-IDF platform, ESPHome's [`web_server` authentication](https://esphome.io/components/web_server.html#configuration-variables) check can pass incorrectly when the client-supplied base64-encoded `Authorization` value is empty or is a substring of the correct value (e.g., correct username with partial password). This allows access to `web_server` functionality (including OTA, if enabled) without knowing any information about the correct username or password. ### Details The HTTP basic auth check in `web_server_idf`'s [`AsyncWebServerRequest::authenticate`](https://github.com/esphome/esphome/blob/ef2121a215890d46dc1d25ad363611ecadc9e25e/esphome/components/web_server_idf/web_server_idf.cpp#L256) only compares up to `auth.value().size() - auth_prefix_len` bytes of the base64-encoded `user:pass` string. This means a client-provided valuer like `dXNlcjpz` (`user:s`) will pass the check when the correct value is much longer, e.g., `dXNlcjpzb21lcmVhbGx5bG9uZ3Bhc3M=` (`user...

**Affected Versions:** > 0.2.0 and < 1.0.0 **Patched Versions:** >= 1.0.0 **Description:** The library stored confidential information, including API keys, in a local SQLite database without encryption. This behavior was not clearly documented outside of the database architecture page. Users were not given the ability to configure the database location. As a result, anyone with access to the container or host filesystem could retrieve sensitive data in plaintext by accessing the `.db` file. **Impact:** Unauthorized access to API keys and other confidential data if the SQLite database file was exposed. **Fixed in Version 1.0.0:** - Database is fully encrypted - Database location is configurable - API keys can be set via environment variables (this capability existed in earlier versions)

A vulnerability in Next.js Image Optimization has been fixed in v15.4.5 and v14.2.31. When images returned from API routes vary based on request headers (such as `Cookie` or `Authorization`), these responses could be incorrectly cached and served to unauthorized users due to a cache key confusion bug. All users are encouraged to upgrade if they use API routes to serve images that depend on request headers and have image optimization enabled. More details at [Vercel Changelog](https://vercel.com/changelog/cve-2025-57752)

A vulnerability in **Next.js Image Optimization** has been fixed in **v15.4.5** and **v14.2.31**. The issue allowed attacker-controlled external image sources to trigger file downloads with arbitrary content and filenames under specific configurations. This behavior could be abused for phishing or malicious file delivery. All users relying on `images.domains` or `images.remotePatterns` are encouraged to upgrade and verify that external image sources are strictly validated. More details at [Vercel Changelog](https://vercel.com/changelog/cve-2025-55173)