CVE-2026-81927

Executive Summary

CVE-2026-81927 is a stored cross-site scripting (XSS) vulnerability in Concrete CMS (CWE-79) affecting versions before 9.5.3. The flaw is specific to the non-default concrete.file_manager.images.svg_sanitization.action = reject SVG sanitization mode, where uploaded SVG files are validated only against a narrow blocklist that covers the script element and on* event-handler attributes while discarding the more comprehensive enshrined/svg-sanitize result. As a result, dangerous SVG vectors such as a javascript: URI in an xlink:href are persisted unmodified and execute when the file is opened directly. An authenticated user with file-upload privileges can thereby execute arbitrary JavaScript in the browser context of any user who views the uploaded file, yielding limited but genuine confidentiality and integrity impact. The default sanitize mode is unaffected, and the vendor's CVSS v4.0 score is 1.8, reflecting the narrow preconditions required for exploitation.

Technical Analysis

Concrete CMS offers configurable handling of uploaded SVG files through the configuration key concrete.file_manager.images.svg_sanitization.action. Operators may choose between a sanitize mode and a "reject" mode described as "Reject files containing potentially harmful elements." The vulnerability resides in the reject-mode validation path.

According to the NVD description, when reject mode is active, uploaded SVGs are checked only against "a small built-in blocklist covering the script element and on* event-handler attributes." This blocklist is an allow/deny heuristic that fails to enumerate the full set of active-content vectors permitted within the SVG specification. Critically, the description states that "the broader enshrined/svg-sanitize pass still ran, but its result was discarded." In other words, the library-based sanitizer that would normally neutralize a wider range of dangerous constructs was executed but its output was not used to replace the stored file. The validation decision was made solely on the narrow blocklist, so any active content outside that blocklist survived.

The description identifies one concrete example of a bypass: "a javascript: URI in an xlink:href." In SVG, the xlink:href attribute (and its modern href equivalent) is used to reference external or internal resources, including via the <use>, <a>, <image>, and related elements. When such an attribute carries a javascript: scheme URI, browsers that evaluate it on direct navigation will execute the referenced script in the origin of the SVG document. Because the keyword javascript: and the attribute name xlink:href are not covered by the blocklist (which only checks for script elements and on* attributes), the payload is stored unmodified.

The attack surface is the file manager's image-upload functionality for users granted file-upload permissions. No pre-authentication vector is described. The XSS is "stored" because the malicious SVG is persisted server-side and served to other users. Execution occurs "when the file is opened directly" — that is, when a victim navigates to the file's URL in a browser context, rather than (necessarily) when the SVG is embedded as an <img> resource, since script execution typically does not occur for SVGs loaded as images.

The default sanitize mode "was not affected," meaning the vulnerability is contingent on an administrative configuration choice (the non-default reject action). The CVSS v4.0 vector reflects this: Attack Requirements (AT) is Present, indicating a non-default deployment/additional condition is required; User Interaction (UI) is Active, meaning a victim must actively open the file; Privileges Required (PR) is High, meaning the attacker needs meaningful authenticated privileges (file upload); and impacts are limited to Low confidentiality and Low integrity (VC:L/VI:L), with no availability, subsequent-system, or downstream impacts. The vendor's score is 1.8.

It is worth emphasizing what is not established by the available data: the specific Concrete CMS file paths, controller class names, upload endpoint URLs, or the exact blocklist implementation are not disclosed in the NVD description and are therefore not asserted here. The analysis rests on the documented behavior: narrow blocklist enforcement with a discarded sanitizer result, and the resulting persistence of javascript: URIs in xlink:href.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available (EPSS 0.00309, ~23.7th percentile). The attack chain below is inferred from the documented vulnerability class (stored XSS via SVG upload) and the specific mechanism described in the NVD entry. No specific function names, endpoints, or parameters beyond those appearing in the description are asserted.

1) Reconnaissance / target identification. An attacker identifies a Concrete CMS deployment running a version before 9.5.3. Fingerprinting leverages known CMS trademarks in page output and headers (supporting the Shodan dorks above). The attacker then determines whether the site administrator has set concrete.file_manager.images.svg_sanitization.action to the non-default reject mode. This configuration is not directly exposed to anonymous users, so the attacker may probe by attempting benign SVG uploads and observing whether SVG files are accepted and how they are served. The attacker must also hold, or obtain, an account with file-upload permission — consistent with the High Privileges Required rating.

2) Triggering the flaw. Once upload privileges exist and reject mode is confirmed or assumed, the attacker crafts a malicious SVG containing active content that falls outside the blocklist. Based on the description, the canonical payload uses a javascript: URI in an xlink:href attribute rather than an event-handler (on*) attribute or a script element, both of which the blocklist would catch. The attacker uploads the SVG through the CMS file manager. During validation, the narrow blocklist does not match the payload; the enshrined/svg-sanitize pass may run but its result is discarded, so the file is stored with the malicious javascript: URI intact.

