PHP2Shell and Salesforce: secure your WordPress integration

A compromised WordPress server may hold credentials that can read or change your Salesforce records. If your website sends leads into Salesforce, the PHP2Shell response needs both your hosting owner and your Salesforce admin.

Start by identifying the connection. A public Web-to-Lead form, an authenticated WordPress plugin, and a PHP service behind an Agentforce action have different exposure. Patch the PHP host, check what Salesforce access it holds, and test downstream automation before reopening an affected integration.

The disclosed vulnerabilities, CVE-2026-109618 and CVE-2026-109619, concern PHP. The cited research doesn’t establish a PHP2Shell vulnerability in Salesforce core or Agentforce. Wiz demonstrated code execution and sensitive-memory disclosure in affected PHP deployments. The Salesforce scenarios below are architecture risks to investigate, not reports of a confirmed Salesforce breach.

Identify how WordPress reaches Salesforce

With a basic Web-to-Lead form, the website contains generated HTML that submits lead fields to Salesforce. That form does not, by itself, require a Salesforce OAuth token on the PHP server. Salesforce documents the generated-form setup and reCAPTCHA option.

For that pattern, inspect the website for changed form destinations or injected scripts, then review lead submissions during the exposure window. Check required fields, validation rules, and assignment behavior. reCAPTCHA can reduce automated form abuse; it does not patch PHP or establish that submitted data is trustworthy.

An authenticated plugin or custom PHP integration is different. It may hold an access token, refresh token, client secret, or signing key. Depending on its authorization, those credentials may allow more than creating Leads. Salesforce’s REST API authorization guide explains access through External Client Apps and existing Connected Apps.

Trace any middleware too. If WordPress sends a webhook to another service that calls Salesforce, identify the webhook secret and the receiving service’s permissions. Don’t assume Salesforce credentials live on WordPress merely because the website creates CRM records.

For each connection, record the production org, application, integration user, credential location, and owner. Include PHP endpoints that Salesforce or an Agentforce action calls outbound. The response from a compromised endpoint also deserves review.

Contain exposed Salesforce credentials

If the PHP host may have been compromised, pause its Salesforce integration and coordinate containment with the hosting and incident-response owners. Preserve relevant logs and snapshots before cleanup. Avoid putting replacement credentials onto a host you haven’t recovered.

In Salesforce, inspect the affected application’s OAuth usage. For External Client Apps, Salesforce’s management documentation describes revoking individual tokens, a user’s tokens for an app, or all tokens for that app. Review the corresponding Connected Apps OAuth Usage controls for older integrations.

Revocation and credential replacement solve different problems. Salesforce’s revocation endpoint invalidates an access token, or a refresh token and its associated access tokens. If a client secret or signing key was exposed, address that credential too, so the attacker cannot obtain replacement access.

The client credentials flow doesn’t issue refresh tokens. It obtains access tokens using the application’s credentials and configured integration identity, as Salesforce explains in its integration-user guidance. Identify the actual flow before choosing the response.

Review available authentication and API evidence alongside affected Lead, Contact, or Case changes. Record timestamps and the integration identity so the investigation can connect website events with Salesforce activity. Our OAuth governance guide covers the broader application inventory.

Limit what the integration and its flows can do

Salesforce recommends a dedicated user per integration and permission sets limited to the required data and operations. Apply that to your website connector. Start with the Lead fields it needs to create, and justify any additional read or update access separately.

An OAuth scope permitting API access doesn’t replace object, field, and record-access controls. Review the integration user’s effective permissions, including inherited permission sets. Using a shared administrator account makes both containment and attribution harder.

Then inspect what happens after a record arrives. Salesforce documents that record-triggered flows run in system context without sharing by default. A narrow intake user’s permissions don’t, by themselves, describe everything a downstream flow can do.

For example, a website-created Lead might trigger account matching or a custom notification process. Review which fields control those decisions and which records the automation can change. Validate public input before letting it determine privileged operations, and review the execution context of any invoked Apex.

Patch the PHP service behind the connector

The first fixed upstream releases are:

• PHP 8.2: 8.2.35
• PHP 8.3: 8.3.36
• PHP 8.4: 8.4.27
• PHP 8.5: 8.5.12

PHP lists those versions in its security advisory. Ask the host for the patched package serving your specific domain, coverage for both CVEs, and confirmation that affected workers were restarted or replaced. A distribution backport may retain an older upstream version number; request the vendor’s security notice.

For WordPress, check Tools → Site Health → Info → Server. Confirm the web runtime with the provider rather than relying only on php -v over SSH. PHP’s configuration documentation explains how runtime interfaces can load different configurations.

On your own infrastructure, install the fixed packages and restart the affected PHP-FPM or Apache processes. Replace running containers with patched images. Include every instance behind a load balancer and any publicly reachable staging copy of the Salesforce connector.

PHP’s release announcement covers older branches and partial mitigations. Cloudflare’s WAF protection can help while patching, but it does not replace the runtime update. Updating the WordPress Salesforce plugin alone also leaves the underlying PHP issue unresolved.

Review what Agentforce does with website content

If your Agentforce configuration retrieves website-originated Lead or Case descriptions, treat that text as untrusted input. A record’s presence in Salesforce doesn’t establish that its contents came from a verified customer or an approved internal instruction.

That is a separate prompt-injection and authorization concern. Patching PHP closes the runtime vulnerability; it doesn’t make public form submissions trustworthy. A newly created Lead also doesn’t automatically trigger Agentforce: inspect the automation and actions configured in your org.

Salesforce’s custom-action security guidance distinguishes the invoking user’s identity for employee-facing agents from the agent identity for service agents. It also requires appropriate access checks in the Flow or Apex implementing an action. Review those checks alongside the intake integration user.

In a sandbox, test an ordinary enquiry and an enquiry containing instructions to disclose unrelated customer records. The latter should remain customer-supplied text, without authority to expand access. Verify customer identity before private service actions, restrict the records those actions can reach, and require confirmation for sensitive changes where appropriate.

Resume intake after testing the complete path

Use a synthetic enquiry with an identifier you can trace from the form to Salesforce. Verify these outcomes before restoring a paused connection:

1. The request creates the intended Lead with the expected fields and owner.
2. Invalid submissions are rejected, and retries follow your intended duplicate-handling behavior.
3. The connector can perform its required job, while operations outside its permissions fail.
4. Downstream Flow and Agentforce actions access only the intended records and perform only approved operations.
5. Revoked credentials fail, and the recovered connector works with its replacement credentials.

Keep real customer data out of those tests. If an investigation found unauthorized records or changes, review them separately; restoring the connection doesn’t resolve that history. WordPress’s recovery guidance is relevant to the website cleanup, alongside the Salesforce investigation.

Close the work with evidence from both owners: the hosting owner confirms the patched runtime, and the Salesforce owner confirms credential handling and the tested business flow. That gives you a defensible answer when someone asks whether the website-to-CRM connection is ready to run again.