Five Security Issues in JEM (Joomla Event Manager), and No Stable Fix Yet

JEM, the Joomla Event Manager, is a long-running events component for Joomla. During security research on the extensions our customers rely on, mySites.guru found several security issues in JEM and reported them privately to the developers and to the Joomla Security Strike Team. The Joomla project’s CVE Numbering Authority has assigned five CVE IDs.

The most serious of them lets an anonymous visitor, with no account at all, overwrite and publish a Joomla article. There is one catch that shapes everything below: the fixes exist so far only in a release candidate, not a stable release, so there is no finished version to update to yet. This post covers what was found, the CVE numbers, and what you can do right now.

TL;DR

• mySites.guru found and privately reported multiple security issues in JEM (Joomla Event Manager), the com_jem component, confirmed against JEM 5
• The most serious lets an anonymous visitor overwrite and publish a Joomla article with no login. Others allow a registered user to take over another user’s event or venue, a reflected cross-site scripting flaw in the PDF export link, and attendee data readable by any logged-in user
• The Joomla CNA assigned five CVE IDs, and all five published on 27 August 2026, each crediting mySites.guru as the finder: CVE-2026-77991 (9.4 Critical), CVE-2026-77034 (6.9), CVE-2026-77990 and CVE-2026-77989 (5.3 each), and CVE-2026-77035 (5.1)
• The fixes are in JEM 5.0.1, which at the time of writing exists only as a public release candidate, not a stable release. The newest stable version, 5.0.0, is affected
• There is no stable fix to install yet. Apply the mitigations below, and update to JEM 5.0.1 the moment the stable release is available
• mySites.guru flags every connected Joomla site running an affected version of JEM automatically

What was found

We confirmed four issues against JEM 5 and noted two more from reading the code. We are describing them at the level of what an attacker can do and how to limit it, not publishing working exploits.

An anonymous visitor can overwrite and publish an article

JEM has a front-end action that updates the Joomla content article linked to an event, and it performed no permission check before writing to that article, including setting it to published. A visitor with nothing more than an ordinary session could republish and overwrite an article, including one that was unpublished. This is the most serious of the set because it needs no account at all and it writes to core Joomla content.

A registered user can take over another user’s event or venue

The check that decides whether you may edit a record trusted values sent in the request rather than the values stored in the database. A logged-in user with permission to edit their own events could send another user’s record along with their own identifier and take the record over. This needs only a plain registered account on a site that lets members create events.

A reflected cross-site scripting flaw in the PDF export link

The export link copied the page’s request parameters into the page without escaping them, so a crafted link could inject markup that runs in the victim’s browser. Joomla’s standard text filtering does not stop this, because the injection does not need HTML tags.

Attendee data readable by any logged-in user

The attendee list only checked that a visitor was logged in, not that they were entitled to see that event’s attendees. Any registered user could read attendee names, usernames, registration dates and statuses for events they do not manage, including events that are not published.

Two further items we noted from the code but did not exploit: an authenticated back-end file write that did not restrict file types, and a stored cross-site scripting issue through unescaped category names. Both need an account with elevated permissions, so they rank below the four above.

The five CVEs

The Joomla project operates its own CVE Numbering Authority, and it assigned five identifiers for these issues on 22 August. All five published on 27 August 2026, and every record credits mySites.guru as the finder. Each one gives the affected range as 1.0.0 to 5.0.0, fixed in 5.0.1.

The top score revises what we said above. We put the back-end file write in the “noted from the code, did not exploit” pile and ranked it below the four confirmed issues. The CNA scored it 9.4 Critical, the highest of the set, because writing PHP to the server is code execution however you arrive at it. It does need an account that already holds administrator access, which is why the record calls it privileged rather than unauthenticated. But if you are deciding who gets an administrator login on a site running JEM, decide it on the 9.4.

What to do right now

There is no stable release to update to yet, so the immediate job is to reduce who can reach the affected features:

1. Find your JEM sites. If you use mySites.guru, we have already flagged every connected site running an affected version of JEM, so you have the list. If not, check each site’s installed extensions for JEM and confirm the version.
2. Restrict front-end editing. If your site lets members create or edit events and venues from the front end, limit that to trusted users, or turn it off until you can update. This closes the record-takeover route and the article-overwrite route on any site that had front-end submission enabled.
3. Restrict the front-end attendees view to event managers rather than any logged-in user, so attendee lists are not readable by ordinary members.
4. Watch for JEM 5.0.1 stable and update the moment it ships. The fixes are already written; they just need to be released as a stable version rather than a release candidate. We will update this post when that happens.

Do not put the release candidate straight onto a production site you care about. A release candidate is a test build, not a finished release. The safer path is the mitigations above now, then the stable 5.0.1 when it is out.

How mySites.guru handles this across many sites

If you manage more than a handful of Joomla sites, the hard part of a story like this is not the fix, it is finding every site that needs it before an attacker does. mySites.guru keeps a live inventory of every extension on every connected site and flags the ones running affected versions, so a vulnerability like this turns into a filtered list rather than an afternoon of logging into control panels. When JEM 5.0.1 stable ships, the same list tells you which sites still need the update.

A note on how this was disclosed

Why is a set of security issues public before there is a stable fix to install? Because the corrected code was pushed to a public release candidate on GitHub before a coordinated release. Once the fix is public, anyone can compare it against the current version and see what changed, which is the moment a private disclosure stops being private. The Joomla Security Strike Team, which assigned the CVE numbers, put it to the vendor: the uncoordinated release candidate turned a responsible disclosure of security issues into a public matter.

We recently republished the Joomla project’s own guidance for extension developers handling a security report, twenty documented practices, and a couple of them are worth noting here. One is to keep the fix private until a coordinated stable release, rather than shipping it in a public release candidate. Another, point 17, is not to hide security fixes in vague language: the commits with these fixes are described with lines like “Improve frontend attendee access handling”, which give no sign that they are security fixes at all. None of this is a swipe at the JEM developers, who are volunteers and who engaged once the report reached them. It is why coordinated disclosure exists, and it is the same standard we hold every extension to.

Where this stands, four days on

Updated 26 August 2026. Four days after the CVE IDs were assigned there is still no stable JEM release, and the gap between what is public and what is installable has got wider rather than narrower.

One useful thing did come out of the RC2 changelog. The vendor’s own version labels list 4.4.2 and 4.5.0 as affected alongside 5.0.0, which is the first confirmation that this reaches back beyond JEM 5 into the 4.x line. If you run JEM 4.x and had filed this away as a JEM 5 problem, it affects you too. The same changelog notes that only stable releases confirmed in the project history are labelled, so older versions are not cleared, they are simply unlabelled.

We will update this post with the CVE record links, scores and the stable release version once they are available.