CVE-2026-81919

Executive Summary

CVE-2026-81919 is a Cross-Site Request Forgery (CSRF) vulnerability in Concrete CMS versions prior to 9.5.3. The block-arrangement backend endpoint — specifically the arrange() action of Concrete\Controller\Backend\Page\ArrangeBlocks — failed to validate an anti-CSRF token while still enforcing page-edit authorization, and its route accepted any HTTP method. An attacker who can induce a signed-in content editor to load an attacker-controlled page can cause block reordering or movement within the draft version of any page the victim is permitted to edit. Impact is limited to integrity of draft page layout (CVSS v4.0 base 2.3), with no confidentiality or availability loss.

Technical Analysis

Concrete CMS is an open-source content management system used for enterprise and public-sector websites. The vulnerable component is the backend controller responsible for arranging (reordering and moving) content blocks on a page: Concrete\Controller\Backend\Page\ArrangeBlocks, invoked through its arrange() action.

Two design weaknesses combine to create the CSRF condition:

1. Missing anti-CSRF token validation. The arrange() action enforced page-edit authorization — meaning the request had to originate from a session that already held edit rights on the target page — but it performed no token check. State-changing requests were therefore accepted based solely on the presence of an authenticated session cookie, without proof that the request was intentionally generated by the application UI.

2. HTTP method flexibility. The route registered for the arrangement endpoint accepted any HTTP method. Because the action did not require a specific method (nor a token bound to method or form), a cross-site request generated by a browser could reach the state-changing code path.

The exploitation precondition is the victim's browser being in a state where the session cookie is transmitted with the forged cross-site request. Per the CNA description, the default "null" cookie SameSite configuration in affected deployments permits the victim's session cookie to accompany the forged request — i.e., the browser does not apply the SameSite=Lax default treatment that would otherwise block the cookie on most cross-site requests.

Authorization is not bypassed: the attacker does not gain access to pages the victim could not already edit. The flaw is that the victim's authority is exercised on the attacker's behalf without consent. The affected state is the draft version of a page — the vulnerability allows reordering or moving blocks in the draft, not publishing or destructive content deletion per the description.

The CNA assigned CVSS v4.0 base score 2.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N. Reading the subscores: network attack vector, low attack complexity, Attack Requirements = Present (a signed-in editor must be induced to browse an attacker page in a session with edit rights), no privileges required (attacker needs no CMS account), User Interaction = Passive (the victim merely loads a page; the submission is automatic), no confidentiality impact, low integrity impact only (draft block arrangement), no availability impact, and no subsequent-system impact. The AT:P and UI:P values are what drive the very low base score despite the missing CSRF token.

CWE-352 (Cross-Site Request Forgery) is the correct classification. No public proof-of-concept, exploit code, or Nuclei template exists as of this report. EPSS is 0.00165, at the 6.1st percentile of scored CVEs — extremely low predicted exploitation likelihood. The vulnerability is not listed in CISA KEV.

Patch status is unpatched in tracked sources (0/4 confidence). No vendor advisory URL, commit, or workaround was surfaced by the tracked patch sources, and affected-version metadata across OSV packages is empty. The CNA description references version 9.5.3 as the fixed release; this must be independently confirmed against the vendor's release notes before being treated as an authoritative remediation target.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the CNA description. It deliberately avoids inventing implementation details not stated in the source data.

1. Reconnaissance / target identification. The attacker identifies a Concrete CMS instance below 9.5.3 — for example via Shodan dorks for the CMS fingerprint — and determines that a target individual (a content editor) has an authenticated session. Because the vulnerability requires a victim with page-edit rights, the attacker selects a plausible editor, such as a site administrator or marketing/content staff member, who is likely signed in.

2. Triggering the flaw class (CSRF against a state-changing action). The attacker hosts an attacker-controlled page containing an auto-submitting cross-site request that targets the Concrete CMS block-arrangement backend endpoint (the arrange() action). Because the action performs no anti-CSRF token validation, the forged request does not need to carry a valid token — only the victim's session cookie must be attached. The route accepts any HTTP method, so the attacker is not constrained to a method the browser would normally restrict.

