If you received an email from me pointing you to this page, it is because your website appears to be running a version of iCagenda (JoomliC’s com_icagenda, an events calendar extension for the Joomla content management system) that is affected by a known security issue. This page explains what the issue is, how to check whether it applies to you, and how to fix it.

This notice concerns CVE-2026-48939, a critical, actively exploited flaw that allows unauthenticated arbitrary file upload leading to remote code execution through the extension’s front-end “Submit an Event” form. It was added to the U.S. Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog on 10 July 2026.

Two conditions, and both have to hold

Your site is affected by the remote-code-execution issue when both of these are true:

  1. iCagenda is on the 4.0.x line, at a version below 4.0.8 (that is, 4.0.0 through 4.0.7), and
  2. Joomla core is below 6.1.2.

If iCagenda is 4.0.8 or later, you are not affected. And if your Joomla core is 6.1.2 or later, you are not affected either, even on an old iCagenda, because the core itself blocks the upload. If that describes your site you can stop reading here, other than to note that updating iCagenda is still worth doing.

The second condition is the part where this page disagrees with the vendor’s own advisory, which says the problem only reaches sites running Joomla 6. It reaches fully up-to-date Joomla 4 and Joomla 5 sites too, and I set out the evidence for that below, because you will see the vendor say otherwise if you follow the link.

If you are on an affected version, update iCagenda, and because this flaw was exploited before a fix existed, also check your site for signs that someone got there first (see If you were on an affected version below).

A note for anyone on the older 3.9.x line. The published CVE range includes 3.9.x, and the vendor patched that line too, in 3.9.15. From my own reading and testing, the 3.9.x line uses a different, protected code path for the upload, so the remote-code-execution outcome is not reachable there: on Joomla 4 and 5 the upload is blocked by the core, and on Joomla 6 that code path no longer exists at all, so the feature simply errors. That is not a reason to ignore the update. The same releases fix a missing authorization check that lets an anonymous visitor push an unapproved event into your site (and, on Joomla 4 and 5, a file of a permitted type along with it). Lower severity, still worth fixing: update to 3.9.15 or later. Note also that the vendor provides security patches for the 3.9.x line only until 13 October 2026.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, upload anything, or exploit anything.

What I read were two public files that your site serves to anyone who asks for them: the iCagenda component manifest at /administrator/components/com_icagenda/icagenda.xml, and the Joomla core manifest at /administrator/manifests/files/joomla.xml. Both are plain XML version files, and they are the same two files described under How to check your versions below, so you can see exactly what I saw. That is the whole of it. I specifically did not submit your event form, did not upload anything, and did not request the attachments directory on your site. That path appears further down this page only as a place for you to look on your own site. Nothing about this check touches your data, your admin area, or any private part of your site.

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

iCagenda publishes an events calendar on Joomla sites. One of its features lets a visitor submit an event through a front-end form, optionally attaching a file, which lands under images/icagenda/frontend/attachments/.

In affected versions, that submission is accepted without logging in, and the attachment is written to disk without any check on what kind of file it is, keeping the name and extension the submitter chose. That combination lets an attacker place a program of their choosing on your server and run it: full remote code execution, with no account and no cooperation from you required.

Nothing has to be switched on for this to apply. The form does not have to be published or visible to visitors: in affected versions the controller behind it accepted the submission regardless.

This is not a theoretical risk. It is scored 9.8 out of 10 by NVD (and 10.0 by the assigning authority under the newer scoring system), and it is being exploited in the wild. The vendor reports exploitation beginning on 15 June 2026 at 08:00 UTC, before the patch existed, and describes the attacks as automated. CISA added it to the Known Exploited Vulnerabilities catalog on 10 July 2026.

I am describing this at the level a site owner needs in order to act, and no further. I am not publishing the details that would let someone reproduce it, and I would ask you not to try it against your own site or anyone else’s. Reading your two version numbers, as described below, tells you everything you need in order to decide what to do.

If my email cited this issue, it means the versions your site reports put it inside the affected range on both counts. I did not test whether your particular site is exploitable or already compromised.

Where this page differs from the vendor’s advisory

The vendor’s advisory is worth reading and I link it below. They shipped a fix quickly and their guidance is good. But one scoping sentence in it does not hold up, and since it is the sentence that would tell most readers of this page to relax, I want to show my work rather than just assert. The advisory says:

Unsafe file uploads were already blocked by default on all Joomla versions prior to Joomla 6. Only install of iCagenda on Joomla 6 (6.0.0-6.1.1) had the critical upload vulnerability.

