Poisoned Plugins, Hijacked SharePoint, and a WordPress Patch You Cannot Ignore: UK SMB Threat Brief, 14 August 2026
Two stories from this week’s intelligence feed sit at the top of the priority stack for UK small businesses. They are not abstract risks. Both are being actively exploited. Both are fixable. Neither required a sophisticated attacker.
Let us go through them.
Story One: Your WordPress Plugins May Have Been Backdoored Through Their Own Update System
This one is particularly unpleasant, because the attack vector is the mechanism you trust to keep your site secure.
Two widely used WordPress plugins, Fluent Forms Pro and Ninja Tables Pro, were distributed in compromised builds through decommissioned update servers. The tampered versions carried rogue PHP files that, once installed, did the following: established a hidden REST API backdoor endpoint, dropped persistent PHP files into the mu-plugins and uploads directories, created a passwordless administrator account, and registered scheduled tasks designed to survive plugin removal.
Read that last part again. The malicious code survives plugin removal. Deleting the plugin does not clean the infection.
These are assigned CVE-2026-73532 and CVE-2026-73533 respectively, both rated CVSS 9.8.
The supply chain vector here matters. The compromised builds were served through a decommissioned update server. If your WordPress site has auto-updates enabled and was pulling from that infrastructure, it may have received the backdoored version without any action on your part.
For UK small businesses, this is a direct threat. WordPress powers a significant proportion of small business websites in this country. A backdoored site is not just a website problem. It is a customer data problem, a GDPR problem, and potentially the entry point for an attacker into any systems that share credentials with that site.
What the data actually says: CVSS 9.8. No authentication required to exploit the backdoor once installed. The persistent files mean standard remediation steps are insufficient.
Story Two: SharePoint Is Being Actively Exploited After a Public Proof-of-Concept Was Released
Microsoft patched CVE-2026-55040 on 14 July. On 11 August, Rapid7 published detailed technical analysis and proof-of-concept exploit code. Within hours of that publication, active exploitation was reported.
The vulnerability allows an attacker to bypass authentication by forging JSON Web Tokens (JWTs), which are the credentials SharePoint uses to verify who you are. Combined with a second vulnerability, CVE-2026-63520, an unauthenticated attacker can achieve full remote code execution on a vulnerable SharePoint server.
This matters to UK small businesses in two specific ways.
First, if your business runs SharePoint on-premises rather than through Microsoft 365, and that server has not been patched since July, you have a problem that needs addressing today, not next week.
Second, if your IT is managed by an MSP, this is a direct test of whether they are doing their job. The patch has been available for a month. The exploit is now public. There is no longer any ambiguity about urgency.
The pattern here is one the intelligence community has documented repeatedly: the window between patch release and active exploitation is compressing. In this case, the trigger was the public PoC, not the original patch advisory. Attackers wait for someone else to do the research, then operationalise it immediately.
The Pattern Connecting Both Threats
These two incidents share a structural feature worth naming precisely.
In both cases, the attack surface was created by a prior decision: the decision not to audit plugin sources, the decision not to apply a patch within the available window. The attacker did not create the vulnerability. They found a door that was already open.
This is not a criticism designed to make business owners feel bad. It is an observation about where the leverage actually sits. The attacker’s job is to find the door. Your job is to close it before they do.
Both of these situations were preventable with existing, non-exotic controls.
Why This Gives You an Edge
Businesses that respond to intelligence like this, quickly and specifically, demonstrate something meaningful to clients and partners.
If your business handles customer data through a WordPress site, being able to say that you audited your plugins and verified your site integrity this week is not a marketing claim. It is evidence of an operating standard. In procurement conversations, in tender responses, in client reassurance discussions, that evidence has value.
If you use SharePoint and your MSP can confirm patch status within 24 hours of being asked, that is a measurable indicator of service quality. If they cannot answer that question, that is also a measurable indicator.
The businesses that treat intelligence-driven patching as a routine operational activity, rather than a crisis response, accumulate a security posture advantage that compounds over time.
Making the Business Case
Three arguments for the budget conversation, if you need them:
The cost of remediation versus the cost of breach. A WordPress site cleaned after a backdoor infection requires forensic analysis, full reinstallation, credential resets, and potentially ICO notification under UK GDPR. That is measured in days of disruption and professional fees. Auditing plugins takes an hour.
Supply chain liability. If your site is used as an entry point to attack a customer or partner, the reputational and contractual consequences extend well beyond the site itself. Regulators are increasingly attentive to supply chain vectors.
Patch compliance as a contractual and regulatory expectation. Cyber Essentials, which is increasingly required for UK government supply chain contracts, explicitly requires that software is patched within 14 days of a critical update being available. CVE-2026-55040 has been patchable for a month. Non-compliance is not a theoretical risk; it is a certification failure waiting to be audited.
What to Do Before the End of This Week
1. Audit your WordPress plugins immediately. Log into your WordPress admin dashboard. Check whether Fluent Forms Pro or Ninja Tables Pro are installed. If they are, do not simply deactivate or delete them. You need to check for the presence of persistent files in your mu-plugins directory and your uploads directory. If you find unexpected PHP files there, your site has been compromised and you need professional remediation, not just a plugin update.
2. Check for unexpected administrator accounts. In WordPress, go to Users and filter by Administrator role. Any account you do not recognise should be treated as malicious and removed immediately. Then investigate how it got there.
3. Verify your SharePoint patch status. If you run SharePoint on-premises, confirm with whoever manages it that CVE-2026-55040 and CVE-2026-63520 have been patched. If you are on Microsoft 365, your SharePoint Online environment is managed by Microsoft and is not affected in the same way, but verify this with your IT contact.
4. Ask your MSP for a patch status report. If you have a managed service provider, send them this article and ask for written confirmation of patch status on both issues. Their response time and the quality of their answer will tell you something useful about the service you are receiving.
5. Verify your backup integrity. Given that the WordPress backdoor persists after plugin removal, your most recent backup may already contain the infection. Identify the date of the compromised plugin release and verify that you have a clean backup predating it. If you do not, your restoration strategy needs to account for this.
Before you go: follow the show wherever you listen, leave a rating or review, drop a comment with your thoughts, and share it with someone who would find it useful. It is how this reaches the people who need it.