3) Payload execution. The stored SVG is now hosted at a CMS-controlled URL. When any user — including an administrator or another authenticated user — opens the file directly (for example by navigating to its file URL), the browser evaluates the javascript: URI referenced in the xlink:href and executes the attacker's script in the security context of the Concrete CMS origin. Because execution is triggered by direct file opening rather than embedding, the attacker typically needs to entice the victim to click or open the file (matching UI:Active).

4) Post-exploitation impact. The executing JavaScript runs with the victim's session context on the CMS origin. The CVSS v4.0 subscores bound the realistic impact: Low confidentiality (VC:L) and Low integrity (VI:L), with no availability impact (VA:N) and no subsequent-system impact (SC:N/SI:N/SA:N). Practical consequences of origin-scoped XSS include reading data accessible to the victim's session and performing state-changing actions on their behalf, subject to the CMS's own CSRF and authorization controls. The script cannot, per the assigned metrics, be expected to compromise the host or pivot to other systems. The attacker's gain is the classic XSS objective — session-adjacent data exposure and action-on-behalf-of the victim — not server compromise.

Impact Assessment

Affected systems. Concrete CMS deployments prior to 9.5.3, and only those configured with the non-default reject sanitization action. Sites using the default sanitize mode are explicitly not affected, which substantially narrows the exposed population. The blast radius within a vulnerable site is any user who opens the malicious SVG — potentially administrators, editors, and authenticated end users — but each victim's exposure is bounded to the CMS origin and a single browsing session.

Business impact. The realistic impact is low-to-moderate: potential exposure of data visible to the victim's session and modification of data or actions performed through the victim's account (VC:L/VI:L). There is no availability impact and no cross-system propagation. The primary risks are account-level action tampering, theft of session-adjacent information rendered in the DOM, and social-engineering-driven phishing content hosted on a trusted corporate domain. Because exploitation requires an authenticated uploader and an active victim interaction, mass or worm-like exploitation is unlikely.

CVSS commentary. The vendor-assigned CVSS v4.0 base score is 1.8 (CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N). The low score is driven by Attack Requirements (Present — the non-default reject configuration), High Privileges Required (a file-upload-capable account), Active User Interaction (a victim must open the file), and Low bounded impacts. From a triage standpoint, this places the vulnerability in the low-priority band despite being network-reachable and requiring no special complexity. Security teams should still remediate it because stored XSS on an authenticated origin can be chained with social engineering, and the configuration required is a documented, selectable option rather than an exotic misconfiguration.

Exploitation likelihood. EPSS is 0.00309, placing this at roughly the 23.7th percentile. No CISA KEV listing, no public PoC, and no exploit code are associated. There is no evidence of active exploitation in the wild.

Detection Guidance

Detection should focus on the upload and retrieval of SVG files containing active content outside the blocklist (e.g., javascript: URIs in xlink:href), and on anomalous access to file-manager asset URLs. The rules below are detection scaffolding for this vulnerability class; thresholds and paths must be tuned to the local deployment, since the NVD description does not disclose exact internal endpoints.

Sigma Rule

title: Concrete CMS SVG Upload with Active Content (CVE-2026-81927)
id: 7b1c9f42-3a6e-4d8b-9c11-8e2f5d6a4b70
status: experimental
description: Detects file-manager uploads of SVG files containing JavaScript URIs or other active content vectors that bypass the reject-mode blocklist.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-81927
author: valtersit.com
date: 2026/01/01
logsource:
  category: webserver
  product: apache
detection:
  selection_method:
    cs-method: 'POST'
  selection_path:
    cs-uri-query|contains:
      - '/file_manager'
      - '/upload'
      - 'svg'
  selection_payload:
    |contains:
      - 'javascript:'
      - 'xlink:href'
      - '<svg'
  condition: selection_method and selection_path and selection_payload
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - cs-user-agent
falsepositives:
  - Legitimate SVG uploads that mention xlink:href with non-javascript URIs
  - Administrative content management activity
level: medium

YARA Rule

