ReportizFlow
Filtered by vendor
Subscriptions
Total
167 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-32148 | 2 Hex, Hexpm | 2 Hex, Hex | 2026-05-05 | 5.9 Medium |
| Insufficient Verification of Data Authenticity vulnerability in hexpm hex (Hex.RemoteConverger module) allows dependency integrity bypass via unverified lockfile checksums. Hex stores checksums for dependencies in the mix.lock file to ensure reproducible and integrity-checked builds. However, Hex.RemoteConverger.verify_resolved/2 never executes checksum verification because the lock data returned by Hex.Utils.lock/1 uses string-based dependency names, while the verification logic compares against atom-based names. This type mismatch causes the verification code path to be silently skipped. Checksums are still validated when packages are initially downloaded from the registry, but mismatches between the lockfile and resolved dependencies are not detected. An attacker who can influence cached packages (e.g., via local cache poisoning or a compromised registry) can provide modified dependency contents that will be accepted without detection. The mix.lock file is silently rewritten with the checksum values from the registry, erasing evidence of tampering. This issue affects hex: from 0.16.0 before 2.4.2. | ||||
| CVE-2026-28402 | 1 Nimiq | 2 Core-rs-albatross, Nimiq Proof-of-stake | 2026-05-04 | 7.1 High |
| nimiq/core-rs-albatross is a Rust implementation of the Nimiq Proof-of-Stake protocol based on the Albatross consensus algorithm. Prior to version 1.2.2, a malicious or compromised validator that is elected as proposer can publish a macro block proposal where `header.body_root` does not match the actual macro body hash. The proposal can pass proposal verification because the macro proposal verification path validates the header but does not validate the binding `body_root == hash(body)`; later code expects this binding and may panic on mismatch, crashing validators. Note that the impact is only for validator nodes. The patch for this vulnerability is formally released as part of v1.2.2. The patch adds the corresponding body root verification in the proposal checks. No known workarounds are available. | ||||
| CVE-2026-5504 | 1 Wolfssl | 1 Wolfssl | 2026-04-29 | 5.3 Medium |
| A padding oracle exists in wolfSSL's PKCS7 CBC decryption that could allow an attacker to recover plaintext through repeated decryption queries with modified ciphertext. In previous versions of wolfSSL the interior padding bytes are not validated. | ||||
| CVE-2026-5479 | 1 Wolfssl | 1 Wolfssl | 2026-04-29 | 8.1 High |
| In wolfSSL's EVP layer, the ChaCha20-Poly1305 AEAD decryption path in wolfSSL_EVP_CipherFinal (and related EVP cipher finalization functions) fails to verify the authentication tag before returning plaintext to the caller. When an application uses the EVP API to perform ChaCha20-Poly1305 decryption, the implementation computes or accepts the tag but does not compare it against the expected value. | ||||
| CVE-2025-24148 | 1 Apple | 1 Macos | 2026-04-28 | 5.5 Medium |
| This issue was addressed with improved handling of executable types. This issue is fixed in macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5. A malicious JAR file may bypass Gatekeeper checks. | ||||
| CVE-2026-32105 | 1 Neutrinolabs | 1 Xrdp | 2026-04-27 | 7.7 High |
| xrdp is an open source RDP server. In versions through 0.10.5, xrdp does not implement verification for the Message Authentication Code (MAC) signature of encrypted RDP packets when using the "Classic RDP Security" layer. While the sender correctly generates signatures, the receiving logic lacks the necessary implementation to validate the 8-byte integrity signature, causing it to be silently ignored. An unauthenticated attacker with man-in-the-middle (MITM) capabilities can exploit this missing check to modify encrypted traffic in transit without detection. It does not affect connections where the TLS security layer is enforced. This issue has been fixed in version 0.10.6. If users are unable to immediately upgrade, they should configure xrdp.ini to enforce TLS security (security_layer=tls) to ensure end-to-end integrity. | ||||
| CVE-2024-3727 | 1 Redhat | 18 Acm, Advanced Cluster Security, Ansible Automation Platform and 15 more | 2026-04-25 | 8.3 High |
| A flaw was found in the github.com/containers/image library. This flaw allows attackers to trigger unexpected authenticated registry accesses on behalf of a victim user, causing resource exhaustion, local path traversal, and other attacks. | ||||
| CVE-2008-3323 | 1 Redhat | 1 Cygwin | 2026-04-23 | N/A |
| setup.exe before 2.573.2.3 in Cygwin does not properly verify the authenticity of packages, which allows remote Cygwin mirror servers or man-in-the-middle attackers to execute arbitrary code via a package list containing the MD5 checksum of a Trojan horse package. | ||||
| CVE-2025-3247 | 1 Rocklobster | 1 Contact Form 7 | 2026-04-22 | 5.3 Medium |
| The Contact Form 7 plugin for WordPress is vulnerable to Order Replay in all versions up to, and including, 6.0.5 via the 'wpcf7_stripe_skip_spam_check' function due to insufficient validation on a user controlled key. This makes it possible for unauthenticated attackers to reuse a single Stripe PaymentIntent for multiple transactions. Only the first transaction is processed via Stripe, but the plugin sends a successful email message for each transaction, which may trick an administrator into fulfilling each order. | ||||
| CVE-2025-3479 | 1 Wpmudev | 1 Forminator Forms | 2026-04-21 | 5.3 Medium |
| The Forminator Forms – Contact Form, Payment Form & Custom Form Builder plugin for WordPress is vulnerable to Order Replay in all versions up to, and including, 1.42.0 via the 'handle_stripe_single' function due to insufficient validation on a user controlled key. This makes it possible for unauthenticated attackers to reuse a single Stripe PaymentIntent for multiple transactions. Only the first transaction is processed via Stripe, but the plugin sends a successful email message for each transaction, which may trick an administrator into fulfilling each order. | ||||
| CVE-2026-40323 | 1 Succinctlabs | 1 Sp1 | 2026-04-20 | N/A |
| SP1 is a zero‑knowledge virtual machine that proves the correct execution of programs compiled for the RISC-V architecture. In versions 6.0.0 through 6.0.2, a soundness vulnerability in the SP1 V6 recursive shard verifier allows a malicious prover to construct a recursive proof from a shard proof that the native verifier would reject. Version 6.1.0 fixes the issue. | ||||
| CVE-2026-26007 | 2 Cryptography.io, Pyca | 2 Cryptography, Cryptography | 2026-04-18 | 6.5 Medium |
| cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5. | ||||
| CVE-2026-25934 | 2 Go-git, Go-git Project | 2 Go-git, Go-git | 2026-04-18 | 4.3 Medium |
| go-git is a highly extensible git implementation library written in pure Go. Prior to 5.16.5, a vulnerability was discovered in go-git whereby data integrity values for .pack and .idx files were not properly verified. This resulted in go-git potentially consuming corrupted files, which would likely result in unexpected errors such as object not found. For context, clients fetch packfiles from upstream Git servers. Those files contain a checksum of their contents, so that clients can perform integrity checks before consuming it. The pack indexes (.idx) are generated locally by go-git, or the git cli, when new .pack files are received and processed. The integrity checks for both files were not being verified correctly. This vulnerability is fixed in 5.16.5. | ||||
| CVE-2026-26275 | 1 Junkurihara | 2 Httpsig-hyper, Httpsig-rs | 2026-04-17 | 7.5 High |
| httpsig-hyper is a hyper extension for http message signatures. An issue was discovered in `httpsig-hyper` prior to version 0.0.23 where Digest header verification could incorrectly succeed due to misuse of Rust's `matches!` macro. Specifically, the comparison `if matches!(digest, _expected_digest)` treated `_expected_digest` as a pattern binding rather than a value comparison, resulting in unconditional success of the match expression. As a consequence, digest verification could incorrectly return success even when the computed digest did not match the expected value. Applications relying on Digest verification as part of HTTP message signature validation may therefore fail to detect message body modification. The severity depends on how the library is integrated and whether additional signature validation layers are enforced. This issue has been fixed in `httpsig-hyper` 0.0.23. The fix replaces the incorrect `matches!` usage with proper value comparison and additionally introduces constant-time comparison for digest verification as defense-in-depth. Regression tests have also been added to prevent reintroduction of this issue. Users are strongly advised to upgrade to the patched version. There is no reliable workaround without upgrading. Users who cannot immediately upgrade should avoid relying solely on Digest verification for message integrity and ensure that full HTTP message signature verification is enforced at the application layer. | ||||
| CVE-2024-46992 | 1 Electron | 1 Electron | 2026-04-15 | 7.8 High |
| Electron is an open source framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From versions 30.0.0-alpha.1 to before 30.0.5 and 31.0.0-alpha.1 to before 31.0.0-beta.1, Electron is vulnerable to an ASAR Integrity bypass. This only impacts apps that have the embeddedAsarIntegrityValidation and onlyLoadAppFromAsar fuses enabled. Apps without these fuses enabled are not impacted. This issue is specific to Windows, apps using these fuses on macOS are not impacted. Specifically this issue can only be exploited if the app is launched from a filesystem the attacker has write access too. i.e. the ability to edit files inside the .app bundle on macOS which these fuses are supposed to protect against. This issue has been patched in versions 30.0.5 and 31.0.0-beta.1. There are no workarounds for this issue. | ||||
| CVE-2023-50738 | 1 Lexmark | 1 Printer Firmware | 2026-04-15 | 4.3 Medium |
| A new feature to prevent Firmware downgrades was recently added to some Lexmark products. A method to override this downgrade protection has been identified. | ||||
| CVE-2024-7402 | 1 Netskope | 1 Netskope | 2026-04-15 | N/A |
| Netskope has identified a potential gap in its agent (Netskope Client) in which a malicious insider can potentially tamper the Netskope Client configuration by performing MITM (Man-in-the-Middle) activity on the Netskope Client communication channel. A successful exploitation would require administrative privileges on the machine, and could result in temporarily altering the configuration of Netskope Client or permanently disabling or removing the agent from the machine. | ||||
| CVE-2025-4418 | 2026-04-15 | 4.4 Medium | ||
| An improper validation of integrity check value vulnerability exists in AVEVA PI Connector for CygNet Versions 1.6.14 and prior that, if exploited, could allow a miscreant with elevated privileges to modify PI Connector for CygNet local data files (cache and buffers) in a way that causes the connector service to become unresponsive. | ||||
| CVE-2025-54887 | 1 Ruby-jwe Project | 1 Ruby-jwe | 2026-04-15 | 9.1 Critical |
| jwe is a Ruby implementation of the RFC 7516 JSON Web Encryption (JWE) standard. In versions 1.1.0 and below, authentication tags of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs. This puts users at risk because JWEs can be modified to decrypt to an arbitrary value, decrypted by observing parsing differences and the GCM internal GHASH key can be recovered. Users are affected by this vulnerability even if they do not use an AES-GCM encryption algorithm for their JWEs. As the GHASH key may have been leaked, users must rotate the encryption keys after upgrading. This issue is fixed in version 1.1.1. | ||||
| CVE-2024-48930 | 1 Secp256k1-node Project | 1 Secp256k1-node | 2026-04-15 | N/A |
| secp256k1-node is a Node.js binding for an Optimized C library for EC operations on curve secp256k1. In `elliptic`-based version, `loadUncompressedPublicKey` has a check that the public key is on the curve. Prior to versions 5.0.1, 4.0.4, and 3.8.1, however, `loadCompressedPublicKey` is missing that check. That allows the attacker to use public keys on low-cardinality curves to extract enough information to fully restore the private key from as little as 11 ECDH sessions, and very cheaply on compute power. Other operations on public keys are also affected, including e.g. `publicKeyVerify()` incorrectly returning `true` on those invalid keys, and e.g. `publicKeyTweakMul()` also returning predictable outcomes allowing to restore the tweak. Versions 5.0.1, 4.0.4, and 3.8.1 contain a fix for the issue. | ||||