## Summary

No confirmed bypass or distinct vulnerable variant was found. The variant stage tested the most relevant alternate public upload path: the iCagenda public event submission endpoint using the `jform[image]` field instead of the disclosed `jform[file]` attachment field. A GIF/PHP polyglot named with a `.php` filename was submitted unauthenticated to both iCagenda 4.0.7 and fixed iCagenda 4.0.8. Both versions stored the file as `.gif` under `images/icagenda/frontend/images/`, and neither version executed it as PHP on the tested Joomla 6 / Apache PHP runtime. The 4.0.8 attachment fix therefore appears to cover the disclosed RCE path, and the alternate image field did not produce RCE or a fixed-version bypass.

## Fix Coverage / Assumptions

The iCagenda 4.0.8 fix relies on the invariant that dangerous event attachment uploads pass through Joomla media validation before any file is written into the web-accessible Joomla images tree.

Explicitly covered code paths:

- Frontend public event attachment path:
  - `site/src/Model/SubmitModel.php`
  - `SubmitModel::submit()` reads `$jinput->files->get('jform')`, extracts `$files['file']`, and now invokes `Joomla\CMS\Helper\MediaHelper::canUpload($file)` before attachment storage.
  - `SubmitModel::frontendFileUpload($file)` now performs a second `MediaHelper::canUpload($file)` check before slugging the filename and calling `Joomla\Filesystem\File::upload()` into `images/icagenda/frontend/attachments/`.
- Administrator event attachment path:
  - `admin/src/Model/EventModel.php`
  - `EventModel::save()` now validates `$files['file']` with `MediaHelper::canUpload()` before calling `EventModel::upload()`, which writes to `images/icagenda/files/`.

The fix does not add `MediaHelper::canUpload()` to `SubmitModel::frontendImageUpload($image)`. That function still implements its own image handling and writes to `images/icagenda/frontend/images/`. The variant test focused on this gap because it is the only materially distinct unauthenticated upload field found in the public submit form. Runtime evidence showed this path did not preserve a PHP extension and did not execute PHP in either tested version.

The extracted iCagenda packages did not include a `SECURITY.md` or threat-model document. A web search found Joomla's security policy and iCagenda's 4.0.8 security-release documentation, but no iCagenda policy excluding unauthenticated public upload RCE from security scope. The trust boundary used for the search is therefore the public Joomla frontend event submission form when configured with public submit access and enabled upload fields.

## Variant / Alternate Trigger

Tested alternate trigger:

- Entry point kind: HTTP endpoint.
- Endpoint: `/index.php?option=com_icagenda&task=submit.submit`.
- Alternate field: multipart `jform[image]`, instead of the original `jform[file]` attachment field.
- Payload: valid GIF header plus embedded PHP code, submitted with multipart filename `pruva-image-field-<role>.php` and content type `image/gif`.
- Tested targets:
  - Vulnerable control: iCagenda 4.0.7 official package.
  - Fixed target: iCagenda 4.0.8 official package.

Relevant code path:

- `site/src/Controller/SubmitController.php::submit()` validates CSRF and the submitted event form, then calls the submit model.
- `site/src/Model/SubmitModel.php::submit()` reads `$files = $jinput->files->get('jform')`, `$image = $files['image']`, and invokes `frontendImageUpload($image)` when the image field is present.
- `site/src/Model/SubmitModel.php::frontendImageUpload($image)` extracts the uploaded name extension, uses `getimagesize($src)` for non-image extensions, rewrites the destination extension based on detected MIME, and writes to `images/icagenda/frontend/images/` with `File::upload()`.

Observed behavior:

- In iCagenda 4.0.7, the alternate image-field payload was stored as `pruva-image-field-vulnerable.gif`; requesting the `.php` path returned 404, and requesting the `.gif` path returned static `image/gif` bytes containing the PHP text without execution.
- In iCagenda 4.0.8, the same alternate image-field payload was stored as `pruva-image-field-fixed.gif`; the `.php` path returned 404, and the `.gif` path returned static `image/gif` bytes without executing `cmd=id`.

No other public unauthenticated upload sink reaching `File::upload()` was found in source inspection. The administrator event attachment path is related but requires administrator authentication and is also covered by `MediaHelper::canUpload()` in 4.0.8, so it is not a same-trust-boundary public variant.

## Impact

- Package/component affected: iCagenda Joomla extension (`com_icagenda`).
- Parent affected version as reproduced: iCagenda 4.0.7.
- Fixed version tested for bypass: iCagenda 4.0.8.
- Parent risk: critical unauthenticated RCE through arbitrary PHP attachment upload.
- Variant-stage result: no RCE from the tested alternate image upload field. The uploaded polyglot content was stored and web-accessible as an image file, but not executed as server-side PHP on the tested default Joomla Apache PHP stack.

## Impact Parity

- Disclosed/claimed maximum impact for the parent issue: unauthenticated remote code execution by uploading a PHP web shell through the public event submission attachment field.
- Reproduced impact from this variant run: no code execution. The alternate image path accepted and stored a GIF/PHP polyglot in both versions, but requests returned static `image/gif` content and did not run `cmd=id`.
- Parity: `none`.
- Not demonstrated: no fixed-version RCE bypass, no command execution, and no privilege escalation. The run did not test non-default web-server configurations that intentionally execute `.gif` or other image extensions as PHP.

## Root Cause

The parent vulnerability exists because iCagenda 4.0.7's public `jform[file]` attachment path preserved attacker-controlled PHP extensions and wrote the file beneath a web-executable directory. iCagenda 4.0.8 addresses that root cause for attachment fields by adding Joomla `MediaHelper::canUpload()` validation before the `File::upload()` sink.

