CVE-2026-73373 is a critical (CVSS 9.8) unrestricted upload flaw in Joomla core: SHTML files were missing from the default list of dangerous file types. On servers that execute them, that can mean code execution. Upgrade to Joomla 5.4.8 or 6.1.3.
What's affected
Joomla CMS versions 1.0.0 through 5.4.7 and 6.0.0 through 6.1.2, according to the Joomla Security Centre announcement 20260810. The fix is in 5.4.8 and 6.1.3.
The announcement rates the issue's severity as low and probability as low, with impact high. That differs from the NVD score of 9.8. The difference comes from a condition: the web server has to execute SHTML files, which means server side includes have to be enabled for the upload location. Check your own server rather than assuming.
The project lists the reported date as 29 July 2026 and the fixed date as 18 August 2026.
How to check if you're exposed
In the Joomla administrator, open System, then System Information to read the version.
Then check your web server for server side includes. On Apache, look for the Includes option or a handler for .shtml files in your configuration and .htaccess files.
grep -rniE "Includes|server-parsed|shtml" /etc/apache2 /var/www --include=*.conf --include=.htaccess
Adjust paths for your setup. On nginx, look for the ssi directive. Also look in your media and image upload folders for any .shtml files you did not put there.
What to do now
- Upgrade Joomla to 5.4.8 (5.x line) or 6.1.3 (6.x line).
- Disable server side includes for upload directories if you do not need them.
- Search upload directories for .shtml files and investigate any you did not add.
- Review which users can upload files through the media manager.
- Keep extensions updated, because many have their own upload handling.
Why it matters
The record maps this to CWE-434, unrestricted upload of a file with a dangerous type. Upload features keep a list of file types that must never be accepted, because the web server might treat them as something to run. If the list is missing a type, the guard has a hole.
The point worth taking from the Joomla announcement is that exposure depends on the server as much as on the application. An uploaded SHTML file is harmless on a server that serves it as plain text and risky on one that processes server side includes. Defense in depth means both an allowlist of accepted file types in the application and a server configuration that never executes content in upload folders.
The KEV flag is false and the record does not describe exploitation.
Reading the project's own rating
Joomla's announcement rates severity and probability as low, with impact high, while NVD shows 9.8. That is a useful reminder that scores describe a worst case, and that real risk depends on configuration. Here the deciding factor is whether your web server executes SHTML. Check, record the answer, and move on to patching either way. Teams that triage by score alone would call this an emergency, and teams that triage by the vendor's rating might ignore it. Reading the conditions is better than either.
Hardening uploads in general
Even after the update, tighten how uploads are served. Keep upload directories outside any path where the server executes content. Turn off server side includes, CGI and script handlers there. Serve user files with a content type that browsers will not run. And limit who can upload. These steps protect you from the next file type that someone forgets to put on the list.
The free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project you maintain pulls in an affected package, and the Gold vulnerability directory keeps the record for this CVE.
Quick check
Do I need to act if SSI is off on my server?
Upgrade anyway. The condition limits the impact, but the default list was wrong and the fix is a routine update.
Sources
Last reviewed: 19 October 2026.
