Vectrain51

Snipe-IT versions 8.2.0 through 8.6.x (fixed in 8.7.0) contain an incorrect authorization flaw in app/Http/Controllers/Users/UsersController::update(). The single-user edit route assigned the activated field from the request payload before evaluating the canEditAuthFields authorization gate, so an authenticated non-admin user holding the users.edit permission in the target's company scope can submit a full valid PUT request to /users/{id} and toggle the activated flag on any user, including admin and superuser accounts. Deactivating an admin locks that account out of the application until another admin or superuser re-enables it. Only the activated field is affected; username, email, password and permissions remain protected by the gate, no data is disclosed, and the API (ApiUsersController::update) and bulk-edit paths are not affected.

**Name of the Vulnerable Software and Affected Versions** Grav versions prior to 2.0.13 **Description** Insufficient validation of backup profile root paths allows users with profile editor access to archive directories outside the `GRAV ROOT` directory, provided the paths are not included in the hard-coded deny-list. This can be exploited using traversal paths to expose sensitive files from system locations such as /opt, /mnt, or /srv. **Recommendations** Update Grav to version 2.0.13 or later.

**Name of the Vulnerable Software and Affected Versions** qs versions 6.14.2 through 6.15.3 **Description** When the `qs.parse` function is used with the `comma` and `throwOnLimitExceeded` options set to `true`, a comma-separated value assigned to a bracket-push key (e.g., `a[]=1,2,3,4`) is split into an array without being validated against the `arrayLimit`. In contrast, the same value assigned to flat, indexed, nested, or dotted keys correctly triggers a `RangeError`. This occurs because the `arrayLimit` check in `lib/parse.js` was applied after the value was wrapped as a nested element, and a subsequent attempt to fix this using an `isFlatArrayValue` flag failed to account for the `[]=` key form. An unauthenticated attacker can exploit this by providing a single `a[]=` parameter to bypass configured limits and force the parser to allocate an array proportional to the request size, potentially leading to excessive memory consumption. **Recommendations** Update qs to version 6.16.0. As a temporary workaround, avoid using the `[]=` key form in query strings when `comma` and `throwOnLimitExceeded` are enabled.