Focus on joomlaworks vulnerabilities and metrics.
Last updated: 13 Jul 2026, 22:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with joomlaworks. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total joomlaworks CVEs: 10
Earliest CVE date: 23 Feb 2010, 18:30 UTC
Latest CVE date: 25 Jun 2026, 16:16 UTC
Latest CVE reference: CVE-2026-48946
30-day Count (Rolling): 7
365-day Count (Rolling): 7
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 2.27
Max CVSS: 7.5
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 7 |
| 4.0-6.9 | 2 |
| 7.0-8.9 | 2 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for joomlaworks, sorted by severity first and recency.
The K2 frontend article-attachment upload path accepts files whose extension is `.php`, and Apache's standard mod_php matches `\.php$` and executes them under the K2 web user. A K2 Author can upload a `shell.php`, then fetch `/media/k2/attachments/shell.php` and execute arbitrary PHP code in the web server's context.
The K2 article gallery upload path accepts a zip/tar archive, extracts it under `/media/k2/galleries/<id>/`, and only renames image files (gif/jpg/jpeg/png/webp) to safe names — non-image files (including `.php`) are extracted as-is and remain executable via direct HTTP access.
The K2 frontend article-save handler accepts an `attachment[N][existing]` POST field that is concatenated with `JPATH_SITE/` and passed to `JFile::copy()`. `JPath::clean` does NOT strip `..`, and there is no allow-list of source paths. An Author can therefore copy `configuration.php` (or any other file readable by the web user — including `../../../etc/passwd`) into `/media/k2/attachments/`, then retrieve the contents via the K2 attachment-download endpoint.
K2 ≤ 2.24 contains a mass-assignment defect in the K2 system user plugin `plg_user_k2`. A Registered Joomla user, by including the field `K2UserForm=1` in a standard `com_users` `profile.save` POST, can write arbitrary values into the `notes`, `image`, and `plugins` columns of their own row in the `#__k2_users` table — none of which are exposed by the K2 frontend profile-edit form.
K2 ≤ 2.26 renders the `#__k2_users.image` column directly into HTML `src` attributes via two distinct templates, in both cases without HTML escaping.
The K2 frontend `item.checkin` task accepts an unauthenticated `sigProFolder` query parameter and uses it directly to address a `JFolder::delete()` call under `/media/k2/galleries/`
A Joomla user with K2 "create item" rights (Author tier by default) can submit an article whose `embedVideo` POST field contains a raw `<script>` tag; K2 stores it verbatim and renders it unescaped to any visitor of the article page.
class.upload.php in verot.net class.upload through 1.0.3 and 2.x through 2.0.4, as used in the K2 extension for Joomla! and other products, omits .pht from the set of dangerous file extensions, a similar issue to CVE-2019-19576.
class.upload.php in verot.net class.upload before 1.0.3 and 2.x before 2.0.4, as used in the K2 extension for Joomla! and other products, omits .phar from the set of dangerous file extensions.
The K2 component 2.8.0 for Joomla! has Incorrect Access Control with directory traversal, allowing an attacker to download arbitrary files, as demonstrated by a view=media&task=connector&cmd=file&target=l1_../configuration.php&download=1 request. The specific pathname ../configuration.php should be base64 encoded for a valid attack. NOTE: the vendor disputes this issue because only files under the media-manager path can be downloaded, and the documentation indicates that sensitive information does not belong there. Nonetheless, 2.8.1 has additional blocking of .php downloads
Directory traversal vulnerability in includes/download.php in the JoomlaWorks AllVideos (Jw_allVideos) plugin 3.0 through 3.2 for Joomla! allows remote attackers to read arbitrary files via a ./../.../ (modified dot dot) in the file parameter.