## Summary

CVE-2026-48939 is an unauthenticated arbitrary PHP file upload vulnerability in the iCagenda Joomla extension public event submission workflow. In iCagenda 4.0.7, a guest can submit the public event form with a PHP file in the attachment field. The component stores the attachment, preserving a PHP extension, under Joomla's web-accessible `images/icagenda/frontend/attachments/` directory. On a Joomla 6 / Apache PHP deployment, requesting the uploaded `.php` file over HTTP executes attacker-controlled PHP code. The reproduction script demonstrates this end-to-end and compares it with iCagenda 4.0.8, which blocks the same PHP upload.

## Impact

- **Package/component affected:** iCagenda Joomla extension (`com_icagenda`), specifically the frontend public event submission attachment handling.
- **Affected versions:** The ticket identifies iCagenda 3.2.1 through 4.0.7, also described as 1.0.0 through 4.0.7. This run validated iCagenda **4.0.7** as vulnerable.
- **Fixed versions:** iCagenda **4.0.8** for the 4.x branch and 3.9.15 for the legacy branch, per the ticket/advisory.
- **Risk level and consequences:** Critical. An unauthenticated remote attacker can upload a PHP web shell through the public event submission form and then execute commands in the web server context (`www-data` in the reproduced Docker deployment). This can lead to full compromise of the Joomla site, disclosure or modification of site data, persistence, and lateral movement depending on host configuration.

## Impact Parity

- **Disclosed/claimed maximum impact:** unauthenticated remote code execution via arbitrary PHP upload through the public iCagenda event submission form.
- **Reproduced impact from this run:** full unauthenticated PHP code execution. The vulnerable run uploaded `pruva-rce-vulnerable.php` through the real public iCagenda event submit endpoint and then fetched `/images/icagenda/frontend/attachments/pruva-rce-vulnerable.php?cmd=id`. The HTTP response contained the attacker-controlled PHP marker and command output: `uid=33(www-data) gid=33(www-data) groups=33(www-data)`.
- **Parity:** `full`.
- **Not demonstrated:** No privilege escalation beyond the web server user was attempted; the reproduced impact is remote command execution as the Joomla/Apache PHP process user.

## Root Cause

In iCagenda 4.0.7, the frontend submit model reads uploaded files from the public event form and passes the attachment directly to `frontendFileUpload()`:

- `SubmitModel::submit()` obtains `$files = $jinput->files->get('jform')` and `$file = $files['file']`.
- For a non-empty attachment, it sets `$eventData->file = $this->frontendFileUpload($file)`.
- `frontendFileUpload($file)` derives a slugged filename while preserving the original extension, creates `images/icagenda/frontend/attachments/`, and calls `Joomla\Filesystem\File::upload($src, $dest, false)` with a destination below the web root.

On Joomla 6, the framework `Joomla\Filesystem\File::upload()` moves the uploaded file but does not perform CMS media allow-list validation. Therefore, a `.php` attachment remains a `.php` file and is served/executed by Apache/PHP from the web-accessible attachments directory.

The fixed iCagenda 4.0.8 code adds Joomla media validation before storing attachments. The local source evidence captured by the script shows 4.0.8 importing and invoking `Joomla\CMS\Helper\MediaHelper` / `MediaHelper::canUpload($file)` before `frontendFileUpload()`. In the fixed runtime, the same PHP attachment is not written and the shell URL returns HTTP 404.

No specific fix commit hash was provided in the ticket. The validated fixed artifact is the official iCagenda 4.0.8 package.

## Reproduction Steps

1. Run `bundle/repro/reproduction_steps.sh`.
2. The script:
   - starts real Docker product stacks for Joomla 6.0 / PHP 8.3 / Apache and MySQL 8.0;
   - installs official iCagenda 4.0.7 in the vulnerable stack and official iCagenda 4.0.8 in the fixed stack;
   - configures a public iCagenda submit menu and enables the file attachment field;
   - fetches the public event submission form and extracts the CSRF token;
   - submits an unauthenticated multipart form upload containing a PHP shell through `index.php?option=com_icagenda&task=submit.submit`;
   - requests the uploaded PHP artifact over HTTP with `?cmd=id`; and
   - repeats the same path against iCagenda 4.0.8 as a fixed-version negative control.
