Source: The Hacker News — https://thehackernews.com/2026/05/ghost-cms-cve-2026-26980-exploited-to.html
What is known#
Threat actors are exploiting CVE-2026-26980, a critical Ghost CMS vulnerability, to compromise legitimate websites and inject malicious JavaScript into published articles.
According to QiAnXin XLab, the campaign abuses a SQL injection flaw in Ghost’s Content API. The flaw could allow an unauthenticated attacker to read arbitrary database data. The issue was fixed in February 2026 in Ghost version 6.19.1.
The important part is not only database access. XLab says attackers used the vulnerability to obtain a target site’s Ghost Admin API key without authorization. That key can be used to call the Ghost Admin API and modify published content. In this campaign, the attackers used it to tamper with articles in bulk and place malicious JavaScript loaders at the bottom of pages.
XLab describes the activity as large-scale site poisoning. It was first detected on May 7, 2026. More than 700 websites are reported compromised across sectors including blockchain, artificial intelligence, SaaS, security research, media, fintech, and other technology-adjacent areas.
The campaign appears to involve at least two threat clusters. In some cases, XLab observed sites being implanted with malicious code within a single day.
How the infection chain works#
The injected code acts as a two-stage loader. It sits inside legitimate Ghost-hosted content and retrieves the next payload at runtime from an external domain identified in the report as clo4shara[.]xyz/11z77u3.php.
That design gives the attacker room to change the payload without reinfecting every compromised site. The visible page remains a trusted article on a real website. The loader can stay in place while the backend decides what to serve next.
XLab says direct access to the PHP endpoint shows a traffic distribution script. Its function is to collect browser fingerprint data, upload it to the attacker-controlled server, and then act on returned instructions. Those instructions can include redirects, popups, downloads, or arbitrary JavaScript execution.
The script is reportedly powered by a commercial cloaking service. Cloaking matters here because it helps separate real victims from scanners, crawlers, and researchers. A security tool may see a harmless page. A human visitor matching the attacker’s criteria may see the actual lure.
For selected visitors, the next stage is a fake CAPTCHA page loaded inside an iframe. The page asks the user to prove they are human. This leads into a ClickFix attack.
ClickFix is a social-engineering pattern. The user is shown instructions that appear to fix a problem or complete verification. In this case, the victim is told to copy and paste a Base64-encoded command into the Windows Run dialog.
That step is the pivot. The browser page does not need a browser RCE. The victim is pushed into executing the attacker’s command locally.
What the Windows payload does#
The command described in the report works as a dropper. It delivers a ZIP archive, extracts a Windows batch script, and runs it.
The batch script then executes PowerShell. PowerShell downloads a DLL from a remote domain, launches it with rundll32.exe, and opens a bogus web page as a distraction for the user.
XLab also observed later iterations where the DLL stage was replaced with a JavaScript payload. The final goal remains similar: drop and run a Windows executable.
In the DLL chain, the resulting executable is described as a PuTTY client with a valid code-signing certificate. In the JavaScript chain, the payload is an Inno Setup installer for an Electron application.
That Electron application is a modified version of open-source software, according to the report. It is designed to persist and poll a remote server at web-telegram[.]ug every 30 seconds. The attacker can then issue instructions, including running JavaScript code or executable files.
The exact victim selection criteria are not fully visible from the public write-up. The use of cloaking suggests the campaign is not necessarily serving the same payload to every visitor.
Why this matters#
This is a CMS compromise used as a malware distribution layer.
That distinction matters. Users are not being lured only through throwaway domains or obvious scam pages. They may land on a real article hosted by a real organization. The site’s existing reputation increases the chance that the fake CAPTCHA looks plausible.
The campaign also shows why API keys are high-value targets. Once the Ghost Admin API key is exposed, the attacker does not need to maintain a noisy web shell to modify content. They can use the platform’s own administrative interface to make bulk changes.
For defenders, that changes the cleanup problem. Removing one suspicious file may not be enough. The malicious code can be embedded inside content records. The database and published articles need review.
For readers, the practical risk is the ClickFix step. A web page asking you to paste a command into Windows Run, PowerShell, Terminal, or Command Prompt should be treated as hostile unless you have independently verified the source and purpose. CAPTCHA systems do not require that action.
What site owners should check#
Ghost CMS operators should first confirm their installed version. The vulnerability was fixed in version 6.19.1, according to the source report. Sites running older versions should be upgraded to the latest available release.
After patching, assume patching alone may not remove prior compromise.
Check the following:
- Ghost version and update status.
- Admin API keys and other credentials.
- Published articles for unexpected JavaScript, especially near the bottom of pages.
- Theme files and custom integrations for unknown loader code.
- Access logs around and after May 7, 2026.
- API activity showing bulk content modification.
- External requests to reported infrastructure, including clo4shara[.]xyz and web-telegram[.]ug, where logs are available.
Rotate credentials after cleanup. That includes Admin API keys and any secrets that may have been exposed through the database. If only the front-end code is removed while stolen keys remain valid, reinfection is possible.
Organizations should also consider notifying users who visited affected pages during the contamination window. The right wording depends on what the logs show. Do not claim user device compromise without evidence. But if a page served fake CAPTCHA instructions or downloads, users should be warned to check whether they executed commands from the page.
What not to overclaim#
The report says more than 700 websites were compromised. It does not mean every visitor to those sites was infected.
The use of cloaking and traffic distribution means some users may have seen nothing malicious. Others may have seen the fake CAPTCHA and still not followed the instructions. The malware chain depends on user execution at the ClickFix stage.
It is also not clear from the public summary how many endpoints were successfully compromised after visiting poisoned Ghost sites. The confirmed scale in the source is site compromise, not confirmed endpoint infection count.
There is enough evidence to treat this as serious. There is not enough in the public material to assign a universal victim count or a single final malware family across all cases.
Practical takeaway#
For Ghost operators: patch, rotate, audit content, and inspect API activity. Treat content integrity as part of incident response, not just server integrity.
For users: never paste commands from a website into Windows Run or PowerShell to complete a CAPTCHA. That is not verification. That is execution.
For security teams: monitor for injected loaders on trusted content platforms. In this campaign, the abuse path is simple and effective: exploit CMS, steal Admin API key, poison real pages, cloak payloads, then push users into running local commands.
The technical exploit opens the door. The trusted website closes the deal.