Fix Guides

PHP2Shell and Your Salesforce Credentials: Org-Side Triage and Rotation Order

Updated 2026-10-30

What Happened

• 21 October 2026: the PHP project released PHP 8.5.12, with matching security releases 8.4.27, 8.3.36 and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619. NVD describes both as remote code execution through request memory that is left in an unsafe state, and scores each 9.2 on CVSS v4.0.
• 21 October 2026: Salesforce Trust published general message 20000267, stating that it has no evidence of exploitation affecting Salesforce or customer data. Read the message itself for its exact wording and any updates.

We have not verified exploitation in the wild from a primary source, and this page does not claim it. The reason to act is simpler: a published unauthenticated remote code execution flaw on a server that holds your Salesforce secrets means those secrets should be treated as readable until the host is patched and the secrets are replaced.

Why This Is an Org Problem, Not a Platform Problem

Salesforce itself does not run your WordPress plugin or your PHP sync script. Those run on your own or a vendor's hosting, and they hold the credentials that let them log in to your org: in plugin settings, configuration files, environment variables, or the legacy Force.com Toolkit for PHP. Anyone who can run code on that host can read them and then log in to Salesforce as the integration, from anywhere, with exactly the access the integration user has.

How to Find Out Whether Your Org Is Exposed

1. 1. List every integration user. Find the users your integrations run as: API-only users, middleware service accounts, and the user behind each connected app. Note which of them have a client hosted on PHP (a WordPress site, a custom PHP script, a legacy toolkit).
2. 2. Read LoginHistory for those users. Query LoginHistory for each integration user and look at Application, SourceIp, LoginType, Status and LoginTime. You are looking for logins from addresses that are not your known hosts, from an Application you do not recognise, or at times when your integration does not run.
3. 3. Check the Setup Audit Trail. Review Setup Audit Trail for changes made by those users or around the same dates: new connected apps, changed OAuth policies, permission set assignments, new users. An attacker who held a working credential might use it to make themselves a second way in.
4. 4. Find connected apps with tokens issued to PHP-hosted clients. In Setup, open OAuth Connected Apps Usage and each connected app's issued tokens (the OauthToken object lists them with user, app, last used and use count). Match each app to the system that holds its consumer secret. Any app whose secret sits on a PHP host is in scope.
5. 5. Find Named Credentials and external services pointing at PHP hosts. Review Named Credentials, External Credentials and external services for endpoints on hosts you know run PHP. These hold credentials in the other direction (Salesforce calling the PHP host), so they matter if the host is a place an attacker could pivot from or to.

What to Rotate, and in Which Order

The order matters: replacing secrets before the host is patched just hands the new ones to the same weakness.

1. 1. Patch the PHP host. Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or later on your branch), and restart PHP-FPM or the web server so the new binary is running. If you cannot patch yet, take the host's Salesforce integration offline rather than rotating onto it.
2. 2. Rotate the connected app consumer secret. In the connected app or external client app, generate a new consumer secret and put it only on the patched host.
3. 3. Revoke refresh tokens and sessions. Revoke the tokens issued to that app from OAuth Connected Apps Usage, or revoke the integration user's sessions, so anything copied from the old host stops working.
4. 4. Reset the integration user's password or replace the JWT certificate. For a password-based integration, reset the password and security token. For JWT bearer flow, upload a new certificate to the connected app, generate a new key pair on the patched host and remove the old certificate.
5. 5. Re-authorize the integration. Authorize the integration again with the new secret and key, one connected app at a time, and note the time of each so you can match it to login rows afterwards.

How to Confirm

1. 1. Watch new login rows. After re-authorizing, LoginHistory for the integration user should show logins only from the patched host's IP addresses and the expected Application. Anything else is a sign an old credential still works somewhere.
2. 2. Check old tokens are gone. OAuth Connected Apps Usage should show no token issued before the rotation time for that app.
3. 3. Check the integration still runs. Run one real sync end to end and compare record counts or last-modified timestamps, so a silent auth failure does not look like a quiet system.

Keep Watching Integration Access

Wrenk runs scheduled checks on connected-app and permission exposure, and proposes fixes plan-first with a rollback. Run the free health check to see which integration users and connected apps in your org carry the broadest access.

Related Guides

• Frozen integration user — recover when Salesforce freezes an integration user.
• OAuth token refresh — when a connection needs to re-authenticate.
• SaaS security audit — review access across the org.

FAQ