Here is what I measured, on isolated installations of my own. No third-party site was involved at any point.

  • iCagenda 4.0.x performs the upload through the framework class Joomla\Filesystem\File, which comes from the joomla/filesystem package that Joomla core bundles. It does not use the older Joomla CMS class of the same name, which is the one that has always carried a safe-file check and is presumably the one the advisory has in mind.
  • That framework method only gained its own safe-file check (the $allowUnsafe parameter and the isSafeFile test) in joomla/filesystem 4.2.0, which is the version that ships with Joomla 6.1.2.
  • The versions actually bundled with the Joomla releases I checked: Joomla 4.4.14 ships filesystem 2.0.2 (no check), Joomla 5.4.7 ships 3.2.0 (no check), and Joomla 6.1.2 ships 4.2.0 (check present).

So a fully patched Joomla 4 or Joomla 5 site running iCagenda 4.0.0 through 4.0.7 is exposed, and that is why this page states the Joomla condition as “below 6.1.2” rather than “Joomla 6 only”. Nothing in the published CVE record, the NVD entry, or the CISA catalog scopes this issue by Joomla version at all; the advisory’s sentence is the only place such a limit appears.

How to check your versions

You do not have to take my word for either number, and there are two of them to check.

Your iCagenda version, from the manifest file (no login needed): open

yourdomain.com/administrator/components/com_icagenda/icagenda.xml

and read its <version> element. That is one of the two files I read.

Your iCagenda version, from the admin area:

  1. Log in to your Joomla administrator (usually at yourdomain.com/administrator).
  2. Go to System then Manage then Extensions.
  3. Search for iCagenda and note the installed version.

Mind which icagenda.xml you read. The iCagenda package also ships a bundled search plugin with a manifest of the same name, carrying its own unrelated version number. Only the component path above tells you what the extension is running.

Your Joomla core version: in the administrator, go to System then System Information. Or read /administrator/manifests/files/joomla.xml and take its <version> element. That is the other file I read.

There is no way to tell iCagenda’s version from your public page source, and you should not try. The extension’s front-end assets carry Joomla’s site-wide media hash rather than a version number, and the one version-shaped number that does appear in the page source belongs to the calendar module’s asset bundle (a low number such as 1.0.4) and has nothing to do with the component. The manifest file or the administrator screen is the only honest check.

Then apply the rule at the top of this page: the 4.0.x line below 4.0.8 and a core below 6.1.2 means affected.

How to upgrade

The safest path is to update through Joomla itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a Joomla backup extension.
  2. In the Joomla admin, open Extensions then Manage then Update, and click Find Updates. If an iCagenda update is listed, install it from here.
  3. If no update appears there, download the current release directly from the vendor, JoomliC, and install it via Extensions then Install.
  4. Which version to install: 4.0.8 is the release that fixes this issue, but the current release at the time of writing is 4.0.11, and the releases after 4.0.8 add further protection around the same feature, including blocking code execution from the iCagenda media folder. Go to 4.0.11 rather than stopping at 4.0.8. On the older line, go to 3.9.15 or later.
  5. Alternatively, updating Joomla core to 6.1.2 or later also closes this particular issue, but it is not a substitute for updating the extension: the missing authorization check is in iCagenda itself and only an iCagenda update fixes that.
  6. After upgrading, confirm the new version number using the steps above, and check that your calendar still displays and that event submission still works the way you expect.

While you are in there, it is worth confirming that Joomla itself and your other extensions are up to date, since the same principle applies to all of them.

If you were on an affected version

Because this flaw was exploited before a fix was available, a site that ran an affected version should not assume that updating is enough. Updating closes the door, but it does not tell you whether anyone had already walked through it. That is worth checking calmly rather than assuming the worst: most sites will find nothing. In the vendor’s own words:

The update closes the entry point and protect the file attachment feature, but does not clean up an already compromised site. […] Keep a copy of any suspicious files as evidence, delete them, change your Joomla passwords and credentials, and audit your entire site, not just the iCagenda folder.

Here is what you (or your webmaster) can look for on your own site:

  • PHP files under images/icagenda/frontend/attachments/. That folder should only ever hold event attachments. On a Linux host, the check is:

    find images/icagenda/frontend/attachments -name '*.php' -type f
  • Unapproved anonymous events sitting in your moderation queue, which you would not expect if you never opened event submission to the public.
  • Hits in your access logs from a scanner identifying itself as icagenda-batch/1.0.

From 4.0.8 onward, iCagenda also checks for signs of compromise itself and raises an alert after you update if it finds any. The vendor is straightforward that the absence of that alert is not a guarantee, so it is a useful signal rather than a clean bill of health.

If you find any of these, treat the site as compromised: keep copies of the suspicious files as evidence and then remove them, rotate all credentials (Joomla admin, database, FTP/SSH, hosting panel), review your Joomla user accounts and the groups they belong to, and audit the whole site rather than just the iCagenda folder. Restoring from a backup taken before 15 June 2026 is often safer than cleaning in place, because a backdoor left behind can undo the cleanup. If your organization has an IT security team or a national CERT, loop them in.

I want to be clear: I have not checked your site for any of these indicators, and I do not know whether your site was affected. This list is here so that you can check for yourself.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor (JoomliC)