What happened this week

On 21st October 2026 the team behind PHP, the programming language that runs WordPress, Drupal, Joomla and most charity websites, released emergency fixes for two serious flaws, known together as PHP2Shell. They let an attacker take control of any website running an unfixed version, with no password, and every version released since 2012 is affected. Attacks were seen before the fix was public, and the National Cyber Security Centre has said any site that cannot be fixed quickly should be taken offline.

If your site is on managed hosting it has probably been fixed already. If an agency looks after it, or it sits on shared hosting, ask who updates the software and when they did it. Updating is the only fix, and a site that was updated late should be checked for anything the attacker left behind.

This week it was PHP. Next time it will be a plugin, a stolen password or a bad theme. We do not manage websites for anyone, so our interest is not the break-in itself. It is what a broken-into website can reach.

This was not a Salesforce breach

Salesforce said so on its Trust site on 21st October: it is aware of and monitoring the flaws and has no evidence of them affecting Salesforce or customer data. Salesforce does not run on PHP, and the platform is not the weak point.

The connection is. Most charity websites send something into Salesforce: a donation, an enquiry, a volunteer sign-up, a newsletter subscription. To do that, the website holds a key to your Salesforce org. It does not matter whether that key was set up by typing in a username and password or by clicking Connect to Salesforce and approving a pop-up; either way the website now acts as a Salesforce user. If the website is broken into, the key goes with it, and the attacker can do whatever that user is allowed to do.

What a hacked website can do

That last sentence is the whole story. Here are the three ways it plays out.

The break-in is the same in all three. Only what the website is allowed to do changes.

If the website holds no key at all, because the form posts through Salesforce’s Web-to-Lead feature or a hosted forms or donation platform, an attacker gets spam and a tampered form, and could capture what people type into it, but no access to the supporter data in your Salesforce.

If the website holds a key for a user that can only add the records the form creates and read as little as possible, the attacker can add bad records and see very little. The damage is a clean-up job.

If the website acts as a real member of staff, or worse as a System Administrator, the attacker has your whole org: every supporter, every donation, every case note, downloadable from anywhere in the world. This third setup is the easiest to end up with, because it is the quickest way to make a plugin work.

Six habits for any charity

1. Know who looks after your website, and ask them.

   Who updates the software behind it, how quickly, and did they do it this week? Write the answer down.

   
   

2. Know what your website connects as.

   Every connection to Salesforce, whether a form plugin, a donation platform or a piece of middleware, acts as a Salesforce user. Find out which user, and what it can do. If the answer is a staff member’s account or an administrator, that is the first thing to fix.

   
   

3. Give the website nothing it does not need.

   This is the habit that limits the damage; the others reduce the odds. Where you can, use a route that leaves no key on the website at all: Web-to-Lead forms, a hosted forms tool or a hosted donation platform.

   Hosted platforms still hold their own key to your Salesforce on their servers, so the same rules apply to them: their own user, as little access as possible, and a place on your audit list. A form built inside Salesforce itself avoids a key on the website too, but it runs as a public guest user that needs the same care; over-permissioned guest users are a well-known source of charity data leaks.

   Where a key is needed, give it its own user (most Salesforce editions include free integration-only users that cannot sign in to the screen) that can add only the records the form creates and read as little as possible.

   
   

4. Tie that user to your website, and know what that does and does not do.

   Salesforce can refuse the user from any location other than your web server’s (your Salesforce partner will know this as the Login IP Ranges setting on the user’s profile, IP meaning Internet Protocol address; the org-wide trusted ranges block nothing). That makes a copied key useless anywhere else, which matters because Salesforce does not ask automated connections for a second factor the way it asks people.

   It does not help when the attacker controls the web server itself, as with this week’s flaw, because they can use the key from the server’s own address, and some shared hosting has no fixed address to tie to. Habit 3 is the protection in that case.

   
   

5. Audit your connections, regularly.

   There is no single screen that lists every connection to your org. Connected Apps have a usage page in Setup; the newer External Client Apps are listed separately in their own manager; and older plugins that sign in with a username, password and security token show up only in that user’s sign-in history. Check all three, or ask your Salesforce partner to list every connection for you.

   At least once a quarter, and after any incident: remove anything nobody recognises, tighten anything with more access than its job needs, and keep the list. This is the habit that turns a nasty surprise into a routine.

   
   

6. Know the ten-minute response.

   Any Salesforce administrator can revoke a connection’s tokens and end its active sessions, change its key, and freeze its user; freezing alone leaves an existing session working. Then check its sign-in history. If in doubt, do all of it; a form being down for ten minutes is cheap.

We have been certified to ISO 27001 since 2017, and much of what it asks for is this kind of plain housekeeping, done on a schedule and written down. You do not need the certificate to borrow the framework, and most charities would be better protected for doing so.

If you think your website was reached

Assume any PHP site that was not updated promptly after the fix came out on 21st October may have been reached, and as attacks were seen before the fix was public, even a quickly updated site is worth checking. Ask your agency what version is running now and whether they checked for changed files. Ask your Salesforce administrator to look at the sign-in history for the website’s user, for unfamiliar places and for unusual times or volumes. Know its limits: an attacker using the key from the compromised server arrives from the familiar address; the history will not tell you what was read or exported, and without Salesforce’s Event Monitoring add-on there is very little visibility of that; and it says nothing about data copied on the website itself or through other connections such as middleware or a donation platform. If in doubt, cut the connection, reconnect from the fixed site with a new key, since reusing the old password or token leaves the attacker’s copy working, and bring in professional help to look properly.

If supporter data could have been read, the Information Commissioner’s Office expects a decision on reporting within 72 hours, and the Charity Commission expects a serious incident report, as its guidance after the Beacon incident set out.

Whose job this is

Security on any cloud platform is shared. Salesforce secures the platform; how your environment is set up, who can get in, and what your website is allowed to do inside it are your organisation’s responsibility, as your website is. Our Managed Service covers this kind of work on request, from your monthly time, rather than as a background check we run unasked. If you are a Managed Service customer, any of the six habits above can be requested through your Delivery Manager, and the second one, finding out what your website connects as, takes under an hour.

This article is general guidance and does not replace advice for your own organisation, its website or its data. If you would like us to look at how your website connects to your Salesforce and what that connection is allowed to do, talk to the team.