CVE-2026-81896

Executive Summary

CVE-2026-81896 is a stored cross-site scripting (XSS) vulnerability in Concrete CMS, affecting all releases prior to 9.5.3. User-defined Form block question labels are rendered as column headers in the Dashboard Form Submissions report (concrete/single_pages/dashboard/reports/forms/legacy.php) without HTML entity encoding, allowing a rogue editor to persist markup or script that executes in the browser of any administrator who opens the submissions report for the affected form. The Concrete CMS security team assigned a CVSS v4.0 score of 8.4, indicating a high-severity issue that requires only limited privileges on the attacker side but yields high confidentiality and integrity impact on administrative sessions — a credible vector for session hijacking, CSRF token theft, and privileged account takeover within the CMS. No public proof-of-concept, exploit code, Nuclei template, or CISA KEV entry exists at time of writing, and no patch evidence from tracked sources is available (patch confidence 0/4).

Technical Analysis

The flaw is a classic stored (persistent) cross-site scripting issue rooted in CWE-79: improper neutralization of user-controllable input during web page generation. The vulnerable component is the Form block, a core Concrete CMS feature that allows content editors to define form questions, each carrying a question label. Those labels are subsequently used as column headers in the aggregate Dashboard Form Submissions report, which is a privileged administrative interface designed to let site administrators review, export, and triage submitted form data.

The affected rendering code path is explicitly identified as:

concrete/single_pages/dashboard/reports/forms/legacy.php

The defect is the omission of HTML entity encoding when the stored question label is interpolated into the report's column headers. Because the label is persisted in the CMS database at form-authoring time and rendered later, in a different user's privileged session, the payload crosses a trust boundary: the editor (lower-privilege authoring role) controls the value, and the administrator (higher-privilege reviewer) triggers execution. This is textbook stored XSS where the sink is a server-side template that writes the label into the response body without contextual HTML escaping.

Three properties of this vulnerability raise its severity relative to a typical reflected XSS:

