CVE-2026-25650: MCP Salesforce Connector Exposes OAuth Tokens, Enabling Silent Salesforce Account Takeover

CVE-2026-25650 Summary

Name: MCP-Salesforce Connector – Salesforce OAuth Token Disclosure
CVE: CVE-2026-25650
Severity: High (Token confidentiality compromise)
CVSS: Mid-to-High severity depending on scoring model (impact on confidentiality significant)
Exploitability: Remote, unauthenticated access to vulnerable pattern
Exploit Availability: No confirmed public proof-of-concept code available at this time

At its core, this vulnerability allowed attackers to cause the MCP-Salesforce Connector to return sensitive Salesforce OAuth tokens back in API responses by requesting attributes the code should not have exposed.

Affected Software and Versions

This issue affects MCP-Salesforce Connector versions prior to v0.1.10. The connector is used to bridge the Model Context Protocol (MCP) with Salesforce APIs, enabling applications to interact with Salesforce through a standardized service.

If your environment runs MCP-Salesforce Connector and it is not updated to v0.1.10 or later, it is vulnerable to unauthorized credential disclosure.

The only official, complete fix is included in v0.1.10 — upgrading to that version eliminates the arbitrary attribute leak.

Official patch / upgrade link:
➡️ https://github.com/smn2gnt/MCP-Salesforce/releases/tag/v0.1.10

Technical Description of the Vulnerability

The core of the problem was a missing validation check for attribute requests. The connector code accepted an attribute name via API parameters and then tried to resolve that attribute on internal Salesforce client objects.

Because there was no whitelist or validation of acceptable names, attackers could request internal attributes, including ones that held the active Salesforce OAuth bearer token. That token is used by the connector to authenticate calls to Salesforce — exposing it is equivalent to handing over valid credentials.

When a crafted request was made with certain values in the request, the server would include in its JSON response object internal fields that were not intended for external consumption, and these were used to leak the token.

Once an attacker obtained the OAuth bearer token, it can be reused to make Salesforce API calls as the connector identity until it expires or is revoked.

How Exploitation Could Work

Here’s how an attacker could exploit this in practice:

Reconnaissance: Attacker identifies a publicly reachable or internal endpoint running an MCP-Salesforce Connector instance.
Crafted Request: Attacker sends requests to the vulnerable API path with a manipulated input parameter (such as object_name or similar) that points to internal object attributes rather than legitimate business data.
Token Disclosure: The server responds with an object representation that includes fields holding the Salesforce OAuth bearer token.
Session Reuse: The attacker uses the stolen token in standard Salesforce API calls (Authorization: Bearer <token>) to read or manipulate Salesforce data.
Persistence & Expansion: Using the valid token, an attacker can maintain persistent unauthorized access until the token is revoked.

There has been no published public exploit script or proof-of-concept code for this specific issue at the time of writing, but the pattern of arbitrary attribute access plus credential leaks is simple enough that exploit code can be developed by attackers with basic HTTP tooling or scripts.

Detection and Logging Indicators

Detection of an exploitation attempt must focus on anomalous requests to the connector API and unexpected token return patterns in logs.

Log Sources to Monitor

The following log sources are most useful:

Application access logs (requests received by MCP-Salesforce endpoints, including query strings and params)
Application error and response logs (capture response bodies where tokens may have been leaked)
Web server / proxy logs (nginx, Apache, load balancer)
Salesforce connected app logs / audit trails (unexpected API calls using connector identity)
Network IDS / WAF logs (HTTP requests with unusual parameter patterns)

Indicators of Attempted Exploitation

Repeated requests to the connector API with unusual values in parameters typically meant to specify object or field names
Requests containing substrings like __, token, auth, secret, or credentials in API parameters
Unexpected outbound API traffic from the connector to Salesforce shortly after suspicious requests
Unexpected API sessions originating from non-trusted IPs using the connector’s client identity
Application logs containing long opaque strings in responses, which resemble bearer tokens

Rules for Detection

Below are search queries and log-rule ideas you can use in SIEM, logs, or monitoring tools. These are illustrative, so field names must be adapted to your specific environment.

Web Access Logs

ELK/KQL Style:

(http.request.uri.query.keyword: "*object_name*") AND 
(
  http.request.uri.query.keyword: "*__*" OR
  http.request.uri.query.keyword: "*token*" OR
  http.request.uri.query.keyword: "*auth*"
)

This rule flags requests that include suspicious values for attributes used by the connector, such as __, token, or auth.

Response Body Token Detection

(response.body: /Bearer\s+[A-Za-z0-9\-_\.]+/)

Searches for response bodies that include patterns resembling Bearer tokens in logs — useful for identifying leaks where tokens appear where they shouldn’t.

Salesforce API Call Anomaly

eventType: "RestApi"
AND user: "<connector_client_identity>"
AND (method: "GET" OR method: "POST")
AND NOT sourceIP IN trustedRanges

Finds unusual Salesforce API calls initiated by the connector identity (after the initial leak), especially from unfamiliar source IPs.

Practical Detection Tips

Focus first on unexpected use of API parameters on the MCP connector service.
Ensure logs are configured to capture full request URIs and parameters.
Do not log sensitive data in application logs — but if logs already contain such data, use parsing to flag presence of tokens.
Correlate web access logs with Salesforce connected-app logs to see if successful API calls follow suspicious attribute access attempts.

Mitigation and Response

Immediate Steps

Upgrade all MCP-Salesforce Connector instances to v0.1.10 or later. Official patch link:
➤ https://github.com/smn2gnt/MCP-Salesforce/releases/tag/v0.1.10
Rotate and revoke all Salesforce OAuth tokens / connected app credentials used by the affected connector instances. Tokens exposed may already have been harvested by attackers if exploited.
Audit application logs for historical indicators of attribute misuse.
Apply WAF / WSG rules to reject requests with suspicious parameters (e.g., containing __ or known bad substrings) before they reach the connector.

Longer Term Steps

Restrict network access to the connector service (private networks, allowlists)
Implement parameter validation and allow-listing in application code
Centralize token management and apply frequent rotation
Add anomaly detection on API usage (identify spikes or unusual API patterns)

Proof-of-Concept and Exploit Availability

As of this writing, no verified public proof-of-concept exploit code exists in public repositories or advisories for this specific CVE. That said:

The vulnerability involves trivial attribute injection and token leak.
Skilled attackers could write a PoC using basic HTTP requests and response inspection.
Detection post-exploit is more valuable because successful exploitation generates legitimate credentials that hide behind normal API trust.

All detection, logging, and monitoring guidance above is aimed at catching both attempts and successful exploitation.

Final Takeaway

CVE-2026-25650 was a vulnerability in MCP-Salesforce Connector that allowed remote attackers to force the connector to return Salesforce OAuth tokens through insecure attribute access. The risk is that stolen tokens act as valid credentials for Salesforce API access.

Your highest priority mitigation is:

Upgrade to MCP-Salesforce Connector v0.1.10

Followed by:

revoking and rotating any exposed tokens
adding monitoring and SIEM rules for suspicious parameter use
correlating web access logs with Salesforce API usage

Properly implemented logging and monitoring can help catch both the exploitation attempts and any misuse of tokens after compromise.