← Back to Feed CACHED · 2026-07-12 01:27:57 · CACHE_KEY CVE-2026-57828
CVE-2026-57828 · CWE-434 · Disclosed 2026-07-11

The Joomla extension Phoca Downloads is vulnerable to an authenticated arbitrary file upload

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"Authenticated RCE in a niche Joomla extension. Trivial to weaponize when self-registration is on; irrelevant when it's off."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain a Joomla account

Attacker registers via the site's /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.
Conditions required:
  • Registration enabled OR valid credential in hand
  • Network reach to the Joomla frontend
Where this breaks in practice:
  • Many production Joomla deployments disable Allow User Registration
  • CAPTCHA/email verification slows automation
  • Fresh accounts often start in Registered role with no upload UI visible
Detection/coverage: Auth logs show new account creation; WAFs rarely flag registration
STEP 02

Reach the Phoca Downloads upload endpoint

Authenticated user navigates to the frontend upload form exposed by 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.
Conditions required:
  • com_phocadownload installed and enabled
  • User-side upload permission granted in the extension config
Where this breaks in practice:
  • Admins often disable frontend uploads and use Phoca only as a read-only download library
  • Group permissions in Joomla ACL frequently restrict uploads to Author or above
Detection/coverage: Web access logs show hits on com_phocadownload upload views by non-admin users
STEP 03

Bypass the file-type filter

Attacker submits a PHP payload with an allowed extension trick — double extension (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.
Conditions required:
  • Weak MIME/extension validation (this CVE's core defect)
  • Apache/nginx configured to execute PHP from the upload directory
Where this breaks in practice:
  • Nginx with strict location ~ \.php$ regex often blocks double-extension execution
  • Some hosts serve /images/phocadownload/ via a static-only vhost
Detection/coverage: Static file analysis / YARA on upload dirs catches web shells post-facto
STEP 04

Execute the shell

Attacker requests the uploaded file over HTTP. PHP interprets it, executing as the web server user (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.
Conditions required:
  • Uploaded file reachable via HTTP
  • PHP handler active for that path
Where this breaks in practice:
  • open_basedir, disable_functions, and PHP-FPM chroots limit post-exploitation
  • EDR on the web host catches shell spawns from php-fpm
Detection/coverage: EDR flags php-fpm → sh → curl/wget/nc; egress firewall catches reverse shell
STEP 05

Pivot / persist

Web shell used to enumerate the LAN, harvest secrets from 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.
Conditions required:
  • Outbound egress permitted
  • Shared DB or file store with other tenants
Where this breaks in practice:
  • Segmented DMZ hosting
  • Immutable content deployments (CI-only writes to webroot)
Detection/coverage: Joomla #__users audit; file-integrity monitoring on webroot
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed as of 2026-07-12. No campaign attribution, no honeypot hits reported.
KEV statusNot listed in CISA KEV.
EPSSNot yet scored (published <48h ago). Expect an initial score in the 0.1–1% band typical of authenticated web-extension file-upload CVEs.
Public PoCNo public PoC yet. Related Phoca family bug CVE-2025-54473 (Phoca Commander authenticated RCE) has PoCs on GitHub; the same technique class will apply.
CVSSNo 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 versionsPhoca Downloads 1.0 through 6.1.2 (all supported branches).
Fixed version6.1.3 — released alongside the advisory 2026-07-11.
Exposure populationPhoca 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.
DisclosureReserved 2026-06-25, published 2026-07-11. Coordinated with vendor.
ReporterPhil Taylor (Joomla community security researcher).
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.8/10)

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.

HIGH technical impact (RCE) and affected version range
MEDIUM real-world exposure population (Shodan/Censys estimates for `com_phocadownload`)
LOW exploitation timeline — no PoC yet, but the bug class is well-understood

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:L in 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. Revoke frontend upload permission from Registered and Author groups in Phoca Downloads config — In com_phocadownload component options, set Enable User Upload = No or restrict to Manager+ only. Blocks step 2 of the attack path even for authenticated users. Deploy within 30 days.
  3. Deny PHP execution inside Phoca's upload directory at the webserver — Apache: drop .htaccess with <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.
  4. WAF rule: block multipart uploads to com_phocadownload upload views with executable extensions — ModSecurity/CRT/Cloudflare rule matching option=com_phocadownload and Content-Disposition: filename= containing \.ph(p|tml|ar). Bridge control until the patch is deployed.
  5. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: inventory every Joomla instance for 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

  1. CVE-2026-57828 record (ThreatINT)
  2. NVD entry for CVE-2026-57828
  3. MITRE CVE record
  4. Phoca Downloads product page
  5. Phoca Downloads on Joomla Extension Directory
  6. Joomla Vulnerable Extensions List
  7. Related Phoca family CVE-2025-54473 (Phoca Commander RCE)
  8. CISA KEV catalog
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.