3. Expected evidence:
   - vulnerable iCagenda 4.0.7 stores `pruva-rce-vulnerable.php` under `images/icagenda/frontend/attachments/`;
   - HTTP GET to the uploaded PHP file returns `PRUVA_PHP_SHELL_ACTIVE_VULNERABLE` and command output from `id` as `www-data`;
   - fixed iCagenda 4.0.8 does not store `pruva-rce-fixed.php` and the shell URL returns HTTP 404.

## Evidence

Primary runtime artifacts from the successful run:

- `bundle/logs/reproduction_steps.log` — full product deployment, extension installation, form submission, uploaded PHP execution, and fixed negative control log.
- `bundle/repro/fetch_vulnerable_rce.log` — HTTP response from the uploaded PHP shell in the vulnerable deployment.
- `bundle/repro/fetch_fixed_rce.log` — HTTP 404 response for the same shell path in the fixed deployment.
- `bundle/repro/upload_vulnerable.log` — HTTP response to the unauthenticated vulnerable form submission.
- `bundle/repro/upload_fixed.log` — HTTP response to the fixed-version form submission.
- `bundle/repro/submitted_files_vulnerable.txt` — container-side listing showing `pruva-rce-vulnerable.php` saved in the attachments directory.
- `bundle/repro/submitted_files_fixed.txt` — fixed-version listing showing the attachment directory was absent / PHP shell not stored.
- `bundle/logs/vulnerable_source.log` and `bundle/logs/fixed_source.log` — runtime source/version evidence from inside each Joomla container.
- `bundle/repro/runtime_manifest.json` — structured runtime evidence manifest written by the script.

Key vulnerable evidence excerpt from `bundle/logs/reproduction_steps.log` and `bundle/repro/fetch_vulnerable_rce.log`:

```text
vulnerable: public form reached with Itemid=112, catid=1, CSRF=...
vulnerable: submitting unauthenticated event form with PHP attachment pruva-rce-vulnerable.php
index.html 47 bytes
pruva-rce-vulnerable.php 258 bytes
vulnerable: requesting uploaded PHP URL http://172.20.0.1:18139/images/icagenda/frontend/attachments/pruva-rce-vulnerable.php?cmd=id
HTTP/1.1 200 OK
PRUVA_PHP_SHELL_ACTIVE_VULNERABLE
PRUVA_ATTACKER_COMMAND_OUTPUT_BEGIN
uid=33(www-data) gid=33(www-data) groups=33(www-data)
PRUVA_ATTACKER_COMMAND_OUTPUT_END
```

Key fixed-version negative-control excerpt:

```text
fixed: public form reached with Itemid=112, catid=1, CSRF=...
fixed: submitting unauthenticated event form with PHP attachment pruva-rce-fixed.php
attachments directory absent
fixed: requesting uploaded PHP URL http://172.20.0.1:18140/images/icagenda/frontend/attachments/pruva-rce-fixed.php?cmd=id
HTTP/1.1 404 Not Found
Fixed iCagenda 4.0.8 negative control passed: PHP shell was not stored/executed
```

Environment details captured by the script include the Docker images `mysql:8.0` and `joomla:6.0-php8.3-apache`, Apache/PHP version output in the source logs, and iCagenda package version evidence.

## Recommendations / Next Steps

- Upgrade iCagenda to **4.0.8** or later (or **3.9.15** or later for legacy 3.x deployments).
- Ensure all frontend file upload paths enforce server-side allow-list validation for extension, MIME type, and file content before saving files.
- Store user-uploaded files outside executable web roots where possible; alternatively configure the web server to disable PHP execution in upload directories such as `images/icagenda/frontend/attachments/`.
- Add regression tests that submit disallowed extensions (`.php`, `.phtml`, `.phar`) through the public event form and assert that the files are neither stored nor executable.
- Consider scanning existing `images/icagenda/frontend/attachments/` directories for unexpected PHP or other executable files on previously exposed sites.

## Additional Notes

- The generated reproduction script was run twice consecutively and passed both times after the install-path adjustment.
- The proof uses the real product and the public HTTP/API boundary: a running Joomla service, official iCagenda packages, a public event submission form, a multipart upload, and an HTTP request to the uploaded artifact.
- The RCE behavior depends on a Joomla 6 / Apache PHP deployment where PHP files under the images directory are executable. This matches the public PoC/advisory description that the uploaded `.php` files execute on Joomla 6.
- No sanitizer or mock harness was used; `sanitizer_used=false` is appropriate for the runtime verdict.