Export limit exceeded: 409409 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3032 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-13990 | 1 Microworld Technologies | 1 Escan | 2026-04-15 | N/A |
| MicroWorld eScan AV's update mechanism failed to ensure authenticity and integrity of updates: update packages were delivered and accepted without robust cryptographic verification. As a result, an on-path attacker could perform a man-in-the-middle (MitM) attack and substitute malicious update payloads for legitimate ones. The eScan AV client accepted these substituted packages and executed or loaded their components (including sideloaded DLLs and Java/installer payloads), enabling remote code execution on affected systems. MicroWorld eScan confirmed remediation of the update mechanism on 2023-07-31 but versioning details are unavailable. NOTE: MicroWorld eScan disputes the characterization in third-party reports, stating the issue relates to 2018–2019 and that controls were implemented then. | ||||
| CVE-2025-32900 | 3 Apple, Google, Kde | 6 Ios, Android, Gsconnect and 3 more | 2026-04-15 | 4.3 Medium |
| In the KDE Connect information-exchange protocol before 2025-04-18, a packet can be crafted to temporarily change the displayed information about a device, because broadcast UDP is used. This affects KDE Connect before 1.33.0 on Android, KDE Connect before 25.04 on desktop, KDE Connect before 0.5 on iOS, Valent before 1.0.0.alpha.47, and GSConnect before 59. | ||||
| CVE-2025-42998 | 2026-04-15 | 5.3 Medium | ||
| 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. | ||||
| CVE-2025-53399 | 1 Sipwise | 1 Rtpengine | 2026-04-15 | N/A |
| In Sipwise rtpengine before 13.4.1.1, an origin-validation error in the endpoint-learning logic of the media-relay core allows remote attackers to inject or intercept RTP/SRTP media streams via RTP packets (except when the relay is configured for strict source and learning disabled). Version 13.4.1.1 fixes the heuristic mode by limiting exposure to the first five packets, and introduces a recrypt flag that fully prevents SRTP attacks when both mitigations are enabled. | ||||
| CVE-2025-53522 | 1 Six Apart Ltd | 1 Movable Type | 2026-04-15 | N/A |
| 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. | ||||
| CVE-2025-53548 | 2026-04-15 | 7.5 High | ||
| Clerk helps developers build user management. Applications that use the verifyWebhook() helper to verify incoming Clerk webhooks are susceptible to accepting improperly signed webhook events. The issue was resolved in @clerk/backend 2.4.0. | ||||
| CVE-2025-58422 | 1 Ricoh | 1 Streamline Nx | 2026-04-15 | N/A |
| RICOH Streamline NX versions 3.5.1 to 24R3 are vulnerable to tampering with operation history. If an attacker can perform a man-in-the-middle attack, they may alter the values of HTTP requests, which could result in tampering with the operation history of the product’s management tool. | ||||
| CVE-2024-38807 | 2026-04-15 | 6.3 Medium | ||
| Applications that use spring-boot-loader or spring-boot-loader-classic and contain custom code that performs signature verification of nested jar files may be vulnerable to signature forgery where content that appears to have been signed by one signer has, in fact, been signed by another. | ||||
| CVE-2024-7819 | 1 Danswer-ai | 1 Danswer | 2026-04-15 | N/A |
| 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. | ||||
| CVE-2024-8183 | 2026-04-15 | N/A | ||
| A CORS (Cross-Origin Resource Sharing) misconfiguration in prefecthq/prefect version 2.20.2 allows unauthorized domains to access sensitive data. This vulnerability can lead to unauthorized access to the database, resulting in potential data leaks, loss of confidentiality, service disruption, and data integrity risks. | ||||
| CVE-2024-36347 | 2026-04-15 | 6.4 Medium | ||
| 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. | ||||
| CVE-2025-3449 | 1 Br-automation | 1 Automation Runtime | 2026-04-15 | 4.2 Medium |
| A Generation of Predictable Numbers or Identifiers vulnerability in the SDM component of B&R Automation Runtime versions before 6.4 may allow an unauthenticated network-based attacker to take over already established sessions. | ||||
| CVE-2024-36472 | 1 Redhat | 2 Enterprise Linux, Rhel Eus | 2026-04-15 | 6.5 Medium |
| In GNOME Shell through 45.7, a portal helper can be launched automatically (without user confirmation) based on network responses provided by an adversary (e.g., an adversary who controls the local Wi-Fi network), and subsequently loads untrusted JavaScript code, which may lead to resource consumption or other impacts depending on the JavaScript code's behavior. | ||||
| CVE-2025-52484 | 1 Risc Zero Project | 1 Risc Zero | 2026-04-15 | N/A |
| RISC Zero is a general computing platform based on zk-STARKs and the RISC-V microarchitecture. Due to a missing constraint in the rv32im circuit, any 3-register RISC-V instruction (including remu and divu) in risc0-zkvm 2.0.0, 2.0.1, and 2.0.2 are vulnerable to an attack by a malicious prover. The main idea for the attack is to confuse the RISC-V virtual machine into treating the value of the rs1 register as the same as the rs2 register due to a lack of constraints in the rv32im circuit. Rust applications using the risc0-zkvm crate at versions 2.0.0, 2.0.1, and 2.0.2 should upgrade to version 2.1.0. Smart contract applications using the official RISC Zero Verifier Router do not need to take any action: zkVM version 2.1 is active on all official routers, and version 2.0 has been disabled. Smart contract applications not using the verifier router should update their contracts to send verification calls to the 2.1 version of the verifier. | ||||
| CVE-2025-40924 | 2026-04-15 | 6.5 Medium | ||
| 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. | ||||
| CVE-2025-11411 | 1 Nlnetlabs | 1 Unbound | 2026-04-15 | 6.9 Medium |
| 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. | ||||
| CVE-2024-54150 | 2026-04-15 | 9.1 Critical | ||
| 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. | ||||
| CVE-2025-54419 | 1 Node-saml | 1 Node-saml | 2026-04-15 | 10 Critical |
| A SAML library not dependent on any frameworks that runs in Node. In version 5.0.1, Node-SAML loads the assertion from the (unsigned) original response document. This is different than the parts that are verified when checking signature. This allows an attacker to modify authentication details within a valid SAML assertion. For example, in one attack it is possible to remove any character from the SAML assertion username. To conduct the attack an attacker would need a validly signed document from the identity provider (IdP). This is fixed in version 5.1.0. | ||||
| CVE-2025-68113 | 1 Altcha | 1 Altcha | 2026-04-15 | 6.5 Medium |
| ALTCHA is privacy-first software for captcha and bot protection. A cryptographic semantic binding flaw in ALTCHA libraries allows challenge payload splicing, which may enable replay attacks. The HMAC signature does not unambiguously bind challenge parameters to the nonce, allowing an attacker to reinterpret a valid proof-of-work submission with a modified expiration value. This may allow previously solved challenges to be reused beyond their intended lifetime, depending on server-side replay handling and deployment assumptions. The vulnerability primarily impacts abuse-prevention mechanisms such as rate limiting and bot mitigation. It does not directly affect data confidentiality or integrity. This issue has been addressed by enforcing explicit semantic separation between challenge parameters and the nonce during HMAC computation. Users are advised to upgrade to patched versions, which include version 1.0.0 of the altcha Golang package, version 1.0.0 of the altcha Rubygem, version 1.0.0 of the altcha pip package, version 1.0.0 of the altcha Erlang package, version 1.4.1 of the altcha-lib npm package, version 1.3.1 of the altcha-org/altcha Composer package, and version 1.3.0 of the org.altcha:altcha Maven package. As a mitigation, implementations may append a delimiter to the end of the `salt` value prior to HMAC computation (for example, `<salt>?expires=<time>&`). This prevents ambiguity between parameters and the nonce and is backward-compatible with existing implementations, as the delimiter is treated as a standard URL parameter separator. | ||||
| CVE-2025-47934 | 1 Openpgpjs | 1 Openpgpjs | 2026-04-15 | N/A |
| 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`. | ||||