# CVE-2026-48939 Fix Verification Report

## Fix Summary

The iCagenda 4.0.7 public event submission form allowed an unauthenticated user to upload an arbitrary file, including `.php` files, through the `jform[file]` attachment field. The uploaded file was stored under the web-accessible `images/icagenda/frontend/attachments/` directory and executed as PHP by the web server, leading to remote code execution. The fix adds Joomla's `MediaHelper::canUpload()` validation at the two points where an attachment is handled—the public `SubmitModel::submit()` entry point and the reusable `SubmitModel::frontendFileUpload()` method—so that unsafe uploads are rejected before any file is written to the web root.

## Changes Made

- `components/com_icagenda/src/Model/SubmitModel.php`
  - Added `use Joomla\CMS\Helper\MediaHelper;` to the import list.
  - In `submit()`, immediately after extracting `$file` from the request, create a new `MediaHelper` instance and call `canUpload($file)`. If the file is not allowed, return `false`.
  - Store the validated upload result in a local `$fileLink` variable and assign it to `$eventData->file`, avoiding the previous double-call to `frontendFileUpload()`.
  - In `frontendFileUpload()`, add a second `MediaHelper::canUpload()` guard at the top of the method so any future caller also rejects unsafe files before writing to `images/icagenda/frontend/attachments/`.

The administrative attachment path in `admin/src/Model/EventModel.php` was also hardened by the vendor in 4.0.8, but it is not part of the unauthenticated CVE described in the ticket, so this patch focuses on the public `SubmitModel` only.

## Verification Steps

1. Prepared a fresh Joomla 6.0 / PHP 8.3 / Apache stack with a MySQL 8.0 database on port 18141.
2. Installed the official vulnerable iCagenda 4.0.7 package via the Joomla CLI extension installer.
3. Copied `bundle/coding/proposed_fix.diff` into the running container and applied it to `/var/www/html/components/com_icagenda/src/Model/SubmitModel.php` with `patch -p1`.
4. Restarted Apache to clear any opcache and reloaded the patched source.
5. Configured iCagenda for public event submission by enabling `submitAccess` for guest users and `submit_fileDisplay`, and added a public "Verify Submit" menu item.
6. Extracted the Joomla CSRF token from the public submit form.
7. Submitted the public event form with a PHP web-shell payload (`verify_rce.php`) as the attachment.
8. Checked the `images/icagenda/frontend/attachments/` directory and requested the expected PHP shell URL.
9. Submitted the same form again with a legitimate text file (`verify_legit.txt`) as the attachment and fetched the stored file.

## Test Results

| Test | Expected | Result |
|------|----------|--------|
| PHP attachment upload | Rejected, no `.php` file stored, no RCE | **PASSED** — attachments directory was absent after submission; PHP shell URL returned HTTP 404 |
| Legitimate text attachment upload | Stored and retrievable | **PASSED** — `verify-legit.txt` was stored in `images/icagenda/frontend/attachments/` and returned HTTP 200 with the original content |

Console output from the verification script:

```
[INFO] Patch applied successfully
[INFO] Files after PHP upload attempt:
attachments directory absent
[INFO] PHP shell fetch returned HTTP 404
[INFO] PHP upload was blocked as expected
[INFO] Files after text upload attempt:
index.html 47 bytes
verify-legit.txt 33 bytes
[INFO] Legit attachment fetch returned HTTP 200
[INFO] CVE-2026-48939 fix verification PASSED
```

## Remaining Concerns

- The fix relies on Joomla's `MediaHelper::canUpload()` whitelist, which is configured by the Joomla media settings. Administrators should ensure that dangerous extensions (e.g., `.php`, `.phtml`, `.phar`, `.htaccess`) are not present in allowed upload types.
- The companion `frontendImageUpload()` method does not use `MediaHelper::canUpload()` in the vendor's 4.0.8 release. The variant analysis tested this path with a GIF/PHP polyglot and confirmed it did not yield PHP execution on the tested Joomla 6 / Apache runtime because the file was stored with a `.gif` extension. Sites running different web-server configurations (e.g., handlers that execute `.gif` as PHP) may want to additionally harden the image upload path.
- The patch should be packaged into a new iCagenda release and distributed to affected users; applying the source patch directly to a live site is sufficient for validation but not a long-term deployment strategy.