Threat Intelligence Report — CVE-2026-81920

Executive Summary

CVE-2026-81920 is a Cross-Site Request Forgery (CSRF) vulnerability in the Concrete CMS dashboard SEO Excluded Words page affecting versions below 9.5.3. The reset() controller action cleared the administrator-configured reserved-word list (concrete.seo.exclude_words) without validating the anti-CSRF token emitted by the reset modal and without enforcing the POST method. A remote attacker who lures an authenticated user with SEO access to a crafted page can revert the reserved-word list to its default, silently altering URL-slug generation for pages, files, topics, and other objects created via the Text urlify service. The Concrete CMS security team assigned a CVSS v4.0 score of 2.3 (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); CISA KEV status is NO and EPSS is 0.00192 (9.1% percentile).

Technical Analysis

CWE-352 (Cross-Site Request Forgery) vulnerabilities arise when a state-changing action is reachable without sufficient verification that the request originated from the legitimate application UI. In CVE-2026-81920, two independent weaknesses combine in a single controller action:

1. Missing/absent anti-CSRF token validation. The NVD description states that the reset() controller action "did not validate the anti-CSRF token that the reset modal emitted." This means the token was presented to the browser but the server-side action did not compare it against the session-bound expected value. A forged request from a third-party origin therefore passes without challenge.
2. No HTTP method restriction. The action "did not restrict the request to the POST method." Because the handler accepts non-POST verbs (e.g., GET), an attacker can trigger the state change via simple vectors such as a hyperlink, an image tag, or an auto-submitting form — bypassing the same-origin policy constraints that make cross-origin POST payloads more cumbersome.

Attack surface. The vulnerable component is the administrative dashboard SEO Excluded Words page within Concrete CMS. The affected configuration key is concrete.seo.exclude_words — a reserved-word list that governs which words should not be converted into URL slugs. When this list is reset to its default, the site's configured SEO slug policy is silently undone.

Downstream effect. The NVD description identifies the Text urlify service as the mechanism that consumes the reserved-word list. Because urlify is used during slug generation for "pages, files, topics, and other objects," the integrity impact propagates beyond the immediate dashboard action: every object created after the reset may receive a URL slug that diverges from the administrator's intended policy. This is a low-latency, low-visibility integrity change — the reset itself is instantaneous, but the resulting slug drift manifests gradually as new content is authored.

CVSS v4.0 decomposition (per vendor score 2.3):

• AV:N — network reachable.
• AC:L — no special conditions beyond normal request delivery.
• AT:P — attack requires the attacker to be present in a path/context that includes the victim (the "P" value indicates an attack precondition, consistent with a lure requiring user interaction).
• PR:N — no privileges required by the attacker.
• UI:P — user interaction is passive (the victim only needs to load a crafted page).
• VC:N / VI:L / VA:N — no confidentiality loss, low integrity impact, no availability impact.
• SC:N / SI:N / SA:N — no subsequent-system impact.

The low integrity-only rating reflects that the attacker cannot read data, cannot take over the site, and cannot cause denial of service — but can corrupt a persistent configuration value with SEO consequences.

Why the token existed but was ignored is significant. The presence of an emitted token in the modal suggests the developers intended CSRF protection; the defect is one of enforcement, not design. This is consistent with a common class of regressions where a framework-provided token is rendered in the view layer but the controller's POST handler omits the validation call (for example, failing to invoke the framework's CSRF check helper or token-comparison routine). Because the description does not name specific Concrete CMS framework functions, that implementation detail cannot be confirmed from the available data.

Exploitation Scenarios

Note: No public PoC, Nuclei template, or exploit code is available (POC_STATUS: None; EPSS 0.00192). The chain below is inferred strictly from the vulnerability class and the facts stated in the NVD description. No specific function, route, or parameter names beyond those in the description (reset(), concrete.seo.exclude_words, "SEO Excluded Words" page, urlify) are assumed.

Step 1 — Reconnaissance / target identification. The attacker identifies a Concrete CMS instance below 9.5.3 (fingerprintable via Shodan dorks such as http.html:"concrete5" or CMS-specific response headers). The attacker also needs to know, or guess, that the target's administrative user with SEO access is active and authenticated in a browser session — a prerequisite implied by the UI:P (passive user interaction) CVSS value.

Step 2 — Triggering the CSRF flaw. The attacker crafts a third-party web page that issues a request to the vulnerable reset() controller action on the SEO Excluded Words endpoint. Because the action does not validate the anti-CSRF token and does not require POST, the attacker can embed the trigger in a low-friction carrier — a link, an <img> tag referencing the action URL, or an auto-submitting form. The request carries the victim's existing session cookies by virtue of normal browser behavior on cross-origin sub-resource requests, so no credential theft is required.

