Concrete CMS 9

CVE-2026-8135 is an insecure deserialization flaw in Concrete CMS ExpressEntryList that affects 9.5.0 and earlier and is fixed in 9.5.1. A user who already has enough Concrete privileges to add blocks can abuse the REST API's JSON handling to satisfy the _fromCIF === true gate, store a malicious serialized payload in the block's filterFields column, and get code execution when an administrator later views or edits that block.

The vendor's *technical* severity is fair for impact but too hot for patch triage across a large estate. The decisive reality check is the prerequisite stack: this is PR:H, requires a Concrete role that can add blocks, depends on a specific block path, and only becomes RCE after admin interaction with the poisoned block state. That's post-initial-access abuse with a narrower exposed population than a typical internet-reachable RCE.

Why this verdict

• Downgrade for PR:H: the attacker already needs a privileged Concrete CMS account with block-creation rights, which implies prior compromise, insider abuse, or risky delegated access.
• Downgrade for narrow exposure: only deployments using the vulnerable ExpressEntryList path and allowing that role to configure blocks are meaningfully exposed.
• Downgrade for trigger friction: the stored payload still needs a later admin view/edit event, so this is not a one-shot wormable RCE.
• Keep at MEDIUM, not LOW: once triggered, the result is real server-side code execution in the web app context, which can expose secrets, data, and adjacent infrastructure.

Why not higher?

This is not an unauthenticated edge-service bug and not even a low-privileged authenticated bug. Requiring high privileges inside the CMS, plus a specific feature path, plus a later admin-trigger event compounds downward pressure on severity for enterprise patch scheduling.

Why not lower?

Calling it LOW would ignore the fact that successful exploitation crosses an important boundary: CMS admin misuse becomes server-side code execution. That materially increases blast radius beyond normal content-management abuse, especially on flat web stacks with accessible secrets and writable deployment paths.

1. Tighten block-creation privileges — Restrict who can add or edit blocks, especially on internet-facing sites and agency-managed instances. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is the single best compensating control while you work through patching.
2. Review delegated admin accounts — Audit SSO groups, local Concrete accounts, and third-party agency users for anyone who can manage blocks or Express content. Remove stale access now; there is no mitigation SLA for MEDIUM, but this sharply cuts the only realistic attacker population before the vendor fix is applied within the 365-day remediation window.
3. Inspect for suspicious serialized block state — Search block configuration data, especially filterFields associated with ExpressEntryList, for unexpected serialized payloads or anomalous admin/API edits. Use this as a hygiene and threat-hunting measure during the 365-day remediation window if you cannot patch immediately.
4. Harden the PHP runtime boundary — Use least-privilege filesystem permissions, separate service accounts, and host/container controls so a web-app RCE has less room to pivot. Even without a mitigation SLA for MEDIUM, this reduces post-exploit blast radius while you complete remediation inside 365 days.

Run this on the target Concrete CMS host or a mounted application filesystem, not from a network scanner. Invoke it as bash verify_concrete_cve_2026_8135.sh /var/www/html (or your Concrete install root); no root is required, but the script needs read access to the app files and php in PATH if it falls back to the CLI version check.

#!/usr/bin/env bash
# verify_concrete_cve_2026_8135.sh
# Checks whether a local Concrete CMS installation appears vulnerable to CVE-2026-8135.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/runtime error

set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 /path/to/concretecms"
  exit 3
fi

if [[ ! -d "$TARGET" ]]; then
  echo "UNKNOWN - target directory not found: $TARGET"
  exit 2
fi

version=""

# Try composer.lock first
if [[ -f "$TARGET/composer.lock" ]]; then
  version=$(php -r '
    $f=$argv[1];
    $j=json_decode(file_get_contents($f), true);
    if (!is_array($j)) exit(1);
    $pkgs=array_merge($j["packages"] ?? [], $j["packages-dev"] ?? []);
    foreach ($pkgs as $p) {
      if (($p["name"] ?? "") === "concretecms/core" || ($p["name"] ?? "") === "concretecms/concretecms") {
        echo $p["version"] ?? "";
        exit(0);
      }
    }
    exit(1);
  ' "$TARGET/composer.lock" 2>/dev/null)
fi

# Fallback to Concrete CLI if present
if [[ -z "$version" && -x "$TARGET/concrete/bin/concrete5" ]]; then
  version=$(php "$TARGET/concrete/bin/concrete5" --version 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -n1)
fi

# Normalize leading v and Composer-style suffixes
version=$(echo "$version" | sed -E 's/^v//; s/^([0-9]+\.[0-9]+\.[0-9]+).*/\1/')

if [[ -z "$version" ]]; then
  echo "UNKNOWN - could not determine Concrete CMS version from composer.lock or CLI"
  exit 2
fi

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

verlt() {
  # returns true if $1 < $2
  [[ "$1" != "$2" ]] && verlte "$1" "$2"
}

if verlte "$version" "9.5.0"; then
  echo "VULNERABLE - Concrete CMS version $version is <= 9.5.0"
  exit 1
elif verlt "$version" "9999.9999.9999"; then
  echo "PATCHED - Concrete CMS version $version is > 9.5.0"
  exit 0
else
  echo "UNKNOWN - unparsable version state: $version"
  exit 2
fi

Sources

1. CVE.org record for CVE-2026-8135
2. Concrete CMS 9.5.1 release notes
3. Concrete CMS GitHub releases
4. Concrete CMS security program page
5. CISA Known Exploited Vulnerabilities catalog
6. FIRST EPSS API documentation
7. OpenCVE record for CVE-2026-8135
8. PatchSiren debrief for CVE-2026-8135