A file cabinet that accepts PHP shells if you have a library card
Phoca Downloads is a file distribution component for Joomla — think document library, driver download page, media asset store. Versions 1.0 through 6.1.2 ship an upload handler that fails to enforce the file-type allowlist for authenticated Joomla users. A logged-in account (any role, including default Registered) can POST an executable file (.php, .phtml, .php7, sometimes hidden via double-extension or content-type games) into the component's storage directory, request it back over HTTP, and execute code as the web server user. Fixed in 6.1.3.
There is no vendor-issued CVSS baseline, only a third-party CVSS 4.0 score of 9.0 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H). That number is *directionally right but overstated for the median deployment*. Every reachable Phoca Downloads install ends at RCE, yes — but only after clearing authentication. On Joomla sites with self-registration disabled, the exposed population is only the site's existing user base. HIGH is the honest read; CRITICAL is reserved for pre-auth internet-facing bugs.
5 steps from start to impact.
Obtain a Joomla account
/index.php?option=com_users&view=registration endpoint, or reuses a leaked credential. Default Joomla installs allow self-registration; hardened sites disable it or gate it behind email verification and admin approval.- Registration enabled OR valid credential in hand
- Network reach to the Joomla frontend
- Many production Joomla deployments disable
Allow User Registration - CAPTCHA/email verification slows automation
- Fresh accounts often start in
Registeredrole with no upload UI visible
Reach the Phoca Downloads upload endpoint
com_phocadownload (typically index.php?option=com_phocadownload&view=user&layout=upload) or hits the AJAX handler directly. Presence of this route is what distinguishes a vulnerable site from a merely-Joomla site.com_phocadownloadinstalled and enabled- User-side upload permission granted in the extension config
- Admins often disable frontend uploads and use Phoca only as a read-only download library
- Group permissions in Joomla ACL frequently restrict uploads to
Authoror above
com_phocadownload upload views by non-admin usersBypass the file-type filter
shell.php.jpg), null-byte, alt PHP suffixes (.phtml, .php7, .pht), or .htaccess upload to re-map extension handling. Public writeups on similar Phoca family bugs (see CVE-2025-54473 in Phoca Commander) demonstrate the pattern; PoCs will surface fast.- Weak MIME/extension validation (this CVE's core defect)
- Apache/nginx configured to execute PHP from the upload directory
- Nginx with strict
location ~ \.php$regex often blocks double-extension execution - Some hosts serve
/images/phocadownload/via a static-only vhost
Execute the shell
www-data, apache, IUSR). From here: read configuration.php for the DB password, dump #__users, pivot to internal DB/network, or drop a persistent backdoor.- Uploaded file reachable via HTTP
- PHP handler active for that path
open_basedir,disable_functions, and PHP-FPM chroots limit post-exploitation- EDR on the web host catches shell spawns from
php-fpm
php-fpm → sh → curl/wget/nc; egress firewall catches reverse shellPivot / persist
configuration.php, tamper with hosted downloads to poison visitors, or plant a Joomla super-user via SQL. This is where a single-site RCE becomes a broader incident.- Outbound egress permitted
- Shared DB or file store with other tenants
- Segmented DMZ hosting
- Immutable content deployments (CI-only writes to webroot)
#__users audit; file-integrity monitoring on webrootThe supporting signals.
| In-the-wild exploitation | None observed as of 2026-07-12. No campaign attribution, no honeypot hits reported. |
|---|---|
| KEV status | Not listed in CISA KEV. |
| EPSS | Not yet scored (published <48h ago). Expect an initial score in the 0.1–1% band typical of authenticated web-extension file-upload CVEs. |
| Public PoC | No public PoC yet. Related Phoca family bug CVE-2025-54473 (Phoca Commander authenticated RCE) has PoCs on GitHub; the same technique class will apply. |
| CVSS | No vendor score. Third-party CVSS 4.0 = 9.0 with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H. The PR:L (auth required) and AT:P (attack requirements present) are the friction points. |
| Affected versions | Phoca Downloads 1.0 through 6.1.2 (all supported branches). |
| Fixed version | 6.1.3 — released alongside the advisory 2026-07-11. |
| Exposure population | Phoca Downloads is a mid-tier Joomla extension. Shodan/Censys queries for com_phocadownload in URLs return on the order of low tens of thousands of instances globally; a subset expose the frontend uploader. |
| Disclosure | Reserved 2026-06-25, published 2026-07-11. Coordinated with vendor. |
| Reporter | Phil Taylor (Joomla community security researcher). |
noisgate verdict.
The single decisive factor is authenticated access with post-auth full RCE on the web host — every prereq beyond a valid Joomla login is trivially satisfied, and on self-registration-enabled sites the auth requirement is a formality. Blast radius is bounded to the Joomla webroot and adjacent DB, which is meaningful but not fleet-scale, so this sits at HIGH rather than CRITICAL.
Why this verdict
- Authentication requirement caps the pre-auth blast radius — on hardened Joomla sites with registration off, the exposed population collapses to existing account holders, which pulls this off the CRITICAL bucket.
- Self-registration is Joomla's default, and thousands of Phoca-using sites leave it on — that keeps this well above MEDIUM.
PR:Lin CVSS 4.0 is doing real work here but is not a hard gate. - Role multiplier — canonical deployment role is a public-facing CMS content server, not an identity/hypervisor/CA. Successful chain ends in webroot RCE and DB compromise for that site, not fleet compromise. No high-value-role floor triggered.
- Fix is available same-day as disclosure (6.1.3), and the extension has a lightweight update path via Joomla's built-in updater — remediation friction is low, which does not reduce severity but constrains the window.
Why not higher?
CRITICAL requires either unauthenticated exploitation, KEV listing, active exploitation, or a high-value-role blast radius (DC, IdP, hypervisor, backup, CA, edge appliance). None apply: this needs a Joomla login, has no observed exploitation, and hits a CMS content tier — not identity or infrastructure. Third-party CVSS 9.0 overweights impact and underweights the auth gate.
Why not lower?
MEDIUM would ignore that Joomla's default configuration allows self-registration, making the auth barrier a speed bump rather than a wall. The outcome is unambiguous full RCE with follow-on DB and secret exposure — that is not a MEDIUM-class impact even when the population is narrow.
What to do — in priority order.
- Disable Joomla self-registration site-wide — Global Configuration → Users →
Allow User Registration = No. Collapses the attacker population to your existing user base. Deploy within 30 days per the noisgate mitigation SLA for HIGH; for internet-facing Phoca instances, do it today. - Revoke frontend upload permission from
RegisteredandAuthorgroups in Phoca Downloads config — Incom_phocadownloadcomponent options, setEnable User Upload = Noor restrict toManager+only. Blocks step 2 of the attack path even for authenticated users. Deploy within 30 days. - Deny PHP execution inside Phoca's upload directory at the webserver — Apache: drop
.htaccesswith<FilesMatch "\.ph(p[0-9]?|tml|ar|ps)$">Require all denied</FilesMatch>in/images/phocadownload/. Nginx:location ~ ^/images/phocadownload/.*\.ph(p[0-9]?|tml|ar|ps)$ { deny all; }. Neuters the payload even if it lands. Deploy within 30 days. - WAF rule: block multipart uploads to
com_phocadownloadupload views with executable extensions — ModSecurity/CRT/Cloudflare rule matchingoption=com_phocadownloadandContent-Disposition: filename=containing\.ph(p|tml|ar). Bridge control until the patch is deployed. - Upgrade to Phoca Downloads 6.1.3+ — The actual fix. Use Joomla's Extension Manager → Update. Complete within 180 days per the noisgate remediation SLA for HIGH; realistically do it within the mitigation window if the site is internet-facing.
- Joomla core version upgrades — this is a third-party extension bug; upgrading Joomla core to 5.x does not patch Phoca.
- Antivirus on the web host — most stock AV signatures do not flag benign-looking PHP web shells (e.g.,
<?php eval($_POST[x]);?>). - Fail2ban / rate limiting on login — the attacker uses a legitimate session; rate-limiting login attempts is orthogonal.
- CAPTCHA on registration alone — solvable and cheap; delays automation by hours, not months.
Crowdsourced verification payload.
Run on each Joomla host as any user with read access to the Joomla webroot. Invoke as ./check-phoca.sh /var/www/joomla where the argument is the Joomla installation path. No elevated privileges required beyond read access to administrator/components/com_phocadownload/phocadownload.xml.
#!/usr/bin/env bash
# noisgate check for CVE-2026-57828 — Phoca Downloads authenticated arbitrary file upload
# Usage: ./check-phoca.sh /path/to/joomla
set -u
JROOT="${1:-/var/www/html}"
FIXED_MAJOR=6
FIXED_MINOR=1
FIXED_PATCH=3
MANIFEST="$JROOT/administrator/components/com_phocadownload/phocadownload.xml"
ALT_MANIFEST="$JROOT/components/com_phocadownload/phocadownload.xml"
if [[ ! -f "$MANIFEST" && ! -f "$ALT_MANIFEST" ]]; then
echo "UNKNOWN: com_phocadownload not installed at $JROOT"
exit 2
fi
[[ -f "$MANIFEST" ]] || MANIFEST="$ALT_MANIFEST"
VER=$(grep -oE '<version>[^<]+</version>' "$MANIFEST" | head -1 | sed -E 's|</?version>||g')
if [[ -z "$VER" ]]; then
echo "UNKNOWN: could not parse version from $MANIFEST"
exit 2
fi
IFS='.' read -r MAJ MIN PAT <<<"$VER"
MAJ=${MAJ:-0}; MIN=${MIN:-0}; PAT=${PAT:-0}
vuln=1
if (( MAJ > FIXED_MAJOR )); then vuln=0
elif (( MAJ == FIXED_MAJOR && MIN > FIXED_MINOR )); then vuln=0
elif (( MAJ == FIXED_MAJOR && MIN == FIXED_MINOR && PAT >= FIXED_PATCH )); then vuln=0
fi
if (( vuln == 1 )); then
echo "VULNERABLE: Phoca Downloads $VER installed (fixed in 6.1.3)"
# Bonus: hunt for existing web shells in the upload dir
UPLOAD_DIR="$JROOT/images/phocadownload"
if [[ -d "$UPLOAD_DIR" ]]; then
SUSPECT=$(find "$UPLOAD_DIR" -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' -o -iname '*.php7' -o -iname '*.pht' \) 2>/dev/null)
if [[ -n "$SUSPECT" ]]; then
echo "WARNING: executable files already present in upload dir:"
echo "$SUSPECT"
fi
fi
exit 1
fi
echo "PATCHED: Phoca Downloads $VER (>= 6.1.3)"
exit 0
If you remember one thing.
com_phocadownload using the verification script, then flip Allow User Registration to No and disable frontend uploads in Phoca config on every hit — those two toggles kill the attack path in minutes. Per the noisgate mitigation SLA for HIGH, complete the registration/upload-permission lockdown and webserver-level PHP-execution deny inside /images/phocadownload/ within 30 days. Per the noisgate remediation SLA for HIGH, roll Phoca Downloads to 6.1.3+ across the fleet within 180 days — but if any affected site is internet-facing and self-registration is enabled, pull that timeline in to match the mitigation window. There is no KEV listing or active exploitation, so no emergency override applies today; revisit if a PoC lands publicly.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.