3. Payload delivery. The attacker induces the victim to load the malicious page (e.g., a link, an embedded resource, or a page the victim is directed to visit) while the victim is signed into Concrete CMS with edit rights on the target page. The browser issues the forged request to the arrangement endpoint with the session cookie included, because the deployment's default null cookie SameSite configuration does not prevent the cookie from being sent on the cross-site request. No authentication token is required (PR:N); the only interaction needed is the victim loading the page (UI:P).

4. Post-exploitation effect. With the request accepted, the backend reorders or moves blocks within the draft version of the page the victim was permitted to edit. The attacker does not gain access to other pages, does not exfiltrate data (no confidentiality impact), and does not take the site down (no availability impact). The realistic outcome is defacement/alteration of draft layouts — a nuisance or, in some workflows, a vector for social-engineering an editor into later publishing the manipulated layout. Severity is low per the CVSS subscores (VC:N, VI:L, VA:N).

Attribution/actor evidence: none. No threat actor campaign, no exploit-in-the-wild evidence, no KEV listing.

Impact Assessment

The blast radius is limited to the integrity of page content on Concrete CMS instances below 9.5.3 that (a) permit editing by users who can be socially engineered into visiting an attacker page, and (b) do not configure the session cookie with a SameSite value that blocks cross-site transmission.

• Confidentiality: None (VC:N). No data is read.
• Integrity: Low (VI:L). Draft page block arrangement can be altered.
• Availability: None (VA:N).
• Subsequent systems: None (SC:N, SI:N, SA:N).

The CVSS v4.0 base score of 2.3 reflects the combination of Attack Requirements: Present and User Interaction: Passive — the attacker must both have a signed-in editor and trick them into loading a page, and gains only a low-integrity, draft-level effect. Business impact is therefore normally limited to operational disruption (content workflow confusion, review churn) and reputational risk where the altered draft is later used. Environments that publish directly from drafts, or that rely on automated content pipelines, should treat the integrity effect on drafts as more consequential than the raw CVSS score suggests. Because no PoC or exploit code exists publicly and EPSS is 0.00165 (6.1st percentile), targeted exploitation is unlikely; the realistic risk is opportunistic or insider-adjacent manipulation.

Detection Guidance

Sigma Rule

title: Potential CSRF Abuse of Concrete CMS Block-Arrangement Endpoint (CVE-2026-81919)
id: 8f1c2b6a-3e4d-4f2a-9c7b-cve202681919
status: experimental
description: Detects POST/GET requests to the Concrete CMS block-arrangement backend action lacking a same-origin Referer and with no anti-CSRF token, consistent with CVE-2026-81919 CSRF.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-81919
author: valtersit.com
date: 2026-01-01
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|contains:
      - '/ccm/system/'
      - 'arrange'
    cs-uri-query|contains: 'ArrangeBlocks'
  filter_legit:
    cs(Referer)|startswith: 'https://'
  condition: selection and not filter_legit
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - cs(Referer)
falsepositives:
  - Legitimate CMS UI requests when reverse proxy strips Referer headers
level: low

YARA Rule

