Pinkdraconian

**Name of the Vulnerable Software and Affected Versions** Google Chrome versions prior to 145.0.7632.45 **Description** A flaw exists in Google Chrome's file input handling that could allow a remote attacker to perform UI spoofing. This requires convincing a user to interact with a specially crafted HTML page through specific UI gestures. The security severity is rated as low. **Recommendations** Update Google Chrome to version 145.0.7632.45 or later.

Name of the Vulnerable Software and Affected Versions: The product name cannot be determined. Description: An unauthenticated attacker can bypass the localhost restrictions imposed by the application, allowing them to create arbitrary packages. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** NVIDIA Triton Inference Server (affected versions not specified) **Description** The issue is related to improper handling of log output, allowing a user to inject arbitrary data as a new log entry, which can lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. A successful exploit might allow an attacker to gain unauthorized access to protected information, elevate their privileges, execute arbitrary code, or cause a denial of service or data tampering. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** NVIDIA Triton Inference Server for Linux (affected versions not specified) **Description** The issue allows a user to set the logging location to an arbitrary file. If this file exists, logs are appended to the file. A successful exploit might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** InstantCMS version 2.16.2 **Description** An open redirect was found in the ICMS2 application when being redirected after modifying one's own user profile. An attacker could trick a victim into visiting their web application, thinking they are still present on the ICMS2 application. They could then host a website stating "To update your profile, please enter your password," upon which the user may type their password and send it to the attacker. **Recommendations** As a temporary workaround, consider restricting access to the user profile modification feature until a patch is available. Avoid using the affected version of InstantCMS until a patched version is released. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Translate versions prior to 3.0.0 **Description** The issue allows an attacker controlling the second variable of the `translate` function to perform a cache poisoning attack, changing the outcome of translation requests made by subsequent users. The `opt.id` parameter enables the overwriting of the cache key. If an attacker sets the `id` variable to the cache key that would be generated by another user, they can choose the response that user gets served. **Recommendations** For versions prior to 3.0.0, update to version 3.0.0 to fix the issue. As a temporary workaround, consider restricting access to the `opt.id` parameter to prevent cache key overwriting. Avoid using the `id` variable in the `translate` function until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** LangChain versions 0.1.10 and earlier **Description** The issue allows ../ directory traversal by an actor who is able to control the final part of the `path` parameter in a `load chain` call. This bypasses the intended behavior of loading configurations only from the hwchase17/langchain-hub GitHub repository. The outcome can be disclosure of an API key for a large language model online service, or remote code execution. **Recommendations** For LangChain versions 0.1.10 and earlier, update to version 0.1.29 or later of langchain-core to resolve the issue. As a temporary workaround, consider restricting the use of the `load chain` call to minimize the risk of exploitation. Avoid using the `path` parameter in the affected `load chain` call until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Alf.io versions prior to 2.0-M4-2402 **Description** The issue allows an administrator on the Alf.io application to upload HTML files that trigger JavaScript payloads. This could enable an attacker who gains administrative access to persist access by planting an XSS payload. There are no known workarounds for this issue. **Recommendations** For versions prior to 2.0-M4-2402, upgrade to version 2.0-M4-2402 or later to resolve the issue. As a temporary workaround, consider restricting access to the HTML file upload feature until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** phpMyFAQ versions prior to 3.2.5 **Description** The issue allows an attacker to spoof another user's details, making a compelling phishing case for removing another user's account. Although the front-end of the user removal page does not allow changing form details, an attacker can use a proxy to intercept the request and submit other data. Upon submitting the form, an email is sent to the administrator, who has no way of telling the difference between the actual user wishing to delete their account or the attacker issuing this for an account they do not control. The API endpoint `/user/request-removal` is involved in this issue, where an attacker can edit the request before sending it, changing fields such as `username`, `Your name`, and `Your email address` to the details of another user. **Recommendations** For versions prior to 3.2.5, update to version 3.2.5 to resolve the issue. As a temporary workaround, consider restricting access to the `/user/request-removal` endpoint until the update is applied. Additionally, administrators should be cautious when receiving account deletion requests and verify the authenticity of such requests through alternative means.

**Name of the Vulnerable Software and Affected Versions** phpMyFAQ versions prior to 3.2.5 **Description** The 'sharing FAQ' functionality in phpMyFAQ allows any unauthenticated actor to misuse the application to send arbitrary emails to a large range of targets. The front-end of this functionality allows any phpMyFAQ articles to be shared with 5 email addresses, but the backend does not limit the number of email addresses that can be sent with a single request. An attacker can solve a single CAPTCHA and send thousands of emails at once, utilizing the target application's email server to send phishing messages. This can lead to the server being blacklisted, causing all emails to end up in spam, and can also result in reputational damages. **Recommendations** For versions prior to 3.2.5, update to version 3.2.5 to resolve the issue. As a temporary workaround, consider restricting access to the 'sharing FAQ' functionality to prevent unauthenticated actors from sending arbitrary emails. Additionally, monitor email server logs for suspicious activity and consider implementing additional security measures to prevent phishing attacks.

