Joomla Helix Ultimate Framework — Unauthenticated Arbitrary File Deletion (CVE-2026-57830)
Published: 2026-07-27 • Researcher: Is4yev (Amin İsayev)
- Severity
- Critical
- CVE
- CVE-2026-57830
- Category
- web
- Affected product
- Helix Ultimate Framework (plg_system_helixultimate), the JoomShaper Joomla template framework bundled with virtually every JoomShaper Joomla template
- Affected versions
- 1.0 – 2.2.6 (fixed in 2.2.7)
- Disclosed
- 2026-07-27
- Patch status
- Patched
Tags
Archive entry
intelseclab/poc-archiveOn this page
Metadata
| Field | Value |
|---|---|
| Date Added | 2026-07-27 |
| Last Updated | 2026-07-27 |
| Author / Researcher | Is4yev (Amin İsayev) |
| CVE / Advisory | CVE-2026-57830 |
| Category | web |
| Severity | Critical |
| CVSS Score | 9.1 (CVSSv3) |
| Status | Weaponized |
| Tags | joomla, helix-ultimate, joomshaper, arbitrary-file-deletion, cwe-862, unauthenticated, csrf-token-only-check |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | Helix Ultimate Framework (plg_system_helixultimate), the JoomShaper Joomla template framework bundled with virtually every JoomShaper Joomla template |
| Versions Affected | 1.0 – 2.2.6 (fixed in 2.2.7) |
| Language / Platform | PHP / Joomla CMS (system plugin, com_ajax dispatch) |
| Authentication Required | No |
| Network Access Required | Yes — any HTTP(S) reachability to the target site’s index.php |
Summary
Helix Ultimate’s plugins/system/helixultimate/src/Platform/Media.php exposes deleteMedia() and getFolders() through the Joomla com_ajax dispatch hook (onAfterRoute()), reachable via option=com_ajax&helix=ultimate&action=delete-media/view-media. These methods only call Session::checkToken() — a plain CSRF check — with no authorise()/login check at all (CWE-862, Missing Authorization). Because a valid CSRF token is trivially harvestable from the site’s own public homepage HTML by any anonymous visitor, this “protection” authorizes nobody in particular: it just proves the request came from a browser that loaded the page once. The result is unauthenticated arbitrary file deletion (and, as a side effect of the same code path, unauthenticated folder/image listing), on any site running a Helix-Ultimate-based JoomShaper template — which is the default, always-enabled state for that whole product line. Fixed in 2.2.7 by confining file operations to validated paths via Helper::resolveMediaPath().
Vulnerability Details
Root Cause
plugins/system/helixultimate/helixultimate.php (onAfterRoute(), site-client branch) dispatches on the raw option/helix/request/action GET parameters:
| |
Media::deleteMedia() itself:
| |
This is inconsistent with the sibling method uploadMedia() in the same class, which correctly requires core.edit on com_templates before touching the filesystem — deleteMedia()/getFolders() simply never got the equivalent gate. Since this is a system plugin, onAfterRoute() fires on every front-end request regardless of which template is active, so the vulnerable path is reachable as long as the plugin is installed and enabled — true by default on any Helix-Ultimate-based site.
A secondary factor amplifies the blast radius: $path passes through Joomla’s PATH input filter (InputFilter::cleanPath()), whose regex allows exactly one run of ../ sitting directly after the string’s leading /, without being caught (only chained ../../.. gets blocked). A value like /../sibling_dir therefore survives the filter intact, letting the primitive reach exactly one directory level above JPATH_ROOT — and unlimited depth below that level. On shared hosting where multiple tenant sites live as sibling directories under one OS user (cPanel addon domains, Plesk subscriptions, etc.), an anonymous visitor to one Helix-Ultimate site can enumerate and delete files belonging to every other site under that account.
Attack Vector
- Anonymous GET to the target’s homepage to harvest a valid, ordinary anonymous-session CSRF token (
csrf.tokenembedded in the page’s Joomla-generated JS/HTML, or a hidden form field matching a 32-hex-char token name). - POST to
index.php?option=com_ajax&helix=ultimate&request=task&action=delete-mediawith body parameterspath(root-relative, e.g./images/x.txt, or webroot-escaping via a single/../),type(fileorfolder), and the harvested token name set to1. - No session login, cookie, or credential of any kind beyond the anonymous CSRF token is required — the whole chain is a single unauthenticated HTTP round trip to obtain the token, followed by a single unauthenticated POST to delete.
action=view-mediaon the same dispatch path additionally allows unauthenticated read/enumeration of folders and image files at any reachable path (used as the safe, non-destructive detection signal).
Impact
Unauthenticated, unconditional deletion of any single file reachable under JPATH_ROOT (trivially configuration.php → immediate “No configuration” fatal error → full site outage), or unauthenticated recursive deletion of an entire folder (type=folder, e.g. /administrator, /components, /media) for near-total destruction of the install. Combined with the one-level webroot escape, the same primitive reaches sibling directories on shared hosting, turning a single vulnerable site into a whole-account blast radius. A companion unauthenticated view-media listing primitive also discloses folder/image names and resolved absolute server paths. This is confirmed file-deletion/DoS impact only — it is not RCE. The upstream researcher explicitly tested the plausible escalation theory (deleting configuration.php to re-expose the Joomla web installer) live and disproved it: Joomla’s own core bootstrap redirects every request — including the exploit’s own — to /installation/index.php before any plugin code runs whenever installation/ is present, so the “delete config, then complete the installer” states never chain. The confirmed, honest impact ceiling is unauthenticated, guaranteed full-site DoS plus unauthenticated info disclosure — already Critical-severity on its own merits without an inflated RCE claim.
Environment / Lab Setup
Target: Joomla site (any version) with a Helix-Ultimate-based JoomShaper template installed —
plg_system_helixultimate enabled and active, versions 1.0-2.2.6
Attacker: Python 3 + requests + urllib3
Tools: helix_ultimate_detect.py, helix_ultimate_delete_poc.py (this folder)Setup Steps
| |
Proof of Concept
See
helix_ultimate_delete_poc.pyandhelix_ultimate_detect.py(both full, unmodified) andupstream-README.mdin this folder — mirrored from Is4yev/CVE-2026-57830. Verified before ingestion: both scripts read in full, cross-checked against the actual JoomShaperMedia.php/helixultimate.phpsource pre-fix (missingauthorise()ondeleteMedia()/getFolders(), present onuploadMedia()) and the vendor’s 2.2.7 fix commit confining file operations to validated paths viaHelper::resolveMediaPath(). Both scripts implement genuine, working requests-based exploitation: they harvest a real anonymous CSRF token from the target’s own homepage HTML and use it directly against thedelete-media/view-mediaAJAX actions — no obfuscation, no unrelated network calls, no destructive default behavior (the detect script never deletes anything; the delete script requires an explicit--deletepath argument).
Step-by-Step Reproduction
Non-destructive detection — confirms unauthenticated reachability of the Media class without touching anything:
Shell script1python3 helix_ultimate_detect.py https://target.comRead-only listing — enumerate folders/images at any root-relative (or one-level-escaping) path:
Shell script1 2python3 helix_ultimate_delete_poc.py https://target.com --list /images python3 helix_ultimate_delete_poc.py https://target.com --list /../sibling_dirDestructive delete — requires explicit
--delete, targets an attacker-chosen path:Shell script1 2python3 helix_ultimate_delete_poc.py https://target.com --delete /images/some_test_file.txt python3 helix_ultimate_delete_poc.py https://target.com --delete /some/folder --type folder
Exploit Code
| |
Expected Output
[*] Target: https://target.com
[*] Harvesting anonymous CSRF token from homepage (no login involved) ...
[*] Token: a1b2c3d4e5f6...
[*] Deleting file: /images/some_test_file.txt
[*] Response: {'status': True}
[+] Delete reported as SUCCESSFUL by the server.Screenshots / Evidence
Not included by the upstream author — the PoC’s own console output (shown above under Expected Output) and the live lab verification transcripts in upstream-README.md (“Live verification (2026-07-06)” and “Path traversal escapes JPATH_ROOT entirely — live proof (2026-07-06)”) serve as the evidence trail.
Detection & Indicators of Compromise
option=com_ajax&helix=ultimate&request=task&action=delete-media
option=com_ajax&helix=ultimate&request=task&action=view-mediaSIEM / IDS Rule (example):
alert http any any -> any any (msg:"Possible Helix Ultimate unauthenticated delete-media attempt"; content:"helix=ultimate"; http_uri; content:"action=delete-media"; http_uri; sid:9000002;)Remediation
| Action | Detail |
|---|---|
| Patch | Upgrade Helix Ultimate Framework to 2.2.7 or later — the fix confines file operations to validated paths via Helper::resolveMediaPath(). |
| Workaround | If upgrading is not immediately possible, add an authorise('core.edit', 'com_templates') (or equivalent core.delete) check to Media::deleteMedia() and Media::getFolders() in src/Platform/Media.php, matching the pattern already used by uploadMedia() in the same class. |
| Config Hardening | Disable/remove plg_system_helixultimate if the site does not actually need the framework’s front-end media AJAX actions; monitor and rate-limit option=com_ajax&helix=ultimate requests at the WAF/reverse-proxy layer. |
References
Notes
Verified before ingestion per this archive’s standard: read the full, real contents of both helix_ultimate_delete_poc.py and helix_ultimate_detect.py (not just the README) and cross-checked the claimed root cause against the actual JoomShaper Media.php/helixultimate.php source both pre-fix (missing authorise() gate on deleteMedia()/getFolders(), present and correct on the sibling uploadMedia()) and the vendor’s 2.2.7 fix commit, which confines file operations to validated paths via the new Helper::resolveMediaPath(). The author (Is4yev / Amin İsayev, Proxima Cyber Security, Azerbaijan) has a credible, non-throwaway account history (active since 2021) with prior legitimate Joomla CVE PoCs (CVE-2026-48909, CVE-2026-57829), which was treated as a track-record signal rather than sole evidence.
The upstream upstream-README.md is itself a strong positive signal of researcher rigor: it documents that an earlier draft’s RCE-escalation theory (deleting configuration.php to re-expose the Joomla web installer and complete a takeover) was tested live in a disposable Docker lab and explicitly disproved — Joomla’s core bootstrap redirects every request, including the exploit’s own, to /installation/index.php whenever that folder is present, so the two states never chain. The same document also self-corrects an earlier wrong claim that Media::createFolder() was unauthenticated-reachable, after a full pass over the plugin’s dispatch wiring showed that method is only reachable via an admin-gated code path (onAfterRespond() requiring isClient('administrator')). Both corrections were made by the author against their own prior work rather than surfaced externally, which is a meaningfully stronger signal than an uncorrected first draft. Confirmed unauthenticated capability set, final: delete (file or recursive folder) + read (folder/image listing) only — file-deletion/DoS impact, not RCE. This distinction is preserved precisely in this write-up’s Impact section above and should not be re-inflated to RCE in any downstream summary of this entry.
| |