CVE WatchAug 6, 2026

CVE-2025-13394

The Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) at

CVSS

5.4

Medium

EPSS

—

KEV

—

Exploit Today

0-100

Published: Aug 6, 2026 · Last modified: Aug 6, 2026 · CWE-352

EPSS · 30d

Not enough EPSS history yet.

Technical description

The Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) attacks. Specifically, it utilizes the HTTP GET method for these operations, and while the SameSite=Lax cookie attribute is employed for mitigation, this mechanism is bypassed as it permits cookies to be sent with cross-origin top-level navigation requests, including GET requests. This allows an attacker to trick an authenticated user's browser into unknowingly executing unintended actions. An attacker can exploit this vulnerability to perform unauthorized state-altering requests on behalf of authenticated users. This could lead to consequences such as data modification, account changes, or other actions that could result in data compromise or loss of user control over their account. However, this attack is only feasible if the Carbon console and related services are exposed to the public internet, which is not recommended according to WSO2's security guidelines.

Official references

security.docs.wso2.comhttps://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4800/

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-666866.5 MED

—

———Unauthenticated Cross Site Request Forgery (CSRF) in Plugins Garbage Collector (Database Cleanup) <= 0.14 versions.8h CVE-2026-666814.3 MED

—

———Unauthenticated Cross Site Request Forgery (CSRF) in Theme My Login <= 7.1.14 versions.7h CVE-2026-281727.1 HIG

—

———Unauthenticated Cross Site Request Forgery (CSRF) in Tracking Code Manager <= 2.6.0 versions.8h CVE-2026-705564.3 MED

—

———Hubzilla 11.2.1 contains a cross-site request forgery vulnerability in the OAuth2 /authorize endpoint handled by Zotlabs\Module\Authorize::post() that allows unauthenticated attackers to register arbitrary OAuth2 applications under an authenticated user's account by submitting a cross-origin POST request without CSRF token or Origin/Referer validation. Attackers can craft a malicious HTML form that autosubmits attacker-chosen OAuth2 parameters including client_id, client_secret, redirect_uri, and scope to silently register a persistent OAuth2 application, enabling interception of future OAuth2 authorization codes when the victim later authenticates against the attacker-controlled client.8h CVE-2026-143135.3 MED

—

——0PeproDev WooCommerce Receipt Uploader (PeproDev WooCommerce Receipt Uploader WordPress plugin through 2.8.0 slug: pepro-bacs-receipt-upload-for-woocommerce), all versions up to and including 2.8.0 (latest on wordpress.org; no fixed version available at the time of writing), is vulnerable to unauthenticated missing-authorization / IDOR write. Requires WooCommerce.8h CVE-2026-66885—

—

——0Cross-Site Request Forgery (CSRF) vulnerability in livebook-dev livebook allows an attacker to authenticate a victim's browser session under the attacker's own Livebook Teams identity. When Livebook is configured to use Livebook Teams for identity, Livebook.ZTA.LivebookTeams.handle_request/4 in lib/livebook/zta/livebook_teams.ex handles the OAuth-style callback carrying a teams_identity marker and a code parameter. The clause exchanges that code for an access token and writes the token into the browser session without verifying any value that ties the callback to the browser session that started the login. No state or nonce is generated when the flow is initiated: Livebook.Teams.Requests.create_auth_request/1 in lib/livebook/teams/requests.ex sends an empty request body, so no per-attempt value is ever registered, and the callback clause has nothing to compare against. An attacker who holds membership in the same Livebook Teams organisation as the target instance can therefore begin the login flow themselves, retain the resulting authorization code without redeeming it, and induce a victim to open a crafted URL carrying that code. The victim's browser completes the exchange and the resulting session is bound to the attacker's identity rather than the victim's. The victim is not required to hold any particular privilege, and no credential belonging to the victim is involved. The vulnerability does not allow the attacker to authenticate as the victim. The consequence is that a user believes they are working in their own authenticated session while they are in fact operating as another identity. Work performed in that session is attributed to the attacker's account, and secrets, uploaded data, or notebook results the victim produces are exposed to the attacker rather than kept in the victim's own account. The authorization code must be redeemed within a short window after the login flow begins, which constrains the timing of the attack but not its feasibility. This issue affects livebook: from 0.15.0 before 0.18.7 and from 0.19.0 before 0.19.9.8h