CVE-2025-34291

What it actually does

The vulnerability chains two web authentication/session-control weaknesses: permissive cross-origin resource sharing that allows credentialed requests from attacker-controlled origins, and a refresh-token cookie set with SameSite=None. If an authenticated user visits a malicious page, the browser can be induced to send the victim’s refresh-token cookie to the vulnerable application’s refresh endpoint. Because the vulnerable CORS behavior permits the malicious origin to read the response, the attacker can obtain valid access and refresh tokens for the victim account. Those tokens can then be used against authenticated APIs, including functionality capable of executing code, resulting in authenticated account takeover and remote code execution with the privileges of the application process.

Why it matters to the business

Successful exploitation can allow an attacker to take over user sessions, access or modify application data, steal secrets available to the application, and execute arbitrary commands on the underlying system. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has a high EPSS likelihood, exposed systems should be treated as high-priority remediation targets. The CISA remediation due date is 2026-06-04. Although ransomware use is not currently indicated, full system compromise can still lead to service disruption, data theft, lateral movement, and deployment-pipeline or workload compromise where affected packages are used.

How an attack unfolds

An attacker first prepares a malicious website, phishing lure, poisoned search result, or fake verification page designed to be opened by a user who is already authenticated to the vulnerable application. Campaign context associated with this issue includes ClickFix and FakeCaptcha-style poisoning, where users are socially engineered into visiting attacker-controlled pages. When the victim’s browser loads the page, attacker JavaScript sends a cross-origin credentialed request to the application’s token refresh endpoint. Due to the vulnerable CORS and cookie configuration, the browser includes the refresh-token cookie and allows the attacker-controlled page to read the returned token response. The attacker extracts fresh access_token and refresh_token values, uses them to call authenticated APIs as the victim, and then invokes built-in code-execution capabilities to run arbitrary commands. From there, the attacker can establish persistence, access secrets, modify flows or application configuration, and pivot to connected systems reachable from the compromised host.

How to fix it

Upgrade affected packages to fixed versions immediately. The provided fixed versions are: argocd-2.14 (MinimOS) fixed in 2.14.20-r1; argocd-2.14-repo-server (MinimOS) fixed in 2.14.20-r1; argocd-2.14-compat (MinimOS) fixed in 2.14.20-r1. For Langflow deployments, upgrade to a vendor-fixed release newer than the affected versions up to and including 1.6.9. As compensating controls, restrict CORS to an explicit allowlist of trusted origins, do not use wildcard origins with credentialed requests, set refresh-token cookies to SameSite=Lax or SameSite=Strict unless cross-site behavior is strictly required, ensure Secure and HttpOnly cookie attributes are set, rotate signing keys or invalidate all existing refresh tokens after patching, and restrict access to code-execution features to trusted administrators. If immediate upgrade is not possible, place the service behind an authentication-aware reverse proxy or VPN, block untrusted origins at the edge, and disable or tightly restrict code-execution functionality where supported.

How to confirm the fix worked

Confirm the installed package versions are at or above the fixed releases, specifically 2.14.20-r1 for the listed MinimOS packages. Validate that vulnerable versions up to and including Langflow 1.6.9 are no longer deployed. Test CORS behavior by sending requests with an untrusted Origin header and confirming the response does not allow that origin together with Access-Control-Allow-Credentials: true. Confirm token refresh cookies are not set with SameSite=None unless explicitly required and protected by strict origin controls. Verify that existing refresh tokens were invalidated or rotated after remediation. Review application configuration, reverse-proxy rules, and response headers to ensure credentialed cross-origin token refreshes are blocked. Attempt a controlled negative test from an untrusted origin to the refresh endpoint and confirm the browser cannot read a token response.

Typical attack path

1. Identify an internet-accessible or internally reachable vulnerable application instance.
2. Deliver a malicious webpage through phishing, SEO poisoning, ClickFix/FakeCaptcha-style lures, compromised websites, or other social-engineering channels.
3. Wait for an authenticated user to visit the attacker-controlled page.
4. Use browser-based JavaScript to send a credentialed cross-origin request to the vulnerable refresh endpoint.
5. Read the token refresh response from the malicious origin and extract fresh access_token and refresh_token values.
6. Use the stolen bearer token to access authenticated API endpoints as the victim user.
7. Invoke application functionality that can execute code or commands.
8. Run arbitrary code on the host, collect secrets and application data, and expand access to adjacent systems if possible.

How to detect it

Review web server, reverse-proxy, application, authentication, and API audit logs for cross-origin token refreshes and follow-on authenticated activity. Focus on requests to token refresh functionality that include unexpected Origin or Referer values, especially domains associated with phishing, fake CAPTCHA, or ClickFix-style pages. Look for refresh requests followed shortly by bearer-token use from a different IP address, ASN, geography, user agent, or automation framework than the victim’s normal session. Examine application audit logs for unusual creation, modification, or execution of flows, components, tools, or code-execution features after token refresh events. On hosts, inspect process creation telemetry for shell, scripting, package-manager, network-download, or reverse-shell processes spawned by the application runtime. Search for suspicious outbound connections initiated by the application process after authenticated API activity. Because the primary artifact may be stolen tokens rather than failed logins, absence of authentication failures does not rule out compromise. If exploitation is suspected, correlate browser-access logs, IdP/session logs, reverse-proxy headers, application API logs, EDR process trees, and outbound network telemetry across the suspected exposure window.

• Origin: http://
• Origin: https://
• Access-Control-Allow-Credentials: true
• Access-Control-Allow-Origin: *
• SameSite=None
• refresh_token=
• access_token
• Authorization: Bearer
• /refresh
• /api/v1/refresh
• ClickFix
• FakeCaptcha
• curl
• wget
• bash -c
• sh -c
• python -c
• python3 -c
• nc -e
• ncat -e
• /bin/sh
• /bin/bash

What your security team should do

• Treat internet-facing affected deployments as urgent because exploitation is active in the wild and the issue is in CISA KEV.
• Upgrade all listed affected packages to 2.14.20-r1 or later and upgrade Langflow deployments beyond affected versions up to and including 1.6.9.
• Invalidate all active sessions and refresh tokens after patching to remove tokens that may have been stolen before remediation.
• Hunt for suspicious token refresh activity involving unusual Origin or Referer headers, especially around phishing, ClickFix, or FakeCaptcha campaign exposure windows.
• Review code-execution, flow-execution, and administrative API logs for commands or actions performed by accounts that did not normally use those features.
• Restrict access to administrative and code-execution endpoints using network controls, SSO policy, MFA, and least privilege.
• Add monitoring for credentialed CORS responses, suspicious bearer-token use from new IP addresses, and child processes spawned by the application runtime.
• If compromise is suspected, preserve logs, rotate application secrets, rotate credentials accessible to the service, and rebuild affected hosts from trusted images.