CVE-2026-49049 | JoomShaper Helix3 (Joomla) – Unauthenticated Arbitrary JSON File Write

1. Introduction

This document illustrates an unauthenticated arbitrary file write vulnerability in JoomShaper’s Helix3 template framework for Joomla — a widely adopted front-end framework used by tens of thousands of Joomla-powered websites worldwide, including those operated by government agencies, financial institutions, and enterprise organizations.

The vulnerability allows a remote, unauthenticated attacker to write attacker-controlled JSON files to arbitrary paths on the server via a path traversal flaw in the Helix3 AJAX plugin. The flaw has been observed being actively exploited in the wild as part of the AntonKill botnet defacement campaign and is listed on the CISA Known Exploited Vulnerabilities (KEV) catalog.

2. Helix3 Description

Helix3 is an open-source Joomla template framework developed and maintained by JoomShaper. It provides a drag-and-drop page builder, layout management, and theme customization features for Joomla sites and is used as the foundation for many commercially distributed Joomla templates.

The framework ships as both a Joomla template and a companion AJAX plugin (plg_ajax_helix3) that handles real-time configuration saves from the front-end builder interface. This plugin is active by default whenever the Helix3 template is set as the site’s default template.

3. Vulnerability Severity

4. Scope of Impact

• Affected: Helix3 versions 1.0 through 3.1.0 (all Joomla-compatible releases prior to the fix)
• Fixed: Helix3 3.1.1 and later; first security-tagged release is v3.1.3 (released 2026-07-15)
• Joomla compatibility: Vulnerability is present across all supported Joomla versions when Helix3 ≤ 3.1.0 is installed (confirmed on Joomla 5.4.8)
• EOL Joomla 3 sites: Covered by the j3-security-v1.0.0 backport tag

5. Where is the vulnerability present?

The vulnerability resides in the onAjaxHelix3() handler inside the plg_ajax_helix3 plugin, reachable through Joomla’s built-in com_ajax component at the endpoint POST /index.php?option=com_ajax&plugin=helix3&format=json. This endpoint is exposed by default on every Joomla installation that has the Helix3 template active, and com_ajax imposes no authentication gate of its own — authentication enforcement is entirely the plugin’s responsibility.

In versions up to and including 3.1.0, the handler processes a data[action]=save request by accepting a caller-supplied data[layoutName] parameter and concatenating it directly onto the layout directory path before calling fopen() and fwrite(). No authorization check, CSRF token validation, or allowlist filtering is performed on layoutName prior to this operation. As a result, any HTTP client — with no session, cookie, or credential — can supply a layoutName value containing ../ sequences that escape the intended templates/<tpl>/layout/ directory.

Three levels of traversal (../../../) from the default template layout directory land in the Joomla web root (/var/www/html/), which is served directly by the web server. An attacker supplying data[layoutName]=../../../attacker-file and arbitrary JSON in data[content] causes the handler to create attacker-file.json in the web root — immediately accessible over HTTP.

The same handler exposes a data[action]=remove action that deletes arbitrary .json files by the same path traversal mechanism, and a data[action]=import action that overwrites template configuration — collectively enabling defacement, stored content injection, and configuration manipulation with zero authentication.

6. Risk

An unauthenticated attacker who can reach the Joomla front-end over the network can immediately write attacker-controlled content into any directory writable by the web server process. In a typical Linux deployment this includes the web root, all template directories, and Joomla’s cache/ and tmp/ paths. Because the written file is served directly by the web server, the attacker gains a persistent, publicly accessible file on the target.

The impact on integrity is high and immediate. While the file format is restricted to JSON (the handler appends .json and writes the content verbatim), the content is fully attacker-controlled, and JSON payloads have been used in downstream attacks including JavaScript injection into Joomla template configuration files and supply-chain style content swaps. Availability is not directly impacted, but an attacker using the action=remove primitive can delete legitimate layout and configuration files, causing template rendering failures.

