Two Joomla file upload vulnerabilities landed on CISA’s Known Exploited Vulnerabilities catalog on July 10. Both were already being hit by automated attackers weeks before anyone assigned them a CVE number. CVE-2026-48939 hits the iCagenda events extension. CVE-2026-56291 hits Balbooa Forms. Each scores a maximum 10.0 on CVSS 4.0. Each traces back to the same root cause: an upload handler that trusted a filename it should never have trusted.
The Joomla file upload vulnerabilities CISA flagged
CISA’s July 10 update flagged both flaws as actively exploited. It gave federal civilian agencies until July 13 to patch or mitigate, per Binding Operational Directive requirements. That window has now closed. For everyone outside federal government, the deadline is really just a signal. Attackers had automated tooling running against iCagenda before CISA even knew about it, so any unpatched site is still exposed today. It is the same fast-exploitation pattern seen with Palo Alto’s GlobalProtect authentication bypass earlier this year. Attackers moved faster than the patch cycle could keep up.
Both bugs share the same CWE classification, unrestricted upload of file with dangerous type, and the same practical effect. An attacker with no account and no special access can plant a working PHP file inside the web root. Requesting it directly hands them code execution on the server.
Inside the iCagenda attack
iCagenda’s flaw sits in the “Submit an Event” feature on Joomla 6.0.0 through 6.1.1. The file attachment step failed to check what kind of file it was actually receiving. Security firm mySites.guru first spotted it after a client’s access log showed a short, ugly sequence. A POST hit the submission endpoint, then a follow-up request pulled the freshly planted file straight back out of the attachments folder. As the researchers put it, it had the shape of an attack that already knew it had won.
The scanning tool identified itself with the user agent icagenda-batch/1.0. That suggests purpose-built automation, not a one-off manual probe. According to JoomliC’s own advisory, mass exploitation began at 8am UTC on June 15, hours before the vendor shipped a fix. iCagenda 4.0.8 patched the Joomla 6 upload bug that same day. Legacy branch 3.9.15 followed on June 16, fixing a lower-severity issue in older Joomla versions.
Balbooa Forms: three failures stacked together
Balbooa Forms went the same way but with a slightly different chain of mistakes. The vulnerable endpoint, com_baforms&task=form.uploadAttachmentFile, skipped an authentication check and skipped Joomla’s CSRF token verification. It also never validated the uploaded file’s type against an allow-list. Worse, the code ran the attacker’s chosen filename through Joomla’s File::makeSafe() function. That function sanitises characters but does nothing to block a .php extension. It then reattached that extension before writing the file into a publicly reachable, PHP-executable directory.
A customer’s Hetzner abuse report brought the bug to light on July 8. Researchers reproduced the exploit within an hour of seeing the raw access log. Balbooa’s team turned around a fix, version 2.4.1, the very next day. Independent researcher Phil Taylor is credited with the report.
What Joomla admins should check now
Patching is the first step. It isn’t the whole job if a site sat exposed during the exploitation window. Anyone running iCagenda should look inside images/icagenda/frontend/attachments/ for files that don’t belong there, particularly anything with a .php extension. Also check the events queue for submissions nobody approved. Balbooa Forms users should inspect images/baforms/uploads/ for the same kind of unexpected executable content.
Because both flaws grant code execution, a clean-looking upload folder isn’t proof of a clean site. Once an attacker has a shell, the next move is usually a new admin account, or sometimes a modified core file elsewhere. Anyone who finds evidence of compromise should treat it as a full incident, not a single-file cleanup. Rotate credentials, audit recently modified files across the install, and don’t assume the attacker stopped at the upload folder.
The pattern here is a familiar one for anyone who tracks Joomla and WordPress extension security. The platform core can be solid while a widely installed add-on quietly becomes the weakest point in the chain. It is the second Joomla extension flaw exploited as a zero-day in barely a month, following the Joomla JCE exploit in June. Two unrelated developers made the same mistake within weeks of each other. Both paid for it with a zero-day before they even knew there was a bug to fix. These Joomla file upload vulnerabilities are a reminder that a popular extension is not automatically a well-tested one.