Joomla Sites Are Being Hacked Right Now: What UK Small Businesses Need to Know This Week
Two vulnerabilities confirmed in active exploitation this week. Both are technically distinct. The business risk they represent is identical: someone gets access to your systems who is not supposed to have it, and you may not know until the damage is visible.
This is the weekly brief. Let’s work through what matters.
Story One: Your Joomla Website Is Being Targeted Right Now
On 16 June 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-48907 to its Known Exploited Vulnerabilities catalogue. That catalogue is not a theoretical risk register. It is a list of vulnerabilities for which CISA has confirmed observed exploitation in the wild.
The vulnerability is in the Widget Factory Joomla Content Editor plugin. The flaw is classified as improper access control. In plain English: the plugin allows unauthenticated users to create new editor profiles, and through that process, upload and execute PHP code on the server.
Let that settle for a moment. An attacker who has never visited your website before, with no account and no credentials, can walk in through this plugin and run arbitrary code on your web server. That means they can install malware, create backdoors, steal data stored by your site, or pivot to other systems on the same network.
Who is at risk. Any public-facing Joomla installation running the Widget Factory Joomla Content Editor plugin. Joomla is the second most widely deployed content management system after WordPress. It is commonly used by small businesses, trade associations, local service providers, and charities across the UK.
What CISA requires. The advisory instructs affected organisations to apply vendor mitigations immediately, verify internet exposure of the asset, and follow forensic triage requirements if exploitation is suspected. In practical terms: if you run Joomla, you need to check whether this plugin is installed today, not at your next scheduled review.
Story Two: The Logout Button That Doesn’t Work
CVE-2026-53776 was published by NIST on 16 June with a CVSS score of 9.1, which places it in the critical severity band.
The affected software is Perry, a library used to handle JWT authentication. JWT stands for JSON Web Token. It is a widely used mechanism for managing login sessions in web applications: when you log in, you receive a token, and that token is presented with each subsequent request to prove you are who you say you are. Tokens have expiry times. When a token expires, or when a session is administratively revoked, the user should be required to log in again.
The flaw in Perry is precise: the verify_decode helper function unconditionally sets validate_exp = false. That means it never checks whether the token has expired. An attacker in possession of a previously issued token can present it indefinitely and retain authenticated access. Force-expiring sessions, logging users out, and administratively revoking access all become ineffective.
The business scenario. An employee leaves. You revoke their access. Their token continues to work. A contractor’s engagement ends. Their token continues to work. A device is stolen. If the attacker extracts the token, it continues to work. This is not a theoretical edge case. It is the direct consequence of a function that was supposed to check token expiry and does not.
Who is at risk. Any application built using the Perry library below version 0.5.1166. If your business uses a custom web application, a SaaS platform, or any developer-built internal tool, the question to ask your technology provider or developer is direct: does this application use Perry for JWT verification, and is it running a version below 0.5.1166?
What These Two Stories Have in Common
Neither of these vulnerabilities requires a sophisticated, targeted attack. Neither requires your business to be on a threat actor’s specific list. Both can be exploited opportunistically by automated tooling scanning for vulnerable systems at scale.
This is the consistent pattern in SMB compromise. Attackers do not choose their targets the way people imagine. They run scans. They find vulnerable systems. They exploit them. The business on the receiving end is collateral, not a chosen victim, right up until the moment they realise their data is gone or their website is serving malware to their own customers.
If you run Joomla, the question is not whether attackers are scanning for CVE-2026-48907. They are. The question is whether your installation is in the results.
Why This Gives You an Edge
Most of your competitors are not reading CISA’s KEV catalogue. Most of them do not have a process for acting on critical vulnerability disclosures within 24 hours. Most of them will learn about incidents like this after they have happened to them.
You are reading this now. That is an operational advantage, not a theoretical one.
Being able to tell a client or prospective customer that you monitor active threat intelligence and act on it within defined timeframes is a differentiator. It is increasingly relevant in procurement, particularly for businesses operating in supply chains that include public sector or financial sector clients. Those clients are asking questions about their suppliers’ security posture. Having a documented, evidence-based response to those questions is worth more than most certifications.
Making the Business Case to Your Board
Three points worth raising if you need to justify action or budget:
Exploitation is confirmed, not predicted. CISA’s Known Exploited Vulnerabilities catalogue requires confirmed evidence of active exploitation before a vulnerability is listed. This is not vendor scaremongering. This is a government agency confirming that attacks are happening. The risk is present tense.
The cost of inaction is asymmetric. Checking whether a plugin is installed and removing or patching it takes less than an hour. The cost of a compromised website, including potential ICO notification obligations under UK GDPR if personal data is affected, a forensic investigation, and the reputational damage of customers being served malware, is measured in days of disruption and potentially thousands of pounds.
Session management failures create insider threat exposure. CVE-2026-53776 is not just a technical problem. It is a governance problem. If your access controls cannot reliably terminate sessions, your offboarding process has a gap that a disgruntled former employee or a stolen device can exploit. Boards understand access control. Frame it in those terms.
What to Do Before Friday
1. Check your Joomla installation today. Log into your Joomla admin panel and navigate to the Extensions list. Look for Widget Factory or Joomla Content Editor. If it is present, check whether an update is available and apply it immediately. If no update is available, disable or uninstall the plugin until a patch is released.
2. If your website is managed by an MSP or web agency, contact them today. Send a direct message or email referencing CVE-2026-48907. Ask them to confirm: whether the plugin is present, whether it has been patched, and whether they have reviewed logs for signs of exploitation. Do not wait for your next scheduled check-in.
3. If you use any web application with user login functionality, ask your provider about CVE-2026-53776. The question is simple: does your application use the Perry JWT library, and if so, is it running version 0.5.1166 or above? If you have an internal developer or a development agency maintaining a custom application, route this question to them directly.
4. Review your offboarding process. Regardless of whether CVE-2026-53776 applies to your specific stack, this disclosure is a useful prompt to verify that when you remove a user’s access, that access is actually removed. Test it. Create a test account, revoke it, and attempt to access a protected resource. If access persists, you have a problem that needs investigating.
5. Check your ICO notification obligations. If you have reason to believe your Joomla site has already been compromised and personal data was processed on that server, the UK GDPR obligation to notify the ICO within 72 hours of becoming aware of a personal data breach applies. Do not assume compromise has not occurred because you have not seen obvious signs. Log review is necessary.
The data does not become less accurate because it is uncomfortable. Two vulnerabilities. Both actively exploited. Both fixable with immediate action. The action list is above. Use it.
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 running a small business who needs to hear this. It takes thirty seconds and it helps more people find this information when they need it.