rule SVG_Javascript_Xlink_CVE_2026_81927
{
    meta:
        description = "Detects SVG files carrying javascript: URIs in xlink:href, the vector stored unmodified by Concrete CMS reject-mode (CVE-2026-81927)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-81927"
        date = "2026-01-01"
        severity = "medium"
    strings:
        $svg_open = "<svg" ascii nocase
        $xlink_js = /xlink:href\s*=\s*[\"']?\s*javascript:/ ascii nocase
        $href_js  = /href\s*=\s*[\"']?\s*javascript:/ ascii nocase
        $js_uri   = "javascript:" ascii nocase
        $script   = "<script" ascii nocase
        $onload   = /on[a-z]+\s*=/ ascii nocase
    condition:
        $svg_open and (($xlink_js or $href_js) or ($js_uri and ($script or $onload)))
}

Suricata IDS Rule

alert http any any -> any any ( \
  msg:"CVE-2026-81927 Concrete CMS SVG upload with javascript: URI in xlink:href"; \
  flow:established,to_server; \
  http.method; content:"POST"; \
  http.uri; content:"svg"; nocase; \
  http.request_body; content:"javascript:"; nocase; \
  http.request_body; content:"xlink:href"; nocase; \
  reference:cve,CVE-2026-81927; \
  classtype:web-application-attack; \
  sid:202681927; rev:1; )

Elastic Detection

// Detects upload requests to file-manager endpoints containing SVG active content
// that would bypass the Concrete CMS reject-mode blocklist (CVE-2026-81927).
// Adjust data_stream and field names to match your ingestion pipeline.
any where http.request.method == "POST"
  and (
        stringContains(http.request.path, "/file_manager")
     or stringContains(http.request.path, "/upload")
     or stringContains(http.request.path, "svg")
  )
  and (
        stringContains(http.request.body, "javascript:")
     or stringContains(http.request.body, "xlink:href")
  )

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=concrete_cms
| eval request_body=coalesce(request_body, form_data, cs_request_body, "")
| eval uri=coalesce(uri_path, cs_uri_stem, "")
| where (method="POST" OR cs_method="POST")
    AND (like(uri, "%svg%") OR like(uri, "%file_manager%") OR like(uri, "%upload%"))
    AND (like(request_body, "%javascript:%") OR like(request_body, "%xlink:href%"))
| stats count min(_time) as first_seen max(_time) as last_seen
        values(uri) as uris values(src_ip) as source_ips
        by user, request_body
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="web,concrete_cms,cve-2026-81927,">
  <rule id="202681927" level="8">
    <decoded_as>web-accesslog</decoded_as>
    <match>svg</match>
    <regex type="pcre2">javascript:|xlink:href</regex>
    <description>CVE-2026-81927: Possible Concrete CMS SVG upload with active content (javascript:/xlink:href) - stored XSS attempt</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_81927,web_attack,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch artifact was confirmed from any tracked source (Patch Sources: empty; Vendor Fix: N/A; no OSV fix version mapped). The NVD description indicates the flaw is corrected in Concrete CMS before 9.5.3 is released — that is, versions prior to 9.5.3 are vulnerable — but no tracked source in the provided data confirms a downloadable patch reference. Treat remediation as version-upgrade-based and verify availability directly with the vendor.

1) Immediate mitigations (if upgrading is not yet possible):

• Do not operate the file manager in the non-default concrete.file_manager.images.svg_sanitization.action = reject mode. Switch to the default sanitize mode, which the description states "was not affected."
• Restrict file-upload permissions to the smallest possible set of trusted users (the vulnerability requires upload capability; PR is High in the CVSS vector).
• Consider disabling SVG uploads entirely for untrusted content, or converting uploaded SVGs to raster formats.
• Serve user-uploaded files with a restrictive Content-Security-Policy and, where feasible, from a separate origin (not the primary CMS origin) to reduce the value of any stored XSS.
• Apply a robust, up-to-date SVG sanitization library at the reverse-proxy/WAF layer as defense-in-depth, since the CMS's native checks in reject mode are insufficient.

2) Patch / upgrade steps:

• Upgrade Concrete CMS to 9.5.3 or later. Because no patch artifact is tracked (Patch Confidence 0/4), validate the upgrade through the vendor's official release channel and changelog before deployment.
• After upgrading, re-audit the svg_sanitization.action configuration and any previously uploaded SVG assets. Scan the file store for SVGs containing javascript: URIs or other active content and quarantine them.
• Stage the upgrade in a test environment and verify that SVG upload validation behaves as expected in all configured modes.

3) Long-term hardening:

• Standardize on allowlist-based SVG sanitization (reject unknown active content) rather than narrow blocklists, and ensure validator output is actually applied to the stored artifact.
• Integrate SCA/version monitoring to catch Concrete CMS releases promptly; monitor the vendor advisory feed for CVE-2026-81927 and related fixes.
• Adopt a strict Content Security Policy and cookie hardening (HttpOnly, Secure, SameSite) to blunt stored-XSS impact generally.
• Log and alert on file uploads containing active SVG content and on direct access to user-uploaded asset URLs (see Detection Guidance).

References

1. NVD — CVE-2026-81927: https://nvd.nist.gov/vuln/detail/CVE-2026-81927
2. Concrete CMS official site and security advisories (vendor release channel; verify 9.5.3 availability and changelog): https://www.concretecms.org/
3. enshrined/svg-sanitize project (the sanitizer referenced in the NVD description whose output was discarded): https://github.com/darylldoyle/svg-sanitizer
4. CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'): https://cwe.mitre.org/data/definitions/79.html
5. CISA KEV Catalog (CVE-2026-81927 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / in-the-wild status: No evidence of active exploitation, public PoC, or exploit code was identified. EPSS is 0.00309 (~23.7th percentile). The vulnerability was reported to the Concrete CMS security team by researcher Oriol Ortiz (credited in the NVD description). Monitor the vendor advisory and NVD for updates, as the patch-confidence assessment is currently unverified.