Step 3 — Execution / payload. Payload construction here is a state-change primitive, not a code-execution payload. Delivering the crafted page to an authenticated SEO administrator (via phishing email, forum post, direct message, or malicious advertisement) causes the browser to silently submit the request. The server executes reset() on the server side and clears concrete.seo.exclude_words back to its default value.

Step 4 — Post-exploitation impact. No shell, no data exfiltration. The effect is persistent configuration tampering: the reserved-word list is reverted, and the Text urlify service subsequently generates URL slugs for pages, files, topics, and other objects without honoring the administrator's SEO exclusions. Recovery is non-trivial because there is no automatic audit signal from the reset action itself — the admin may not notice until URL policy drift becomes visible in newly published content or search-engine indexing behaves unexpectedly.

Detection-in-practice caveat. Because the request is a normal-looking HTTP request to an authenticated dashboard endpoint, network-layer identification is difficult without session correlation, referer inspection, or monitoring of the specific reset() action path. Behavioral detection must therefore key on the scope of the affected endpoint rather than on any payload signature.

Impact Assessment

Business impact. The vulnerability yields an integrity-only effect on a site-wide SEO configuration. For a marketing-critical or high-traffic CMS deployment, silent URL-slug policy changes can:

• Degrade search-engine ranking through inconsistent keyword usage in slug URLs.
• Break inbound deep links that depend on slugging behavior if slug formats drift from the intended policy.
• Force manual remediation (re-adding the excluded-words list) and potentially a re-crawl request.

Affected systems. All Concrete CMS installations below version 9.5.3 where an administrator with SEO permissions is authenticated in a browser session. Because the impact is downstream through the urlify service into pages, files, and topics, a single successful reset can affect content published across the entire site.

Blast radius. Bounded to the site instance and its CMS-configured SEO policy. No lateral movement, no privilege escalation, no confidentiality or availability loss — consistent with the vendor's SI:L and VC:N/VA:N subscores. However, the visibility of the change is low, meaning dwell time before discovery may be significant, which amplifies real-world remediation cost.

Severity rationale. With a CVSS v4.0 score of 2.3 and EPSS of 0.00192 (9.1th percentile of exploited CVEs), this is a low-severity, low-likelihood-of-exploitation issue. It is not listed in CISA KEV, has no known public exploit, and no Nuclei template. Patch Confidence is 0/4 — UNPATCHED per tracked sources: no vendor advisory artifact or package-manager fix metadata is indexed, even though the description indicates 9.5.3 resolves the issue.

Detection Guidance

Because this is a CSRF against an authenticated administrative endpoint, detection must combine server-side request auditing (method, referer, session correlation) with configuration-state monitoring of the affected setting.

Sigma Rule

title: Concrete CMS SEO Excluded Words CSRF Reset Attempt
id: 3f8a2c14-6b7e-4f2d-9c88-concretecms81920
status: experimental
description: Detects requests to the Concrete CMS dashboard SEO Excluded Words reset action, including non-POST methods indicative of CVE-2026-81920 CSRF abuse.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-81920
author: valtersit.com Threat Intelligence
date: 2026-01-01
tags:
  - attack.t1190
  - cwe.352
logsource:
  category: webserver
  product: apache
detection:
  selection_path:
    cs-uri-stem|contains:
      - '/dashboard/system/seo/excluded_words'
      - 'excluded_words/reset'
  selection_method:
    cs-method:
      - 'GET'
      - 'HEAD'
  selection_reset:
    cs-uri-stem|contains: 'reset'
  condition: selection_path and selection_reset and selection_method
falsepositives:
  - Legitimate administrator bookmarks to the SEO Excluded Words dashboard page (non-reset).
level: low

YARA Rule

rule CVE_2026_81920_ConcreteCMS_CSRF_Reset
{
    meta:
        description = "Detects artifacts referencing the Concrete CMS SEO Excluded Words reset action associated with CVE-2026-81920"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-81920"
        date = "2026-01-01"
        cwe = "CWE-352"

    strings:
        $a1 = "concrete.seo.exclude_words" ascii nocase
        $a2 = "excluded_words" ascii nocase
        $a3 = "SEO Excluded Words" ascii nocase
        $a4 = "urlify" ascii nocase
        $reset = "reset" ascii nocase

    condition:
        uint16(0) == 0x3C3F or // '<?'
        (2 of ($a*) and $reset)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-81920 Concrete CMS SEO Excluded Words CSRF Reset Attempt"; flow:to_server,established; http.uri; content:"excluded_words"; nocase; http.uri; content:"reset"; nocase; http.method; content:"GET"; nocase; reference:cve,2026-81920; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-81920; classtype:web-application-attack; sid:202681920; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [ network where event.category == "web" and
    url.path : "*excluded_words*" and
    http.request.method : "GET" and
    url.path : "*reset*" ]
  [ file where event.category == "configuration" and
    file.path : "*concrete*" and
    event.action : "change" ]

