Vulnerabilities

RSSHub is an RSS network. Prior to commit 64e00e7, RSSHub's `docker-test-cont.yml` workflow is vulnerable to Artifact Poisoning, which could have lead to a full repository takeover. Downstream users of RSSHub are not vulnerable to this issue, and commit 64e00e7 fixed the underlying issue and made the repository no longer vulnerable. The `docker-test-cont.yml` workflow gets triggered when the `PR - Docker build test` workflow completes successfully. It then collects some information about the Pull Request that triggered the triggering workflow and set some labels depending on the PR body and sender. If the PR also contains a `routes` markdown block, it will set the `TEST_CONTINUE` environment variable to `true`. The workflow then downloads and extracts an artifact uploaded by the triggering workflow which is expected to contain a single `rsshub.tar.zst` file. However, prior to commit 64e00e7, it did not validate and the contents were extracted in the root of the workspace overriding any existing files. Since the contents of the artifact were not validated, it is possible for a malicious actor to send a Pull Request which uploads, not just the `rsshub.tar.zst` compressed docker image, but also a malicious `package.json` file with a script to run arbitrary code in the context of the privileged workflow. As of commit 64e00e7, this scenario has been addressed and the RSSHub repository is no longer vulnerable.

Tenda G3 Router firmware v15.03.05.05 was discovered to contain a remote code execution (RCE) vulnerability via the usbPartitionName parameter in the formSetUSBPartitionUmount function.

In Grafana, the wrong permission is applied to the alert rule write API endpoint, allowing users with permission to write external alert instances to also write alert rules.

The goTenna Pro App allows unauthenticated attackers to remotely update <br /> the local public keys used for P2P and group messages. It is advised to <br /> update your app to the current release for enhanced encryption <br /> protocols.

Agnai is an artificial-intelligence-agnostic multi-user, mult-bot roleplaying chat system. A vulnerability in versions prior to 1.0.330 permits attackers to upload arbitrary files to attacker-chosen locations on the server, including JavaScript, enabling the execution of commands within those files. This issue could result in unauthorized access, full server compromise, data leakage, and other critical security threats. This does not affect `agnai.chat`, installations using S3-compatible storage, or self-hosting that is not publicly exposed. This does affect publicly hosted installs without S3-compatible storage. Version 1.0.330 fixes this vulnerability.

Agnai is an artificial-intelligence-agnostic multi-user, mult-bot roleplaying chat system. A vulnerability in versions prior to 1.0.330 permits attackers to read arbitrary JSON files at attacker-chosen locations on the server. This issue can lead to unauthorized access to sensitive information and exposure of confidential configuration files. This only affects installations with `JSON_STORAGE` enabled which is intended to local/self-hosting only. Version 1.0.330 fixes this issue.

Agnai is an artificial-intelligence-agnostic multi-user, mult-bot roleplaying chat system. A vulnerability in versions prior to 1.0.330 permits attackers to upload image files at attacker-chosen location on the server. This issue can lead to image file uploads to unauthorized or unintended directories, including overwriting of existing images which may be used for defacement. This does not affect `agnai.chat`, installations using S3-compatible storage, or self-hosting that is not publicly exposed. Version 1.0.330 fixes this vulnerability.

Nix is a package manager for Linux and other Unix systems. Starting in version 1.11 and prior to versions 2.18.8 and 2.24.8, `` did not verify TLS certificates on HTTPS connections. This could lead to connection details such as full URLs or credentials leaking in case of a man-in-the-middle (MITM) attack. `` is also known as the builtin derivation builder `builtin:fetchurl`. It&amp;#39;s not to be confused with the evaluation-time function `builtins.fetchurl`, which was not affected by this issue. A user may be affected by the risk of leaking credentials if they have a `netrc` file for authentication, or rely on derivations with `impureEnvVars` set to use credentials from the environment. In addition, the commonplace trust-on-first-use (TOFU) technique of updating dependencies by specifying an invalid hash and obtaining it from a remote store was also vulnerable to a MITM injecting arbitrary store objects. This also applied to the impure derivations experimental feature. Note that this may also happen when using Nixpkgs fetchers to obtain new hashes when not using the fake hash method, although that mechanism is not implemented in Nix itself but rather in Nixpkgs using a fixed-output derivation. The behavior was introduced in version 1.11 to make it consistent with the Nixpkgs `pkgs.fetchurl` and to make `` work in the derivation builder sandbox, which back then did not have access to the CA bundles by default. Nowadays, CA bundles are bind-mounted on Linux. This issue has been fixed in Nix 2.18.8 and 2.24.8. As a workaround, implement (authenticated) fetching with `pkgs.fetchurl` from Nixpkgs, using `impureEnvVars` and `curlOpts` as needed.

In the goTenna Pro App, the encryption keys are stored along with a <br /> static IV on the End User Device (EUD). This allows for complete <br /> decryption of keys stored on the EUD if physically compromised. This <br /> allows an attacker to decrypt all encrypted broadcast communications <br /> based on encryption keys stored on the EUD. This requires access to and <br /> control of the EUD, so it is recommended to use strong access control <br /> measures and layered encryption on the EUD for more secure operation.

The goTenna Pro App does not encrypt callsigns in messages. It is <br /> recommended to not use sensitive information in callsigns when using <br /> this and previous versions of the app and update your app to the current<br /> app version which uses AES-256 encryption for callsigns in encrypted <br /> operation.

The goTenna Pro App does not authenticate public keys which allows an <br /> unauthenticated attacker to manipulate messages. It is advised to update<br /> your app to the current release for enhanced encryption protocols.

The goTenna Pro App does not use SecureRandom when generating passwords <br /> for sharing cryptographic keys. The random function in use makes it <br /> easier for attackers to brute force this password if the broadcasted <br /> encryption key is captured over RF. This only applies to the optional <br /> broadcast of an encryption key, so it is advised to share the key with <br /> local QR code for higher security operations.