rule CVE_2026_81919_ConcreteCMS_CSRF_Arrange
{
    meta:
        description = "Detects cross-site request forgery content targeting Concrete CMS ArrangeBlocks arrange() action (CVE-2026-81919)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-81919"
        date = "2026-01-01"
        severity = "low"

    strings:
        $a = "ArrangeBlocks" nocase ascii wide
        $b = "arrange" nocase ascii wide
        $c = "ccm/system" nocase ascii wide
        $d1 = "auto" nocase ascii
        $d2 = "submit" nocase ascii
        $e = "concrete5" nocase ascii wide

    condition:
        uint32(0) == 0x3c68746d or uint32(0) == 0x3c48544d or
        (
            (any of ($a, $b)) and
            (any of ($c, $e)) and
            (all of ($d*))
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-81919 Concrete CMS ArrangeBlocks CSRF Attempt"; flow:to_server,established; http.uri; content:"ArrangeBlocks"; nocase; http.uri; content:"arrange"; nocase; http.header; content:"Referer"; negate; pcre:"/ArrangeBlocks/i"; reference:cve,2026-81919; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-81919; classtype:attempted-admin; sid:2026819190; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [network where network.protocol == "http" and url.path : "*ArrangeBlocks*" and
   not url.path : "*/concrete/*" and http.request.method in ("GET","POST")]
  [http where url.path : "*arrange*" and not http.request.referrer : "*concrete*"]

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=nginx:plus:access
| eval csrf_target = if(match(uri, "ArrangeBlocks") OR (match(uri, "arrange") AND match(referer, "^-$|^http")AND NOT match(referer,"concrete")), 1, 0)
| where csrf_target=1
| stats count min(_time) as first_seen max(_time) as last_seen by clientip, uri, referer, useragent
| where count > 1
| sort - count

Wazuh OSSEC Rule

<group name="web,concrete_cms,csrf,">
  <rule id="202681919" level="5">
    <decoded_as>web-accesslog</decoded_as>
    <match>ArrangeBlocks|arrange</match>
    <action>get|post</action>
    <description>CVE-2026-81919: Possible CSRF to Concrete CMS ArrangeBlocks arrange() action</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations (until a verified patch is available):

   • Set the session cookie with SameSite=Lax or SameSite=Strict (the CNA description identifies the default null cookie SameSite configuration as what allows the session cookie to accompany the forged request). This is the single most effective control and can generally be applied at the web-server/reverse-proxy or application configuration layer.
   • Require a Referer/Origin check on the block-arrangement backend endpoint so cross-origin submissions are rejected.
   • Restrict access to the backend arrange endpoint to trusted administrative networks or IP allowlists where operationally feasible.
   • Apply only the HTTP methods actually required by the UI (do not allow arbitrary methods), which aligns with the "route accepted any HTTP method" weakness described.
   • Educate content editors not to follow links or load pages while signed in with edit rights, and to use a separate browser/profile for CMS administration.

2. Patch/upgrade steps:

   • Upgrade Concrete CMS to version 9.5.3 or later as indicated in the CNA description. Independently verify this version against the official Concrete CMS release notes/advisory before rolling out, because no patch source was confirmed by the tracked systems (patch source list is empty; affected-version metadata empty).
   • Confirm the upgraded ArrangeBlocks controller enforces anti-CSRF token validation on arrange().
   • After upgrading, verify that the route no longer accepts arbitrary HTTP methods.

3. Long-term hardening:

   • Enforce CSRF token validation on every state-changing backend action, not only high-severity ones.
   • Adopt a global framework policy requiring tokens and origin checks for all non-idempotent routes.
   • Add automated tests asserting CSRF token enforcement for backend controllers.
   • Monitor vendor advisories for CVE-2026-81919 follow-up and re-run patch validation.

References

1. NVD — CVE-2026-81919: https://nvd.nist.gov/vuln/detail/CVE-2026-81919
2. CWE-352, Cross-Site Request Forgery: https://cwe.mitre.org/data/definitions/352.html
3. Concrete CMS official release notes / security advisories (verify 9.5.3 fix): https://www.concretecms.org/ (release page for 9.5.3)
4. CISA Known Exploited Vulnerabilities catalog (CVE-2026-81919 not listed at time of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
5. Credit: Yonatan Drori, Tenzai — reporter acknowledged in the CNA description.

Evidence of exploitation in the wild: none available. No public PoC, no exploit code, no Nuclei template, EPSS 0.00165 (6.1st percentile), no KEV listing, and no known threat actor campaign associated with CVE-2026-81919 as of this report.