Export limit exceeded: 10440 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10440 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-65539 | 2 Bimal Rekhadiya, Wordpress | 2 Kwayy Html Sitemap, Wordpress | 2026-07-23 | 7.1 High |
| Unauthenticated Cross Site Request Forgery (CSRF) in Kwayy HTML Sitemap <= 4.0 versions. | ||||
| CVE-2026-65540 | 2 Metin Saraç, Wordpress | 2 Popup For Cf7 With Sweet Alert, Wordpress | 2026-07-23 | 7.1 High |
| Unauthenticated Cross Site Request Forgery (CSRF) in Popup for CF7 with Sweet Alert <= 1.6.5 versions. | ||||
| CVE-2026-61981 | 2026-07-23 | 5.4 Medium | ||
| Unauthenticated Cross Site Request Forgery (CSRF) in Simple Link Directory Pro <= 15.0.8 versions. | ||||
| CVE-2026-57626 | 2 Mailpoet, Wordpress | 2 Mailpoet, Wordpress | 2026-07-23 | 7.1 High |
| Cross-Site Request Forgery (CSRF) vulnerability in MailPoet allows Cross Site Request Forgery. This issue affects MailPoet: from 5.30.0 through 5.33.0. | ||||
| CVE-2026-57784 | 2026-07-23 | 9.6 Critical | ||
| Unauthenticated Cross Site Request Forgery (CSRF) in Ninja Forms File Uploads Extension <= 3.3.26 versions. | ||||
| CVE-2026-65512 | 2 Melapress, Wordpress | 2 Wp Activity Log, Wordpress | 2026-07-23 | 5.4 Medium |
| Unauthenticated Cross Site Request Forgery (CSRF) in WP Activity Log <= 5.6.4 versions. | ||||
| CVE-2026-65460 | 2 Wordpress, Zarinpal | 2 Wordpress, Zarinpal Gateway | 2026-07-23 | 4.3 Medium |
| Unauthenticated Cross Site Request Forgery (CSRF) in Zarinpal Gateway <= 5.1.0 versions. | ||||
| CVE-2026-24537 | 2026-07-23 | 4.3 Medium | ||
| Unauthenticated Cross Site Request Forgery (CSRF) in WP Accessibility Helper (WAH) <= 0.6.6 versions. | ||||
| CVE-2026-65488 | 2026-07-23 | 7.1 High | ||
| Unauthenticated Cross Site Request Forgery (CSRF) in LA-Studio Element Kit for Elementor <= 1.6.2 versions. | ||||
| CVE-2026-16317 | 1 Aws | 1 S2n-tls | 2026-07-22 | 6.5 Medium |
| Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag. This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write. All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6 | ||||
| CVE-2026-16216 | 1 Geex-arts | 1 Django-jet | 2026-07-21 | 4.3 Medium |
| A weakness has been identified in geex-arts django-jet up to 1.0.8. Affected is an unknown function of the component OAuth Handler. Executing a manipulation can lead to cross-site request forgery. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-63913 | 1 Linux | 1 Linux Kernel | 2026-07-21 | 8.2 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check An unintended behavior in the TCP conntrack state machine allows a connection to be forced into the CLOSE state using an RST packet with an invalid sequence number. Specifically, after a SYN packet is observed, an RST with an invalid SEQ can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of whether the RST corresponds to the expected reply direction. The relevant code path assumes the RST is a response to an outgoing SYN, but does not validate packet direction or ensure that a matching SYN was actually sent in the opposite direction. As a result, a crafted packet sequence consisting of a SYN followed by an invalid-sequence RST can prematurely terminate an active NAT entry. This makes connection teardown easier than intended. So, tighten the state transition logic to ensure that RST-triggered CLOSE transitions only occur when the RST is a valid response to a previously observed SYN in the correct direction. | ||||
| CVE-2026-58482 | 1 Jovancoding | 1 Network-ai | 2026-07-20 | 5.9 Medium |
| Network-AI, a TypeScript/Node.js multi-agent orchestrator, has a shipped, exported, documented feature called `ApprovalInbox` (`lib/approval-inbox.ts`). It is the network surface of the human-in-the-loop Approval Gate, which `ApprovalGate` uses to require explicit human approval for high-risk operations. The HTTP server it exposes has no authentication of any kind and sets `Access-Control-Allow-Origin: *` on every route, including the state-changing `POST /approvals/:id/approve` and `/deny`. As a result, in versions 5.0.0 through 5.12.1, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent. This issue is fixed in v5.12.2. `ApprovalInbox` now accepts a `secret` option. When set, the mutating endpoints `POST /:id/approve` and `POST /:id/deny` require an `Authorization: Bearer <secret>` header, validated in constant time with `crypto.timingSafeEqual`. `startServer()` already binds to `127.0.0.1` by default; operators exposing the inbox on a network must set a secret. | ||||
| CVE-2026-42770 | 1 Openssl | 1 Openssl | 2026-07-20 | 3.7 Low |
| Issue summary: When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the peer key is not properly checked for the subgroup membership. Impact summary: A malicious peer which presents an X9.42 key carrying the victim's p and g parameters, a forged q = r (a small prime factor of the cofactor (p−1)/q_local), and a public value Y of order r can recover the victim's private key after a small number of key exchange attempts. When EVP_PKEY_derive_set_peer() is called with a DHX (X9.42) peer key, the subgroup membership check Y^q ≡ 1 (mod p) is performed using the peer's own q parameter, not the local key's q. The peer's domain parameters are then matched against the domain parameters of the private key, but the value of q is not compared. A malicious peer who presents an X9.42 key carrying the victim's p, g, a forged q = r (a small prime factor of the cofactor), and a public value Y of order r passes all checks. The shared secret then takes only r distinct values, leaking priv mod r. Repeating for each small-prime factor of the cofactor and combining via CRT recovers the full private key (Lim–Lee / small-subgroup-confinement attack). The realistic attack surface is narrow: principally CMP deployments with long-lived RA/CA DHX keys and bespoke enterprise or government applications using X9.42 DHX static keys with interactive protocols and therefore this issue was assigned Low severity. The FIPS modules in 4.0, 3.6, 3.5, 3.4, 3.1.2 and 3.0 are affected by this issue. | ||||
| CVE-2026-64151 | 1 Linux | 1 Linux Kernel | 2026-07-20 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: iommupt: Check for missing PAGE_SIZE in the pgsize_bitmap Sashiko pointed out that the driver could drop PAGE_SIZE from the pgsize_bitmap. That is technically allowed but nothing does it, and such an iommu_domain would not be used with the DMA API today. Still, it is against the design and it is trivial to fix up. Lift the PT_WARN_ON to the if branch and just skip the fast path. | ||||
| CVE-2026-16081 | 1 Sipeed | 1 Picoclaw | 2026-07-20 | 4.3 Medium |
| A vulnerability was determined in Sipeed PicoClaw up to 0.2.9. The affected element is an unknown function of the file web/backend/api/auth.go. Executing a manipulation can lead to cross-site request forgery. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. This patch is called 4b0229351678f479429b8d8b19207757266f246b. Applying a patch is advised to resolve this issue. | ||||
| CVE-2026-53369 | 1 Linux | 1 Linux Kernel | 2026-07-20 | 8.4 High |
| In the Linux kernel, the following vulnerability has been resolved: udf: reject descriptors with oversized CRC length udf_read_tagged() skips CRC verification when descCRCLength + sizeof(struct tag) exceeds the block size. A crafted UDF image can set descCRCLength to an oversized value to bypass CRC validation entirely; the descriptor is then accepted based solely on the 8-bit tag checksum, which is trivially recomputable. Reject such descriptors instead of silently accepting them. A legitimate single-block descriptor should never have a CRC length that exceeds the block. | ||||
| CVE-2026-13156 | 2026-07-20 | 5.4 Medium | ||
| The MailerSend WordPress plugin before 1.0.8 does not perform a nonce check on its configuration-delete action (it verifies the manage_options capability but ignores the nonce), so an attacker can trick a logged-in administrator into visiting a crafted page that wipes the MailerSend WordPress plugin before 1.0.8's SMTP configuration and deactivates the MailerSend WordPress plugin before 1.0.8, breaking the site's email delivery. | ||||
| CVE-2026-49215 | 1 Symfony | 1 Ux | 2026-07-17 | N/A |
| Symfony UX is a JavaScript ecosystem for Symfony. From 2.22.0 until 2.36.0 and 3.1.0, Symfony\UX\LiveComponent\EventListener\LiveComponentSubscriber::isLiveComponentRequest() gates #[LiveAction] invocations on Accept: application/vnd.live-component+html, but the Accept header is CORS-safelisted and cross-origin fetch() can set it without preflight, allowing forged cross-origin #[LiveAction] requests against a victim session when applications use SameSite=None, credentials: 'include', a permissive cookie policy, or a same-origin pivot. This issue is fixed in versions 2.36.0 and 3.1.0. | ||||
| CVE-2026-62236 | 1 Getgrav | 1 Grav | 2026-07-17 | 5.4 Medium |
| grav-plugin-login before 3.8.11 contains a cross-site request forgery (CSRF) vulnerability in the login.regenerate2FASecret frontend task, which regenerates and persists a new TOTP secret for the authenticated session user without any anti-CSRF nonce or Origin/Referer check. Because Grav core dispatches the task from the GET 'task:' URI parameter and the default session cookie is SameSite=Lax, an attacker can lure a logged-in victim to an off-site page that performs a top-level GET navigation, rotating the victim's TOTP secret so their enrolled authenticator no longer matches the server, effectively forcing 2FA re-enrollment. Sites configured with session.samesite: Strict are not affected. | ||||