Threat feed
CVE-2026-48939 — Unauthenticated upload to RCE in iCagenda (Joomla): explainer & fixes
CVE-2026-48939: an unauthenticated file upload → RCE in Joomla's iCagenda events-calendar extension (3.2.1–3.9.14 / 4.0.0–4.0.7). CVSS 10.0 and actively exploited (CISA KEV). The real fix is updating to 3.9.15 / 4.0.8, plus a compromise check — defensively, no attack how-to.
A defensive advisory for a vulnerability with confirmed in-the-wild exploitation (listed in CISA KEV). What happens, what's affected, and how to respond — with no attack how-to or proof-of-concept. For the durable design-level defense, see file upload vulnerabilities and how to defend.
- CVE
- CVE-2026-48939
- Severity
- Critical (CVSS 10.0 / v4.0; 9.8 / v3.1) — actively exploited (CISA KEV)
- Type
- Unauthenticated arbitrary file upload → RCE (CWE-434)
- Impact
- Remote code execution (RCE) with no authentication
- Affected
- iCagenda for Joomla — 3.2.1–3.9.14 and 4.0.0–4.0.7
- Real fix
- Update to 3.9.15 or 4.0.8 or later
Why not-patching is dangerous
Because RCE is reachable without authentication, it's a prime target for blind scanning (which is why it made the KEV list). CISA ordered federal agencies to remediate by 2026-07-13. An events calendar may feel like a corner of the site, but if the public form is internet-facing, size is irrelevant.
What's affected
| Item | Detail |
|---|---|
| Extension | iCagenda for Joomla (events-calendar extension) |
| Affected versions | 3.2.1–3.9.14 and 4.0.0–4.0.7 |
| Fixed version | 3.9.15 / 4.0.8 and later |
| Precondition | No authentication required (via the public form) |
| Reachable impact | Remote code execution (RCE); data theft |
| Status | Actively exploited (CISA KEV; public PoC exists; remediation due 2026-07-13) |
A note on the root cause (an unsettled point)
NVD classifies this as CWE-434 (unrestricted upload of file with dangerous type). Some trackers frame the root cause as CWE-284 (improper access control) — pointing at the reported implementation flaw where authorization was checked only at the view layer. Both describe the same issue from different angles. The affected-version floor also varies across sources; this advisory uses NVD's range (from 3.2.1).
How to respond
Update to 3.9.15 / 4.0.8+ (top priority, the real fix)
Check for compromise (assume you were reached before updating)
Buy time until you can update (defense-in-depth)
Inventory extensions + machine-monitor CVEs
This site's take: kill the pattern, not just the CVE
This is one instance of a pattern being exploited across Joomla extensions in a row. In the same period, CVE-2026-48908 (SP Page Builder) and a sibling extension, CVE-2026-56290, were exploited the same way — "unauthenticated upload → RCE." The single update is mandatory, but what pays off long-term is designing the pattern out: authenticate the upload endpoint, allow-list plus content-inspect server-side, and store outside the web root or disable execution. See file upload vulnerabilities and how to defend.
Read next
- Defense (durable): file upload vulnerabilities — designing out web shells / RCE
- Same pattern, alert: CVE-2026-48908 (SP Page Builder / Joomla)
- Glossary: what RCE (remote code execution) is / what a CVE is
- All alerts: vulnerability alerts
FAQ
QWhat does CVE-2026-48939 let an attacker do?
An unauthenticated attacker can upload an arbitrary file (e.g. PHP) through the public event-registration form of a Joomla site running iCagenda, and have it executed — reaching remote code execution (RCE). That leads directly to defacement, data theft, secretly minted admin accounts, and pivoting to other systems. It is a worst-case flaw: CVSS 10.0, with confirmed in-the-wild exploitation (CISA KEV; remediation due 2026-07-13).
QWhat's the surest fix?
Update the iCagenda extension to 3.9.15 (3.x line) or 4.0.8 (4.x line) or later. Until you can, reduce exposure in layers: restrict access to the public event-registration form / attachment feature, disable script execution in the upload directory, and use a WAF. If you don't use it, removing it is the surest fix.
QIf I update, am I safe from compromise?
Updating stops future intrusion, but whether you were reached between disclosure and patching is a separate question. This pattern persists via web shells and rogue admin accounts, so after updating always run a compromise check (stray PHP in the upload directory, unexpected admins, odd outbound traffic).