P3Ngu1Nw

AnythingLLM is an application designed to enhance Large Language Models (LLMs) by providing contextual information from content. A Streaming Phase Cross-Site Scripting (XSS) issue exists in the chat rendering pipeline, potentially leading to Remote Code Execution (RCE) on the host operating system. This is due to an insecure Electron configuration, specifically the combination of `nodeIntegration: true` and `contextIsolation: false`. The vulnerability arises from the interpolation of token content directly into the `alt` attribute within the custom markdown-it image renderer located in `frontend/src/utils/chat/markdown.js` without proper HTML entity escaping. The `PromptReply` component then renders this output using `dangerouslySetInnerHTML` without DOMPurify sanitization, unlike the `HistoricalMessage` component which correctly applies DOMPurify.sanitize(). An attacker can exploit this by influencing the content generated by the LLM, such as through poisoned Retrieval-Augmented Generation (RAG) documents or compromised LLM endpoints, to achieve full host compromise.

The issue is related to an uncontrolled resource consumption in the latchset Jose module for signing and encrypting JSON objects. This can be exploited by an attacker to cause a denial of service through CPU consumption by using a large `p2c` (also known as PBES2 Count) value.

The issue is related to an uncontrolled resource consumption in the erlang-jose module for JSON object signing and encryption for Erlang and Elixir languages. This can be exploited by a remote attacker to cause a denial of service through CPU consumption by using a large `p2c` (PBES2 Count) value in a JOSE header.

A vulnerability has been identified in the JSON Web Encryption (JWE) decryption interfaces, specifically related to the support for decompressing plaintext after its decryption. Under certain conditions, it is possible to have the user's environment consume an unreasonable amount of CPU time or memory during JWE Decryption operations. The impact is limited to Node.js users utilizing the JWE decryption APIs to decrypt JWEs from untrusted sources.

The issue is related to an uncontrolled resource consumption in the jwcrypto library. An attacker can cause a denial of service attack by passing in a malicious JWE Token with a high compression ratio. When the server processes this token, it will consume a lot of memory and processing time.

The issue arises from the use of `memcmp` to verify authentication, which is not constant time. This makes it easier to bypass authentication via a timing side channel.

The issue arises from the use of `strcmp` to verify authentication, which is not a constant time operation. This makes it easier for attackers to bypass authentication via a timing side channel.

The issue allows bypass of identity checks via a sign/encryption confusion attack. For example, JWE can sometimes be used to bypass JSON::JWT.decode.

The issue is related to the JWE key management algorithms based on PBKDF2, which require a JOSE Header Parameter called `p2c` (PBES2 Count). This parameter dictates the number of PBKDF2 iterations needed to derive a CEK wrapping key. Its primary purpose is to intentionally slow down the key derivation function, making password brute-force and dictionary attacks more resource-intensive. However, if an attacker sets the `p2c` parameter in JWE to a very large number, it can cause excessive computational consumption, resulting in a denial of service.