CVE-2026-48939: Verified Repro With Script Download

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.

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.

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

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

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:

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.