{
  "version": 1,
  "generatedAt": "2026-10-19T21:16:21.340Z",
  "license": "CC BY 4.0",
  "source": "https://letsauth.eu/breaches/",
  "vulnerabilities": [
    {
      "id": "salesloft-drift-oauth-tokens",
      "title": "Stolen OAuth tokens of an AI chat agent used to export Salesforce data",
      "class": "token-theft",
      "summary": "Salesloft's Drift chat agent held OAuth access and refresh tokens for its customers' Salesforce instances and other integrations. Between 8 and 18 August 2025 an actor who had obtained those tokens used them to run queries and bulk exports against hundreds of instances, then searched the exports for cloud keys and passwords. The tokens were accepted from wherever they were presented, so a credential issued to one agent vendor became a key to every tenant that had connected it. Salesloft and Salesforce revoked all Drift tokens on 20 August. Short-lived, sender-constrained tokens and a narrow scope per integration limit what a stolen token can do; this incident is why those controls exist.\n",
      "disclosed": "2025-08-26",
      "fixed": "All Drift access and refresh tokens revoked on 20 August 2025; the integration removed from the Salesforce AppExchange",
      "affects": [
        "Salesloft Drift integrations with Salesforce and, for a few accounts, Google Workspace",
        "More than 700 organizations that had connected Drift"
      ],
      "features": [],
      "sources": [
        "https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift",
        "https://blog.cloudflare.com/response-to-salesloft-drift-incident/",
        "https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/"
      ],
      "replay": null
    },
    {
      "id": "cve-2025-6514",
      "title": "Authorization endpoint from untrusted metadata run as a command",
      "class": "untrusted-metadata",
      "summary": "mcp-remote, the proxy that lets desktop MCP clients reach remote servers, discovers the authorization server from the MCP server it was pointed at and hands the metadata's authorization_endpoint to the operating system to open in a browser. A hostile or hijacked server could answer with a value that was not an https URL, and the proxy passed it on unchecked, which on the client machine led to command execution. Every endpoint an authorization server advertises must be https, and a client must refuse metadata that says otherwise before it acts on it.\n",
      "disclosed": "2025-07-09",
      "fixed": "mcp-remote 0.1.16",
      "affects": [
        "mcp-remote 0.0.5 to 0.1.15",
        "Desktop MCP clients that connect to an untrusted or plain-http MCP server through it"
      ],
      "features": [
        "mcp.as.https"
      ],
      "scenario": "mcp-authorization",
      "sources": [
        "https://nvd.nist.gov/vuln/detail/CVE-2025-6514",
        "https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/",
        "https://github.com/geelen/mcp-remote/commit/607b226a356cb61a239ffaba2fb3db1c9dea4bac"
      ],
      "replay": "/explorer/mcp-authorization/endpoint-from-untrusted-metadata/"
    },
    {
      "id": "asana-mcp-cross-tenant",
      "title": "One tenant's MCP server answered with another tenant's data",
      "class": "tenant-isolation",
      "summary": "Asana's MCP server, released on 1 May 2025, carried a logic flaw that could return data from one customer's domain to MCP users of other customers, within the kinds of objects the asking user was allowed to see. Asana found it on 4 June, took the server offline, fixed the code, reset every connection and notified about a thousand customers; it reported no evidence of malicious use. The server authenticated who was asking but did not bind every answer to that caller's tenant, which is the check a multi-tenant resource server owes on every request, not only at sign-in.\n",
      "disclosed": "2025-06-16",
      "fixed": "Server offline from 5 to 17 June 2025; code fixed and all MCP connections reset",
      "affects": [
        "Asana MCP server (beta), 1 May to 4 June 2025"
      ],
      "features": [],
      "sources": [
        "https://www.upguard.com/blog/asana-discloses-data-exposure-bug-in-mcp-server",
        "https://www.bleepingcomputer.com/news/security/asana-warns-mcp-ai-feature-exposed-customer-data-to-other-orgs/",
        "https://www.theregister.com/security/2025/06/18/asana-mcp-server-back-online-after-plugging-a-data-leak-hole/"
      ],
      "replay": null
    },
    {
      "id": "cve-2025-4143",
      "title": "Authorization codes sent to an unchecked redirect URI",
      "class": "redirect-uri",
      "summary": "The OAuth provider library behind many remote MCP servers on Cloudflare Workers checked the redirect URI against the client's registered URIs at the token endpoint, but not at the authorization endpoint. An authorization request could therefore name any redirect URI, and a server that re-approves clients it has seen before would send the authorization code there without asking the person again. Checking the redirect URI where the request arrives, before any consent decision, is the control that was missing.\n",
      "disclosed": "2025-05-01",
      "fixed": "@cloudflare/workers-oauth-provider 0.0.5",
      "affects": [
        "@cloudflare/workers-oauth-provider before 0.0.5",
        "Remote MCP servers built on it whose consent step re-approves known clients"
      ],
      "features": [],
      "scenario": "mcp-authorization",
      "sources": [
        "https://github.com/cloudflare/workers-oauth-provider/security/advisories/GHSA-4pc9-x2fx-p7vj",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-4143",
        "https://github.com/cloudflare/workers-oauth-provider/pull/26"
      ],
      "replay": "/explorer/mcp-authorization/redirect-uri-unchecked/"
    },
    {
      "id": "cve-2025-4144",
      "title": "PKCE verification skipped at the token endpoint",
      "class": "pkce-bypass",
      "summary": "The same library implemented PKCE, which OAuth 2.1 and the MCP specification require, but a token request could be shaped so that the code verifier was never compared with the challenge recorded at authorization. Anyone holding an authorization code could then redeem it without the secret the honest client generated. An authorization server must refuse a token request for a code that was issued with a challenge unless the verifier matches; advertising S256 is not the same as enforcing it.\n",
      "disclosed": "2025-05-01",
      "fixed": "@cloudflare/workers-oauth-provider 0.0.5",
      "affects": [
        "@cloudflare/workers-oauth-provider before 0.0.5",
        "Remote MCP servers built on it"
      ],
      "features": [
        "mcp.as.pkce-s256",
        "mcp.client.pkce"
      ],
      "scenario": "mcp-authorization",
      "sources": [
        "https://github.com/cloudflare/workers-oauth-provider/security/advisories/GHSA-qgp8-v765-qxx9",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-4144",
        "https://github.com/cloudflare/workers-oauth-provider/pull/27"
      ],
      "replay": "/explorer/mcp-authorization/pkce-skipped/"
    }
  ]
}