| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| cjwt is a C JSON Web Token (JWT) Implementation. Algorithm confusion occurs when a system improperly verifies the type of signature used, allowing attackers to exploit the lack of distinction between signing methods. If the system doesn't differentiate between an HMAC signed token and an RS/EC/PS signed token during verification, it becomes vulnerable to this kind of attack. For instance, an attacker could craft a token with the alg field set to "HS256" while the server expects an asymmetric algorithm like "RS256". The server might mistakenly use the wrong verification method, such as using a public key as the HMAC secret, leading to unauthorised access. For RSA, the key can be computed from a few signatures. For Elliptic Curve (EC), two potential keys can be recovered from one signature. This can be used to bypass the signature mechanism if an application relies on asymmetrically signed tokens. This issue has been addressed in version 2.3.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| A CORS misconfiguration in danswer-ai/danswer v1.4.1 allows attackers to steal sensitive information such as chat contents, API keys, and other data. This vulnerability occurs due to improper validation of the origin header, enabling malicious web pages to make unauthorized requests to the application's API. |
| gitoxide An idiomatic, lean, fast & safe pure Rust implementation of Git. `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account on Windows systems. Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories. Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it. Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\Program Files (x86)` directory. A limited user on a 32-bit Windows system can therefore create the `C:\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other user accounts including administrators will execute it if they run an application that uses `gix-path` and do not have `git` in a `PATH` directory. (While having `git` found in a `PATH` search prevents exploitation, merely having it installed in the default location under the real `C:\Program Files` directory does not. This is because the first hard-coded path's `mingw64` component assumes a 64-bit installation.). Only Windows is affected. Exploitation is unlikely except on a 32-bit system. In particular, running a 32-bit build on a 64-bit system is not a risk factor. Furthermore, the attacker must have a user account on the system, though it may be a relatively unprivileged account. Such a user can perform privilege escalation and execute code as another user, though it may be difficult to do so reliably because the targeted user account must run an application or service that uses `gix-path` and must not have `git` in its `PATH`. The main exploitable configuration is one where Git for Windows has been installed but not added to `PATH`. This is one of the options in its installer, though not the default option. Alternatively, an affected program that sanitizes its `PATH` to remove seemingly nonessential directories could allow exploitation. But for the most part, if the target user has configured a `PATH` in which the real `git.exe` can be found, then this cannot be exploited. This issue has been addressed in release version 0.10.9 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| A vulnerability in the installation process of Cisco IOS XR Software could allow an authenticated, local attacker to bypass Cisco IOS XR Software image signature verification and load unsigned software on an affected device. To exploit this vulnerability, the attacker must have root-system privileges on the affected device.
This vulnerability is due to incomplete validation of files during the installation of an .iso file. An attacker could exploit this vulnerability by modifying contents of the .iso image and then installing and activating it on the device. A successful exploit could allow the attacker to load an unsigned file as part of the image activation process. |
| xml-crypto is an XML digital signature and encryption library for Node.js. An attacker may be able to exploit a vulnerability in versions prior to 6.0.1, 3.2.1, and 2.1.6 to bypass authentication or authorization mechanisms in systems that rely on xml-crypto for verifying signed XML documents. The vulnerability allows an attacker to modify a valid signed XML message in a way that still passes signature verification checks. For example, it could be used to alter critical identity or access control attributes, enabling an attacker to escalate privileges or impersonate another user. Users of versions 6.0.0 and prior should upgrade to version 6.0.1 to receive a fix. Those who are still using v2.x or v3.x should upgrade to patched versions 2.1.6 or 3.2.1, respectively. |
| tiny-secp256k1 is a tiny secp256k1 native/JS wrapper. Prior to version 1.1.7, a malicious JSON-stringifyable message can be made passing on verify(), when global Buffer is the buffer package. This affects only environments where require('buffer') is the NPM buffer package. Buffer.isBuffer check can be bypassed, resulting in strange objects being accepted as a message, and those messages could trick verify() into returning false-positive true values. This issue has been patched in version 1.1.7. |
| A code execution vulnerability exists in the Xiaomi shop applicationproduct. The vulnerability is caused by improper input validation and can be exploited by attackers to execute malicious code. |
| An intent redriction vulnerability exists in the Xiaomi quick App framework application product. The vulnerability is caused by improper input validation and can be exploited by attackers tointent redriction. |
| An code execution vulnerability exists in the Xiaomi smarthome application product. The vulnerability is caused by improper input validation and can be exploited by attackers to execute malicious code. |
| xml-crypto is an xml digital signature and encryption library for Node.js. In affected versions the default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of the w3 xmldsig-core-20080610 spec. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks. As a result `xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`. `xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes. An attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element. This vulnerability is combination of changes introduced to `4.0.0` on pull request 301 / commit `c2b83f98` and has been addressed in version 6.0.0 with pull request 445 / commit `21201723d`. Users are advised to upgrade. Users unable to upgrade may either check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation or set `xml-crypto's getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification. |
| check-jsonschema is a CLI and set of pre-commit hooks for jsonschema validation. The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. `https://example.org/schema.json` will be stored as `schema.json`. This naming allows for conflicts. If an attacker can get a user to run `check-jsonschema` against a malicious schema URL, e.g., `https://example.evil.org/schema.json`, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema. Such a cache confusion attack could be used to allow data to pass validation which should have been rejected. This issue has been patched in version 0.30.0. All users are advised to upgrade. A few workarounds exist: 1. Users can use `--no-cache` to disable caching. 2. Users can use `--cache-filename` to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.) 3. Users can explicitly download the schema before use as a local file, as in `curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json` |
| On Wear OS devices, when Google Messages is configured as the default SMS/MMS/RCS application, the handling of ACTION_SENDTO intents utilizing the sms:, smsto:, mms:, and mmsto: Uniform Resource Identifier (URI) schemes is incorrectly implemented.
Due to this misconfiguration, an attacker capable of invoking an Android intent can exploit this vulnerability to send messages on the user’s behalf to arbitrary receivers without requiring any further user interaction or specific permissions. This allows for the silent and unauthorized transmission of messages from a compromised Wear OS device. |
| In OpenStack Neutron before 25.0.1, neutron/extensions/tagging.py can use an incorrect ID during policy enforcement. It does not apply the proper policy check for changing network tags. An unprivileged tenant is able to change (add and clear) tags on network objects that do not belong to the tenant, and this action is not subjected to the proper policy authorization check. This affects 23 before 23.2.1, 24 before 24.0.2, and 25 before 25.0.1. |
| The security settings in the SAP Business One Integration Framework are not adequately checked, allowing attackers to bypass the 403 Forbidden error and access restricted pages. This leads to low impact on confidentiality of the application, there is no impact on integrity and availability. |
| An insufficiently secured internal function allows session generation for arbitrary users. The decodeParam function checks the JWT but does not verify which signing algorithm was used. As a result, an attacker can use the "ex:action" parameter in the VerifyUserByThrustedService function to generate a session for any user. |
| A vulnerability has been found in IROAD Dash Cam X5 and Dash Cam X6 up to 20250308 and classified as problematic. This vulnerability affects unknown code of the component Domain Handler. The manipulation of the argument Domain Name leads to origin validation error. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. |
| The WooCommerce POS plugin for WordPress is vulnerable to information disclosure in all versions up to, and including, 1.4.11. This is due to the plugin not properly verifying the authentication and authorization of the current user This makes it possible for authenticated attackers, with customer-level access and above, to view potentially sensitive information about other users by leveraging their order id |
| The Authorize.net Payment Gateway For WooCommerce plugin for WordPress is vulnerable to payment bypass in all versions up to, and including, 8.0. This is due to the plugin not properly verifying the authenticity of the request that updates a orders payment status. This makes it possible for unauthenticated attackers to update order payment statuses to paid bypassing any payment. |
| Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious microcode, potentially resulting in loss of integrity of x86 instruction execution, loss of confidentiality and integrity of data in x86 CPU privileged context and compromise of SMM execution environment. |
| There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X12STW . An attacker can update the system firmware with a specially crafted image. |
