| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| In the CryptX module before 0.062 for Perl, gcm_decrypt_verify() and chacha20poly1305_decrypt_verify() do not verify the tag. |
| There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X13SEM-F . An attacker can update the system firmware with a specially crafted image. |
| 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. |
| A vulnerability has been identified in SIMATIC RTLS Locating Manager (6GT2780-0DA00) (All versions < V3.0.1.1), SIMATIC RTLS Locating Manager (6GT2780-0DA10) (All versions < V3.0.1.1), SIMATIC RTLS Locating Manager (6GT2780-0DA20) (All versions < V3.0.1.1), SIMATIC RTLS Locating Manager (6GT2780-0DA30) (All versions < V3.0.1.1), SIMATIC RTLS Locating Manager (6GT2780-1EA10) (All versions < V3.0.1.1), SIMATIC RTLS Locating Manager (6GT2780-1EA20) (All versions < V3.0.1.1), SIMATIC RTLS Locating Manager (6GT2780-1EA30) (All versions < V3.0.1.1). Affected components do not properly authenticate heartbeat messages. This could allow an unauthenticated remote attacker to affected the availability of secondary RTLS systems configured using a TeeRevProxy service and potentially cause loss of data generated during the time the attack is ongoing. |
| 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 with a valid account 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. |
| Deck Mate 2's firmware update mechanism accepts packages without cryptographic signature verification, encrypts them with a single hard-coded AES key shared across devices, and uses a truncated HMAC for integrity validation. Attackers with access to the update interface - typically via the unit's USB update port - can craft or modify firmware packages to execute arbitrary code as root, allowing persistent compromise of the device's integrity and deck randomization process. Physical or on-premises access remains the most likely attack path, though network-exposed or telemetry-enabled deployments could theoretically allow remote exploitation if misconfigured. The vendor confirmed that firmware updates have been issued to correct these update-chain weaknesses and that USB update access has been disabled on affected units. |
| 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. |
| 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. |
| Insufficient verification of data authenticity in some Intel(R) DSA software before version 23.4.39 may allow an authenticated user to potentially enable escalation of privilege via local access. |
| eGovFramework/egovframe-common-components versions up to and including 4.3.1 includes Web Editor image upload and related file delivery functionality that uses symmetric encryption to protect URL parameters, but exposes an encryption oracle that allows attackers to generate valid ciphertext for chosen values. The image upload endpoints /utl/wed/insertImage.do and /utl/wed/insertImageCk.do encrypt server-side paths, filenames, and MIME types and embed them directly into a download URL that is returned to the client. Because these same encrypted parameters are trusted by other endpoints, such as /utl/web/imageSrc.do and /cmm/fms/getImage.do, an unauthenticated attacker can abuse the upload functionality to obtain encrypted representations of attacker-chosen identifiers and then replay those ciphertext values to file-serving APIs. This design failure allows an attacker to bypass access controls that rely solely on the secrecy of encrypted parameters and retrieve arbitrary stored files that are otherwise expected to require an existing session or specific authorization context. KISA/KrCERT has identified this unpatched vulnerability as "KVE-2023-5281." |
| 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. |
| 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. |
| An issue in KIA Seltos vehicle instrument cluster with software and hardware v1.0 allows attackers to cause a Denial of Service (DoS) via ECU reset UDS service. NOTE: this is disputed by the Supplier because the findings came from a potentially unrealistic test environment (an isolated ECU part that was not in a vehicle), and because the ECUReset specification does not allow a manufacturer to require SecurityAccess and Authentication. |
| There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X12STW-F . An attacker can update the system firmware with a specially crafted image. |
| The RegistrationMagic – Custom Registration Forms, User Registration, Payment, and User Login plugin for WordPress is vulnerable to payment bypass due to insufficient verification of data authenticity on the 'process_paypal_sdk_payment' function in all versions up to, and including, 6.0.6.9. This is due to the plugin trusting client-supplied values for payment verification without validating that the payment actually went through PayPal. This makes it possible for unauthenticated attackers to bypass paid registration by manipulating payment status and activating their account without completing a real PayPal payment. |
| CWE-347: Improper Verification of Cryptographic Signature vulnerability exists that could
compromise the Data Center Expert software when an upgrade bundle is manipulated to
include arbitrary bash scripts that are executed as root. |
| 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. |
| The Kossy module before 0.60 for Perl allows JSON hijacking because of X-Requested-With mishandling. |
| 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`. |
