ghsa

## Summary ## The *Command Execution* feature of Filebrowser only allows the execution of shell command which have been predefined on a user-specific allowlist. The implementation of this allowlist is erroneous, allowing a user to execute additional commands not permitted. ## Impact ## A user can execute more shell commands than they are authorized for. The concrete impact of this vulnerability depends on the commands configured, and the binaries installed on the server or in the container image. Due to the missing separation of *scopes* on the OS-level, this could give an attacker access to all files managed the application, including the File Browser database. ## Vulnerability Description ## For a user to make use of the command execution feature, two things need to happen in advance: 1. An administrator needs to grant that account the `Execute commands` permission 2. The command to be executed needs to be listed in the `Commands` input field (also done by an administrator) If...

## Summary ## In the web application, all users have a *scope* assigned, and they only have access to the files within that *scope*. The *Command Execution* feature of Filebrowser allows the execution of shell commands which are not restricted to the scope, potentially giving an attacker read and write access to all files managed by the server. ## Impact ## Shell commands are executed with the *uid* of the server process without any further restrictions. This means, that they will have access to at least * all files managed by the application from all *scopes*, even those the user does not have access to in the GUI. * the Filebrowser database file containing the password hashes of all accounts. The concrete impact depends on the commands being granted to the attacker, but due to other vulnerabilities identified ("Bypass Command Execution Allowlist", "Shell Commands Can Spawn Other Commands", "Insecure File Permissions") it is likely, that full read- and write-access will exist. R...

## Summary URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The *Filebrowser* violates this practice, since access tokens are used as GET parameters. ## Impact The *JSON Web Token (JWT)* which is used as a session identifier will get leaked to anyone having access to the URLs accessed by the user. This will give the attacker full access to the user's account and, in consequence, to all sensitive files the user has access to. ## Description Sensitive information in URLs is logged by several components (see the following examples), even if access is protected by TLS. * The browser history * The access logs on the affected web server * Proxy servers or reverse proxy servers * Third-party servers via the HTTP referrer header In case attackers can access certain logs, they could read the included sensitive data. ## Proof of Concept ## When a file ...

### Summary A malicious JSON-stringifyable message can be made passing on `verify()`, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer) ### Details This affects only environments where `require('buffer')` is <https://npmjs.com/buffer> E.g.: browser bundles, React Native apps, etc. `Buffer.isBuffer` check can be bypassed, resulting in strange objects being accepted as `message`, and those messages could trick `verify()` into returning false-positive `true` values v2.x is unaffected as it verifies input to be an actual `Uint8Array` instance Such a message can be constructed for any already known message/signature pair There are some restrictions though (also depending on the known message/signature), but not very limiting, see PoC for example https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this ### PoC This code deliberately doesn't provide `reencode` for now, could be updated later ```js import { randomBytes } from 'crypto'...

### Summary Private key can be extracted on signing a malicious JSON-stringifiable object, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer) ### Details This affects only environments where `require('buffer')` is <https://npmjs.com/buffer> E.g.: browser bundles, React Native apps, etc. `Buffer.isBuffer` check can be bypassed, resulting in `k` reuse for different messages, leading to private key extraction over a single invalid message (and a second one for which any message/signature could be taken, e.g. previously known valid one) v2.x is unaffected as it verifies input to be an actual `Uint8Array` instance Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still shou...

In Akka through 2.10.6, akka-cluster-metrics uses Java serialization for cluster metrics.

Deserialization of Untrusted Data vulnerability in Apache Seata (incubating). This security vulnerability is the same as CVE-2024-47552, but the version range described in the CVE-2024-47552 definition is too narrow. This issue affects Apache Seata (incubating): from 2.0.0 before 2.3.0. Users are recommended to upgrade to version 2.3.0, which fixes the issue.

### Summary The /get-patch endpoint processes a purchase in two separate database queries: a SELECT that verifies the token is unused, followed by an UPDATE that marks the token as used. Because SQLite only guards each statement, a malicious actor can issue two requests at the exact same moment and have both SELECT statements succeed before either UPDATE runs. ### Details The handler executes (step 1): ``` SELECT id, token_used_at FROM purchases WHERE patch_id = ? AND purchase_token = ? AND status = 'COMPLETED' ``` If token_used_at IS NULL, the request passes the check (step 2): ``` if (row.token_used_at) { return res.status(403).json({ error: "Purchase token has already been used." }); } ``` The handler finally runs (step 3): ``` UPDATE purchases SET token_used_at = CURRENT_TIMESTAMP WHERE id = ? ``` When two requests arrive at the same time, they both finish step 1 while the row is still unused. SQLite serializes writers only per statement, so ea...

A vulnerability was found in HKUDS LightRAG up to 1.3.8. It has been declared as critical. Affected by this vulnerability is the function upload_to_input_dir of the file lightrag/api/routers/document_routes.py of the component File Upload. The manipulation of the argument file.filename leads to path traversal. It is possible to launch the attack on the local host. The identifier of the patch is 60777d535b719631680bcf5d0969bdef79ca4eaf. It is recommended to apply a patch to fix this issue.

### Summary Arbitrary HTML can be inserted into the DOM by inserting a payload into any allowed attribute of the `<tabber>` tag. ### Details The `args` provided within the wikitext as attributes to the `<tabber>` tag are passed to the TabberComponentTabs class: https://github.com/StarCitizenTools/mediawiki-extensions-TabberNeue/blob/3a23b703ce36cfc4128e7921841f68230be4059a/includes/Tabber.php#L76 In TabberComponentTabs, the attributes are validated before being supplied to the Tabs template. https://github.com/StarCitizenTools/mediawiki-extensions-TabberNeue/blob/3a23b703ce36cfc4128e7921841f68230be4059a/includes/Components/TabberComponentTabs.php#L15-L31 However, the validation is insufficient. What `Sanitizer::validateTagAttributes` does is call `validateAttributes`, which ``` * - Discards attributes not on the given list * - Unsafe style attributes are discarded * - Invalid id attributes are re-encoded ``` However, the attribute values are expected to be escaped when inserte...