Phoca Gallery 6.1.6 fixes a stored XSS hidden in a photo's EXIF data

On 19 October 2026 Phoca released Phoca Gallery 6.1.6, a security release for the Joomla gallery extension. The release notes say one thing about it: “This is a security release.” The Joomla CNA published the detail as CVE-2026-102786 on 23 October 2026, a stored cross-site scripting flaw through HTML attribute injection, affecting Phoca Gallery 4.5.0 to 6.1.5.

We read the 6.1.5 to 6.1.6 diff to work out what that means for a site running the extension. It means a photo can attack the person looking at it. The EXIF metadata inside an uploaded image was written into the photo’s info page without escaping, so a crafted image runs script in the browser of anyone who opens that view, and the fix is only on offer to Joomla 6 sites.

TL;DR

• Phoca Gallery 4.5.0 to 6.1.5 builds the front-end photo info view from the image’s own EXIF metadata, and raw fragments of it reach the page markup
• A crafted EXIF value breaks out of an HTML attribute and runs as script when anyone opens that photo’s info view, in the context of your site
• The attacker needs to get an image into a gallery: back-end upload rights, or the front-end user upload feature, which is off by default
• 6.1.6 fixes it, and only on the Joomla 6 line. The current Joomla 5 (5.1.3) and Joomla 4 (4.5.5) releases are inside the affected range with no patched successor
• Most affected sites run Joomla 6 and update normally. Joomla 4 and 5 sites have to install the 6.x package by hand or remove the component
• The flaw is CVE-2026-102786, CVSS 4.0 8.6 High, published by the Joomla CNA on 23 October 2026. This is Phoca’s fix; we analysed the release after it shipped

How a photo’s EXIF data becomes script in Phoca Gallery

Phoca Gallery has a front-end info view for each image that shows the camera data stored inside the file: the EXIF block that a camera or phone writes at capture time, and that any image editor can rewrite afterwards. Part of that block is the GPS position, which EXIF stores as fractions, and the view in site/views/info/view.html.php split those fractions on the / and joined the pieces into a display string for the page.

Before 6.1.6 the pieces went into that string exactly as they were read from the file. The view expected numbers and never checked that it had them. An EXIF field that holds a quote mark and some markup instead of a number closes the HTML attribute it was dropped into, and whatever follows is parsed as part of the page. The browser runs it with the site’s own origin, for whoever opened the photo.

That is what makes this stored rather than reflected. The payload lives in the image file in the gallery, so it fires for every visitor who opens that photo’s info view until the image is removed, with nothing in the URL to give it away. An administrator who opens it from the back end hands over their session, which is why the CNA scored confidentiality and integrity both high.

The attacker’s only requirement is to get the image into a gallery. On a typical site that means an account with upload rights in the Phoca Gallery back end. If the front-end user upload feature is switched on, which it is not by default, a lower-privileged user can do it from the public side. That is the gap between the CNA’s title, which says “authenticated”, and its vector, which says no privileges required: the person who plants the image needs access, the person it fires on needs none.

What changed in Phoca Gallery 6.1.6

The fix is in one file, the info view, and it is the only functional change between the 6.1.5 and 6.1.6 tags. Each component of the EXIF fractions is now cast to a float before it is used, and a division by zero is guarded so a zero denominator no longer produces an error or an odd value. Only numeric data reaches the markup, so there is nothing left for a crafted EXIF value to break out with.

That is a narrow fix for a narrow path. It treats the GPS fields as numbers, which they are supposed to be, and it closes the attribute injection. It does not add output escaping across the rest of the view, so the release tells you which values were the problem rather than hardening the whole page, and the CNA’s description matches that scope.

Which Phoca Gallery versions are affected?

Phoca Gallery 4.5.0 to 6.1.5 inclusive, which is the range the Joomla CNA record names. Phoca maintains one release line per Joomla version, and only the Joomla 6 line received the fix:

That table comes from Phoca’s update manifest, which matches each Joomla generation to a release on a targetplatform pattern. The Joomla 5 release, 5.1.3, and the Joomla 4 release, 4.5.5, both sit inside 4.5.0 to 6.1.5 and neither has a patched successor. A site on either of them cannot update to safety from Joomla’s update screen.