The vulnerability requires no authentication, no interaction from a victim user, and no prior knowledge of the site beyond the presence of the Helix3 template (detectable from the page source). The low attack complexity combined with the high integrity impact accounts for the CVSS 7.5 HIGH rating. The active exploitation by the AntonKill botnet – which mass-scans for this endpoint and deploys defacement payloads – demonstrates that the barrier to exploitation at scale is effectively zero.

Persistence is achievable through the action=import sub-primitive, which allows overwriting the template’s stored configuration JSON. An adversary can embed persistent redirects, injected scripts, or altered page layouts that survive administrator logins and cache clears until the Helix3 plugin itself is updated or its configuration file is manually restored.

7. Mitigation

• (https://github.com/JoomShaper/Helix3/releases/tag/v3.1.3). For Joomla 3 EOL sites, apply the j3-security-v1.0.0 backport tag.
• If Helix3 is unused or non-essential, uninstall the template and disable both the plg_ajax_helix3 plugin and the shaper_helix3 template from the Joomla Extension Manager — this fully removes the attack surface.
• WAF mitigation (short-term): Block POST requests to /index.php whose query string contains both option=com_ajax and plugin=helix3. AWS WAF GenericLFI_Body rules will also catch the ../ traversal pattern in the POST body.
• Audit for compromise: Check templates/*/layout/*.json and the web root for unexpected .json files. The AntonKill campaign typically writes files named after the botnet to the web root and modifies templates/shaper_helix3/layout/default.json.
• Harden file permissions: Ensure the web server user does not have write access to the web root (/var/www/html/) beyond the directories strictly required by Joomla (typically only cache/, tmp/, images/, and media/).

8. Exploit Implementation

Attack Scenario

The lab environment consists of two Docker containers — a vulnerable Joomla 5.4.8 instance with Helix3 3.1.0 (http://localhost:8284) and a patched instance with Helix3 v3.1.3 (http://localhost:8285). Both containers are pre-configured with a full Joomla installation; the Docker environment is already running before the demonstration begins.

The attack requires no credentials, no prior knowledge of the admin panel, and no tools beyond a terminal with curl, python3, and nuclei.

Prerequisites:

• Docker Compose (containers already running)
• Python 3 (stdlib only — no pip dependencies)
• nuclei v3.x in PATH
• curl

Exploitation

Step 1. Confirm the vulnerable target is accessible and serving the Helix3 template.

This confirms the Helix3 template is the active front-end template on the target. The com_ajax handler is therefore exposed and reachable without authentication.

Step 2. Run the Nuclei template to confirm the vulnerability is present.

Nuclei confirms the endpoint is vulnerable by sending a probe save request with a traversal layoutName and verifying that {“success”:true} is returned in the response. No credentials are used.

Step 3. Execute the manual exploit using curl – unauthenticated arbitrary JSON file write into the web root.

The server responds with {“success”:true} with HTTP 200 – no authentication, no CSRF token, no session required. The handler has written the attacker-supplied JSON to /var/www/html/safe-aev-demo.json, three directory levels above the intended layout path.

Step 4. Verify impact – read the written file back over HTTP.

The file written by the unauthenticated POST request is now publicly served by the web server. Any visitor to the target can fetch this file. In a real attack this payload would contain defacement content, a redirect script, or injected configuration data.

Step 5. Confirm the patched version returns HTTP 403 and rejects the same request.

On Helix3 v3.1.3 the identical request is rejected immediately at requireAuthorisedAdminRequest() before any file operation is attempted. The layoutName parameter is also sanitized with basename() and an alphanumeric allowlist, making traversal impossible even if the auth check were bypassed.

Step 6. Run the Python proof-of-exploitation script for a full automated demonstration including cleanup.

The script writes a uniquely named canary file (safe-aev-<random>.json) to the web root, reads it back over HTTP to confirm web-accessibility, then deletes it via the same handler’s action=remove primitive — leaving the target clean.

References

Disclaimer: For authorized security research and education only. Run only against lab systems you own or have explicit written permission to test.