SURIQ
A Joomla site can be fully patched, pass every file scan, and still greet visitors with a defacement. That is the awkward shape of the campaign now hitting sites built on JoomShaper's Helix3 template framework. The bug behind it, CVE-2026-49049, takes no credentials, and what it plants does not sit on disk where defenders usually hunt. It sits in the database.
Since roughly July 5, 2026, an automated botnet has been rewriting Joomla home pages into a black screen with a skull and one of two signatures: "Hacked by AntonKill" or "Hacked by trenggalek6etar." The researcher who found the flaw, at mySites.guru, and an unrelated Joomla vendor, ChronoEngine, independently walked through the same attack, and a proof-of-concept has since landed on GitHub.
What an anonymous request can do here
Helix3 leaves an AJAX handler task reachable with no authentication or authorization check in front of it. Reach that endpoint and you can erase files, drop JSON files of your choosing onto the server, and overwrite the settings that drive a site's template. The National Vulnerability Database scores it 7.5 and marks it integrity-only: no data theft, no outage, but full control over what the page renders. For a defacement crew, that is the entire toolkit.
| Item | Detail |
|---|---|
| CVE | CVE-2026-49049 |
| Product | JoomShaper Helix3 template framework for Joomla |
| Severity | CVSS 7.5, unauthenticated, integrity impact |
| Flaw class | Improper access control, CWE-284 |
| Affected | Helix3 1.0 through 3.1.1 |
| Fixed in | 3.1.2 (both Helix3 plugins: framework and Ajax) |
| Disclosed | June 29, 2026 |
| Exploitation | Active since about July 5, 2026, automated defacement botnet |
| Persistence | Database, not filesystem |
Both write-ups also flag a quieter version of the attack. Rather than the skull page, some hijacked sites serve a bogus reCAPTCHA prompt wired to a crypto wallet drainer, turning the visit into money instead of a trophy. A Helix3 site that looks normal is not automatically a site that got passed over.
Why your file scan keeps saying the site is clean
This is the part the fast coverage skims, and it decides whether your cleanup actually holds. The botnet plants no webshell and edits no template file. It writes its JavaScript into Joomla's database, into the settings Helix3 keeps for each template style. In a stock install those settings live as a JSON blob on the template-styles row, in the custom-code fields a site owner would normally fill with an analytics snippet: custom JavaScript, custom CSS, the before-head slot. From there the script fires on every page view.
Filesystem malware scanners, file-integrity monitoring, and rule-based file checks will all wave the site through, because not a single byte on disk moved. The defacement is one row in a table. It is also why reinstalling the Helix3 files changes nothing: you swap out code that was never touched while the real payload keeps sitting in the database.
So the hunt is a query, not a scan. On a site you control, read back the stored template-style settings and look for markup you never added, a stray script tag or a DOM write:
`SELECT id, title FROM jos_template_styles WHERE params LIKE '% Any row that comes back carrying injected code is a compromise you can trust over any scanner's all-clear.
Patching to 3.1.2 is half the job
Two things about the fix catch people out. The first is the number. JoomShaper pushed 3.1.1 on June 29, the day of disclosure, but that build did not fully shut the flaw, and NVD still lists 3.1.1 among the affected versions. The release you want is 3.1.2 or later. The second is that Helix3 is not one plugin but two. Both have to reach 3.1.2: the framework one, which Joomla lists as System - Helix3 Framework, and its companion, the Helix3 - Ajax plugin. Upgrade one and forget the other and the endpoint stays open.
Handle it as two jobs, not one:
- Get both of the Helix3 plugins onto 3.1.2, or a later build, to stop fresh injection.
- Then clear what already landed: strip the rogue script out of the stored template-style settings and put back any configuration the attacker rewrote.
- Sweep
/tmp, your media directories, and the template folders for leftovers, since the same flaw can also drop stray JSON files and delete legitimate ones.
If a site sat reachable and unpatched anywhere between early July and the moment you updated, treat it as hit and check the database before you sign it off.
The Joomla add-on layer keeps being the way in
This is the third Joomla extension flaw in recent weeks that earns an urgent patch, and the shape does not change: the core platform holds, and the intruders come in through the add-ons. Only last week CISA tagged two page builders, one of them JoomShaper's own SP Page Builder, as actively exploited for takeover, and shortly before that an unauthenticated hole in the JCE editor was being turned into webshells on live hosts. Different component each time, same entry strategy. If you run Joomla, how fast you patch extensions counts for more than how fast you patch core, and your response checklist needs a database step, because the next one may live there too.