This is a spare master key hidden behind the receptionist desk, not a crowbar at the front door
CVE-2026-48907 maps to JCE's insufficient profile access validation in the file browser: a logged-in Joomla user could reach an Editor Profile they were not assigned and then use whatever file-browser actions that borrowed profile allowed. Public reporting around the 2.9.99.4 security release says all prior JCE Free and JCE Pro versions were affected, with the fixed release shipping on May 28, 2026 for Joomla 3.10, 4.x, 5.x, and 6.x; your prompt's June 5, 2026 date is best understood as CVE disclosure timing rather than patch availability.
Reality is lower than the scary reading of 'file browser actions' suggests. This is not unauthenticated remote compromise: the attacker needs a valid Joomla session first, then only inherits the permissions of another JCE profile, so the blast radius is heavily shaped by whether the target site has public registration, multiple editor roles, and permissive JCE filesystem settings. JCE's popularity keeps this from being LOW, but the post-auth requirement and configuration-bounded impact keep it out of HIGH.
4 steps from start to impact.
Get any valid Joomla session
- Joomla site exposes a login-capable workflow
- Attacker can register or obtain credentials
- JCE is installed and reachable in the authenticated workflow
- Many enterprise Joomla sites do not allow open registration
- MFA, SSO, or account approval can block account acquisition
- Compromised credentials may still map to roles that never invoke JCE
Hit JCE file-browser endpoints with a different profile context
task=plugin.display and JCE plugin selectors such as imgmanager, filemanager, or browser, where the access-control failure let a user reach a profile not assigned to them.- Authenticated session cookie is accepted
- Target user can reach JCE-backed editor or media workflows
- A second, more permissive Editor Profile exists on the site
- Single-profile deployments remove much of the privilege-separation boundary to abuse
- Some sites disable JCE for low-privilege groups entirely
- Attackers still need to understand the target's profile layout
Borrow the other profile's filesystem rights
- Unauthorized profile grants meaningful filesystem capabilities
- Relevant directories are writable or browsable by the web application
- Profile settings allow actions beyond plain content editing
- Well-run sites keep upload roots narrow and file types restricted to media
- Many profiles are intentionally minimal for authors and customers
- This is not equivalent to full Joomla administrator access
Turn misconfiguration into real impact
- Profile points at sensitive or broad directories
- Server-side execution or dangerous file handling is possible in those paths
- Admins have not constrained permitted extensions and roots
- Default-safe media-only settings blunt the worst outcomes
- Modern hosting often blocks PHP execution in upload directories
- A separate hardening failure is usually needed for full takeover
images/, media/, and custom upload roots.The supporting signals.
| In-the-wild status | No public active-exploitation evidence found in the sources reviewed, and no KEV listing was present during this assessment. |
|---|---|
| Proof-of-concept availability | No public PoC repo or exploit write-up located for this specific CVE. That said, once a tester has credentials, the abuse path is straightforward enough that bespoke reproduction should not be difficult. |
| EPSS | No public EPSS value was surfaced for CVE-2026-48907 in the searched material at assessment time; this likely reflects metadata lag around a newly disclosed CVE rather than safety. |
| KEV status and dates | Not listed in CISA KEV as assessed. Vendor patch release was 2026-05-28; your supplied CVE disclosure date is 2026-06-05. |
| CVSS / vector reality | No vendor or authority CVSS exists yet. Practically, this behaves like an authenticated remote authorization flaw with impact bounded by the unauthorized profile's filesystem settings, not like unauthenticated RCE. |
| Affected versions | Public write-ups on the 2.9.99.4 advisory say all prior JCE Free and JCE Pro versions were affected, including sites on Joomla 3.10, 4.x, 5.x, and 6.x. |
| Fixed versions | JCE 2.9.99.4 is the first fixed release for this issue family; 2.9.99.5 is later and also not vulnerable to this CVE. |
| Exposure / prevalence | This is not niche software. JCE is a long-running, top-ranked Joomla extension, and mySites.guru describes it as consistently one of the top two installed extensions across its managed fleet. |
| Detection notes | Hunt in authenticated web logs for JCE requests containing task=plugin.display or plugin selectors such as imgmanager, filemanager, or browser, especially when made by low-privilege users. |
| Research / reporting | Public analysis says the fix shipped within 24 hours of the external report landing. The sources reviewed did not publicly name a reporter for 2.9.99.4. |
noisgate verdict.
The single biggest reason this lands at MEDIUM is that it requires a valid Joomla login before the bug is reachable. Even after exploitation, impact is capped by the borrowed JCE profile's own filesystem permissions, so this is a post-auth privilege-boundary failure, not a turnkey internet-edge takeover.
Why this verdict
- Requires authenticated Joomla access: this immediately cuts the reachable population from 'anyone on the internet' to sites where the attacker can register, steal, or already hold an account.
- Impact inherits another profile's limits, not full site ownership: the attacker gets whatever that unauthorized profile can do in JCE's file browser, which may be meaningful but is often narrower than full admin or shell access.
- Still worth scheduling because JCE is widely deployed: a bug in a top-tier Joomla extension with low-priv user workflows in scope is operationally relevant across large fleets, even without KEV or vendor CVSS.
Why not higher?
There is no evidence here of unauthenticated exploitation, active KEV-listed abuse, or guaranteed code execution. The chain also relies on an additional environmental amplifier: another JCE profile must exist and grant materially broader filesystem rights than the attacker's assigned one.
Why not lower?
Broken authorization on a file-management path is not harmless, especially on multi-author, membership, customer-portal, and public-registration Joomla sites. Because JCE is so common and the vulnerable boundary sits inside a trusted content-management workflow, the issue deserves real patch governance rather than backlog oblivion.
What to do — in priority order.
- Restrict JCE to trusted roles — If you cannot patch immediately, remove JCE from low-trust frontend and contributor roles, or switch those groups to TinyMCE/CodeMirror. For a MEDIUM finding there is no mitigation SLA — use this as an interim risk reduction and go straight to patching within the 365-day remediation window.
- Tighten Editor Profile permissions — Review every JCE Editor Profile and shrink file-browser roots, upload locations, and permitted extensions so that a borrowed profile has little to steal or misuse. There is no mitigation SLA for MEDIUM, but this is the best compensating control if patch rollout is delayed.
- Audit authenticated JCE endpoint usage — Pull recent web logs and Joomla activity for authenticated requests hitting JCE file-browser routes, especially from customer, registered, author, or subscriber-type accounts. There is no mitigation SLA for MEDIUM, but this is the fastest way to decide whether you are merely exposed or may already have abuse to investigate.
- A generic WAF traversal rule is not enough; this CVE's core problem is broken authorization on legitimate authenticated application routes, not just bad path characters.
- Admin-only MFA does not solve it if the attacker can use a valid lower-privilege account on a site with public registration or contributor workflows.
- Blocking anonymous access to
/administrator/is insufficient because the risk model includes authenticated frontend users, not just backend admins.
Crowdsourced verification payload.
Run this on the target Joomla host with read access to the web root. Save it as check_jce_cve_2026_48907.sh, make it executable with chmod +x check_jce_cve_2026_48907.sh, then run sudo ./check_jce_cve_2026_48907.sh /var/www/html/joomla; root is not strictly required, but you must be able to read JCE manifest files under the Joomla installation.
#!/usr/bin/env bash
# check_jce_cve_2026_48907.sh
# Detects likely exposure to CVE-2026-48907 by locating installed JCE manifests
# and comparing discovered versions against the fixed version 2.9.99.4.
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 3 = UNKNOWN (not installed, unreadable, or version not determinable)
set -u
FIXED_VERSION="2.9.99.4"
ROOT="${1:-}"
if [ -z "$ROOT" ]; then
echo "UNKNOWN - usage: $0 /path/to/joomla"
exit 3
fi
if [ ! -d "$ROOT" ]; then
echo "UNKNOWN - path does not exist: $ROOT"
exit 3
fi
ver_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && [ "$1" != "$2" ]
}
extract_version() {
local file="$1"
local v
v=$(grep -Eio '<version>[^<]+</version>' "$file" 2>/dev/null | head -n1 | sed -E 's#</?version>##gi' | tr -d '[:space:]')
if [ -n "$v" ]; then
printf '%s' "$v"
return 0
fi
return 1
}
FOUND=0
VULN=0
UNKNOWN_VER=0
OUT=""
# Prefer common Joomla manifest locations first, then fall back to a bounded find.
CANDIDATES="
$ROOT/administrator/manifests/packages/pkg_jce.xml
$ROOT/administrator/manifests/packages/pkg_jce_pro.xml
$ROOT/administrator/components/com_jce/jce.xml
$ROOT/components/com_jce/jce.xml
"
for f in $CANDIDATES; do
if [ -f "$f" ]; then
FOUND=1
v=$(extract_version "$f") || v=""
if [ -n "$v" ]; then
OUT+="$f => $v\n"
if ver_lt "$v" "$FIXED_VERSION"; then
VULN=1
fi
else
OUT+="$f => version unreadable\n"
UNKNOWN_VER=1
fi
fi
done
# Fallback: search for additional JCE manifests if nothing obvious was found.
if [ "$FOUND" -eq 0 ]; then
while IFS= read -r f; do
[ -z "$f" ] && continue
FOUND=1
v=$(extract_version "$f") || v=""
if [ -n "$v" ]; then
OUT+="$f => $v\n"
if ver_lt "$v" "$FIXED_VERSION"; then
VULN=1
fi
else
OUT+="$f => version unreadable\n"
UNKNOWN_VER=1
fi
done < <(find "$ROOT" -maxdepth 5 -type f \( -iname 'pkg_jce*.xml' -o -iname 'jce.xml' -o -path '*/com_jce/*.xml' \) 2>/dev/null | sort -u)
fi
if [ "$FOUND" -eq 0 ]; then
echo "UNKNOWN - no JCE manifests found under $ROOT"
exit 3
fi
printf "Discovered JCE manifest data:\n%b" "$OUT"
if [ "$VULN" -eq 1 ]; then
echo "VULNERABLE - found JCE version older than $FIXED_VERSION"
exit 1
fi
if [ "$UNKNOWN_VER" -eq 1 ]; then
echo "UNKNOWN - JCE found, but at least one manifest version could not be read"
exit 3
fi
echo "PATCHED - all discovered JCE versions are >= $FIXED_VERSION"
exit 0
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.