Concrete CMS 9

CVE-2026-8140 affects Concrete CMS 9.5.0 and earlier. The /dashboard/extend/install/download/<remoteId> route performs a state-changing package download from the Concrete marketplace but, prior to 9.5.1, did not validate a CSRF token first. If an authenticated user with canInstallPackages() rights is lured to a crafted page, their browser can be used to trigger a package download into DIR_PACKAGES.

The vendor's MEDIUM 6.5 is still a little generous in enterprise reality. The missing token is real, but the exploit path is heavily narrowed by admin-session dependency, user interaction, marketplace connectivity, and the fact that this CVE by itself downloads code but does not install or execute it. That makes it more like *unauthorized staging* than direct takeover.

Why this verdict

• Admin-session required: the attacker position is not unauthenticated remote; it requires a live browser session for a user who can install packages, which sharply narrows reachable victims.
• Marketplace-connected only: the prerequisite implies a specific deployment posture. Environments not linked to the Concrete marketplace are simply not exploitable on this path.
• Download is not execution: the endpoint writes a package to DIR_PACKAGES, but this CVE alone does not install or run it. That missing final step is the biggest reason to push the score down from the vendor baseline.

Why not higher?

If this route installed packages or executed package code automatically, the rating would jump fast. But on the facts available, it is a CSRF-triggered staging action with multiple prerequisites and a second-stage dependency for serious impact.

Why not lower?

This still causes a real server-side state change and places attacker-selected package content on disk. In shops with weak admin hygiene or adjacent package-management flaws, that staging action can become meaningful, so this is not pure noise.

1. Constrain package-install privileges — Reduce the set of accounts that pass canInstallPackages() to the smallest possible group. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene, but do it during the next role-review cycle because shrinking the privileged browser population directly kills the attack path.
2. Disable marketplace connectivity where unused — If the site does not need in-dashboard extension downloads, disconnect it from the Concrete marketplace or move extension handling to a controlled build process. For LOW, there is no mitigation SLA; fold this into routine hardening because it removes a core prerequisite of the bug.
3. Monitor DIR_PACKAGES for drift — Add file integrity monitoring or SIEM alerts for unexpected new package directories and marketplace download events. For LOW, there is no mitigation SLA; treat as normal control improvement, especially on shared CMS estates with multiple administrators.
4. Harden admin browsing — Use separate admin browsers, reauthentication for privileged actions, and web filtering/browser isolation for CMS operators. For LOW, there is no mitigation SLA; implement through standard privileged-access hardening because it reduces CSRF success in general, not just for this CVE.

Run this on the target Concrete CMS host from a shell on the web server, pointing it at the Concrete webroot. Example: bash verify_cve_2026_8140.sh /var/www/html. It needs only read access to the webroot and the ability to invoke php; root is not required.

#!/usr/bin/env bash
# verify_cve_2026_8140.sh
# Checks whether a local Concrete CMS instance is vulnerable to CVE-2026-8140
# Usage: bash verify_cve_2026_8140.sh /path/to/concrete-webroot
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE

set -u

WEBROOT="${1:-}"
if [[ -z "$WEBROOT" ]]; then
  echo "UNKNOWN - usage: $0 /path/to/concrete-webroot"
  exit 3
fi

if [[ ! -d "$WEBROOT" ]]; then
  echo "UNKNOWN - webroot not found: $WEBROOT"
  exit 2
fi

version=""

# Preferred path: use Concrete CLI if present.
if [[ -x "$WEBROOT/concrete/bin/concrete" ]]; then
  info_out="$((cd "$WEBROOT" && php concrete/bin/concrete c5:info) 2>/dev/null)"
  version="$(printf '%s\n' "$info_out" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"
fi

# Fallback: parse composer.lock for concrete package version.
if [[ -z "$version" && -f "$WEBROOT/composer.lock" ]]; then
  version="$(grep -A4 -E '"name":\s*"(concrete5/core|concretecms/core)"' "$WEBROOT/composer.lock" 2>/dev/null | grep -Eo '"version":\s*"v?[0-9]+\.[0-9]+\.[0-9]+' | head -n1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+')"
fi

# Very loose fallback: search common PHP files for a semantic version string near 'concrete'.
if [[ -z "$version" ]]; then
  version="$(grep -RIEo 'concrete[^\n]{0,80}[0-9]+\.[0-9]+\.[0-9]+' "$WEBROOT" 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)"
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN - unable to determine Concrete CMS version"
  exit 2
fi

verlte() {
  # returns success if $1 <= $2
  [[ "$1" == "$2" ]] && return 0
  local first
  first="$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)"
  [[ "$first" == "$1" ]]
}

if verlte "$version" "9.5.0"; then
  echo "VULNERABLE - Concrete CMS version $version is <= 9.5.0"
  exit 1
else
  echo "PATCHED - Concrete CMS version $version is > 9.5.0"
  exit 0
fi

Sources

1. NVD CVE-2026-8140
2. Concrete CMS 9.5.1 Release Notes
3. Concrete CMS Security page
4. Concrete CMS Installing Extensions documentation
5. Concrete CMS CLI commands documentation
6. FIRST EPSS API documentation
7. CISA Known Exploited Vulnerabilities Catalog
8. Concrete CMS Version Archive