1. Persistence and target amplification. The payload is stored once in the form definition and re-rendered each time any administrator opens the submissions report for that form. There is no requirement for the administrator to click a crafted link — merely navigating to the Dashboard report is sufficient to trigger execution.
2. Privilege asymmetry. The attacker only requires the ability to author or edit Form block content (an editor-level capability in Concrete CMS workflows), while the victim is an administrator. This privilege differential is why the CVSS v4.0 Threat Metrics show PR:H (Privileges Required: High — the editor capability) yet VC:H/VI:H (High impact to the victim's confidentiality and integrity).
3. Dashboard context. The malicious script executes inside an authenticated administrative session. Any data readable by that admin session — including CSRF tokens, form submission content, and administrative session cookies (where not hardened with HttpOnly) — is exposed to the attacker's JavaScript.

The supplied NVD description does not enumerate specific DOM sinks, JavaScript APIs, request handlers, or sanitization functions beyond the legacy.php file path and the label-as-column-header rendering pattern. No request parameters, cookies, or endpoint URIs beyond the file path are provided. Consequently, the attack mechanism should be understood strictly at the class level: an unescaped, attacker-controlled, stored string is rendered into an HTML response executed by a higher-privileged user's browser. No CNA Title was supplied, so the vendor's own short description is unavailable and cannot be cited.

The legacy.php filename strongly suggests the defect exists in a legacy, non-ORM or legacy-rendering code path retained for backward compatibility — a common source of XSS because such paths frequently predate modern auto-escaping conventions adopted elsewhere in the framework. Note this inference about legacy code paths is derivational from the filename only; the NVD description does not state that other code paths are affected or unaffected.

Exploitation Scenarios

No public proof-of-concept is available for CVE-2026-81896. The attack chain below is inferred entirely from the vulnerability class (stored XSS in a privileged reporting interface) and the specific facts in the NVD description. No function names, parameters, or endpoints beyond those in the description are assumed.

1. Reconnaissance / target identification. The attacker identifies a Concrete CMS instance running a version earlier than 9.5.3. Fingerprinting is straightforward via publicly observable artifacts (e.g., static asset paths and page generator metadata queryable with the Shodan dorks in the METADATA block). The attacker then determines whether they hold, or can obtain, editor-level authoring rights — the precondition for this attack (PR:H).
2. Precondition — editor capability. Because the vulnerable value is a user-defined Form block question label, the attacker must be able to create or edit a Form block and define a question. This is a privileged authoring action, not an anonymous one, consistent with the High Privileges Required metric.
3. Payload insertion (vulnerability-class level). The attacker authors or edits a form question and places markup or script into the label field. The label is stored in the CMS data store without HTML entity encoding relevant to this sink. The exact payload syntax is not specified in the source description and is not fabricated here.
4. Trigger. Any administrator who opens the Dashboard Form Submissions report for the affected form causes the stored label to be rendered as a column header in legacy.php without HTML entity encoding. The browser parses the injected markup/script as part of the dashboard response and executes it in the administrator's authenticated origin.
5. Post-exploitation impact. In the administrator's session the script can read and exfiltrate page content and CSRF tokens, perform authenticated actions against the CMS on the admin's behalf, and, where cookies are not HttpOnly-protected, attempt session theft. The CVSS v4.0 vector records VC:H and VI:H with VA:N, meaning the demonstrated impact is to confidentiality and integrity of the vulnerable system, with no availability impact and no assessed impact to subsequent systems (SC:N/SI:N/SA:N). The UI:P (User Interaction: Passive) metric reflects that the administrator need only browse to the report; the AT:N (Attack Requirements: None) metric indicates no additional exploitation conditions.

Observable attacker-side indicators are limited to a stored content change (a form label containing markup) authored by an editor account, followed by administrator access to the submissions report. There is no network-level exploit primitive beyond ordinary authenticated HTTP traffic.

Impact Assessment

Business impact. A successful exploitation converts a low-trust content-authoring account into code execution in the browser of a highly privileged administrator. In CMS deployments, administrators typically hold the broadest capabilities: content publishing, user and role management, plugin/theme administration, and configuration of integrations. Although the CVSS vector caps system impact at Confidentiality and Integrity (no availability impact, no subsequent-system impact), VC:H/VI:H indicates the attacker can read and modify anything the administrator session can. Realistic business consequences include defacement, injection of further malicious content, theft of form submission data (often containing PII), unauthorized administrative actions, and potential escalation toward broader site or infrastructure access if the CMS is tightly integrated with other systems.

Affected systems. All Concrete CMS deployments below 9.5.3 that (a) use the Form block, and (b) have at least one user with editor-level rights who is not fully trusted, or whose account can be compromised or socially engineered. The legacy.php path indicates the exposure is within the Dashboard reporting interface, so any installation where administrators routinely review form submissions is in scope.

Blast radius. The SC:N/SI:N/SA:N subscores mean the Concrete CMS security team assesses the compromise as contained to the vulnerable CMS instance rather than pivoting into subsequent systems by default. In practice, blast radius depends on deployment context: a CMS that stores SSO credentials, API keys, or acts as a trusted origin for other applications could widen the effective impact beyond the scored boundary. The PR:H metric restricts unauthenticated attackers, so the realistic threat actor is an insider, a malicious contractor, a compromised low-privilege account, or someone who has obtained editor credentials through phishing or credential stuffing.

Severity. The vendor-assigned CVSS v4.0 base score of 8.4 is High. The EPSS score of 0.00251 (≈16.6th percentile) indicates that at the time of writing, the probability of observed exploitation in the wild within 30 days is low relative to the broader exploited-CVE corpus. Given the absence of a public PoC, the lack of a CISA KEV listing, and the privileged precondition, near-term mass exploitation is unlikely — however, targeted exploitation by actors with an editor foothold remains plausible.

Detection Guidance

The rules below target the vulnerability class (stored XSS rendered in a Concrete CMS administrative dashboard) and must be tuned to local logging pipelines. No exploitation has been observed in the wild; these are preventative detection content, not confirmed-IOC signatures.

Sigma Rule

title: Potential Stored XSS via Concrete CMS Form Block Question Label (CVE-2026-81896)
id: 9c1e7a4b-2f6d-4b8a-9e3c-0c7f5d1a2b64
status: experimental
description: Detects form label content containing HTML/script markup being stored or subsequently rendered in the Concrete CMS Dashboard Form Submissions report, consistent with CVE-2026-81896.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-81896
author: Valters IT Threat Intelligence
date: 2026/01/01
logsource:
  category: webserver
  product: apache
detection:
  selection_endpoint:
    cs-uri-stem|contains:
      - '/dashboard/reports/forms'
      - '/dashboard/reports/forms/legacy'
  selection_payload:
    cs-uri-query|contains:
      - '<script'
      - '%3Cscript'
      - 'onerror='
      - 'onload='
      - 'javascript:'
      - '<img'
      - '<svg'
      - '<iframe'
  selection_method:
    cs-method:
      - 'POST'
      - 'GET'
  condition: selection_endpoint and selection_method and selection_payload
falsepositives:
  - Legitimate rich-text or markup captured in form labels through sanctioned content workflows
  - Security scanners and fuzzers probing the dashboard
level: high
tags:
  - attack.t1059.007
  - cwe.79

YARA Rule

rule CVE_2026_81896_Concrete_CMS_Stored_XSS_Label
{
    meta:
        description = "Detects Concrete CMS dashboard report code that renders form question labels without HTML entity encoding (CVE-2026-81896)"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-81896"
        date = "2026-01-01"
        severity = "high"
        cve = "CVE-2026-81896"

    strings:
        $path1 = "single_pages/dashboard/reports/forms/legacy.php" ascii wide
        $path2 = "dashboard/reports/forms" ascii wide

        $label1 = "question" ascii wide nocase
        $label2 = "label" ascii wide nocase
        $label3 = "column" ascii wide nocase
        $label4 = "header" ascii wide nocase

        $sink_php = "<?php" ascii
        $sink_echo = "echo " ascii
        $sink_print = "print " ascii

    condition:
        (uint16(0) == 0x3C3F or $path1 or $path2) and
        ($sink_php or any of ($sink_echo, $sink_print)) and
        2 of ($label*) and
        filesize < 2MB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-81896 Possible Stored XSS Payload in Concrete CMS Form Label"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/dashboard/reports/forms"; http.request_body; content:"<script"; nocase; http.request_body; content:"<img"; nocase; http.request_body; content:"onerror"; nocase; threshold:type both, track by_src, count 5, seconds 60; classtype:web-application-attack; reference:cve,2026-81896; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-81896; sid:2026818960; rev:1;)

Elastic Detection

sequence by user.name with maxspan=10m
  [ authentication where event.action == "logon" and user.name != null ]
  [ network where http.request.method in ("POST", "GET")
      and stringContains(http.request.uri, "/dashboard/reports/forms")
      and (stringContains(http.request.body, "<script")
           or stringContains(http.request.body, "onerror")
           or stringContains(http.request.body, "onload")
           or stringContains(http.request.body, "<svg")
           or stringContains(http.request.body, "<iframe")) ]

Note: If equivalent form-authoring endpoints emit different URI stems, replace /dashboard/reports/forms with the locally observed authoring and reporting paths. Only paths present in the source description (dashboard Form Submissions report) were assumed.

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=*concrete*
  (uri_path="*/dashboard/reports/forms*" OR uri_path="*/dashboard/reports/forms/legacy*")
  (form_data="*<script*" OR form_data="*%3Cscript*" OR form_data="*onerror*"
   OR form_data="*onload*" OR form_data="*javascript:*" OR form_data="*<svg*" OR form_data="*<iframe*")
| eval risk="stored_xss_attempt"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(uri_path) as paths values(clientip) as src_ips
        by user, risk
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="concrete_cms,web,appsec,">
  <rule id="2026818" level="12">
    <if_sid>31100</if_sid>
    <id>^202681</id>
    <description>CVE-2026-81896: Potential stored XSS payload submitted to Concrete CMS Form/Dashboard endpoint</description>
    <group>cve_2026_81896,xss,stored_xss,</group>
  </rule>

  <rule id="2026819" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <url>/dashboard/reports/forms</url>
    <regex type="pcre2">(?i)(%3Cscript|<script|onerror\s*=|onload\s*=|javascript:)</regex>
    <description>CVE-2026-81896: Markup/script observed in request targeting Concrete CMS forms report endpoint</description>
    <group>cve_2026_81896,xss,web_attack,</group>
  </rule>

  <rule id="2026820" level="8">
    <decoded_as>web-accesslog</decoded_as>
    <url>/dashboard/reports/forms/legacy</url>
    <description>CVE-2026-81896: Access to legacy Concrete CMS forms report rendering path (monitor for label XSS)</description>
    <group>cve_2026_81896,xss,monitoring,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source was provided. Sources list: empty. No vendor fix URL, no workaround, and no affected-version enumeration beyond the upstream "before 9.5.3" boundary were supplied.

1. Immediate mitigations (compensating controls).

   • Restrict editor-level authoring rights to the minimum set of trusted users; this directly addresses the PR:H precondition for CVE-2026-81896.
   • Where feasible, temporarily disable or tightly gate the Form block's label-editing capability on high-value deployments, or restrict which roles may define form questions.
   • Constrain administrator access to the Dashboard Form Submissions report to a hardened management network or VPN, reducing opportunity for an administrator to trigger the stored payload from an untrusted context.
   • Deploy a reverse-proxy or WAF rule that strips or blocks script/markup tokens (<script, onerror=, onload=, <svg, <iframe, javascript:) in requests to the Dashboard reports/forms endpoints. This is a defense-in-depth measure, not a fix.
   • Enforce HttpOnly, Secure, and SameSite attributes on session cookies, and apply a strict Content-Security-Policy to dashboard pages, to reduce the exploitability of any residual XSS.

2. Patch / upgrade steps.

   • Upgrade Concrete CMS to 9.5.3 or later — the version boundary given in the NVD description is the only remediation signal available. Confirm the target release is actually installed and that the concrete/single_pages/dashboard/reports/forms/legacy.php rendering path applies context-appropriate HTML entity encoding to question labels.
   • Because no patch reference or vendor advisory URL was supplied, obtain the upgrade through the official Concrete CMS distribution channel and validate release notes against the version boundary before deployment.
   • After upgrading, audit existing Form blocks for stored labels containing raw markup or script that may have been planted prior to remediation; stored payloads persist in the database independently of the code fix.

3. Long-term hardening.

   • Adopt context-aware output encoding as a mandatory, framework-enforced default for all rendering paths, and retire or refactor legacy rendering code (such as the legacy.php path) that predates auto-escaping conventions.
   • Implement role separation so that content editors cannot influence administrative dashboard rendering surfaces without review; add server-side validation/sanitization on all form label storage.
   • Deploy a Content-Security-Policy with nonce- or hash-based script allowlisting to mitigate residual XSS classes in the CMS.
   • Monitor the Concrete CMS security advisory channel and the NVD entry for CVE-2026-81896 for patch publication and any revision to the affected-version range.

References

1. NVD — CVE-2026-81896 detail: https://nvd.nist.gov/vuln/detail/CVE-2026-81896
2. Concrete CMS — official project and security advisories: https://www.concretecms.org/
3. CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): https://cwe.mitre.org/data/definitions/79.html
4. CVSS v4.0 Specification (vector interpretation: AV:N/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N): https://www.first.org/cvss/v4.0/specification-document
5. CISA Known Exploited Vulnerabilities Catalog (checked — CVE-2026-81896 is NOT listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild status. No evidence of active exploitation was provided. CVE-2026-81896 is not listed in CISA KEV. There is no public PoC, no exploit code, and no Nuclei template as of this report. EPSS is 0.00251 (≈16.6th percentile), indicating low predicted exploitation likelihood in the near term. No named threat actor campaigns are associated with this CVE in the supplied data. The vulnerability was reported by Yonatan Drori of Tenzai and credited by the Concrete CMS security team.