
Hoplon InfoSec
17 Jun, 2026
Content Summary
This article covers three major CMS security incidents from 2026: the maximum-severity JCE vulnerability in Joomla (CVE-2026-48907), a supply chain attack targeting over one million WordPress sites through three popular plugins, and a Turkish threat actor running an SEO fraud campaign via a fake WordPress plugin and database-resident web shells. You will find technical breakdowns, attack flow explanations, detection methods, and a complete protection guide for both Joomla and WordPress site owners.
Quick Reference
|
Incident |
Platform |
Severity |
Affected Sites |
Status |
|
CVE-2026-48907 JCE |
Joomla |
CVSS 10.0 |
All JCE 1.0.0 to 2.9.99.4 |
Patched June 3, 2026 |
|
Supply Chain Attack |
WordPress |
Critical |
1 million+ |
Under investigation |
|
PBN Backdoor Campaign |
WordPress |
High |
Unknown, growing |
Active |
Picture this. You wake up one morning, open your website, and everything looks fine. Pages load. Forms work. Your analytics dashboard shows normal traffic. But somewhere deep inside your database, a stranger has been living in your server for days, reading your files, injecting invisible links into every page your visitors see, and quietly building a backdoor they can return to anytime they want.
This is not a hypothetical. In June 2026, this exact scenario played out across hundreds of thousands of websites running on Joomla and WordPress, the two most popular content management systems on the planet. Three separate attack campaigns came to light within days of each other, and together they paint a picture of how sophisticated, patient, and financially motivated modern cybercriminals have become.
If you run a website on either of these platforms, this article is for you. It does not matter if you are a developer who manages dozens of client sites or a small business owner running your first WordPress blog. The threats discussed here are real, actively exploited, and in some cases completely invisible to standard security scans. Let us walk through what happened, why it matters, and exactly what you need to do.
WordPress and Joomla together power somewhere around 45% of all websites on the internet. Think about that number for a moment. Nearly half the web runs on two platforms, both of which rely heavily on third-party plugins and extensions built by independent developers scattered around the world.
From a hacker's perspective, this is an extraordinary opportunity.
On June 16, 2026, the US Cybersecurity and Infrastructure Security Agency, better known as CISA, added a new entry to something called the Known Exploited Vulnerabilities catalog, or KEV. This catalog is CISA's official. Rather than attacking one site at a time, you discover one vulnerability in a popular plugin or extension, and you now have a key that opens millions of doors at the same time.
On June 16, 2026, the US Cybersecurity and Infrastructure Security Agency, or CISA, as it's more commonly known, added a new entry to something called the Known Exploited Vulnerabilities catalog, or KEV. This catalog is CISA’s official list of security flaws that are not theoretical risks but are actively exploited by real attackers in the wild right now.
When a vulnerability gets added to this list, it is a five-alarm signal. Federal civilian agencies are legally required to patch it within a set deadline, and every other organization should treat it as an urgent priority.
The vulnerability that earned this distinction was tracked as CVE-2026-48907, a flaw in the Joomla Content Editor extension made by Widget Factory. It received a CVSS score of 10.0, the absolute maximum on the scale used to rate how dangerous a security flaw is. At the same time, researchers were uncovering two separate WordPress attack campaigns, one targeting over a million sites through compromised plugins and another driven by a financially motivated threat actor using fake plugins and database-hidden malware to steal SEO authority from legitimate websites.
Three campaigns. Two platforms. Millions of potential victims. Here is what you need to know about each one.
Security researchers love technical terms, but most website owners understandably do not have time to decode them. So let us start with a plain-language explanation of what "improper access control" means, because understanding this concept is the key to understanding why this vulnerability is so dangerous.
Every web application has rules about who can do what. An unauthenticated visitor should be able to read your blog posts. A logged-in subscriber might be able to leave comments. An editor can publish articles. An administrator can change site settings. These are access controls, and they exist to make sure that people can only do things they are supposed to do.
Improper access control means the application failed to enforce these rules correctly. In the case of the Joomla Content Editor extension, the failure was severe: a person who had never logged in, who had no account on your site whatsoever, could interact with an administrative function and use it to upload and run PHP code on your server.
PHP is the programming language that runs most of the web, including Joomla and WordPress. When an attacker can upload and execute their own PHP code on your server, they essentially have the same level of access as if they were sitting at the keyboard of the computer that hosts your website. They can read any file, write any file, delete anything, install anything, and communicate with other servers. This is why the vulnerability scored a 10.0. There is no more complete form of compromise.
The way this vulnerability works in practice follows a logical progression that any technically curious person can follow.
First, an attacker identifies a Joomla website running a vulnerable version of JCE, any version from 1.0.0 through 2.9.99.4. Because JCE is one of the most popular Joomla extensions ever made, with millions of installations worldwide, this is not a difficult targeting problem.
Second, the attacker sends a crafted request to the JCE editor endpoint, an address within the site that the editor uses to function. Under normal circumstances, only authenticated administrators should be able to interact with certain editor functions. But due to the access control flaw, the attacker can reach a specific function without being logged in.
Third, that function allows the creation of new editor profiles. The attacker abuses this to create a profile that serves as a vehicle for uploading a PHP file, typically a web shell, to the server.
Fourth, once the PHP file is on the server, the attacker simply accesses it through a browser or an automated tool, and their code runs on the server with whatever permissions the web server process has. From that moment, the site is compromised.
Once a threat actor has remote code execution on your server, the practical outcomes range from annoying to catastrophic. At the lower end, they might deface your website, replacing your homepage with a political message or a hacker calling card. Further up the severity scale, they can steal your database, which contains customer information, email addresses, hashed passwords, and potentially payment-related data depending on your site's function.
At the most serious level, attackers with server access can install ransomware, encrypt your files, and demand payment for the decryption key. They can also use your server as a launching point to attack other systems, which puts you in the uncomfortable position of being both a victim and an unwitting participant in attacks on others.
Widget Factory released the patched version, JCE 2.9.99.5, on June 3, 2026. The release notes acknowledged that insufficient access controls had permitted unauthenticated users to upload editor profiles. Federal civilian agencies in the United States were ordered to apply the fix by June 19, 2026.
If you have the Joomla Content Editor installed and you have not updated to version 2.9.99.5 or newer, your site is at risk, and you should treat this as an emergency.
To update, log into your Joomla administrator panel and navigate to System, then Update, then Extensions. Find JCE in the list and apply the available update. If you manage multiple Joomla sites, do this for every single one of them today.
If for some reason you cannot update immediately, consider temporarily disabling the JCE extension and falling back to the default Joomla editor until you can apply the patch. You should also implement a web application firewall rule that blocks requests to the vulnerable JCE endpoint. Services like Cloudflare, Sucuri, or a server-level solution with web application security testing services can help you identify whether your site has specific firewall needs.
After patching, do not assume you are safe just because the vulnerability is closed. Check your server access logs for any requests to the JCE editor endpoint from IP addresses that were not logged in. Look for any PHP files that were recently created in directories where user-uploaded content is stored. If you find evidence of exploitation, treat your site as compromised and proceed to the incident response steps at the end of this article.
If you want professional eyes on your Joomla infrastructure, a proper vulnerability management review can identify not just this flaw but any other gaps in your configuration before attackers find them.
Most people understand a direct attack intuitively. Someone tries to break into your house by picking your lock or breaking a window. You defend against it by using better locks and stronger glass.
A supply chain attack is different. The attacker doesn't attack your house directly. Instead, he breaks into the factory that makes your locks. He changes the locks before they are shipped to you. You install something that you think is a legitimate, trusted product, but it’s been compromised before it even got to you.
In the context of WordPress plugins this means an attacker does not try to hack
your site directly. They undermine the plugin itself by either hacking into the
developer’s account or by inserting malicious code into an update.
When you install or update the plugin, you are unknowingly installing malware. And because millions of sites use the same popular plugins, a single successful supply chain attack scales instantly.
This is exactly what happened to OptinMonster, TrustPulse, and PushEngage, three well-known WordPress plugins used collectively by over a million websites.
The threat actors injected JavaScript into these plugins that behaved in a very deliberate and patient way. Rather than immediately doing something visible, the script sat quietly and waited. It was specifically watching for a logged-in administrator, someone with full privileges over the WordPress installation.
When it detected that an administrator had logged in, it sprang into action. It created a new administrator account in the background, one that the legitimate site owner did not create and might not notice for days or weeks. Then it installed a second payload: a plugin designed to hide itself from the WordPress admin interface. This self-hiding backdoor plugin would not appear in the standard list of installed plugins, making it extremely difficult to detect through normal administrative review.
This is a sophisticated approach. It is not smash-and-grab; it is patient, methodical, and designed for persistence. The attacker plants a flag on your site and returns at their leisure, often without the site owner ever knowing the initial intrusion happened.
Here is something most site owners do not realize: self-hiding plugins work by hooking into the WordPress API and filtering themselves out of query results. When you go to Plugins in your admin dashboard, WordPress is asking the database for a list of plugins and displaying what it receives. A self-hiding plugin intercepts that database query and removes itself from the list before it reaches your screen.
This means that simply looking at your admin panel and seeing a clean list of plugins does not mean your plugins are clean. The only way to reliably detect a self-hiding plugin is to look directly at the file system, specifically the wp-content/plugins directory, using FTP, cPanel file manager, or SSH access to your server, and compare what is physically there against what appears in your admin panel.
If you use any of these three plugins, here is a practical checklist. First, access your server's file system directly and list everything in wp-content/plugins. Make a note of every directory name. Then compare that list against what appears in your WordPress admin panel under Installed Plugins. If there is anything in the file system that does not appear in the admin panel, you have found something suspicious.
Second, check your admin users. Run the following query on your WordPress database:
SELECT user_login, user_email, user_registered FROM wp_users WHERE ID IN (SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%');
Compare every account returned against the administrators you know you have created. Any unfamiliar account should be treated as a backdoor account and removed immediately, but only after you have preserved evidence for forensic investigation.
Third, look for recently modified PHP files throughout your WordPress installation, including in the core directories. Legitimate WordPress files rarely change outside of an update cycle.
For ongoing monitoring, tools like Wordfence or Sucuri offer file integrity monitoring that alerts you when core files are modified unexpectedly. A proper endpoint security protection service can extend this kind of monitoring across your entire infrastructure if you manage multiple websites or servers.
To understand this third campaign, you first need to understand what a private blog network is and why someone would go to enormous criminal lengths to build one.
Google ranks websites partly based on how many other websites link to them, and crucially, on the authority of those linking sites. If a well-established, trusted website links to yours, Google interprets that as a signal of credibility and pushes your content higher in search results. This is the legitimate foundation of what is known as link building.
A Private Blog Network, or PBN, is a black hat SEO technique where someone controls a collection of websites and uses them to artificially manufacture these valuable links. Instead of earning links through genuine content and relationships, the PBN operator creates or buys websites with existing authority and points their links wherever they want, usually toward gambling sites, adult content, pharmaceutical products, or other niches where organic search rankings translate directly into affiliate revenue.
Building a legitimate PBN is expensive. Buying authoritative domains costs money. Creating content for each site costs money. Hosting it all costs money. Hacking into real, legitimate websites and turning them into involuntary PBN nodes is free.
Researchers at Sucuri discovered a compromised WordPress site that had been turned into exactly this kind of involuntary PBN node. The attackers had managed to install a fake plugin named "Beloved PBN Entegrasyonu" on the site. This name itself is a clue to the origin of the campaign: "Entegrasyonu" is a Turkish word meaning integration.
This plugin did two things on every single page load, for every visitor who came to the site. First, it sent the site's URL to an external server operated by the attackers, essentially checking in and saying "I am here, I am active." Second, it received instructions back from that server and injected whatever HTML or JavaScript was returned into the footer of every page.
This means the attackers could change what was being injected at any time, without touching the site's files again. They could push links to any website they wanted, on demand, through thousands of compromised sites simultaneously.
Beyond the plugin, the attackers stored two PHP web shells directly in the WordPress database, specifically as raw executable code in the wp_posts table. This deserves special attention because it represents a technique that defeats most traditional security tools.
Standard malware scanners work by looking at files on your server and checking them for known malicious signatures. They scan PHP files, JavaScript files, and image files. They look in the directories where code typically lives. What they generally do not do is execute every row in your database as if it were code and check whether it contains something malicious.
By storing their web shells as database entries rather than files, the attackers ensured their access mechanism was invisible to file-based scanning. The shells could be invoked through HTTP requests that triggered their execution, giving the attackers full read and write access to the entire server file system without authentication.
This is why dark web monitoring and behavioral detection matter as much as signature-based scanning. When the attack leaves no file trace, you need tools that detect anomalous behavior rather than known patterns.
Every visitor to a compromised site received these injected outbound links in their page source, on every page, on every visit. From Google's perspective, your website was voluntarily linking to gambling and adult sites. It was participating in a link scheme designed to manipulate search rankings, which is a direct violation of Google's webmaster guidelines.
Google may respond to this in two ways. The first is algorithmic, where the search engine automatically devalues your site's trust score and lowers its rankings without any human intervention or notification. The second is a manual penalty, where a member of Google's team reviews your site, confirms the violation, and applies a manual action that can suppress your site from search results entirely or dramatically reduce its visibility.
Algorithmic devaluation can begin within days of the compromise. Manual penalties can take weeks to issue, but recovery from either can take months. After cleaning your site, you need to submit a reconsideration request through Google Search Console explaining what happened, what you found, and what steps you took. Google does not rush these reviews, and in the meantime, your organic traffic, which may be your primary source of business, continues to suffer.
The threat actor behind this campaign was identified as Turkish-speaking based on language artifacts in the code and the domain infrastructure used for command-and-control. Attribution like this is always probabilistic rather than definitive, based on patterns of language, tooling, and operational security rather than absolute proof of identity.
These three incidents did not happen in isolation. They are part of a broader and accelerating pattern of attacks against CMS platforms. The reason is straightforward economics. WordPress and Joomla represent a massive attack surface area because of their market share. A researcher or criminal who invests time in understanding these platforms can apply that knowledge to millions of targets.
Plugin and extension marketplaces make this worse. Both WordPress and Joomla rely heavily on third-party code that is reviewed inconsistently and updated infrequently by site owners. The average WordPress site runs between 20 and 30 active plugins. Each one is a potential entry point.
Attacks against CMS platforms tend to be financially motivated rather than nation-state driven. The JCE vulnerability, the plugin supply chain attack, and the PBN campaign all have clear financial objectives: server access for resale on criminal markets, persistent backdoors for long-term exploitation, and stolen SEO value converted to affiliate revenue.
The KEV catalog was created for federal agencies, but its signal value extends far beyond government. When CISA adds a vulnerability to the KEV list, it means they have verified that the vulnerability is being actively exploited in the real world right now. It is not a theoretical risk. Someone is using it. Probably many someones.
For private organizations and individual site owners, this should function as a patch prioritization signal. Not all vulnerabilities are equal. Most published CVEs are never actively exploited. KEV entries are the ones that are. If you have limited time for security maintenance, start with whatever appears on that list.
You can subscribe to the KEV catalog feed directly from CISA's website as an RSS or JSON feed and set up alerts to notify you whenever new entries are added. This is free, takes about five minutes to set up, and gives you early warning on the most dangerous vulnerabilities affecting widely used software.
This section is where you actually do something. Reading about threats is useful. Taking action is what keeps your site safe.
Update JCE to version 2.9.99.5 or later right now. Log into your Joomla admin panel, go to System, then Extensions Update, and apply the patch. If you manage sites for clients, check every single installation.
After patching, review your server access logs for the period
before you applied the update. Look specifically for POST requests to paths
containing the JCE editor endpoint. If you see requests from IPs that had no
session cookies or no previous login activity, these are suspicious and should
be investigated further.
Check what permissions each of your installed extensions has. Many Joomla
extensions ask for more access than they really need. Reducing unnecessary
permissions reduces your attack surface. 2. You may want to consider a security
extension such as Akeeba Admin Tools or RSFirewall that each add meaningful
layers of protection to Joomla installations.
If your Joomla site contains customer data or transactions, a formal gap
assessment against a recognized security standard can identify systemic
weaknesses beyond this vulnerability alone.
If you are running OptinMonster, TrustPulse, or PushEngage,
your immediate steps are First, go directly to the file system of your server
and compare the files under wp-content/plugins with the list presented on your
admin dashboard. Any difference is a warning sign. Second, audit administrator
accounts by executing the database query above. Thirdly, check in wp_posts for
any rows that contain PHP code, especially anything with eval, base64_decode,
or anything shell-related in the content field.
If you see signs of compromise, don’t delete anything. “Keep copies of the
database and file system for forensic investigation.
Then begin the cleanup process, either through a professional service or using established malware removal guides from Sucuri or Wordfence.
For ongoing protection, configure email security and anti-phishing protection for the email account associated with your WordPress admin, since account takeover through phished credentials is a common initial access method.
A web application firewall should be considered essential infrastructure at this point, not optional. Services like Cloudflare's WAF, Sucuri's firewall, or server-level solutions filter malicious requests before they reach your application. Many of the attack patterns described in this article, including the JCE exploitation attempts, would be blocked by a properly configured WAF.
Enable two-factor authentication on every administrator account for both Joomla and WordPress. This single step prevents a large percentage of account takeover attacks even if passwords are stolen. If your hosting control panel also has 2FA, enable it there too.
Keep backups automated and offsite. Your hosting provider's backups are useful, but they are not sufficient on their own because a compromised server can sometimes affect those backups too. Services like JetBackup, UpdraftPlus for WordPress, or Akeeba Backup for Joomla can push encrypted backups to cloud storage automatically.
Minimize the number of plugins and extensions you have installed. Every additional plugin is an additional attack surface. If you installed something to test it two years ago and never removed it, remove it now.
Subscribe to security newsletters and vulnerability feeds specific to the platforms you use. WPScan maintains a WordPress vulnerability database. Joomla publishes security bulletins at joomla.org. These resources give you early warning before vulnerabilities become widely exploited.
If you manage websites for clients or run a significant online business, investing in proper cyber resilience assessment will give you a structured picture of your current risk posture and a roadmap for improvement.
The moment you suspect compromise, the first step is containment. Take the site offline or put it in maintenance mode to prevent further damage and to stop serving malicious content to your visitors. Contact your hosting provider and let them know what you have found. They may have logs and forensic information you cannot access yourself.
Before you clean anything, preserve the evidence. Make a copy of the database and a copy of the file system, and save your server access logs. If you eventually need to involve law enforcement or legal counsel, this evidence will be important.
For the cleanup itself, if you are not highly technical, engaging a professional malware remediation service is genuinely worth the cost. For complex infections involving database-resident payloads like the one described in this article, DIY cleanup can miss components that allow the attacker to regain access. An incident response and recovery service that specializes in web compromises can ensure the cleanup is complete and help you understand how the initial breach occurred.
If you experience a breach involving customer data, you likely have notification obligations under GDPR, CCPA, or other applicable regulations. Engage legal counsel familiar with data protection law as soon as possible.
For SEO recovery after a PBN injection or malicious link injection attack, document everything thoroughly. Screenshot the injected content, save copies of the malicious code, and keep records of all the steps you took to clean the site. When you submit your reconsideration request to Google through Search Console, a detailed and credible explanation of what happened significantly improves your chances of a timely resolution.
Free tools worth using:
The CISA KEV catalog is available at cisa.gov/known-exploited-vulnerabilities-catalog, and you can subscribe to it as an automated feed. WPScan at wpscan.com offers a free tier for scanning WordPress sites against a regularly updated vulnerability database. VirusTotal at virustotal.com lets you scan URLs and files for known malicious signatures across dozens of antivirus engines. Have I Been Pwned at haveibeenpwned.com lets you check whether email addresses associated with your admin accounts have appeared in known data breaches.
Paid and professional services worth knowing:
Sucuri offers both site scanning and professional malware removal, and their research blog at sucuri.net is one of the best sources of real-world web security intelligence available. Wordfence for WordPress includes a firewall, malware scanner, and login protection in its free tier, with significantly enhanced capabilities in the paid version. Patchstack provides vulnerability alerts specifically for WordPress plugins and themes, with notifications delivered directly to you when plugins you use are found to be vulnerable.
Ongoing intelligence sources:
Make a habit of reading. The Hacker News at thehackernews.com for timely coverage of newly discovered vulnerabilities. Follow Sansec at sansec.io for deep research into e-commerce and CMS-specific threats. Subscribe to your platform's official security bulletin. For Joomla, that is joomla.org/announcements. For WordPress, it is wordpress.org/news.
If you want to go deeper into understanding how attackers approach targets like your website, cyber threat intelligence services provide curated, contextualized intelligence about threats relevant to your specific technology stack and industry.
Security advice is only useful if it translates into action. Here are the five things to do based on everything covered in this article.
One: If you use JCE on any Joomla installation, update to 2.9.99.5 today. Not this week. Today. Check every site you manage.
Two: If you use OptinMonster, TrustPulse, or PushEngage on WordPress, audit your administrator accounts and your plugin file system immediately. Look for discrepancies that could indicate a self-hiding backdoor.
Three: Accept that database-resident malware exists and that your file scanner will not find it. Schedule a database audit and consider a behavioral monitoring solution alongside your traditional scanner.
Four: Understand that SEO damage from a site compromise can last months after the technical problem is resolved. Document everything, clean thoroughly, and communicate transparently with Google through Search Console.
Five: Add the CISA KEV catalog feed to whatever system you use to track technology news. Treat every new addition as an urgent patching signal for any software in your environment that matches.
Security is not a product you buy once and forget about. It is a practice. The attackers described in this article are persistent, patient, and financially motivated. They will continue probing for weaknesses. The best defense is staying informed, acting quickly when threats emerge, and having the right tools and partners in place before you need them.
Official References
1. CISA Known Exploited Vulnerabilities Catalog:
Was this article helpful?
React to this post and see the live totals.
Share this :