**Name of the Vulnerable Software and Affected Versions** pyload versions prior to 0.5.0b3.dev77 **Description** A log injection issue allows any unauthenticated actor to inject arbitrary messages into the logs gathered by pyload. This can be achieved by supplying a username containing a newline when attempting to sign in with faulty credentials, as the newline is not properly escaped and serves as the delimiter between log entries. Forged or corrupted log files can be used to cover an attacker's tracks or implicate another party in a malicious act. **Recommendations** For versions prior to 0.5.0b3.dev77, update to version 0.5.0b3.dev77 to resolve the issue. As a temporary workaround, consider restricting access to the login functionality to minimize the risk of exploitation. Avoid using the `username` parameter in the login endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** pyLoad versions prior to 0.5.0b3.dev77 **Description** Any unauthenticated user can browse to a specific URL to expose the Flask config, including the `SECRET KEY` variable. This issue allows attackers to access sensitive information, which could have detrimental consequences for security. The estimated number of potentially affected devices is not specified. **Recommendations** For versions prior to 0.5.0b3.dev77, update to version 0.5.0b3.dev77 or later to resolve the issue. As a temporary workaround, consider restricting access to the `/render/info.html` endpoint to minimize the risk of exploitation. Avoid using the `SECRET KEY` variable in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** google-translate-api-browser versions prior to 4.1.3 **Description** A Server-Side Request Forgery (SSRF) issue is present in applications utilizing the `google-translate-api-browser` package and exposing the `translateOptions` to the end user. An attacker can set a malicious `tld`, causing the application to return unsafe URLs pointing towards local resources. The `translateOptions.tld` field is not properly sanitized before being placed in the Google translate URL. This can allow an attacker with control over the `translateOptions` to set the `tld` to a payload such as `@127.0.0.1`. This causes the full URL to become `https://translate.google.@127.0.0.1/...`, where `translate.google.` is the username used to connect to localhost. An attacker can send requests within internal networks and the local host. Should any HTTPS application be present on the internal network with a vulnerability exploitable via a GET call, then it would be possible to exploit this using this vulnerability. **Recommendations** To resolve the issue, upgrade to release version 4.1.3 or later. As a temporary workaround, consider restricting access to the `translateOptions` to prevent malicious `tld` settings. Additionally, restrict access to the vulnerable `google-translate-api-browser` package to minimize the risk of exploitation. Avoid using the `tld` parameter in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** fast-jwt versions prior to 3.3.2 **Description** The fast-jwt library does not properly prevent JWT algorithm confusion for all public key types. The 'publicKeyPemMatcher' in 'fast-jwt/src/crypto.js' does not properly match all common PEM formats for public keys. To exploit this issue, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work if the victim application utilizes a public key containing the `BEGIN RSA PUBLIC KEY` header. Applications using the RS256 algorithm, a public key with a `BEGIN RSA PUBLIC KEY` header, and calling the verify function without explicitly providing an algorithm, are vulnerable to this algorithm confusion attack which allows attackers to sign arbitrary payloads which will be accepted by the verifier. **Recommendations** For versions prior to 3.3.2, update to version 3.3.2 to resolve the issue. As a temporary workaround, change line 29 of `fast-jwt/src/crypto.js` to include a regular expression: `const publicKeyPemMatcher = /^-----BEGIN( RSA)? PUBLIC KEY-----/`. Restrict access to the `verify` function to minimize the risk of exploitation until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** joaquimserafim/json-web-token (affected versions not specified) **Description** The json-web-token library is vulnerable to a JWT algorithm confusion attack. This issue arises because the algorithm to use for verifying the signature of the JWT token is taken from the JWT token itself, which at that point is still unverified and thus shouldn't be trusted. To exploit this vulnerability, an attacker needs to craft a malicious JWT token containing the HS256 algorithm, signed with the public RSA key of the victim application. This attack will only work against this library if the RS256 algorithm is in use, which is considered a best practice. **Recommendations** To resolve this issue, either of the following solutions can be applied: 1. Change the signature of the `decode` function to ensure that the algorithm is set in that call. 2. Check whether or not the secret could be a public key in the decode function and, in that case, set the key to be a public key.

**Name of the Vulnerable Software and Affected Versions** pyLoad versions prior to 0.5.0b3.dev78 **Description** The issue is related to a Cross-Site Request Forgery (CSRF) attack. Since the session cookie is not set to `SameSite: strict`, this opens the library up to severe attack possibilities. Any API call can be made via a CSRF attack by an unauthenticated user. For example, an attacker can trick an administrator into visiting a malicious page, which can make a request to `/api/add user/` and add a new administrator to the `pyload` application. **Recommendations** For versions prior to 0.5.0b3.dev78, upgrade to release 0.5.0b3.dev78 or later to address the issue. As a temporary workaround, consider restricting access to the `pyload` API to minimize the risk of exploitation. Avoid using the `pyload` API until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: BIQS IT Biqs-drive versions 1.83 and below Description: A local file inclusion (LFI) issue exists when sending a specific payload as the `file` parameter to the "download/index.php" endpoint. This allows an attacker to read arbitrary files from the server with the permissions of the configured web-user. Recommendations: For BIQS IT Biqs-drive versions 1.83 and below, consider disabling access to the "download/index.php" endpoint until a patch is available. As a temporary workaround, restrict the `file` parameter to prevent arbitrary file reading.