Interpretation: correlates a GET-based access to the reset action with a subsequent configuration-file change on the CMS host. Adjust file.path and event.category to your Concrete CMS deployment's logging pipeline.

Splunk SPL Query

index=web (uri_path="*excluded_words*" AND uri_path="*reset*" AND http_method="GET")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(http_method) as methods
        values(referer) as referers
        values(src_ip) as client_ips
        by uri_path, user, dest_host
| where count >= 1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"),
       last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count

Wazuh OSSEC Rule

<group name="concrete_cms,web,cve_2026_81920">
  <rule id="2026819" level="6">
    <decoded_as>web-accesslog</decoded_as>
    <match>excluded_words</match>
    <match>reset</match>
    <regex>GET|HEAD</regex>
    <description>CVE-2026-81920: Possible CSRF reset of Concrete CMS SEO Excluded Words via non-POST request</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cwe_352,csrf,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The affected-version evidence and the NVD description indicate that Concrete CMS 9.5.3 addresses CVE-2026-81920, but no vendor advisory, package-registry fix record, or vendor-supplied patch artifact is indexed by the tracked sources. Treat the upgrade target as advisory and verify against the vendor's release notes before deployment.

1) Immediate mitigations (short term, in deployment order of preference):

• Restrict dashboard access. Limit the Concrete CMS administrative dashboard (/dashboard/...) to trusted IP ranges, VPN, or SSO-gated reverse-proxy paths so that a lure cannot reach the vulnerable action from an arbitrary browser context.
• Enforce POST on the action at the edge. If the deployment uses a reverse proxy (nginx, HAProxy, Cloudflare WAF, etc.), block non-POST methods to the SEO Excluded Words reset path until a code-level fix is available.
• Deploy a same-site cookie policy. Set SameSite=Strict or SameSite=Lax on the Concrete CMS session cookie. Lax blocks most cross-site sub-resource forgery; Strict is stronger but may affect legitimate SSO flows.
• Referer/Origin validation at the proxy. Reject requests to the dashboard whose Origin/Referer do not match the CMS host.
• User-awareness brief. Inform administrators with SEO access not to browse untrusted pages while authenticated to the dashboard.

2) Patch / upgrade steps:

• Target upgrade to Concrete CMS 9.5.3 or higher per the NVD description.
• Verify the release notes from the Concrete CMS security team to confirm that reset() now (a) validates the anti-CSRF token emitted by the reset modal, and (b) rejects non-POST methods before executing.
• After upgrade, re-confirm the concrete.seo.exclude_words value against the site's intended policy and re-apply any customized reserved words.
• As defence in depth, review other dashboard actions for the same two defects (missing token validation, missing method enforcement) — CWE-352 regressions often cluster.

3) Long-term hardening:

• Adopt a framework-level CSRF enforcement middleware so individual controllers cannot silently opt out of token validation.
• Enforce POST (or stricter) for all state-changing endpoints centrally; any verb-permissive controller should require an explicit, documented, and reviewed exemption.
• Add CI/CD checks for CMS configuration drift and for the presence of an anti-CSRF token validation call in every state-changing controller action.
• Log and alert on any reset of SEO-affecting configuration keys, with a dedicated detection (see Detection Guidance, above) and a review ticket for every event.
• Track the Concrete CMS security advisories feed and subscribe to CVE notifications for the 9.x branch.

References

• NVD — CVE-2026-81920: https://nvd.nist.gov/vuln/detail/CVE-2026-81920
• CWE-352 — Cross-Site Request Forgery: https://cwe.mitre.org/data/definitions/352.html
• Concrete CMS Security Advisories: https://www.concretecms.org/security
• CVSS v4.0 Specification (FIRST): https://www.first.org/cvss/v4-0/
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/

Threat-actor / exploit-in-the-wild assessment: No public PoC, no Nuclei template, no exploit code, no CISA KEV entry, and an EPSS score of 0.00192 (9.1st percentile) — there is no evidence of in-the-wild exploitation for CVE-2026-81920 at the time of writing. The reporting credit in the NVD description ("Thanks riodrwn for reporting") is the only attribution detail present in the supplied data; it does not indicate an active campaign. No threat-actor tracking is applicable to this entry.