| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`. When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`. |
| rfc3161-client is a Python library implementing the Time-Stamp Protocol (TSP) described in RFC 3161. Prior to version 1.0.3, there is a flaw in the timestamp response signature verification logic. In particular, chain verification is performed against the TSR's embedded certificates up to the trusted root(s), but fails to verify the TSR's own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce any TSR signature so long as the embedded leaf chains up to some root TSA. This issue has been patched in version 1.0.3. There is no workaround for this issue. |
| An improper verification of cryptographic signature in Zscaler's SAML authentication mechanism on the server-side allowed an authentication abuse. |
| SEL-5037 Grid Configurator contains an overly permissive Cross Origin Resource Sharing (CORS) configuration for a data gateway service in the application. This gateway service includes an API which is not properly configured to reject requests from unexpected sources. |
| Quest KACE Systems Management Appliance (SMA) 13.0.x before 13.0.385, 13.1.x before 13.1.81, 13.2.x before 13.2.183, 14.0.x before 14.0.341 (Patch 5), and 14.1.x before 14.1.101 (Patch 4) allows unauthenticated users to upload backup files to the system. While signature validation is implemented, weaknesses in the validation process can be exploited to upload malicious backup content that could compromise system integrity. |
| 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. |
| Hickory DNS is a Rust based DNS client, server, and resolver. A vulnerability present starting in version 0.8.0 and prior to versions 0.24.3 and 0.25.0-alpha.5 impacts Hickory DNS users relying on DNSSEC verification in the client library, stub resolver, or recursive resolver. The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone. Versions 0.24.3 and 0.25.0-alpha.5 fix the issue. |
| Movable Type contains an issue with use of less trusted source. If exploited, tampered email to reset a password may be sent by a remote unauthenticated attacker. |
| Cryptographic validation of upgrade images could be circumventing by dropping a specifically crafted file into the upgrade ISO |
| An unauthenticated remote attacker is able to use an existing session id of a logged in user and gain full access to the device if configuration via ethernet is enabled. |
| The SimpleSAMLphp SAML2 library is a PHP library for SAML2 related functionality. Prior to versions 4.17.0 and 5.0.0-alpha.20, there is a signature confusion attack in the HTTPRedirect binding. An attacker with any signed SAMLResponse via the HTTP-Redirect binding can cause the application to accept an unsigned message. Versions 4.17.0 and 5.0.0-alpha.20 contain a fix for the issue. |
| libsignal-service-rs is a Rust version of the libsignal-service-java library which implements the core functionality to communicate with Signal servers. Prior to commit 82d70f6720e762898f34ae76b0894b0297d9b2f8, any contact may forge a sync message, impersonating another device of the local user. The origin of sync messages is not checked. Patched libsignal-service can be found after commit 82d70f6720e762898f34ae76b0894b0297d9b2f8. The `Metadata` struct contains an additional `was_encrypted` field, which breaks the API, but should be easily resolvable. No known workarounds are available. |
| An issue was discovered in the oidc (aka OpenID Connect Authentication) extension before 4.0.0 for TYPO3. The account linking logic allows a pre-hijacking attack, leading to Account Takeover. The attack can only be exploited if the following requirements are met: (1) an attacker can anticipate the e-mail address of the user, (2) an attacker can register a public frontend user account using that e-mail address before the user's first OIDC login, and (3) the IDP returns an email field containing the e-mail address of the user, |
| DNS rebinding vulnerability in Neo4j Cypher MCP server allows malicious websites to bypass Same-Origin Policy protections and execute unauthorised tool invocations against locally running Neo4j MCP instances. The attack relies on the user being enticed to visit a malicious website and spend sufficient time there for DNS rebinding to succeed. |
| NLnet Labs Unbound up to and including version 1.24.1 is vulnerable to possible domain hijack attacks. Promiscuous NS RRSets that complement positive DNS replies in the authority section can be used to trick resolvers to update their delegation information for the zone. Usually these RRSets are used to update the resolver's knowledge of the zone's name servers. A malicious actor can exploit the possible poisonous effect by injecting NS RRSets (and possibly their respective address records) in a reply. This could be done for example by trying to spoof a packet or fragmentation attacks. Unbound would then proceed to update the NS RRSet data it already has since the new data has enough trust for it, i.e., in-zone data for the delegation point. Unbound 1.24.1 includes a fix that scrubs unsolicited NS RRSets (and their respective address records) from replies mitigating the possible poison effect. Unbound 1.24.2 includes an additional fix that scrubs unsolicited NS RRSets (and their respective address records) from YXDOMAIN and non-referral nodata replies, further mitigating the possible poison effect. |
| CGGMP24 is a state-of-art ECDSA TSS protocol that supports 1-round signing (requires 3 preprocessing rounds), identifiable abort, and a key refresh protocol. Prior to version 0.6.3, there is a missing check in the ZK proof that enables an attack in which single malicious signer can reconstruct full private key. This issue has been patched in version 0.6.3, for full mitigation it is recommended to upgrade to cggmp24 version 0.7.0-alpha.2 as it contains more security checks. |
| quic-go is an implementation of the QUIC protocol in Go. An off-path attacker can inject an ICMP Packet Too Large packet. Since affected quic-go versions used IP_PMTUDISC_DO, the kernel would then return a "message too large" error on sendmsg, i.e. when quic-go attempts to send a packet that exceeds the MTU claimed in that ICMP packet. By setting this value to smaller than 1200 bytes (the minimum MTU for QUIC), the attacker can disrupt a QUIC connection. Crucially, this can be done after completion of the handshake, thereby circumventing any TCP fallback that might be implemented on the application layer (for example, many browsers fall back to HTTP over TCP if they're unable to establish a QUIC connection). The attacker needs to at least know the client's IP and port tuple to mount an attack. This vulnerability is fixed in 0.48.2. |
| 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. |
| The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message. |
| Catalyst::Plugin::Session before version 0.44 for Perl generates session ids insecurely.
The session id is generated from a (usually SHA-1) hash of a simple counter, the epoch time, the built-in rand function, the PID and the current Catalyst context. This information is of low entropy. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage.
Predicable session ids could allow an attacker to gain access to systems. |
