How a Single Database Flaw Put Over 700 Websites at Risk
Imagine running a small blog or managing a university website. You trust the content management system you chose years ago. You update it rarely, if ever. Then one morning, you discover your site has been serving malware to visitors. This nightmare scenario became reality for over 700 domains recently. A critical vulnerability in Ghost CMS allowed attackers to steal admin keys and inject malicious code into articles. The campaign used a clever social engineering trick called ClickFix to compromise unsuspecting visitors. Let’s walk through exactly what happened, why it matters, and how you can protect yourself.
The Vulnerability Behind the Attack: CVE-2026-26980
The technical root of this problem is a SQL injection vulnerability tracked as CVE-2026-26980. This flaw affects Ghost CMS versions 3.24.0 through 6.19.0. SQL injection is a type of attack where malicious code is inserted into a database query. In this case, an unauthenticated attacker can send a specially crafted request to the Ghost database. The request tricks the database into returning data it should not expose.
What data are we talking about? The most dangerous piece is the admin API key. This key acts like a master password for the entire Ghost installation. With it, an attacker gains full management access. They can create new users, modify existing articles, change themes, and inject JavaScript into any page. The vulnerability was discovered by XLab, a threat intelligence team at the Chinese cybersecurity company Qianxin.
Why SQL Injection Remains a Persistent Threat
SQL injection has been a known attack vector for over two decades. Yet it continues to cause major breaches. The reason is simple: many developers and site owners neglect input validation. When user-supplied data is not properly sanitized before being passed to a database query, attackers can manipulate that query. In the Ghost CMS case, the vulnerability allowed attackers to read arbitrary data from the database without needing any credentials. This is a classic example of a low-effort, high-reward exploit for criminals.
The Attack Chain: From SQL Injection to Malware Delivery
The campaign observed by XLab followed a clear, multi-step process. Understanding each stage helps website owners know where to look for signs of compromise.
Stage 1: Exploiting the SQL Injection to Steal Admin Keys
Attackers first scanned the internet for Ghost CMS installations running a vulnerable version. They sent malicious SQL queries to these sites. If the site was vulnerable, the database returned the admin API key. This step required no password and no user interaction. It was entirely automated. The researchers at XLab estimated that the scanning and exploitation happened within hours of the vulnerability details becoming public.
Stage 2: Injecting Malicious JavaScript into Articles
Once the attackers had the admin API key, they logged into the Ghost admin panel. They navigated to existing articles or created new ones. Then they injected a small piece of JavaScript code into the article body. This JavaScript was not visible to normal visitors. It was hidden within the HTML of the page. The code itself was lightweight, often just a few lines. Its only job was to fetch a second-stage script from the attacker’s server.
Stage 3: Fingerprinting Visitors with a Cloaking Script
The second-stage script was a cloaking tool. It ran in the visitor’s browser and collected information. It checked the visitor’s IP address, browser type, operating system, and even the time of day. The goal was to determine if the visitor was a valuable target. Security researchers, automated scanners, and bots were filtered out. Only real human visitors who matched certain criteria were passed to the next stage. This technique makes detection harder for security tools.
Stage 4: The Fake Cloudflare Prompt
Visitors who passed the fingerprinting check saw a fake Cloudflare prompt. A transparent iframe was loaded on top of the article page. The iframe displayed a message claiming the visitor needed to verify they were human. This is a classic social engineering trick. It exploits the trust people have in well-known brands like Cloudflare. The prompt looked professional and convincing. It included a Cloudflare logo and a message about bot detection.
Stage 5: The ClickFix Lure
The fake prompt instructed the visitor to press a key combination, typically Windows Key + R, to open the Run dialog. Then it asked them to paste a command into the dialog and press Enter. This command was a PowerShell script or a direct command that downloaded and executed a payload. The payload was often a DLL loader, a JavaScript dropper, or an Electron-based malware sample named UtilifySetup.exe. Once the victim executed the command, their system was compromised.
Why Attackers Targeted Universities and Nonprofits
You might wonder why attackers would target Harvard, Oxford, Auburn, and DuckDuckGo instead of large corporations. The answer lies in trust and visibility. University websites and nonprofit portals have high domain authority. They are trusted by search engines and users alike. When a visitor sees a Cloudflare prompt on a Harvard.edu page, they are far more likely to trust it than if they saw the same prompt on a random blog. The attackers exploited this halo effect. They used the reputation of these institutions to lend credibility to their phishing lure.
Additionally, many university websites run older versions of Ghost CMS. IT departments in academic institutions often manage hundreds of departmental websites. Keeping all of them patched is a massive challenge. This creates a large attack surface for criminals to exploit.
Two Attacker Groups Fighting Over Compromised Sites
XLab observed something unusual during their investigation. At least two distinct activity clusters were targeting the same vulnerable sites. In some cases, one group would clean the injected script left by another group. Then they would inject their own script. This created a tug-of-war over compromised domains. One site might be re-infected multiple times with different scripts after cleanup. This shows that the vulnerability was widely known among criminal circles. It also means that simply removing the malicious code is not enough. The underlying vulnerability must be patched, or the site will be re-infected.
High-Profile Victims: Harvard, Oxford, Auburn, and DuckDuckGo
The list of compromised domains includes some of the most respected names on the internet. Harvard University, Oxford University, and Auburn University all had malicious code planted on their Ghost CMS installations. DuckDuckGo, the privacy-focused search engine, was also affected. The presence of these high-profile domains in the attacker’s list highlights the scale of the campaign. It also underscores the importance of timely patching, even for organizations with dedicated security teams.
How to Check If Your Ghost CMS Site Is Vulnerable
If you run a Ghost CMS website, you need to determine your current version immediately. Here is how to do it.
Check Your Version in the Admin Panel
Log into your Ghost admin panel. Look for the “Labs” or “About” section in the left sidebar. The version number is usually displayed at the bottom of the page. If you see version 3.24.0 through 6.19.0, your site is vulnerable. You must upgrade immediately.
Check via Command Line
If you have SSH access to your server, you can run this command in your Ghost installation directory:
ghost --version
This will output the current version. Compare it to the vulnerable range.
Check Your Database for Signs of Compromise
Even if your version is patched, you should check if your site was already compromised. Look for any articles that contain suspicious JavaScript code. The injected code often looks like a short script that fetches content from an external URL. You can search your database for common patterns like “
