| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Landing Page Builder – Coming Soon page, Maintenance Mode, Lead Page, WordPress Landing Pages plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.5.3.6. This is due to missing or incorrect nonce validation on the ulpb_admin_ajax function. This makes it possible for unauthenticated attackers to create, update, retitle, or change the post status, slug, and type of arbitrary posts and write ULPB_DATA post meta via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. This attack requires the victim to hold an editor-level or administrator session, as the wp_ajax_ulpb_admin_data action enforces a capability check that the forged request must satisfy by inheriting the logged-in user's session cookies. |
| Joomla Extension - joomdonation.com - User enumeration in Events Booking < 5.8.0 - The Joomla extension Events Booking prior version 5.8.0 had an frontend file upload endpoint that lacked CSRF protection. |
| The W3SC Elementor to Zoho CRM plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 2.2.0. This is due to missing or incorrect nonce validation on the storeInfo function. This makes it possible for unauthenticated attackers to modify the plugin's Zoho CRM integration settings, replacing the configured data center, client ID, client secret, and user email credentials with attacker-controlled values via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. |
| dataCycle is a data management system for centrally storing, managing, searching, finding, and distributing data. In dataCycle-CORE, the module handling core processing and framework rules, before and including version 25.07.3, the application exposes server-side state changes through `GET` routes. Because browsers automatically send cookies on same-site top-level navigation and Rails does not apply CSRF protections to `GET`, an attacker can force a logged-in victim to modify application state by embedding a link, image, iframe, or redirect to one of these endpoints. This was confirmed on the target with a normal `Standard` account: a cross-site-style `GET` to `watch_lists/:id/add_item?thing_id=...` inserted content into a watch list with no CSRF token. Additional `GET` mutation routes exist in the codebase, including user impersonation for authorized admins and cache or
translation state changes. This is patched in version 26.06.08. |
| djangoSIGE through 1.10 (commit a6fe7e8) contains a cross-site request forgery vulnerability that allows unauthenticated attackers to cancel sales or purchase orders on behalf of authenticated users by exploiting order-cancellation logic implemented inside HTTP GET method handlers in CancelarOrcamentoVendaView, CancelarPedidoVendaView, CancelarOrcamentoCompraView, and CancelarPedidoCompraView. Attackers can lure an authenticated victim with change_orcamentovenda or equivalent permissions to a page containing a cross-origin reference such as an img tag pointing to the cancellation endpoint, bypassing CSRF token validation entirely since Django's CsrfViewMiddleware only enforces CSRF checks on unsafe HTTP methods. |
| Unauthenticated Cross Site Request Forgery (CSRF) in ApusListing <= 1.2.63 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in GiveWP <= 4.16.3 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Avada Core <= 5.15.6 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in افزونه حمل و نقل ووکامرس (پست پیشتاز و سفارشی، پیک موتوری) <= 4.4.5 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Kwayy HTML Sitemap <= 4.0 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Popup for CF7 with Sweet Alert <= 1.6.5 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Simple Link Directory Pro <= 15.0.8 versions. |
| 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. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Ninja Forms File Uploads Extension <= 3.3.26 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in WP Activity Log <= 5.6.4 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in Zarinpal Gateway <= 5.1.0 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in WP Accessibility Helper (WAH) <= 0.6.6 versions. |
| Unauthenticated Cross Site Request Forgery (CSRF) in LA-Studio Element Kit for Elementor <= 1.6.2 versions. |
| 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. |
| 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. |