The Joomla 3 line is a different case. Its newest release, 3.2.8, is below the 4.5.0 floor of the published range, so we are not claiming it is affected, and we are not claiming it is clean either. The CNA record does not cover it.

Joomla 4 and 5 sites have to install Phoca Gallery 6.1.6 by hand

Phoca’s update feed offers each Joomla version one release, and Joomla discards any offered version that is not higher than the one installed. On Joomla 4 and Joomla 5 that produces two different failures:

• A Joomla 4 or 5 site on the 4.x or 5.x line is offered 4.5.5 or 5.1.3. Both are inside the affected range, so the site owner can apply the update in good faith and still be exposed.
• A Joomla 4 or 5 site already running a 6.x build is offered a lower version. Joomla shows no update at all, and the site looks current while it runs 6.1.5 or older.

The fix in both cases is the 6.x package from the 6.1.6 release, installed through Joomla’s extension installer after a backup. That may mean moving the site to Joomla 6 first, and if the gallery is no longer earning its place on the site, removing the component is the shorter route.

Across the Joomla sites we manage, the majority of the affected Phoca Gallery installs run Joomla 6 and will update normally. About one in seven is on a Joomla 4 or 5 line with no fixed release. That proportion is from sites that an agency actively looks after; the wider Joomla world still runs a lot of Joomla 4, so the share of stranded galleries out there is likely higher.

What to do about it on each Joomla version

1. Joomla 6: update Phoca Gallery to 6.1.6 through the normal Joomla updater, then confirm the version number.
2. Joomla 5: take a backup, then install the 6.x package by hand from the GitHub release. Do not take the 5.1.3 the updater offers as a fix for this. If the package will not install on your site, plan the move to Joomla 6 or remove the gallery.
3. Joomla 4: the same choice. The updater’s 4.5.5 is inside the affected range. Install the 6.x package by hand after a backup, which will usually mean moving the site to Joomla 6 first, or remove the component until you can.
4. On any Joomla version: this is stored XSS, so the question is who could have planted an image. If front-end user upload was ever enabled, review which accounts had it and what they uploaded. Check the existing galleries for images added by accounts you do not recognise, and treat an administrator who opened a suspect photo’s info view as having a session that may have been used.

How mySites.guru flags vulnerable Phoca Gallery installs

The Phoca Gallery version alone does not tell you what to do here. You need the Joomla version beside it, because that decides whether the updater will deliver 6.1.6, whether you need the package by hand, or whether the site has to move to Joomla 6 first.

mySites.guru keeps both for each connected Joomla site. We added this flaw to our vulnerability database on the day the CVE was published, so every site running Phoca Gallery between 4.5.0 and 6.1.5 is flagged on its dashboard now, with the Joomla version on the same screen. The Joomla 6 sites can go out in one batch with the mass updater, which leaves a short list of Joomla 4 and 5 sites for the manual package. That works the same way across a portfolio of Joomla sites of any size, and is part of every subscription.

Why a gallery’s EXIF data is attacker-controlled

EXIF is written by whoever made the file. A camera fills it in, but so does any image editor, any command-line tool, and any script, and the file does not care whether the GPS field holds a fraction or a sentence. From the moment a site accepts an uploaded image, every byte of its metadata is input from the person who uploaded it, and a feature that reads that metadata back onto a page is an injection surface in the same way a comment form is. Developers tend to see the image as a blob and the EXIF as trusted camera data, when it is a user-supplied text block that happens to travel inside a JPEG.

In fifteen years of looking after client sites, the galleries have been the features nobody reviews. They are installed once for a photo page, the upload accounts are handed out to whoever runs the events, and the extension sits there for a decade. A flaw in the info view of a gallery on a site like that fires on the one person who clicks every photo to check it, which is usually the administrator.

This is the third Phoca extension this year where the fix reached only the current Joomla line. The Phoca Cart product filter SQL injection in August showed the distribution problem first, the Phoca Cart download IDOR in October repeated it, and the Phoca Download upload flaw had the same shape. Phoca is quick with the fix each time. What a site on an older Joomla gets from each release is a version number that looks current and the same vulnerable code underneath, and the release notes do not say which lines were left out.