The tested alternate `jform[image]` path reaches a similar file-write sink but not the same dangerous extension-preserving behavior. When supplied a `.php` filename containing valid GIF bytes, `frontendImageUpload()` detects the image MIME type and stores the file with a `.gif` extension. The tested Apache PHP configuration executes files matching `.php` only; it served the `.gif` payload as static `image/gif`. Therefore, the same underlying executable-extension root cause was not reachable through this alternate public image field in the tested target.

No fix commit hash was provided. The tested fixed artifact was the official iCagenda 4.0.8 package with SHA-256 `be3788daaef85b903b540685eebeec2bf3257ed2cc02159f11fbddf5e707ce74`.

## Reproduction Steps

1. Run `bundle/vuln_variant/reproduction_steps.sh`.
2. The script:
   - starts isolated Docker Joomla/MySQL stacks for iCagenda 4.0.7 and iCagenda 4.0.8;
   - installs the official iCagenda packages;
   - configures a public iCagenda submit menu with upload fields enabled;
   - fetches the public submit form and CSRF token;
   - submits an unauthenticated event using `jform[image]` with a GIF/PHP polyglot named `.php`;
   - checks container-side stored filenames; and
   - requests both the would-be `.php` URL and the actual `.gif` URL with `?cmd=id`.
3. Expected evidence for the negative variant result:
   - both versions reach the public form;
   - both versions store `pruva-image-field-<role>.gif` under `images/icagenda/frontend/images/`;
   - both would-be `.php` URLs return HTTP 404;
   - both `.gif` URLs return static `image/gif` content containing the PHP text but no `uid=33(www-data)` command output;
   - the script exits 1 to indicate no fixed-version bypass reproduced.

## Evidence

Primary evidence locations:

- `bundle/logs/vuln_variant/reproduction_steps.log` — full script log from the latest idempotency run.
- `bundle/logs/vuln_variant/vulnerable_version.txt` — iCagenda 4.0.7 package URL, SHA-256, PHP/Apache version, and relevant source anchors.
- `bundle/logs/vuln_variant/fixed_version.txt` — iCagenda 4.0.8 package URL, SHA-256, PHP/Apache version, and relevant `MediaHelper::canUpload()` source anchors.
- `bundle/vuln_variant/submitted_images_vulnerable.txt` and `bundle/vuln_variant/submitted_images_fixed.txt` — container-side file listings showing `.gif` storage.
- `bundle/vuln_variant/fetch_image_vulnerable_php.log` and `bundle/vuln_variant/fetch_image_fixed_php.log` — HTTP 404 responses for the would-be preserved `.php` URLs.
- `bundle/vuln_variant/fetch_image_vulnerable_gif.log` and `bundle/vuln_variant/fetch_image_fixed_gif.log` — HTTP 200 static `image/gif` responses containing the embedded PHP text but no execution output.
- `bundle/vuln_variant/runtime_manifest.json` — structured runtime manifest.

Key excerpts from the latest run:

```text
vulnerable: submitting unauthenticated event form with image-field GIF/PHP polyglot named pruva-image-field-vulnerable.php
index.html 47 bytes
pruva-image-field-vulnerable.gif 198 bytes
vulnerable: PHP image URL returned HTTP 404
vulnerable: GIF image URL returned HTTP 200
vulnerable: image-field payload did not execute as PHP
```

```text
fixed: submitting unauthenticated event form with image-field GIF/PHP polyglot named pruva-image-field-fixed.php
index.html 47 bytes
pruva-image-field-fixed.gif 193 bytes
fixed: PHP image URL returned HTTP 404
fixed: GIF image URL returned HTTP 200
fixed: image-field payload did not execute as PHP
No fixed-version bypass reproduced. Vulnerable image RCE=false; fixed image RCE=false; vulnerable stored=true; fixed stored=true.
```

Environment and source identity excerpts:

```text
role=fixed
package_url=https://www.joomlic.com/download/icagenda/icagenda-core-4-0-8/package-icagenda-core-4-0-8-zip
be3788daaef85b903b540685eebeec2bf3257ed2cc02159f11fbddf5e707ce74  .../icagenda-4-0-8-package.zip
PHP 8.3.30
Server version: Apache/2.4.66 (Debian)
<version>4.0.8</version>
use Joomla\CMS\Helper\MediaHelper;
$can = $helper->canUpload($file);
```

## Recommendations / Next Steps

- Keep the iCagenda 4.0.8 `MediaHelper::canUpload()` validation on all event attachment upload paths.
- Consider applying `MediaHelper::canUpload()` or an equivalent strict allow-list to `frontendImageUpload()` as defense in depth, even though the tested default runtime did not execute image extensions.
- Store all user-uploaded event files outside executable web roots where possible.
- Ship `.htaccess` or web-server configuration that disables PHP/script execution in `images/icagenda/frontend/attachments/`, `images/icagenda/frontend/images/`, and `images/icagenda/files/`.
- Add regression tests for public submit uploads covering `.php`, `.phtml`, `.phar`, multi-extension filenames such as `.jpg.php`, and image polyglots submitted through both `jform[file]` and `jform[image]`.

## Additional Notes

The variant script was executed twice. Both executions completed without crashing and exited 1, which is the intended script result for "no fixed-version bypass reproduced." The latest run log is stored at `bundle/logs/vuln_variant/reproduction_steps.log`; the live shell output from the previous run showed the same negative result. The conclusion is limited to the tested Joomla `joomla:6.0-php8.3-apache` runtime and official iCagenda 4.0.7/4.0.8 packages.