CVE-2026-48939: iCagenda unauthenticated file upload RCE in public event submission form

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.

• 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:

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:

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.