Table of Contents
- Reporting a vulnerability
- Fixed in 6.6.0
- What to do
- EGSA-2026-06: Cross-site request forgery of list tasks of the back end
- EGSA-2026-07: The image proxy of the Google Photos picker fetched any address with the token of the account
- EGSA-2026-08: Cross-site scripting and open redirect on the share mini page
- Hardening in 6.6.0 without a known vulnerability
- September 2026: fixed in 6.5.0 and 4.3.3
- What to do
- EGSA-2026-01: Path traversal in Clear Cache
- EGSA-2026-02: Cross-site scripting and open redirect on the front-end upload page
- EGSA-2026-03: Cross-site request forgery of the upload
- EGSA-2026-04: Cross-site request forgery of the cart
- EGSA-2026-05: Cross-site request forgery of the clean-up links of the back end
- Hardening in 6.5.0 without a known vulnerability
This chapter says how to report a vulnerability (Reporting a vulnerability) and lists the vulnerabilities which were fixed in Event Gallery: which versions they affect, what an attacker needs to exploit them, which version fixes them and what you should do. The release note of the fixing version names them as well, in its section Security Fixes.
Every vulnerability has an identifier of the form EGSA-<year>-<number>. When a CVE ID is assigned, it is added here.
The severity is the CVSS 4.0 base score as assessed by the maintainer. For the entries of September 2026 it is the score of the CVE record: Joomla’s CVE Numbering Authority scored them with CVSS 4.0 when it assigned the CVE IDs, and these scores replaced the CVSS 3.1 scores the maintainer had published with 6.5.0.
The list starts with the release 6.5.0. Security relevant changes of earlier versions, such as the brute force protection and the random download tokens of 6.0.0, are described in the release notes of their version.
If you found a vulnerability in Event Gallery, please send it by mail to svenbluege@gmail.com. Please do not report it in a public place - a forum, a public issue tracker, a comment or social media - so that sites can update before others learn about it.
A good report says:
- the versions of Event Gallery, Joomla and PHP you found it with;
- which page, request or parameter is affected;
- the steps to reproduce it, or a proof of concept;
- what an attacker can do with it, and which account or permissions they need;
- whether it is known elsewhere already;
- how you would like to be credited.
What happens then:
- You get a confirmation within one business day and a first assessment within five business days. If the investigation takes longer, you hear how it goes.
- The fix is developed in private. If you like, you can check it before the release.
- The date of the publication is agreed with you. A vulnerability which is already exploited is fixed and published as fast as possible.
- Every vulnerability gets a CVE ID, requested from Joomla’s CVE Numbering Authority before the release.
- The fixed version names the vulnerability in its release note and in this chapter - enough to decide how urgent the update is, but without a working exploit.
- You are credited in the form you choose: your name, a handle, your organisation, or not at all. Nothing which identifies you is published without your consent.
Security fixes are made for the current version of Event Gallery only; older versions get no fixes. 4.3.3 for Joomla 3 and Joomla 4 was a one-time exception. There is no bug bounty.
Good-faith security research is welcome. Researchers who follow this policy will not be subject to legal action by the maintainer solely for activities conducted in accordance with it. Please test on an installation of your own, and do not
- access data of other people beyond what is needed to show the vulnerability,
- run destructive tests or denial of service attacks,
- use social engineering,
- scan web sites of others automatically,
- keep access to a system or take data from it.