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 item.checkin task accepts an unauthenticated sigProFolder query parameter and uses it directly to address a JFolder::delete() call under /media/k2/galleries/

The K2 frontend article-attachment upload path accepts files whose extension is .php, and Apache's standard modphp 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 frontend article-save handler accepts an attachment[N][existing] POST field that is concatenated with JPATHSITE/ 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.26 renders the #k2users.image column directly into HTML src attributes via two distinct templates, in both cases without HTML escaping.

K2 ≤ 2.24 contains a mass-assignment defect in the K2 system user plugin plguserk2. A Registered Joomla user, by including the field K2UserForm=1 in a standard comusers profile.save POST, can write arbitrary values into the notes, image, and plugins columns of their own row in the #k2users table — none of which are exposed by the K2 frontend profile-edit form.