Concrete Cms
Monthly
Stored cross-site scripting in Concrete CMS before 9.5.4 allows an attacker to upload a plain XML document through a publicly reachable Form Block file-upload question; because uploads were validated by extension only and stored as inline-served, same-origin files, the XML can carry an xml-stylesheet processing instruction pointing at an attacker-controlled XSLT stylesheet. When a victim opens the stored file's URL directly in a browser, the stylesheet transforms the document into HTML and runs attacker JavaScript in the Concrete CMS origin - and if that victim is an authenticated administrator, the script acts with the admin session (the reporter demonstrated creating a new user in the Administrators group). Exploitation is conditional rather than opportunistic: the site must expose a file-upload Form Block question and the victim must be lured into opening the hostile file, and no public exploit code was identified at time of analysis; the flaw is fixed in 9.5.4.
Stored cross-site scripting in Concrete CMS versions below 9.5.4 allows an attacker to persist a JavaScript payload in the user timezone field (uTimezone), which the Dashboard user-management page renders without output encoding so that the script runs inside an administrator's authenticated session - enabling theft of CSRF tokens, creation of rogue administrator accounts, or modification of site settings. Exploitation is conditionally gated rather than a broad drive-by threat: it requires the non-default setting concrete.misc.user_timezones to be enabled, and the unauthenticated write path exists only in 9.5.3 and only when public registration is also enabled, while versions below 9.5.3 permit only an authenticated user to write the field via the account profile editor; an administrator must subsequently view the malicious user record. No public exploit code was identified at time of analysis, and the vendor's CVSS v4.0 score of 7.7 is substantially moderated by these stacked non-default preconditions, which our independent assessment reflects with a higher attack-complexity and user-interaction-dependent CVSS 3.1 vector.
Stored cross-site scripting in Concrete CMS 9.0.0 through 9.5.2 lets an authenticated user who holds the Add Group Folder permission save a JavaScript payload as a group folder name, which the Members > Groups dashboard then renders as live markup without output encoding. When an administrator opens that dashboard page, the injected script executes in the administrator's session, enabling session and token theft plus any action the administrator can perform. The vendor assigned CVSS v4.0 7.3 (AV:N/AC:L/AT:P/PR:H/UI:P); no CISA KEV listing or public exploit code was identified in the provided data, and no EPSS score was supplied.
Account takeover of non-superuser accounts is possible in Concrete CMS 9.2.0 through 9.5.2 because the REST API user write endpoints (PUT /ccm/api/1.0/users/{uID} and POST /ccm/api/1.0/users/{uID}/change_password) fail to enforce per-field edit_user_properties permissions. An attacker holding an OAuth token scoped for updates and permission to edit only one non-sensitive field on another user can rewrite that user's password, username, email, and attributes, fully seizing the account; superuser accounts are explicitly out of reach. There is no public exploit identified and no CISA KEV listing at time of analysis, so this currently represents a targeted, credential-gated authorization defect rather than a mass-exploitation event. Concrete CMS rated it CVSS v4.0 7.4 (CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:N).
Stored cross-site scripting in the Concrete CMS Top Navigation Bar block (versions 9.0 through 9.5.2) allows any user who can create or rename pages to embed a script payload inside a child page name, which the block writes into the rendered navigation without HTML escaping. The payload executes in the origin of every visitor, editor, or administrator who expands the affected dropdown, letting it read same-origin content or perform actions under that victim's session. No public exploit code or CISA KEV listing was identified at time of analysis, and the vendor rates the issue 7.5 (CVSS v4.0) with PR:H, reflecting that the attacker must already hold page-management privileges.
Stored cross-site scripting in Concrete CMS versions before 9.5.3 lets any user who can submit an Address attribute inject JavaScript that later executes in the browser session of a dashboard user viewing the affected Express association entry. The root cause is a country-less text formatter for the Address attribute that skips HTML-escaping, combined with Express association templates (such as concrete/elements/express/form/view/dashboard/association.php) echoing the association label mask without calling the h() escaping helper. The vendor scored this CVSS v4.0 7.5 (AV:N/AC:L/AT:P/PR:L/UI:P) and published the fix in the 9.5.3 release notes; no CISA KEV listing or public exploit code was identified at time
Let me synthesize. Product: Concrete CMS. CVE-2026-81897: stored XSS via CSRF in Express entities forms dashboard controller save_control action, no anti-CSRF token validation. Authenticated admin tricked into submitting forged cross-site request → attacker-controlled headline and body values written to existing Express form Text control → emitted without output encoding → stored XSS. CVSS 4.0 vector: AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N → 7.7. Note: CVSS 3.1 equivalent — for assessed_cvss_vector, I need my own. This is CSRF+stored XSS: AV:N, AC:L (or H due to requiring admin interaction), PR:N (attacker unauthenticated), UI:R (requires victim admin to visit a page / submit), S:C (scope change — attacker from web goes to admin's browser context... Actually with stored XSS in admin panel, scope could be C), C:H/I:H/A:H? Hmm. In classic CVSS 3.1 for CSRF leading to stored XSS in admin context, score would be like 8.0-8.8. Let's think: AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N is typical for XSS (score 7.4). But here it's stored XSS that gives full admin session control → possibly full compromise. Concrete CMS admin XSS can lead to RCE (file manager, install packages). But from data, the impact per CVSS 4.0 is VC:H/VI:H/VA:H on the vulnerable system. So map to CVSS 3.1: C:H/I:H/A:H? Hmm, VI:H and VA:H — writing to form control, executing JS. VA:H means high availability impact — which is a peculiar mapping; concrete CMS team used the new "vulnerable system" impacts. I'll produce a reasonable 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N? Hmm. Let me be careful: with the attacker needing to craft cross-site request (AC:L), no privileges (PR:N), requiring user interaction (UI:R). Scope: the vulnerability in the web app causing script execution in the admin's browser — typically S:C for XSS. Impact: stored XSS executes with admin privileges → can change content, possibly execute code, availability impact indirect. I'd pick C:H/I:L/A:N under S:C
Stored cross-site scripting in Concrete CMS versions before 9.5.3 lets an authenticated user with form-editing privileges plant HTML or script inside a Form block question label, which is then rendered unencoded as a column header in the Dashboard Form Submissions report. The payload fires in the browser of any administrator who opens that report for the affected form, allowing the attacker to act with the administrator's session privileges. No public exploit code or active exploitation has been identified at time of analysis; the vendor scored the issue 8.4 under CVSS 4.0 (PR:H, UI:P).
Stored cross-site scripting in Concrete CMS lets any user holding page-editing permissions — for example Add Block combined with Edit Contents on a single page — plant a crafted external link value in Feature, Feature Link, Hero Image, or Image blocks that breaks out of the link markup and injects JavaScript. Because the payload is persisted and rendered without output escaping, the script executes in the browser session of every user who later views, previews, or edits that page, enabling session hijacking and privilege escalation up to full administrative takeover. The vendor scored this 8.5 (CVSS v4.0, PR:H/UI:P); no public exploit code or CISA KEV entry was provided at time of analysis, so exploitation is currently a realistic internal-threat and low-privileged-editor risk rather than a confirmed internet-wide campaign.
Stored SQL injection in Concrete CMS 9.5.2 and earlier lets an authenticated user who is permitted to add or edit a Document Library block persist arbitrary SQL syntax into the block's stored configuration (btDocumentLibrary.setIds), which is then executed every time the published page containing that block is rendered. The flaw arises because the fsID[] file-set identifiers submitted by the block editor are stored without integer validation and are concatenated directly into the file-set filter query when setMode is 'any' instead of being cast or parameter-bound. There is no evidence of active exploitation or public exploit code at time of analysis, and the high privileges required (PR:H) and render-triggered execution (UI:P) temper the 8.5 CVSS v4.0 score assigned by the vendor.
Stored DOM-based cross-site scripting in Concrete CMS 9.5.2 and earlier allows a page editor to plant JavaScript inside a Gallery block image caption, which then executes in the browser of any visitor who opens that image's lightbox. The flaw sits in the bundled Magnific Popup lightbox code (concrete/js/features/imagery/frontend.js), which decodes the caption attribute and re-parses it as HTML via jQuery's .append() inside titleSrc rather than inserting it as text. The vendor rates it CVSS v4.0 8.5 (AV:N/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:H), requiring an authenticated editor (PR:H) but only passive victim interaction (UI:P); no public exploit code or CISA KEV entry is indicated in the supplied intelligence, and no EPSS score was provided.
Unauthenticated user enumeration in Concrete CMS 9.0.0 through 9.5.2 allows any anonymous visitor to dump the complete backend account list — including internal user IDs, usernames and email addresses of every administrator and the super-administrator (user ID 1) — by sending an empty search to the /ccm/system/user/autocomplete endpoint and paginating the results. The endpoint enforces only a CSRF-style token that is bound to the selector's display options rather than to caller identity, and that token is handed out to anonymous visitors, so there is no authentication or privilege barrier to clear. No password hashes or session material leak, but the disclosed email and account inventory is a ready-made target list for credential stuffing, phishing and password-spray campaigns against named admins; no public exploit code and no CISA KEV entry are present in the supplied intelligence.
Stored XSS in Concrete CMS before 9.5.3 allows a user with edit_block permission to inject malicious JavaScript into a page's YouTube embed block by supplying an unsanitized iframe width or height value. Because only PHP's trim() is applied before the values are written into HTML attribute context, an attacker can persist an event-handler payload that executes in every visitor's browser - and, when the victim holds administrative privileges, the script acts with those privileges. No public exploit code or active exploitation has been identified at time of analysis; the vendor has patched the issue in version 9.5.3.
Stored XSS in Concrete CMS 8.3.0-9.5.2 permits a registered user with calendar event creation rights to inject script payloads via unsanitized event names that later execute in an administrator's browser through unescaped rendering in the dashboard "Waiting For Me" workflow notification block. Because the injected script runs under an active administrator session, an attacker can leverage it to silently create a new administrator account, achieving full CMS compromise. No active exploitation or public proof-of-concept has been identified; the vendor has released version 9.5.3 as the fix and assigned this a CVSS 4.0 score of 7.3.
Stored XSS in Concrete CMS 9.0.0-9.5.2 allows an authenticated editor to escalate privileges to administrator by injecting malicious JavaScript into the custom page alias name (customAliasName) field. The Edit Alias dialog applied only a trim() call to the submitted value with no HTML encoding or output neutralization, causing the alias to render unescaped in the administrative Sitemap panel. Any administrator or editor who subsequently opens the Sitemap panel automatically executes the stored payload, enabling session hijacking and full privilege escalation from editor to administrator. No public exploit has been identified at time of analysis, and the CVE is not listed in CISA KEV.
Stored cross-site scripting via authorization bypass in Concrete CMS 9.2.0-9.5.2 allows an authenticated content editor to inject persistent JavaScript into the HTML head element of every page served by the site. The REST API page update endpoint (PUT /ccm/api/1.0/pages/{cID}) enforces only basic content-editing authorization, omitting checks for page-property, page-template, and page-type changes; the `header_extra_content` attribute is rendered unescaped site-wide. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the stored XSS payload targets all visitors including privileged reviewers, enabling session hijacking and effective privilege escalation in multi-user editorial deployments.
Missing CSRF token validation on the orphaned block removal action (`removeOrphanedBlocks`) in Concrete CMS 9.0.0 through 9.5.2 enables remote attackers to permanently destroy all block content on any page the victim can edit. By tricking an authenticated editor into loading a crafted URL, an attacker triggers deletion of every block on the targeted page's current version; blocks not aliased elsewhere are additionally purged from the global Blocks table and their block-type data tables, making the destruction irreversible without a database backup. No public exploit code identified at time of analysis; the Concrete CMS security team assigned a CVSS 4.0 score of 7.1 reflecting high integrity impact gated on one user interaction.
Stored XSS in Concrete CMS 9.0.0-9.5.2 allows a low-privileged user with delegated access to the Page Containers dashboard to inject malicious script via a crafted container icon value that breaks out of an img src attribute due to missing output encoding. The payload persists in the database and executes in the authenticated session of any administrator or editor who subsequently views the Containers dashboard list or editor views, enabling session token theft and unauthorized privileged CMS actions. No public exploit code and no CISA KEV listing have been identified at time of analysis; the vendor released a fix in version 9.5.3.
Stored cross-site scripting in Concrete CMS versions 5.0.0 through 9.5.2 lets an editor-level account inject unsanitized custom style values through the Block Design dialog, which are then written into page CSS via a DOM sink and execute in the browser of any higher-privileged user who views the affected page. Because the payload runs in an administrator's session, an editor can hijack the admin session and escalate to full administrative control of the site. No public exploit code or in-the-wild exploitation is identified at time of analysis (SSVC Exploitation: none; not listed in CISA KEV), and the vendor-rated CVSS v4.0 score is 7.0 with a passive user-interaction requirement (UI:P).
PHP object injection in Concrete CMS versions below 9.5.2 allows authenticated high-privileged attackers to trigger arbitrary PHP object instantiation through unsafe unserialize() calls in the Workflow, Form block, and File/Set components. The vulnerability requires a malicious serialized payload to be placed in the database beforehand, and no public exploit identified at time of analysis. The vendor scored this 8.4 (CVSS 4.0), and CISA SSVC indicates no observed exploitation but total technical impact if successfully chained.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator's browser into triggering a core CMS upgrade to an attacker-chosen version. The dashboard's do_update() controller emits a CSRF token in the rendered POST form but never calls $this->token->validate('do_update'), leaving the update workflow effectively unauthenticated against forged cross-origin requests. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Remote code execution in Concrete CMS 9.5.0 and earlier is achievable through a CSRF flaw in the /dashboard/extend/update/prepare_remote_upgrade/<remoteMPID> endpoint, which fails to validate anti-CSRF tokens. An attacker who controls a marketplace package matching an item ID already installed on the victim site can overwrite package PHP files and trigger the upgrade() method via a single navigation by a privileged admin, resulting in code execution as the web server user. No public exploit identified at time of analysis, though the vendor (Concrete CMS security team) has acknowledged and rated the issue at CVSS 4.0 7.5.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator with canInstallPackages permission into installing an attacker-controlled package, resulting in remote code execution as the web server user. The flaw resides in the install_package() method of the dashboard's extend/install.php controller, which lacks CSRF token validation. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Privilege escalation in Concrete CMS 9.5.0 and earlier allows authenticated users with access to the bulk user assignment dashboard to add arbitrary accounts to the Administrators group and remove existing admins, effectively hijacking site control. The flaw stems from missing authorization checks in bulk_user_assignment.php and was disclosed with a vendor-assigned CVSS v4.0 score of 7.5. No public exploit identified at time of analysis, and the issue is not present in CISA KEV.
Stored cross-site scripting in Concrete CMS 9.5.0 and earlier allows authenticated editors to inject persistent JavaScript via the unvalidated 'height' parameter, executing in any subsequent visitor's browser. The CVSS 4.0 score of 7.3 reflects high privilege requirements (editor role) combined with high impact, and no public exploit identified at time of analysis.
Stored cross-site scripting in Concrete CMS 9.5.0 and earlier allows a high-privileged admin to inject arbitrary HTML/JavaScript into the OAuth authorize template via the integration name field. The flaw arises because the integration name is wrapped in <strong> tags by PHP string interpolation before being passed to the t() translation helper, causing the resulting raw HTML to be rendered when end users view the OAuth consent screen. No public exploit identified at time of analysis, but a rogue or compromised admin could potentially harvest OAuth login submissions from victims.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce authenticated administrators into downloading arbitrary marketplace packages to the server's DIR_PACKAGES directory by luring them to a crafted page that triggers the unprotected /dashboard/extend/install/download/<remoteId> GET endpoint. The vendor assigned CVSS 4.0 of 7.5 reflecting high impact on confidentiality, integrity, and availability, though no public exploit identified at time of analysis and the flaw is not listed in CISA KEV.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator into triggering arbitrary package upgrades by luring them to a malicious page that issues a single GET to /dashboard/extend/update/do_update/<pkgHandle>. The do_update() handler only checks the canInstallPackages() permission and omits CSRF token validation on this state-changing route, so a cross-site navigation is sufficient to invoke upgradeCoreData() and the package controller's upgrade() routine. No public exploit identified at time of analysis and no CISA KEV listing; EPSS not provided.
Remote code execution in Concrete CMS versions 5.0 through 9.5.0 allows a high-privileged administrator to bypass the platform's `_fromCIF` deserialization guard by submitting malicious payloads through the REST API instead of standard form POST requests. The flaw resides in the ExpressEntryList block controller (CWE-502) and stores a serialized PHP gadget in the `filterFields` database column, which is unmarshalled when another administrator subsequently views or edits the block, leading to full server takeover. No public exploit identified at time of analysis, and the issue is not present in CISA KEV.
Authenticated remote code execution in Concrete CMS 9.5.0 and earlier allows an administrator with composer form editing privileges to chain a path traversal flaw in the ptComposerFormLayoutSetControlCustomTemplate field with the platform's permissive file uploader to execute arbitrary PHP on the server. The vendor scored this 9.4 (CVSS v4.0) reflecting high confidentiality, integrity, and availability impact across both the vulnerable component and downstream subsequent systems. No public exploit identified at time of analysis, and the issue is not currently listed in CISA KEV.
Remote code execution in Concrete CMS prior to version 9.4.8 stems from unsafe deserialization of PHP objects in the Express Entry List block configuration. An authenticated administrator can inject malicious serialized data through the columns parameter that executes arbitrary code when unserialized without validation. This allows attackers with admin privileges to achieve complete system compromise through stored object injection attacks.
Unauthenticated information disclosure in Concrete CMS releases before 9.5.3 allows a remote visitor who knows or can guess a valid Express entity identifier to query a legacy Express entry search endpoint that omits the canViewExpressEntries() permission check, returning entry attribute values that should be restricted to privileged users. The impact is read-only (C:L/I:N/A:N) and exploitation requires that identifier prerequisite, which is why the vendor and independent assessments both score it as hardening-limited rather than trivially exploitable; disclosure is worse for Express entities where supportsEntrySpecificPermissions() returns false, because EntryList::ignorePermissions() then bypasses per-entry filtering entirely. No public exploit code has been identified at time of analysis, and this CVE is not confirmed actively exploited (no CISA KEV listing); the fix is included in the 9.5.3 release.
Deactivated, deleted, or password-reset-locked Concrete CMS accounts keep working API access via any bearer token issued to them before the account state change, letting the holder continue calling the OAuth REST API endpoints under /ccm/api/1.0/* until that already-issued token expires on its own. All Concrete CMS versions before 9.5.4 are affected when the OAuth REST API is enabled; the vendor rates this only 2.0 (CVSS v4.0) and our independent assessment aligns with a low-impact, high-complexity authenticated issue, with no public exploit identified at time of analysis. The flaw is time-limited to the residual lifetime of the token and grants no more access than that token originally had, so it is a stale-credential/session-expiration problem rather than a route to new privileges.
Concrete CMS 9.2.0 through 9.5.3 fails to enforce an authorization check on its REST API user-creation endpoint (POST /ccm/api/1.0/users), so any request bearing a valid OAuth token that carries the users:add scope - including a client_credentials token with no associated user context - can create active, validated accounts while bypassing email verification and administrator approval. The endpoint's add() method in concrete/src/Api/Controller/Users.php performs no permission verification, making this a classic missing-authorization weakness (CWE-862) that an authenticated API consumer can abuse to gain a foothold. Under default registration settings the newly minted accounts are allowed to edit page content, which provides an escalation path to stored cross-site scripting and further compromise of the CMS. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the reporter-independent assessment rates the impact as limited to low integrity loss on the CMS itself.
Broken authorization in Concrete CMS 9 through 9.5.3 allows an authenticated user who already holds edit-board-contents permission on one board instance to query the custom-slot preview endpoint with an InstanceItem identifier belonging to a different board instance, causing the system to return summary fields - including the underlying page title and description - for pages that user is not permitted to view. The endpoint fails both to validate that the submitted item belongs to a board the requester is authorized to edit and to enforce page-view permission before generating the page-backed summary content. Rated CVSS v4.0 5.3 (our independent assessment: CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), this is a low-to-moderate severity IDOR-class information-disclosure flaw with no published exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); no user interaction is required, but exploitation is gated behind an authenticated account with per-board edit permission.
Stored cross-site scripting in Concrete CMS 9.5.2 and earlier allows an authenticated user with file-upload rights to embed a javascript: URI in an SVG's xlink:href attribute that survives storage and executes in the browser of any user who opens the uploaded file directly. The flaw only manifests when the non-default 'Reject files containing potentially harmful elements' mode is selected (concrete.file_manager.images.svg_sanitization.action = reject), because in that mode the CMS discarded the output of the enshrined/svg-sanitize pass and relied solely on a narrow built-in blocklist covering <script> and on* handlers. No public exploit code or CISA KEV listing was identified, and the vendor-assigned CVSS v4.0 base score is a low 1.8, reflecting the need for upload privileges, a non-default configuration, and victim interaction.
Concrete CMS versions 9.4.0 through 9.5.2 fail to escape page paths before rendering them inside the location panel's duplicate-path confirmation dialog: the panel's check endpoint reflects the submitted path unmodified in its JSON response, and client-side JavaScript injects that value as raw HTML, so a crafted path executes script in an authenticated editor's browser session. An attacker must already hold page-authoring privileges and must engineer a path collision so the confirmation dialog appears, and the victim must then open that panel; no public exploit code or CISA KEV entry is associated with this CVE at time of analysis.
Let me synthesize. CVE-2026-18426: Concrete CMS 9.0.0 through 9.5.2, missing block-level edit permission check on Express Form block control-management actions, relying solely on CSRF token validation. Token bound to user and action, not block/page/form. So authenticated user with edit access to one Express Form could reuse token to add/modify/delete controls on forms they aren't authorized to edit, including injecting control whose value later rendered as HTML → stored XSS. CVSS 4.0 2.0, AV:N/AC:H/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N. CWE-862 missing authorization. Tags: XSS, Authentication Bypass, CSRF. Hmm — "Authentication Bypass" tag is arguably mislabeled since it's a missing authorization check (CWE-862), not authentication bypass. Actually that's a good candidate for data_quality_flags mislabeled_tag. The tag "Authentication Bypass" is wrong — this is an authorization flaw (CWE-862), not authentication bypass. Confidence: medium/high. I'd say medium-high. Let's use "high" given CWE-862 is explicitly missing authorization and PR:H required (authenticated user). Actually the tag list includes both XSS and CSRF — both apply somewhat (stored XSS outcome, CSRF token bypass). "Authentication Bypass" is the questionable one. I'll flag it with confidence "medium" or "high". I'll use "high" — the description explicitly says "did not enforce a block-level edit-permission check", which is authorization, and CVSS PR:H means authenticated. So "Authentication Bypass" is mislabeled. Suggest "Missing Authorization" — hmm, suggested field is "the correct/canonical slug if you know it". Perhaps suggested: "missing-authorization" or "authorization-bypass". I'll say "authorization-bypass". Missing tags? Maybe "concrete-cms" / "concrete5" vendor tag absent. Tags list: XSS, Authentication Bypass, CSRF. Missing tag candidates: "Concrete CMS" (vendor/product) — suggested "concrete-cms", high confidence from description. Also "CWE-862" / "Missing Authorization" technique tag. I'll add "
Reflected cross-site scripting in Concrete CMS versions 5.0.0 through 9.5.2 lets an attacker run arbitrary JavaScript in a victim's browser by abusing the conversation messages feature's handling of a user-supplied custom date format. Because the conversation view endpoint carries no CSRF token, the payload can be delivered through an auto-submitting cross-origin POST from an attacker-controlled page, and the independently assessed vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) treats the attack as unauthenticated, requiring only that the victim load a malicious page. Impact is limited to the victim's browser session - reflected rather than stored XSS, with partial confidentiality and integrity loss and no availability impact - and the vendor's own CVSS v4.0 score of 2.1 (AT:P/PR:L/UI:P) reflects that exploitability depends on attacker-provided content and victim interaction; no public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fully remediated in 9.5.3.
Concrete CMS 9.0.0 through 9.5.2 lets an authenticated user who holds only the global access_sitemap permission reorder any page in the site tree, including pages they have no rights to edit, because the dashboard sitemap reorder controller (Concrete\Controller\Backend\Dashboard\SitemapUpdate) never checks per-page edit permission before writing each page's cDisplayOrder value. The same action validates no CSRF token, so a forged request from a sitemap-privileged victim's browser can perform the write silently, changing the order in which pages appear in navigation menus, breadcrumbs, and page lists. Concrete CMS shipped a fix in 9.5.3; the vendor rates the issue CVSS v4.0 2.1 (integrity-only, no confidentiality or availability impact), and there is no public exploit code or CISA KEV listing identified at time of analysis.
Server-side request forgery in Concrete CMS 9.0.0 through 9.5.2 allows an authenticated user who holds file-import privileges to make the server fetch internal-only resources by abusing a DNS pin that is validated once per host and then reused for every later URL on that host. Because the pinned validation and the unpinned download can resolve to different addresses, a rebinding host can redirect the request to loopback services, internal admin panels, or cloud metadata endpoints, with responses saved into the file manager. The vendor rates this only CVSS 4.0 base 2.1 given the high complexity and privileged prerequisite; no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS 9.0.0 through 9.5.2 contains an insecure direct object reference in the Express saved search preset delete and edit dialogs, letting any authenticated user who holds only view permission on a single Express entity permanently delete (with no undo) or rename saved search presets owned by Express entities they have no permission over. Because a renamed preset is rendered back to users of the targeted entity, the flaw enables content defacement or social-engineering-style manipulation of other teams' saved searches. The vendor scored it CVSS 4.0 2.1 (Low) with PR:H and AT:P; no public exploit code, EPSS score, or CISA KEV listing was identified at time of analysis.
Concrete CMS 9.5.2 and earlier fail to enforce a destination-side authorization check and omit CSRF token validation in the multilingual page-assignment backend action (Backend\Page\Multilingual::assign), letting an authenticated editor who holds the Edit Page Multilingual Settings permission on just one page rebind an arbitrary page from another locale as that page's translation and delete legitimate translation pairs maintained by other editors. The result is silent manipulation of public-facing language routing across the site, with no confidentiality impact and only limited integrity/availability damage. The vendor scores this 2.1 (CVSS v4.0) because the actor must already be an authenticated, privileged editor; no public exploit code and no active exploitation have been reported.
Cross-site request forgery in Concrete CMS before 9.5.3 lets a remote attacker silently create theme page-template records inside a logged-in administrator's session. The Dashboard theme Inspect controller's activate_files() action accepts attacker-supplied pageTemplates[] values without validating an anti-CSRF token, so a forged auto-submitting POST from a page the admin merely visits is honored as legitimate. Impact is limited to unauthorized configuration change (integrity only, CVSS v4.0 base 2.1), and no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS versions before 9.5.3 contain a missing-authorization flaw in the SEO Bulk Update Meta Tags editor: the saveRecord() action validated the per-page CSRF token but never invoked canEditPageProperties() for the target page. As a result, an authenticated user who was granted access to the bulk SEO tool and could merely view a page could rewrite that page's meta title, meta description, and URL handle, tampering with presentation content and live URLs outside their intended edit scope. The vendor rates this only 2.1 (CVSS v4.0, integrity-only), there is no public exploit code identified at time of analysis, and the issue is not known to be actively exploited (no CISA KEV listing).
Missing per-page authorization in the Concrete CMS sitemap controller (all versions before 9.5.3) lets any authenticated dashboard user who can reach the sitemap reorder pages they have no edit or arrange rights over, silently altering the site's global navigation order. The send_to_top and send_to_bottom tasks trust the attacker-supplied cNodeID parameter and load/update the target page without verifying move permission on that specific node (CWE-862); impact is integrity-only (CVSS v4.0 2.1, PR:H, VI:L). No public exploit code or CISA KEV entry was identified at time of analysis, and a vendor fix is available in Concrete CMS 9.5.3.
Concrete CMS 8.5.3 through 9.5.2 lets a suspended or deactivated user keep minting valid OAuth 2.0 access tokens through the refresh-token grant, because the grant never re-checks the account's active flag (uIsActive=0) before issuing new tokens. Anyone who legitimately obtained a refresh token while their account was active retains API access after offboarding, so deactivation alone no longer revokes API credentials. The vendor assigned a low CVSS v4.0 base score of 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N, all impacts Low); no public exploit code or CISA KEV listing was provided at time of analysis.
Cross-site request forgery in the Concrete CMS dashboard 'SEO Excluded Words' reset action lets a remote attacker who lures an authenticated administrator to a crafted page silently wipe the site's reserved-word list (concrete.seo.exclude_words) and restore vendor defaults, in every release below 9.5.3. The reset() controller validated neither the anti-CSRF token emitted by its own modal nor the HTTP method, so a cross-site request from the victim's authenticated browser is honoured. The impact is integrity-only and narrowly scoped — future automatically generated URL slugs for pages, files and topics stop honouring the site's SEO policy — and the vendor rates it CVSS 4.0 2.3; no public exploit code or CISA KEV entry was identified at the time of analysis.
Concrete CMS versions 9.0.0 through 9.5.2 fail to validate a CSRF token on the dashboard group type controller's delete action, allowing a remote attacker to force a logged-in administrator into deleting a custom group type. The attacker needs no authentication of their own but must lure a victim who holds group type management permission into visiting a malicious page while logged in, which is why the vendor rated it only 2.3 under CVSS 4.0. There is no indication of active exploitation or public exploit code, and the issue is fixed in the 9.5.3 release.
Concrete CMS versions below 9.5.3 import files uploaded through the conversation attachment endpoint into the site's file manager before verifying the 'Add Message Attachments' permission, so the authorization check happens only after the file has already been stored. A low-privileged authenticated user who has been explicitly denied that permission — or an unauthenticated visitor on a site configured to allow guest posting — can therefore inject files of allowed types into the file manager, altering stored content or consuming storage. The vendor rates this CVSS v4.0 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L), indicating limited integrity and availability impact rather than code execution, and there is no public exploit code identified at time of analysis.
Stored cross-site scripting in Concrete CMS 5.0.0 through 9.5.2 lets an unauthenticated attacker inject raw HTML through a publicly accessible Express Form; the payload is rendered unsanitized as an Express entry label whenever associated entries are displayed, executing in an administrator's dashboard session and in the browsers of visitors to pages containing an Express Entry List block with association columns. The Concrete CMS security team rates this CVSS v4.0 2.3 (AV:N/AC:L/AT:P/PR:N/UI:P), reflecting that exploitation depends on specific Express configuration and passive victim interaction rather than open, unconditional exposure. No public exploit code or CISA KEV listing was identified at time of analysis, and fixed code is available in Concrete CMS 9.5.3.
Concrete CMS versions below 9.5.3 fail to validate an anti-CSRF token on the block-arrangement backend endpoint (Concrete\Controller\Backend\Page\ArrangeBlocks::arrange), so a session-holding content editor can be tricked into silently reordering or moving blocks in the draft of a page they are allowed to edit. Exploitation is browser-driven cross-site request forgery: the attacker needs only to lure a logged-in editor to an attacker-controlled page while the default null SameSite cookie setting lets the victim's session cookie ride along with the forged request. Impact is limited to integrity of draft content layout (CVSS v4.0 2.3, CWE-352); no public exploit code and no active exploitation are indicated in the supplied intelligence, and no EPSS score was provided.
CSRF in Concrete CMS 9.5.2 and below allows a remote unauthenticated attacker to permanently delete all entries of an Express entity by tricking an authenticated administrator into visiting an attacker-controlled page. The root flaw is that the delete_entries controller records a CSRF token mismatch but proceeds with the destructive operation anyway, making the protection entirely non-functional. The default Contact Express object ships with a fixed, predictable entity UUID, so attackers can target that data store without any prior dashboard access.
Stored cross-site scripting in Concrete CMS versions below 9.5.3 allows an authenticated user with edit_page_contents permissions to inject malicious script payloads via the Date Format field in the Page Attribute Display block. Any site visitor who subsequently loads a page containing the poisoned block will execute the attacker's script in their browser, enabling session-token theft or malicious redirects. A vendor-released patch is available (9.5.3), no public exploit has been identified, and no CISA KEV listing exists at time of analysis.
Broken access control in Concrete CMS before 9.5.3 allows authenticated users with limited Express entry permissions to inject entries into Express objects they are not authorized to modify. The vulnerability stems from a parameter confusion bug where the permission check validates the entity supplied in the POST body, but the dashboard submit route resolves the actual target entity from an attacker-controlled route ID - and the two are never compared. An attacker who legitimately holds add-entry permissions on one Express object can therefore write to entirely different, protected datasets, potentially triggering administrative workflows or polluting content managed by higher-privilege users. No public exploit code or CISA KEV listing has been identified at time of analysis.
Stored cross-site scripting in Concrete CMS below 9.5.3 allows an authenticated user holding file-property edit permissions to inject persistent script payloads via the Document Library block's description and tags fields, executing against any visitor - including unauthenticated users - who loads a page rendering those columns. The block controller returned description and tags values without the h() output-escaping helper already applied to the title column, and the view template wrote these raw values directly into the HTML results table. Successful exploitation can result in session token theft or unauthorized browser-side actions against visitors. No public exploit code or CISA KEV listing has been identified at time of analysis.
Missing authorization in Concrete CMS 9.2.0-9.5.2 allows authenticated editors holding block-add scope to bypass file-manager visibility controls by exploiting the Area API's block-create endpoint, which never invokes the block type controller's validate() method. For file-referencing block types such as hero_image and gallery, this validate() call is the sole enforcement point for file access authorization - its omission means a restricted file reference can be stored and rendered on any page. The unauthorized file's URL and thumbnail preview are then disclosed to both the submitting editor and all page visitors, with the severity of that disclosure dependent on whether public or private file storage is configured. No public exploit has been identified at time of analysis.
Missing object-level authorization in Concrete CMS below 9.5.3 allows a signed-in dashboard user with limited Page Type editing rights to modify arbitrary Page Types outside their assigned permission boundary. The Types::submit() controller accepts a user-supplied ptID parameter and persists the targeted Page Type without invoking canEditPageType(), meaning the CSRF token validation - which is action- and user-scoped only - provides no object-level constraint. No public exploit or active exploitation has been identified; the vendor self-reported this as a moderate integrity issue (CVSS 4.0: 5.1) and patched it in version 9.5.3.
Missing CSRF token validation in Concrete CMS before 9.5.3 allows a remote attacker to trick an authenticated calendar editor into silently creating unwanted duplicate events. The vulnerable endpoint - the Calendar event duplicate dialog's submit() action in concrete/controllers/dialog/event/duplicate.php - enforced only object-level permissions (canAccess() and canAddCalendarEvent()) without verifying an anti-CSRF synchronizer token, meaning any forged cross-site request submitted on behalf of a legitimate session could produce spurious CalendarEvent and CalendarEventVersions database records. No public exploit or active exploitation has been identified; the vendor-assigned CVSS 4.0 score of 5.3 reflects the bounded, integrity-only impact.
Open redirect in Concrete CMS 9.5.0-9.5.2 allows an unauthenticated attacker to craft a legitimate-looking URL on the victim site that silently forwards an authenticated user to an arbitrary external domain immediately after login or registration. The vulnerability targets the newly introduced `rcURL` parameter in the authentication and registration flows, making it uniquely scoped to the 9.5.x minor release line. Exploitation facilitates phishing and credential harvesting by abusing the implicit trust users place in a URL belonging to a known, legitimate domain. No public exploit code or active exploitation has been identified at time of analysis.
Cross-site request forgery in Concrete CMS before 9.5.3 allows an attacker to silently relocate user group tree nodes on behalf of an authenticated administrator, exploiting the missing action-token validation on the dashboard/users/groups/bulkupdate/confirm() endpoint. Because Concrete CMS inherits parent-group permissions down to child-group members, a forged group move can silently expand the authorization scope of affected users, granting access to restricted content areas without any administrator awareness. No public exploit has been identified at time of analysis; the vendor released a fix in version 9.5.3.
Stored XSS in Concrete CMS 9.0.0-9.5.2 allows a user with board-editing permissions to inject arbitrary JavaScript into the description field of a summary object via the Board Custom Slot's `save_template` endpoint, which accepts the raw client-supplied `selectedTemplateOption[collection]` parameter without server-side validation or sanitization. The default summary template renders the description field without output encoding, so the stored payload fires in the browser of every subsequent visitor to the affected board slot - including unauthenticated front-end users and dashboard administrators. Successful exploitation enables session hijacking or forced CSRF actions, potentially escalating to full administrative compromise. No public exploit has been identified and the vulnerability is not listed in CISA KEV.
Server-Side Template Injection in Concrete CMS 9 through 9.5.2 allows a privileged user holding the Theme Customization permission to inject arbitrary LESS directives into style values processed by the server-side LESS compiler. By crafting an @import (inline) directive within color, font, or image style fields, the attacker can read arbitrary files from the server filesystem and reach internal network resources via PHP stream wrappers, with the compiled output - including any exfiltrated file contents - written directly to the publicly accessible CSS cache. This combination of sensitive file disclosure and SSRF enables credential theft and further lateral movement; no public exploit has been identified at time of analysis.
Missing authorization in the block alias route of Concrete CMS 9.x through 9.5.2 allows an authenticated editor holding only a limited area-scoped add_block_to_area delegation to read and permanently destroy arbitrary block content across the entire site. The vulnerable method Process::alias() in concrete/controllers/backend/block/process.php accepts caller-supplied block IDs without verifying ownership over the source block or confirming it is genuinely orphaned on the caller's page, enabling cross-page content theft via duplication and forced silent deletion of the original. No active exploitation has been confirmed in CISA KEV and no public exploit code exists, but the attack is mechanically straightforward for any qualifying editor account.
Stored cross-site scripting in Concrete CMS's RSS Displayer block (versions below 9.5.3) allows an external attacker who controls a syndicated feed to inject arbitrary JavaScript into any page that renders that feed, executing in the site origin for all visitors including authenticated administrators. The attack requires no account on the vulnerable site; the malicious payload persists across all page loads until the feed content changes or the block is removed. Concrete CMS assigned a CVSS 4.0 score of 6.0 reflecting high attack complexity, and no public exploit has been identified at time of analysis.
Missing per-entry authorization in Concrete CMS 9.2.0-9.5.2 allows any low-privileged OAuth token holder to enumerate Express entries they are not permitted to view via the REST API collection endpoint. The Express entry list endpoint omitted the per-entry view permission check, so a token with read scope for an Express entity returns restricted records including identifiers, URLs, labels, dates, and any custom attribute or associated-entry data requested through the includes parameter. The issue is fixed in 9.5.3; no public exploit has been identified and it is not listed in CISA KEV.
Unauthorized group enumeration in Concrete CMS 9.2.0 through 9.5.2 exposes the full organizational group structure to any authenticated API user holding a groups:read token. The root cause is a permission-checker callback in the REST API Groups controller that unconditionally returns true, eliminating per-object (tree-node) authorization on the group collection endpoint. With authentication required and no public exploit identified, the practical blast radius is limited to insiders or compromised API accounts, but the disclosed group hierarchy can materially assist privilege-escalation reconnaissance on affected sites.
Concrete CMS versions prior to 9.5.3 allow deactivated or email-unvalidated users to bypass account-status enforcement by authenticating through the OAuth callback path. When a user whose account has been deactivated or whose email address has not been verified holds an existing OAuth provider binding, the CMS completes the OAuth handshake, records a login event, and issues a fully-authenticated session without verifying whether the account is permitted to log in. No public exploit has been identified at time of analysis; the vendor (Concrete CMS security team) assigned a CVSS 4.0 score of 6.3 reflecting the constrained attack preconditions.
Hash type confusion in Concrete CMS (below 9.5.3) allows cross-purpose token redemption: a long-lived registration hash (60-day expiry) can be submitted to the password-change endpoint to take over an account, or a password-reset hash can activate an unverified account. This is an amplifier vulnerability - exploitation requires the attacker to first acquire a valid hash through a separate channel such as email interception, log exposure, or SSRF against an internal mail relay, making it a force-multiplier for hash disclosure rather than a standalone attack path. No public exploit is identified and the vendor-assigned CVSS 4.0 score of 6.3 with AC:H and AT:P reflects the conditional nature of exploitation.
Unauthenticated event metadata disclosure in Concrete CMS 9.5.2 and earlier allows any visitor to enumerate private calendar event details via a sequential IDOR on the frontend lightbox endpoint. The controller at /ccm/calendar/view_event/{bID}/{occurrence_id} loads occurrence records directly from attacker-supplied integer IDs without verifying that the occurrence belongs to the calendar block referenced by bID or that the caller holds read permission on the owning calendar. This enables systematic disclosure of event titles, dates, descriptions, page links, and configured attributes across all calendars on the installation, including those intended to be access-restricted. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
Cross-site request forgery in Concrete CMS 9.x through 9.5.2 allows an unauthenticated attacker to forge board-content modifications on behalf of any authenticated user who holds board-edit permission. The saveTemplate() action in the Boards custom slot dialog controller omits anti-CSRF token validation, permitting a crafted HTTP request to write attacker-controlled slot and template data to a board under the victim's authority. No public exploit has been identified at time of analysis, and the vendor has released version 9.5.3 as the fix.
Calendar event authorization in Concrete CMS 8.3.0-9.5.2 is bypassed because the event edit dialog validates the actor's permissions against a calendar identifier supplied in the HTTP request rather than the calendar that actually owns the targeted event occurrence. An authenticated user holding 'Add Event' rights on any single calendar can read and overwrite events across all other calendars in the installation, and delete individual event occurrences; publishing the injected version as the live-approved revision additionally requires approve_calendar_event workflow rights or an auto-approving workflow. Vendor-released patch is available in version 9.5.3; no public exploit has been identified at time of analysis.
Stored XSS in Concrete CMS 9.0 through 9.5.0 enables a rogue editor to inject persistent JavaScript via the page name field within the Atomik theme, executing in the browser session of any authenticated user who visits the affected pages. Consequences include session hijacking, credential theft, and unauthorized actions performed as the victim - potentially escalating to higher privileges if an administrator is targeted. No active exploitation is confirmed (SSVC: none; EPSS 0.04% at the 13th percentile), and a vendor-released patch is available in version 9.5.1.
Concrete CMS 9.5.0 and earlier exposes an IDOR combined with an incorrect authorization level check in the Express association Reorder dialog, enabling authenticated users with only view-only permission to tamper with entity ordering state for entries they do not own. The flaw is limited to sites actively using the Concrete CMS Express application-builder feature with entity ordering configured - a non-default deployment subset. No public exploit or active exploitation has been identified; all available signals (CVSS 4.0 of 2.3, EPSS at 0.04%, SSVC exploitation: none) consistently characterize this as a low-priority, narrow-impact finding.
CSRF in Concrete CMS 9.5.0 and below enables a network-based attacker to trick an authenticated backend editor into silently approving an unintended file version via the Backend\File::approveVersion endpoint, effectively downgrading a published file or activating an unpublished co-editor version without the victim's knowledge. Exploitation is constrained to users holding the edit_file_contents permission who can be socially engineered into visiting an attacker-controlled page while logged in. No public exploit code exists and no active exploitation has been identified; EPSS at 0.02% and SSVC Exploitation:none confirm minimal real-world urgency. Vendor patch available in version 9.5.1.
CSRF vulnerability in Concrete CMS 9.x before 9.5.0 allows a network-based attacker to trigger unauthorized log deletion by tricking an authenticated user into visiting a crafted page that silently issues a forged request to the concrete/controllers/dialog/logs/delete endpoint. The Concrete CMS security team assigned this a CVSS v4.0 score of 2.3, reflecting low integrity impact and the presence of attack prerequisites. No public exploit code has been identified and it is not listed in the CISA KEV catalog.
Stored XSS in Concrete CMS 9.5.0 and below allows a high-privileged authenticated attacker to inject malicious scripts via the cvName parameter of external-link pages, exploiting a sanitization bypass in the updateCollectionAliasExternal function. The injected payload is persisted server-side and executes in the browser of any user who subsequently views the affected page within the CMS backend. The vendor-assigned CVSS v4.0 score of 2.0 reflects constrained real-world impact: exploitation requires admin-level credentials, prerequisite attack conditions (AT:P), and passive victim interaction, with no public exploit identified at time of analysis.
Server-side request forgery in Concrete CMS 9.5.0 and earlier allows authenticated high-privileged page editors to direct the application server to fetch attacker-controlled URLs via the RSS Displayer block, with redirect-following behavior bypassing input validation to reach internal network resources. The CVSS v4.0 score of 2.1 (PR:H, AT:P) reflects that exploitation is constrained to users already holding page editor privileges and requires the RSS Displayer block to be in active use. No public exploit has been identified and this vulnerability is not listed in CISA KEV, placing it in a low real-world priority tier absent insider-threat or post-compromise scenarios.
Cross-Site Request Forgery in Concrete CMS 9.x allows an unauthenticated remote attacker to delete application logs on behalf of an authenticated victim by tricking them into visiting a malicious page. The vulnerable endpoint is concrete/controllers/dialog/logs/bulk/delete, and exploitation results in low-integrity impact - specifically, destruction of audit log data. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS v4.0 score of 2.3 reflects the combination of required user interaction and the presence of attack prerequisites.
Cross-Site Request Forgery in Concrete CMS 9.x through 9.5.0 allows a remote unauthenticated attacker to trigger bulk page deletion by tricking an authenticated user into visiting a malicious web page. The vulnerable endpoint is concrete/controllers/dialog/page/bulk/delete, and exploitation results in low-integrity impact against the vulnerable system. No public exploit code has been identified at time of analysis, and the Concrete CMS security team assigned a CVSS v4.0 score of 2.3, reflecting the prerequisite of passive victim interaction and the constrained impact.
Cross-Site Request Forgery in Concrete CMS 9 allows a remote unauthenticated attacker to trigger unauthorized bulk cache operations against authenticated CMS users. The vulnerable endpoint is concrete/controllers/dialog/page/bulk/cache, which fails to validate request origin, enabling an attacker to manipulate page cache state by deceiving a logged-in user into loading a crafted page. No public exploit or active exploitation has been identified; the Concrete CMS security team rated this CVSS v4.0 2.3 (Low), reflecting limited integrity impact and the prerequisite of user interaction.
Cross-Site Request Forgery in Concrete CMS 9.x exposes the bulk page design dialog endpoint (concrete/controllers/dialog/page/bulk/design) to forged requests, allowing a network-accessible attacker to manipulate page design settings on behalf of an authenticated user who visits a malicious link. The Concrete CMS security team assigned a CVSS v4.0 score of 2.3 (Low), reflecting that exploitation requires specific attack prerequisites (AT:P) and user interaction (UI:P), with impact limited to low-severity integrity modifications on the vulnerable system. No public exploit identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.
Cross-site request forgery in Concrete CMS 9.x before 9.5.0 permits a remote unauthenticated attacker to trigger unauthorized event duplication on behalf of an authenticated user by luring that user to an attacker-controlled page. The vulnerable endpoint is `concrete/controllers/dialog/event/duplicate`, which lacks CSRF token validation. The vendor-assigned CVSS v4.0 score of 2.3 reflects genuinely low impact - limited to a low-integrity effect on the vulnerable system - and no public exploit code or CISA KEV listing has been identified at the time of analysis.
Cross-Site Request Forgery in Concrete CMS 9.x allows a remote unauthenticated attacker to trigger unauthorized reordering of Express Object associations by tricking an authenticated user into visiting a crafted page. The vulnerability targets the endpoint concrete/controllers/dialog/express/association/reorder, with impact limited to low-severity integrity modification of the vulnerable system only. No public exploit has been identified at time of analysis, and the low CVSS v4.0 score of 2.3 reflects the combination of required user interaction, specific prerequisite conditions (AT:P), and limited data impact.
Cross-Site Request Forgery in Concrete CMS 9.x allows a remote unauthenticated attacker to forge state-changing requests against the file manager's addFavoriteFolder endpoint on behalf of an authenticated victim. Exploitation results in low-integrity impact - specifically unauthorized modification of a victim's favorite folder state - without any confidentiality or availability consequences. No public exploit has been identified at time of analysis, and the low CVSS v4.0 score of 2.3 reflects the passive user interaction requirement and constrained impact scope.
Cross-Site Request Forgery in Concrete CMS 9.x (versions prior to 9.5.0) allows a remote attacker to trigger the removeFavoriteFolder action on behalf of an authenticated CMS user by tricking them into visiting a malicious page. The affected endpoint is concrete/controllers/backend/file and the impact is limited to low-integrity modification - removal of a favorite folder. No public exploit has been identified and this vulnerability is not confirmed as actively exploited (CISA KEV). The CVSS 4.0 score of 2.3 accurately reflects the constrained, low-impact nature of the flaw.
Cross-Site Request Forgery (CSRF) in Concrete CMS 9.x before 9.5.1 allows a remote unauthenticated attacker to trigger unauthorized file-starring actions on behalf of an authenticated victim by luring them to a malicious page. The vulnerable endpoint is concrete/controllers/backend/file/star(), and successful exploitation results in a low-integrity modification of file bookmark state within the CMS. No public exploit code has been identified at time of analysis, and the Concrete CMS security team assigned this a CVSS v4.0 score of 2.3, reflecting its narrow, low-impact scope.
CSRF vulnerability in Concrete CMS 9.x exposes the backend file rescan controller at concrete/controllers/backend/file to unauthorized state-changing requests. Affecting versions 9.0 through 9.4.x (patched in 9.5.1), an unauthenticated remote attacker can trigger unintended file rescan operations against an authenticated victim's session by luring them to a malicious page. Rated CVSS v4.0 at 2.3 - limited to low integrity impact with no confidentiality or availability consequence - and no public exploit identified at time of analysis.
Cross-Site Request Forgery (CSRF) in Concrete CMS 9.x through 9.5.0 allows a remote unauthenticated attacker to trigger unauthorized file rescanning via the rescanMultiple() function in the backend file controller, provided a logged-in user can be lured to interact with an attacker-crafted page. The integrity impact is limited to the vulnerable component, with no confidentiality or availability consequence. No public exploit or active exploitation has been identified; the Concrete CMS security team assigned a CVSS v4.0 score of 2.3, reflecting the low real-world impact and the prerequisite of user interaction and specific attack conditions.
Cross-Site Request Forgery in Concrete CMS versions 9.0 through 9.5.0 exposes the approveVersion() backend file management endpoint to forged requests, allowing an unauthenticated remote attacker to manipulate file version approval state on behalf of an authenticated victim. The vendor's own CVSS v4.0 scoring assigns a 2.3 (Very Low) severity, reflecting the constrained impact - limited to low integrity change within the vulnerable component with no confidentiality or availability consequence. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, positioning this as a low-priority but legitimately tracked integrity weakness in CMS file workflows.
Stored cross-site scripting in Concrete CMS before 9.5.4 allows an attacker to upload a plain XML document through a publicly reachable Form Block file-upload question; because uploads were validated by extension only and stored as inline-served, same-origin files, the XML can carry an xml-stylesheet processing instruction pointing at an attacker-controlled XSLT stylesheet. When a victim opens the stored file's URL directly in a browser, the stylesheet transforms the document into HTML and runs attacker JavaScript in the Concrete CMS origin - and if that victim is an authenticated administrator, the script acts with the admin session (the reporter demonstrated creating a new user in the Administrators group). Exploitation is conditional rather than opportunistic: the site must expose a file-upload Form Block question and the victim must be lured into opening the hostile file, and no public exploit code was identified at time of analysis; the flaw is fixed in 9.5.4.
Stored cross-site scripting in Concrete CMS versions below 9.5.4 allows an attacker to persist a JavaScript payload in the user timezone field (uTimezone), which the Dashboard user-management page renders without output encoding so that the script runs inside an administrator's authenticated session - enabling theft of CSRF tokens, creation of rogue administrator accounts, or modification of site settings. Exploitation is conditionally gated rather than a broad drive-by threat: it requires the non-default setting concrete.misc.user_timezones to be enabled, and the unauthenticated write path exists only in 9.5.3 and only when public registration is also enabled, while versions below 9.5.3 permit only an authenticated user to write the field via the account profile editor; an administrator must subsequently view the malicious user record. No public exploit code was identified at time of analysis, and the vendor's CVSS v4.0 score of 7.7 is substantially moderated by these stacked non-default preconditions, which our independent assessment reflects with a higher attack-complexity and user-interaction-dependent CVSS 3.1 vector.
Stored cross-site scripting in Concrete CMS 9.0.0 through 9.5.2 lets an authenticated user who holds the Add Group Folder permission save a JavaScript payload as a group folder name, which the Members > Groups dashboard then renders as live markup without output encoding. When an administrator opens that dashboard page, the injected script executes in the administrator's session, enabling session and token theft plus any action the administrator can perform. The vendor assigned CVSS v4.0 7.3 (AV:N/AC:L/AT:P/PR:H/UI:P); no CISA KEV listing or public exploit code was identified in the provided data, and no EPSS score was supplied.
Account takeover of non-superuser accounts is possible in Concrete CMS 9.2.0 through 9.5.2 because the REST API user write endpoints (PUT /ccm/api/1.0/users/{uID} and POST /ccm/api/1.0/users/{uID}/change_password) fail to enforce per-field edit_user_properties permissions. An attacker holding an OAuth token scoped for updates and permission to edit only one non-sensitive field on another user can rewrite that user's password, username, email, and attributes, fully seizing the account; superuser accounts are explicitly out of reach. There is no public exploit identified and no CISA KEV listing at time of analysis, so this currently represents a targeted, credential-gated authorization defect rather than a mass-exploitation event. Concrete CMS rated it CVSS v4.0 7.4 (CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:N).
Stored cross-site scripting in the Concrete CMS Top Navigation Bar block (versions 9.0 through 9.5.2) allows any user who can create or rename pages to embed a script payload inside a child page name, which the block writes into the rendered navigation without HTML escaping. The payload executes in the origin of every visitor, editor, or administrator who expands the affected dropdown, letting it read same-origin content or perform actions under that victim's session. No public exploit code or CISA KEV listing was identified at time of analysis, and the vendor rates the issue 7.5 (CVSS v4.0) with PR:H, reflecting that the attacker must already hold page-management privileges.
Stored cross-site scripting in Concrete CMS versions before 9.5.3 lets any user who can submit an Address attribute inject JavaScript that later executes in the browser session of a dashboard user viewing the affected Express association entry. The root cause is a country-less text formatter for the Address attribute that skips HTML-escaping, combined with Express association templates (such as concrete/elements/express/form/view/dashboard/association.php) echoing the association label mask without calling the h() escaping helper. The vendor scored this CVSS v4.0 7.5 (AV:N/AC:L/AT:P/PR:L/UI:P) and published the fix in the 9.5.3 release notes; no CISA KEV listing or public exploit code was identified at time
Let me synthesize. Product: Concrete CMS. CVE-2026-81897: stored XSS via CSRF in Express entities forms dashboard controller save_control action, no anti-CSRF token validation. Authenticated admin tricked into submitting forged cross-site request → attacker-controlled headline and body values written to existing Express form Text control → emitted without output encoding → stored XSS. CVSS 4.0 vector: AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N → 7.7. Note: CVSS 3.1 equivalent — for assessed_cvss_vector, I need my own. This is CSRF+stored XSS: AV:N, AC:L (or H due to requiring admin interaction), PR:N (attacker unauthenticated), UI:R (requires victim admin to visit a page / submit), S:C (scope change — attacker from web goes to admin's browser context... Actually with stored XSS in admin panel, scope could be C), C:H/I:H/A:H? Hmm. In classic CVSS 3.1 for CSRF leading to stored XSS in admin context, score would be like 8.0-8.8. Let's think: AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N is typical for XSS (score 7.4). But here it's stored XSS that gives full admin session control → possibly full compromise. Concrete CMS admin XSS can lead to RCE (file manager, install packages). But from data, the impact per CVSS 4.0 is VC:H/VI:H/VA:H on the vulnerable system. So map to CVSS 3.1: C:H/I:H/A:H? Hmm, VI:H and VA:H — writing to form control, executing JS. VA:H means high availability impact — which is a peculiar mapping; concrete CMS team used the new "vulnerable system" impacts. I'll produce a reasonable 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N? Hmm. Let me be careful: with the attacker needing to craft cross-site request (AC:L), no privileges (PR:N), requiring user interaction (UI:R). Scope: the vulnerability in the web app causing script execution in the admin's browser — typically S:C for XSS. Impact: stored XSS executes with admin privileges → can change content, possibly execute code, availability impact indirect. I'd pick C:H/I:L/A:N under S:C
Stored cross-site scripting in Concrete CMS versions before 9.5.3 lets an authenticated user with form-editing privileges plant HTML or script inside a Form block question label, which is then rendered unencoded as a column header in the Dashboard Form Submissions report. The payload fires in the browser of any administrator who opens that report for the affected form, allowing the attacker to act with the administrator's session privileges. No public exploit code or active exploitation has been identified at time of analysis; the vendor scored the issue 8.4 under CVSS 4.0 (PR:H, UI:P).
Stored cross-site scripting in Concrete CMS lets any user holding page-editing permissions — for example Add Block combined with Edit Contents on a single page — plant a crafted external link value in Feature, Feature Link, Hero Image, or Image blocks that breaks out of the link markup and injects JavaScript. Because the payload is persisted and rendered without output escaping, the script executes in the browser session of every user who later views, previews, or edits that page, enabling session hijacking and privilege escalation up to full administrative takeover. The vendor scored this 8.5 (CVSS v4.0, PR:H/UI:P); no public exploit code or CISA KEV entry was provided at time of analysis, so exploitation is currently a realistic internal-threat and low-privileged-editor risk rather than a confirmed internet-wide campaign.
Stored SQL injection in Concrete CMS 9.5.2 and earlier lets an authenticated user who is permitted to add or edit a Document Library block persist arbitrary SQL syntax into the block's stored configuration (btDocumentLibrary.setIds), which is then executed every time the published page containing that block is rendered. The flaw arises because the fsID[] file-set identifiers submitted by the block editor are stored without integer validation and are concatenated directly into the file-set filter query when setMode is 'any' instead of being cast or parameter-bound. There is no evidence of active exploitation or public exploit code at time of analysis, and the high privileges required (PR:H) and render-triggered execution (UI:P) temper the 8.5 CVSS v4.0 score assigned by the vendor.
Stored DOM-based cross-site scripting in Concrete CMS 9.5.2 and earlier allows a page editor to plant JavaScript inside a Gallery block image caption, which then executes in the browser of any visitor who opens that image's lightbox. The flaw sits in the bundled Magnific Popup lightbox code (concrete/js/features/imagery/frontend.js), which decodes the caption attribute and re-parses it as HTML via jQuery's .append() inside titleSrc rather than inserting it as text. The vendor rates it CVSS v4.0 8.5 (AV:N/AC:L/AT:N/PR:H/UI:P/VC:H/VI:H/VA:H), requiring an authenticated editor (PR:H) but only passive victim interaction (UI:P); no public exploit code or CISA KEV entry is indicated in the supplied intelligence, and no EPSS score was provided.
Unauthenticated user enumeration in Concrete CMS 9.0.0 through 9.5.2 allows any anonymous visitor to dump the complete backend account list — including internal user IDs, usernames and email addresses of every administrator and the super-administrator (user ID 1) — by sending an empty search to the /ccm/system/user/autocomplete endpoint and paginating the results. The endpoint enforces only a CSRF-style token that is bound to the selector's display options rather than to caller identity, and that token is handed out to anonymous visitors, so there is no authentication or privilege barrier to clear. No password hashes or session material leak, but the disclosed email and account inventory is a ready-made target list for credential stuffing, phishing and password-spray campaigns against named admins; no public exploit code and no CISA KEV entry are present in the supplied intelligence.
Stored XSS in Concrete CMS before 9.5.3 allows a user with edit_block permission to inject malicious JavaScript into a page's YouTube embed block by supplying an unsanitized iframe width or height value. Because only PHP's trim() is applied before the values are written into HTML attribute context, an attacker can persist an event-handler payload that executes in every visitor's browser - and, when the victim holds administrative privileges, the script acts with those privileges. No public exploit code or active exploitation has been identified at time of analysis; the vendor has patched the issue in version 9.5.3.
Stored XSS in Concrete CMS 8.3.0-9.5.2 permits a registered user with calendar event creation rights to inject script payloads via unsanitized event names that later execute in an administrator's browser through unescaped rendering in the dashboard "Waiting For Me" workflow notification block. Because the injected script runs under an active administrator session, an attacker can leverage it to silently create a new administrator account, achieving full CMS compromise. No active exploitation or public proof-of-concept has been identified; the vendor has released version 9.5.3 as the fix and assigned this a CVSS 4.0 score of 7.3.
Stored XSS in Concrete CMS 9.0.0-9.5.2 allows an authenticated editor to escalate privileges to administrator by injecting malicious JavaScript into the custom page alias name (customAliasName) field. The Edit Alias dialog applied only a trim() call to the submitted value with no HTML encoding or output neutralization, causing the alias to render unescaped in the administrative Sitemap panel. Any administrator or editor who subsequently opens the Sitemap panel automatically executes the stored payload, enabling session hijacking and full privilege escalation from editor to administrator. No public exploit has been identified at time of analysis, and the CVE is not listed in CISA KEV.
Stored cross-site scripting via authorization bypass in Concrete CMS 9.2.0-9.5.2 allows an authenticated content editor to inject persistent JavaScript into the HTML head element of every page served by the site. The REST API page update endpoint (PUT /ccm/api/1.0/pages/{cID}) enforces only basic content-editing authorization, omitting checks for page-property, page-template, and page-type changes; the `header_extra_content` attribute is rendered unescaped site-wide. No public exploit has been identified at time of analysis and the vulnerability is not listed in CISA KEV, but the stored XSS payload targets all visitors including privileged reviewers, enabling session hijacking and effective privilege escalation in multi-user editorial deployments.
Missing CSRF token validation on the orphaned block removal action (`removeOrphanedBlocks`) in Concrete CMS 9.0.0 through 9.5.2 enables remote attackers to permanently destroy all block content on any page the victim can edit. By tricking an authenticated editor into loading a crafted URL, an attacker triggers deletion of every block on the targeted page's current version; blocks not aliased elsewhere are additionally purged from the global Blocks table and their block-type data tables, making the destruction irreversible without a database backup. No public exploit code identified at time of analysis; the Concrete CMS security team assigned a CVSS 4.0 score of 7.1 reflecting high integrity impact gated on one user interaction.
Stored XSS in Concrete CMS 9.0.0-9.5.2 allows a low-privileged user with delegated access to the Page Containers dashboard to inject malicious script via a crafted container icon value that breaks out of an img src attribute due to missing output encoding. The payload persists in the database and executes in the authenticated session of any administrator or editor who subsequently views the Containers dashboard list or editor views, enabling session token theft and unauthorized privileged CMS actions. No public exploit code and no CISA KEV listing have been identified at time of analysis; the vendor released a fix in version 9.5.3.
Stored cross-site scripting in Concrete CMS versions 5.0.0 through 9.5.2 lets an editor-level account inject unsanitized custom style values through the Block Design dialog, which are then written into page CSS via a DOM sink and execute in the browser of any higher-privileged user who views the affected page. Because the payload runs in an administrator's session, an editor can hijack the admin session and escalate to full administrative control of the site. No public exploit code or in-the-wild exploitation is identified at time of analysis (SSVC Exploitation: none; not listed in CISA KEV), and the vendor-rated CVSS v4.0 score is 7.0 with a passive user-interaction requirement (UI:P).
PHP object injection in Concrete CMS versions below 9.5.2 allows authenticated high-privileged attackers to trigger arbitrary PHP object instantiation through unsafe unserialize() calls in the Workflow, Form block, and File/Set components. The vulnerability requires a malicious serialized payload to be placed in the database beforehand, and no public exploit identified at time of analysis. The vendor scored this 8.4 (CVSS 4.0), and CISA SSVC indicates no observed exploitation but total technical impact if successfully chained.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator's browser into triggering a core CMS upgrade to an attacker-chosen version. The dashboard's do_update() controller emits a CSRF token in the rendered POST form but never calls $this->token->validate('do_update'), leaving the update workflow effectively unauthenticated against forged cross-origin requests. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Remote code execution in Concrete CMS 9.5.0 and earlier is achievable through a CSRF flaw in the /dashboard/extend/update/prepare_remote_upgrade/<remoteMPID> endpoint, which fails to validate anti-CSRF tokens. An attacker who controls a marketplace package matching an item ID already installed on the victim site can overwrite package PHP files and trigger the upgrade() method via a single navigation by a privileged admin, resulting in code execution as the web server user. No public exploit identified at time of analysis, though the vendor (Concrete CMS security team) has acknowledged and rated the issue at CVSS 4.0 7.5.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator with canInstallPackages permission into installing an attacker-controlled package, resulting in remote code execution as the web server user. The flaw resides in the install_package() method of the dashboard's extend/install.php controller, which lacks CSRF token validation. No public exploit identified at time of analysis, and the issue is not listed in CISA KEV.
Privilege escalation in Concrete CMS 9.5.0 and earlier allows authenticated users with access to the bulk user assignment dashboard to add arbitrary accounts to the Administrators group and remove existing admins, effectively hijacking site control. The flaw stems from missing authorization checks in bulk_user_assignment.php and was disclosed with a vendor-assigned CVSS v4.0 score of 7.5. No public exploit identified at time of analysis, and the issue is not present in CISA KEV.
Stored cross-site scripting in Concrete CMS 9.5.0 and earlier allows authenticated editors to inject persistent JavaScript via the unvalidated 'height' parameter, executing in any subsequent visitor's browser. The CVSS 4.0 score of 7.3 reflects high privilege requirements (editor role) combined with high impact, and no public exploit identified at time of analysis.
Stored cross-site scripting in Concrete CMS 9.5.0 and earlier allows a high-privileged admin to inject arbitrary HTML/JavaScript into the OAuth authorize template via the integration name field. The flaw arises because the integration name is wrapped in <strong> tags by PHP string interpolation before being passed to the t() translation helper, causing the resulting raw HTML to be rendered when end users view the OAuth consent screen. No public exploit identified at time of analysis, but a rogue or compromised admin could potentially harvest OAuth login submissions from victims.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce authenticated administrators into downloading arbitrary marketplace packages to the server's DIR_PACKAGES directory by luring them to a crafted page that triggers the unprotected /dashboard/extend/install/download/<remoteId> GET endpoint. The vendor assigned CVSS 4.0 of 7.5 reflecting high impact on confidentiality, integrity, and availability, though no public exploit identified at time of analysis and the flaw is not listed in CISA KEV.
Cross-site request forgery in Concrete CMS 9.5.0 and earlier allows remote attackers to coerce an authenticated administrator into triggering arbitrary package upgrades by luring them to a malicious page that issues a single GET to /dashboard/extend/update/do_update/<pkgHandle>. The do_update() handler only checks the canInstallPackages() permission and omits CSRF token validation on this state-changing route, so a cross-site navigation is sufficient to invoke upgradeCoreData() and the package controller's upgrade() routine. No public exploit identified at time of analysis and no CISA KEV listing; EPSS not provided.
Remote code execution in Concrete CMS versions 5.0 through 9.5.0 allows a high-privileged administrator to bypass the platform's `_fromCIF` deserialization guard by submitting malicious payloads through the REST API instead of standard form POST requests. The flaw resides in the ExpressEntryList block controller (CWE-502) and stores a serialized PHP gadget in the `filterFields` database column, which is unmarshalled when another administrator subsequently views or edits the block, leading to full server takeover. No public exploit identified at time of analysis, and the issue is not present in CISA KEV.
Authenticated remote code execution in Concrete CMS 9.5.0 and earlier allows an administrator with composer form editing privileges to chain a path traversal flaw in the ptComposerFormLayoutSetControlCustomTemplate field with the platform's permissive file uploader to execute arbitrary PHP on the server. The vendor scored this 9.4 (CVSS v4.0) reflecting high confidentiality, integrity, and availability impact across both the vulnerable component and downstream subsequent systems. No public exploit identified at time of analysis, and the issue is not currently listed in CISA KEV.
Remote code execution in Concrete CMS prior to version 9.4.8 stems from unsafe deserialization of PHP objects in the Express Entry List block configuration. An authenticated administrator can inject malicious serialized data through the columns parameter that executes arbitrary code when unserialized without validation. This allows attackers with admin privileges to achieve complete system compromise through stored object injection attacks.
Unauthenticated information disclosure in Concrete CMS releases before 9.5.3 allows a remote visitor who knows or can guess a valid Express entity identifier to query a legacy Express entry search endpoint that omits the canViewExpressEntries() permission check, returning entry attribute values that should be restricted to privileged users. The impact is read-only (C:L/I:N/A:N) and exploitation requires that identifier prerequisite, which is why the vendor and independent assessments both score it as hardening-limited rather than trivially exploitable; disclosure is worse for Express entities where supportsEntrySpecificPermissions() returns false, because EntryList::ignorePermissions() then bypasses per-entry filtering entirely. No public exploit code has been identified at time of analysis, and this CVE is not confirmed actively exploited (no CISA KEV listing); the fix is included in the 9.5.3 release.
Deactivated, deleted, or password-reset-locked Concrete CMS accounts keep working API access via any bearer token issued to them before the account state change, letting the holder continue calling the OAuth REST API endpoints under /ccm/api/1.0/* until that already-issued token expires on its own. All Concrete CMS versions before 9.5.4 are affected when the OAuth REST API is enabled; the vendor rates this only 2.0 (CVSS v4.0) and our independent assessment aligns with a low-impact, high-complexity authenticated issue, with no public exploit identified at time of analysis. The flaw is time-limited to the residual lifetime of the token and grants no more access than that token originally had, so it is a stale-credential/session-expiration problem rather than a route to new privileges.
Concrete CMS 9.2.0 through 9.5.3 fails to enforce an authorization check on its REST API user-creation endpoint (POST /ccm/api/1.0/users), so any request bearing a valid OAuth token that carries the users:add scope - including a client_credentials token with no associated user context - can create active, validated accounts while bypassing email verification and administrator approval. The endpoint's add() method in concrete/src/Api/Controller/Users.php performs no permission verification, making this a classic missing-authorization weakness (CWE-862) that an authenticated API consumer can abuse to gain a foothold. Under default registration settings the newly minted accounts are allowed to edit page content, which provides an escalation path to stored cross-site scripting and further compromise of the CMS. No public exploit code or confirmed active exploitation (CISA KEV) was identified at time of analysis, and the reporter-independent assessment rates the impact as limited to low integrity loss on the CMS itself.
Broken authorization in Concrete CMS 9 through 9.5.3 allows an authenticated user who already holds edit-board-contents permission on one board instance to query the custom-slot preview endpoint with an InstanceItem identifier belonging to a different board instance, causing the system to return summary fields - including the underlying page title and description - for pages that user is not permitted to view. The endpoint fails both to validate that the submitted item belongs to a board the requester is authorized to edit and to enforce page-view permission before generating the page-backed summary content. Rated CVSS v4.0 5.3 (our independent assessment: CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), this is a low-to-moderate severity IDOR-class information-disclosure flaw with no published exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); no user interaction is required, but exploitation is gated behind an authenticated account with per-board edit permission.
Stored cross-site scripting in Concrete CMS 9.5.2 and earlier allows an authenticated user with file-upload rights to embed a javascript: URI in an SVG's xlink:href attribute that survives storage and executes in the browser of any user who opens the uploaded file directly. The flaw only manifests when the non-default 'Reject files containing potentially harmful elements' mode is selected (concrete.file_manager.images.svg_sanitization.action = reject), because in that mode the CMS discarded the output of the enshrined/svg-sanitize pass and relied solely on a narrow built-in blocklist covering <script> and on* handlers. No public exploit code or CISA KEV listing was identified, and the vendor-assigned CVSS v4.0 base score is a low 1.8, reflecting the need for upload privileges, a non-default configuration, and victim interaction.
Concrete CMS versions 9.4.0 through 9.5.2 fail to escape page paths before rendering them inside the location panel's duplicate-path confirmation dialog: the panel's check endpoint reflects the submitted path unmodified in its JSON response, and client-side JavaScript injects that value as raw HTML, so a crafted path executes script in an authenticated editor's browser session. An attacker must already hold page-authoring privileges and must engineer a path collision so the confirmation dialog appears, and the victim must then open that panel; no public exploit code or CISA KEV entry is associated with this CVE at time of analysis.
Let me synthesize. CVE-2026-18426: Concrete CMS 9.0.0 through 9.5.2, missing block-level edit permission check on Express Form block control-management actions, relying solely on CSRF token validation. Token bound to user and action, not block/page/form. So authenticated user with edit access to one Express Form could reuse token to add/modify/delete controls on forms they aren't authorized to edit, including injecting control whose value later rendered as HTML → stored XSS. CVSS 4.0 2.0, AV:N/AC:H/AT:P/PR:H/UI:P/VC:L/VI:N/VA:N. CWE-862 missing authorization. Tags: XSS, Authentication Bypass, CSRF. Hmm — "Authentication Bypass" tag is arguably mislabeled since it's a missing authorization check (CWE-862), not authentication bypass. Actually that's a good candidate for data_quality_flags mislabeled_tag. The tag "Authentication Bypass" is wrong — this is an authorization flaw (CWE-862), not authentication bypass. Confidence: medium/high. I'd say medium-high. Let's use "high" given CWE-862 is explicitly missing authorization and PR:H required (authenticated user). Actually the tag list includes both XSS and CSRF — both apply somewhat (stored XSS outcome, CSRF token bypass). "Authentication Bypass" is the questionable one. I'll flag it with confidence "medium" or "high". I'll use "high" — the description explicitly says "did not enforce a block-level edit-permission check", which is authorization, and CVSS PR:H means authenticated. So "Authentication Bypass" is mislabeled. Suggest "Missing Authorization" — hmm, suggested field is "the correct/canonical slug if you know it". Perhaps suggested: "missing-authorization" or "authorization-bypass". I'll say "authorization-bypass". Missing tags? Maybe "concrete-cms" / "concrete5" vendor tag absent. Tags list: XSS, Authentication Bypass, CSRF. Missing tag candidates: "Concrete CMS" (vendor/product) — suggested "concrete-cms", high confidence from description. Also "CWE-862" / "Missing Authorization" technique tag. I'll add "
Reflected cross-site scripting in Concrete CMS versions 5.0.0 through 9.5.2 lets an attacker run arbitrary JavaScript in a victim's browser by abusing the conversation messages feature's handling of a user-supplied custom date format. Because the conversation view endpoint carries no CSRF token, the payload can be delivered through an auto-submitting cross-origin POST from an attacker-controlled page, and the independently assessed vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) treats the attack as unauthenticated, requiring only that the victim load a malicious page. Impact is limited to the victim's browser session - reflected rather than stored XSS, with partial confidentiality and integrity loss and no availability impact - and the vendor's own CVSS v4.0 score of 2.1 (AT:P/PR:L/UI:P) reflects that exploitability depends on attacker-provided content and victim interaction; no public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fully remediated in 9.5.3.
Concrete CMS 9.0.0 through 9.5.2 lets an authenticated user who holds only the global access_sitemap permission reorder any page in the site tree, including pages they have no rights to edit, because the dashboard sitemap reorder controller (Concrete\Controller\Backend\Dashboard\SitemapUpdate) never checks per-page edit permission before writing each page's cDisplayOrder value. The same action validates no CSRF token, so a forged request from a sitemap-privileged victim's browser can perform the write silently, changing the order in which pages appear in navigation menus, breadcrumbs, and page lists. Concrete CMS shipped a fix in 9.5.3; the vendor rates the issue CVSS v4.0 2.1 (integrity-only, no confidentiality or availability impact), and there is no public exploit code or CISA KEV listing identified at time of analysis.
Server-side request forgery in Concrete CMS 9.0.0 through 9.5.2 allows an authenticated user who holds file-import privileges to make the server fetch internal-only resources by abusing a DNS pin that is validated once per host and then reused for every later URL on that host. Because the pinned validation and the unpinned download can resolve to different addresses, a rebinding host can redirect the request to loopback services, internal admin panels, or cloud metadata endpoints, with responses saved into the file manager. The vendor rates this only CVSS 4.0 base 2.1 given the high complexity and privileged prerequisite; no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS 9.0.0 through 9.5.2 contains an insecure direct object reference in the Express saved search preset delete and edit dialogs, letting any authenticated user who holds only view permission on a single Express entity permanently delete (with no undo) or rename saved search presets owned by Express entities they have no permission over. Because a renamed preset is rendered back to users of the targeted entity, the flaw enables content defacement or social-engineering-style manipulation of other teams' saved searches. The vendor scored it CVSS 4.0 2.1 (Low) with PR:H and AT:P; no public exploit code, EPSS score, or CISA KEV listing was identified at time of analysis.
Concrete CMS 9.5.2 and earlier fail to enforce a destination-side authorization check and omit CSRF token validation in the multilingual page-assignment backend action (Backend\Page\Multilingual::assign), letting an authenticated editor who holds the Edit Page Multilingual Settings permission on just one page rebind an arbitrary page from another locale as that page's translation and delete legitimate translation pairs maintained by other editors. The result is silent manipulation of public-facing language routing across the site, with no confidentiality impact and only limited integrity/availability damage. The vendor scores this 2.1 (CVSS v4.0) because the actor must already be an authenticated, privileged editor; no public exploit code and no active exploitation have been reported.
Cross-site request forgery in Concrete CMS before 9.5.3 lets a remote attacker silently create theme page-template records inside a logged-in administrator's session. The Dashboard theme Inspect controller's activate_files() action accepts attacker-supplied pageTemplates[] values without validating an anti-CSRF token, so a forged auto-submitting POST from a page the admin merely visits is honored as legitimate. Impact is limited to unauthorized configuration change (integrity only, CVSS v4.0 base 2.1), and no public exploit code or CISA KEV entry was identified at time of analysis.
Concrete CMS versions before 9.5.3 contain a missing-authorization flaw in the SEO Bulk Update Meta Tags editor: the saveRecord() action validated the per-page CSRF token but never invoked canEditPageProperties() for the target page. As a result, an authenticated user who was granted access to the bulk SEO tool and could merely view a page could rewrite that page's meta title, meta description, and URL handle, tampering with presentation content and live URLs outside their intended edit scope. The vendor rates this only 2.1 (CVSS v4.0, integrity-only), there is no public exploit code identified at time of analysis, and the issue is not known to be actively exploited (no CISA KEV listing).
Missing per-page authorization in the Concrete CMS sitemap controller (all versions before 9.5.3) lets any authenticated dashboard user who can reach the sitemap reorder pages they have no edit or arrange rights over, silently altering the site's global navigation order. The send_to_top and send_to_bottom tasks trust the attacker-supplied cNodeID parameter and load/update the target page without verifying move permission on that specific node (CWE-862); impact is integrity-only (CVSS v4.0 2.1, PR:H, VI:L). No public exploit code or CISA KEV entry was identified at time of analysis, and a vendor fix is available in Concrete CMS 9.5.3.
Concrete CMS 8.5.3 through 9.5.2 lets a suspended or deactivated user keep minting valid OAuth 2.0 access tokens through the refresh-token grant, because the grant never re-checks the account's active flag (uIsActive=0) before issuing new tokens. Anyone who legitimately obtained a refresh token while their account was active retains API access after offboarding, so deactivation alone no longer revokes API credentials. The vendor assigned a low CVSS v4.0 base score of 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N, all impacts Low); no public exploit code or CISA KEV listing was provided at time of analysis.
Cross-site request forgery in the Concrete CMS dashboard 'SEO Excluded Words' reset action lets a remote attacker who lures an authenticated administrator to a crafted page silently wipe the site's reserved-word list (concrete.seo.exclude_words) and restore vendor defaults, in every release below 9.5.3. The reset() controller validated neither the anti-CSRF token emitted by its own modal nor the HTTP method, so a cross-site request from the victim's authenticated browser is honoured. The impact is integrity-only and narrowly scoped — future automatically generated URL slugs for pages, files and topics stop honouring the site's SEO policy — and the vendor rates it CVSS 4.0 2.3; no public exploit code or CISA KEV entry was identified at the time of analysis.
Concrete CMS versions 9.0.0 through 9.5.2 fail to validate a CSRF token on the dashboard group type controller's delete action, allowing a remote attacker to force a logged-in administrator into deleting a custom group type. The attacker needs no authentication of their own but must lure a victim who holds group type management permission into visiting a malicious page while logged in, which is why the vendor rated it only 2.3 under CVSS 4.0. There is no indication of active exploitation or public exploit code, and the issue is fixed in the 9.5.3 release.
Concrete CMS versions below 9.5.3 import files uploaded through the conversation attachment endpoint into the site's file manager before verifying the 'Add Message Attachments' permission, so the authorization check happens only after the file has already been stored. A low-privileged authenticated user who has been explicitly denied that permission — or an unauthenticated visitor on a site configured to allow guest posting — can therefore inject files of allowed types into the file manager, altering stored content or consuming storage. The vendor rates this CVSS v4.0 2.3 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:L), indicating limited integrity and availability impact rather than code execution, and there is no public exploit code identified at time of analysis.
Stored cross-site scripting in Concrete CMS 5.0.0 through 9.5.2 lets an unauthenticated attacker inject raw HTML through a publicly accessible Express Form; the payload is rendered unsanitized as an Express entry label whenever associated entries are displayed, executing in an administrator's dashboard session and in the browsers of visitors to pages containing an Express Entry List block with association columns. The Concrete CMS security team rates this CVSS v4.0 2.3 (AV:N/AC:L/AT:P/PR:N/UI:P), reflecting that exploitation depends on specific Express configuration and passive victim interaction rather than open, unconditional exposure. No public exploit code or CISA KEV listing was identified at time of analysis, and fixed code is available in Concrete CMS 9.5.3.
Concrete CMS versions below 9.5.3 fail to validate an anti-CSRF token on the block-arrangement backend endpoint (Concrete\Controller\Backend\Page\ArrangeBlocks::arrange), so a session-holding content editor can be tricked into silently reordering or moving blocks in the draft of a page they are allowed to edit. Exploitation is browser-driven cross-site request forgery: the attacker needs only to lure a logged-in editor to an attacker-controlled page while the default null SameSite cookie setting lets the victim's session cookie ride along with the forged request. Impact is limited to integrity of draft content layout (CVSS v4.0 2.3, CWE-352); no public exploit code and no active exploitation are indicated in the supplied intelligence, and no EPSS score was provided.
CSRF in Concrete CMS 9.5.2 and below allows a remote unauthenticated attacker to permanently delete all entries of an Express entity by tricking an authenticated administrator into visiting an attacker-controlled page. The root flaw is that the delete_entries controller records a CSRF token mismatch but proceeds with the destructive operation anyway, making the protection entirely non-functional. The default Contact Express object ships with a fixed, predictable entity UUID, so attackers can target that data store without any prior dashboard access.
Stored cross-site scripting in Concrete CMS versions below 9.5.3 allows an authenticated user with edit_page_contents permissions to inject malicious script payloads via the Date Format field in the Page Attribute Display block. Any site visitor who subsequently loads a page containing the poisoned block will execute the attacker's script in their browser, enabling session-token theft or malicious redirects. A vendor-released patch is available (9.5.3), no public exploit has been identified, and no CISA KEV listing exists at time of analysis.
Broken access control in Concrete CMS before 9.5.3 allows authenticated users with limited Express entry permissions to inject entries into Express objects they are not authorized to modify. The vulnerability stems from a parameter confusion bug where the permission check validates the entity supplied in the POST body, but the dashboard submit route resolves the actual target entity from an attacker-controlled route ID - and the two are never compared. An attacker who legitimately holds add-entry permissions on one Express object can therefore write to entirely different, protected datasets, potentially triggering administrative workflows or polluting content managed by higher-privilege users. No public exploit code or CISA KEV listing has been identified at time of analysis.
Stored cross-site scripting in Concrete CMS below 9.5.3 allows an authenticated user holding file-property edit permissions to inject persistent script payloads via the Document Library block's description and tags fields, executing against any visitor - including unauthenticated users - who loads a page rendering those columns. The block controller returned description and tags values without the h() output-escaping helper already applied to the title column, and the view template wrote these raw values directly into the HTML results table. Successful exploitation can result in session token theft or unauthorized browser-side actions against visitors. No public exploit code or CISA KEV listing has been identified at time of analysis.
Missing authorization in Concrete CMS 9.2.0-9.5.2 allows authenticated editors holding block-add scope to bypass file-manager visibility controls by exploiting the Area API's block-create endpoint, which never invokes the block type controller's validate() method. For file-referencing block types such as hero_image and gallery, this validate() call is the sole enforcement point for file access authorization - its omission means a restricted file reference can be stored and rendered on any page. The unauthorized file's URL and thumbnail preview are then disclosed to both the submitting editor and all page visitors, with the severity of that disclosure dependent on whether public or private file storage is configured. No public exploit has been identified at time of analysis.
Missing object-level authorization in Concrete CMS below 9.5.3 allows a signed-in dashboard user with limited Page Type editing rights to modify arbitrary Page Types outside their assigned permission boundary. The Types::submit() controller accepts a user-supplied ptID parameter and persists the targeted Page Type without invoking canEditPageType(), meaning the CSRF token validation - which is action- and user-scoped only - provides no object-level constraint. No public exploit or active exploitation has been identified; the vendor self-reported this as a moderate integrity issue (CVSS 4.0: 5.1) and patched it in version 9.5.3.
Missing CSRF token validation in Concrete CMS before 9.5.3 allows a remote attacker to trick an authenticated calendar editor into silently creating unwanted duplicate events. The vulnerable endpoint - the Calendar event duplicate dialog's submit() action in concrete/controllers/dialog/event/duplicate.php - enforced only object-level permissions (canAccess() and canAddCalendarEvent()) without verifying an anti-CSRF synchronizer token, meaning any forged cross-site request submitted on behalf of a legitimate session could produce spurious CalendarEvent and CalendarEventVersions database records. No public exploit or active exploitation has been identified; the vendor-assigned CVSS 4.0 score of 5.3 reflects the bounded, integrity-only impact.
Open redirect in Concrete CMS 9.5.0-9.5.2 allows an unauthenticated attacker to craft a legitimate-looking URL on the victim site that silently forwards an authenticated user to an arbitrary external domain immediately after login or registration. The vulnerability targets the newly introduced `rcURL` parameter in the authentication and registration flows, making it uniquely scoped to the 9.5.x minor release line. Exploitation facilitates phishing and credential harvesting by abusing the implicit trust users place in a URL belonging to a known, legitimate domain. No public exploit code or active exploitation has been identified at time of analysis.
Cross-site request forgery in Concrete CMS before 9.5.3 allows an attacker to silently relocate user group tree nodes on behalf of an authenticated administrator, exploiting the missing action-token validation on the dashboard/users/groups/bulkupdate/confirm() endpoint. Because Concrete CMS inherits parent-group permissions down to child-group members, a forged group move can silently expand the authorization scope of affected users, granting access to restricted content areas without any administrator awareness. No public exploit has been identified at time of analysis; the vendor released a fix in version 9.5.3.
Stored XSS in Concrete CMS 9.0.0-9.5.2 allows a user with board-editing permissions to inject arbitrary JavaScript into the description field of a summary object via the Board Custom Slot's `save_template` endpoint, which accepts the raw client-supplied `selectedTemplateOption[collection]` parameter without server-side validation or sanitization. The default summary template renders the description field without output encoding, so the stored payload fires in the browser of every subsequent visitor to the affected board slot - including unauthenticated front-end users and dashboard administrators. Successful exploitation enables session hijacking or forced CSRF actions, potentially escalating to full administrative compromise. No public exploit has been identified and the vulnerability is not listed in CISA KEV.
Server-Side Template Injection in Concrete CMS 9 through 9.5.2 allows a privileged user holding the Theme Customization permission to inject arbitrary LESS directives into style values processed by the server-side LESS compiler. By crafting an @import (inline) directive within color, font, or image style fields, the attacker can read arbitrary files from the server filesystem and reach internal network resources via PHP stream wrappers, with the compiled output - including any exfiltrated file contents - written directly to the publicly accessible CSS cache. This combination of sensitive file disclosure and SSRF enables credential theft and further lateral movement; no public exploit has been identified at time of analysis.
Missing authorization in the block alias route of Concrete CMS 9.x through 9.5.2 allows an authenticated editor holding only a limited area-scoped add_block_to_area delegation to read and permanently destroy arbitrary block content across the entire site. The vulnerable method Process::alias() in concrete/controllers/backend/block/process.php accepts caller-supplied block IDs without verifying ownership over the source block or confirming it is genuinely orphaned on the caller's page, enabling cross-page content theft via duplication and forced silent deletion of the original. No active exploitation has been confirmed in CISA KEV and no public exploit code exists, but the attack is mechanically straightforward for any qualifying editor account.
Stored cross-site scripting in Concrete CMS's RSS Displayer block (versions below 9.5.3) allows an external attacker who controls a syndicated feed to inject arbitrary JavaScript into any page that renders that feed, executing in the site origin for all visitors including authenticated administrators. The attack requires no account on the vulnerable site; the malicious payload persists across all page loads until the feed content changes or the block is removed. Concrete CMS assigned a CVSS 4.0 score of 6.0 reflecting high attack complexity, and no public exploit has been identified at time of analysis.
Missing per-entry authorization in Concrete CMS 9.2.0-9.5.2 allows any low-privileged OAuth token holder to enumerate Express entries they are not permitted to view via the REST API collection endpoint. The Express entry list endpoint omitted the per-entry view permission check, so a token with read scope for an Express entity returns restricted records including identifiers, URLs, labels, dates, and any custom attribute or associated-entry data requested through the includes parameter. The issue is fixed in 9.5.3; no public exploit has been identified and it is not listed in CISA KEV.
Unauthorized group enumeration in Concrete CMS 9.2.0 through 9.5.2 exposes the full organizational group structure to any authenticated API user holding a groups:read token. The root cause is a permission-checker callback in the REST API Groups controller that unconditionally returns true, eliminating per-object (tree-node) authorization on the group collection endpoint. With authentication required and no public exploit identified, the practical blast radius is limited to insiders or compromised API accounts, but the disclosed group hierarchy can materially assist privilege-escalation reconnaissance on affected sites.
Concrete CMS versions prior to 9.5.3 allow deactivated or email-unvalidated users to bypass account-status enforcement by authenticating through the OAuth callback path. When a user whose account has been deactivated or whose email address has not been verified holds an existing OAuth provider binding, the CMS completes the OAuth handshake, records a login event, and issues a fully-authenticated session without verifying whether the account is permitted to log in. No public exploit has been identified at time of analysis; the vendor (Concrete CMS security team) assigned a CVSS 4.0 score of 6.3 reflecting the constrained attack preconditions.
Hash type confusion in Concrete CMS (below 9.5.3) allows cross-purpose token redemption: a long-lived registration hash (60-day expiry) can be submitted to the password-change endpoint to take over an account, or a password-reset hash can activate an unverified account. This is an amplifier vulnerability - exploitation requires the attacker to first acquire a valid hash through a separate channel such as email interception, log exposure, or SSRF against an internal mail relay, making it a force-multiplier for hash disclosure rather than a standalone attack path. No public exploit is identified and the vendor-assigned CVSS 4.0 score of 6.3 with AC:H and AT:P reflects the conditional nature of exploitation.
Unauthenticated event metadata disclosure in Concrete CMS 9.5.2 and earlier allows any visitor to enumerate private calendar event details via a sequential IDOR on the frontend lightbox endpoint. The controller at /ccm/calendar/view_event/{bID}/{occurrence_id} loads occurrence records directly from attacker-supplied integer IDs without verifying that the occurrence belongs to the calendar block referenced by bID or that the caller holds read permission on the owning calendar. This enables systematic disclosure of event titles, dates, descriptions, page links, and configured attributes across all calendars on the installation, including those intended to be access-restricted. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.
Cross-site request forgery in Concrete CMS 9.x through 9.5.2 allows an unauthenticated attacker to forge board-content modifications on behalf of any authenticated user who holds board-edit permission. The saveTemplate() action in the Boards custom slot dialog controller omits anti-CSRF token validation, permitting a crafted HTTP request to write attacker-controlled slot and template data to a board under the victim's authority. No public exploit has been identified at time of analysis, and the vendor has released version 9.5.3 as the fix.
Calendar event authorization in Concrete CMS 8.3.0-9.5.2 is bypassed because the event edit dialog validates the actor's permissions against a calendar identifier supplied in the HTTP request rather than the calendar that actually owns the targeted event occurrence. An authenticated user holding 'Add Event' rights on any single calendar can read and overwrite events across all other calendars in the installation, and delete individual event occurrences; publishing the injected version as the live-approved revision additionally requires approve_calendar_event workflow rights or an auto-approving workflow. Vendor-released patch is available in version 9.5.3; no public exploit has been identified at time of analysis.
Stored XSS in Concrete CMS 9.0 through 9.5.0 enables a rogue editor to inject persistent JavaScript via the page name field within the Atomik theme, executing in the browser session of any authenticated user who visits the affected pages. Consequences include session hijacking, credential theft, and unauthorized actions performed as the victim - potentially escalating to higher privileges if an administrator is targeted. No active exploitation is confirmed (SSVC: none; EPSS 0.04% at the 13th percentile), and a vendor-released patch is available in version 9.5.1.
Concrete CMS 9.5.0 and earlier exposes an IDOR combined with an incorrect authorization level check in the Express association Reorder dialog, enabling authenticated users with only view-only permission to tamper with entity ordering state for entries they do not own. The flaw is limited to sites actively using the Concrete CMS Express application-builder feature with entity ordering configured - a non-default deployment subset. No public exploit or active exploitation has been identified; all available signals (CVSS 4.0 of 2.3, EPSS at 0.04%, SSVC exploitation: none) consistently characterize this as a low-priority, narrow-impact finding.
CSRF in Concrete CMS 9.5.0 and below enables a network-based attacker to trick an authenticated backend editor into silently approving an unintended file version via the Backend\File::approveVersion endpoint, effectively downgrading a published file or activating an unpublished co-editor version without the victim's knowledge. Exploitation is constrained to users holding the edit_file_contents permission who can be socially engineered into visiting an attacker-controlled page while logged in. No public exploit code exists and no active exploitation has been identified; EPSS at 0.02% and SSVC Exploitation:none confirm minimal real-world urgency. Vendor patch available in version 9.5.1.
CSRF vulnerability in Concrete CMS 9.x before 9.5.0 allows a network-based attacker to trigger unauthorized log deletion by tricking an authenticated user into visiting a crafted page that silently issues a forged request to the concrete/controllers/dialog/logs/delete endpoint. The Concrete CMS security team assigned this a CVSS v4.0 score of 2.3, reflecting low integrity impact and the presence of attack prerequisites. No public exploit code has been identified and it is not listed in the CISA KEV catalog.
Stored XSS in Concrete CMS 9.5.0 and below allows a high-privileged authenticated attacker to inject malicious scripts via the cvName parameter of external-link pages, exploiting a sanitization bypass in the updateCollectionAliasExternal function. The injected payload is persisted server-side and executes in the browser of any user who subsequently views the affected page within the CMS backend. The vendor-assigned CVSS v4.0 score of 2.0 reflects constrained real-world impact: exploitation requires admin-level credentials, prerequisite attack conditions (AT:P), and passive victim interaction, with no public exploit identified at time of analysis.
Server-side request forgery in Concrete CMS 9.5.0 and earlier allows authenticated high-privileged page editors to direct the application server to fetch attacker-controlled URLs via the RSS Displayer block, with redirect-following behavior bypassing input validation to reach internal network resources. The CVSS v4.0 score of 2.1 (PR:H, AT:P) reflects that exploitation is constrained to users already holding page editor privileges and requires the RSS Displayer block to be in active use. No public exploit has been identified and this vulnerability is not listed in CISA KEV, placing it in a low real-world priority tier absent insider-threat or post-compromise scenarios.
Cross-Site Request Forgery in Concrete CMS 9.x allows an unauthenticated remote attacker to delete application logs on behalf of an authenticated victim by tricking them into visiting a malicious page. The vulnerable endpoint is concrete/controllers/dialog/logs/bulk/delete, and exploitation results in low-integrity impact - specifically, destruction of audit log data. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS v4.0 score of 2.3 reflects the combination of required user interaction and the presence of attack prerequisites.
Cross-Site Request Forgery in Concrete CMS 9.x through 9.5.0 allows a remote unauthenticated attacker to trigger bulk page deletion by tricking an authenticated user into visiting a malicious web page. The vulnerable endpoint is concrete/controllers/dialog/page/bulk/delete, and exploitation results in low-integrity impact against the vulnerable system. No public exploit code has been identified at time of analysis, and the Concrete CMS security team assigned a CVSS v4.0 score of 2.3, reflecting the prerequisite of passive victim interaction and the constrained impact.
Cross-Site Request Forgery in Concrete CMS 9 allows a remote unauthenticated attacker to trigger unauthorized bulk cache operations against authenticated CMS users. The vulnerable endpoint is concrete/controllers/dialog/page/bulk/cache, which fails to validate request origin, enabling an attacker to manipulate page cache state by deceiving a logged-in user into loading a crafted page. No public exploit or active exploitation has been identified; the Concrete CMS security team rated this CVSS v4.0 2.3 (Low), reflecting limited integrity impact and the prerequisite of user interaction.
Cross-Site Request Forgery in Concrete CMS 9.x exposes the bulk page design dialog endpoint (concrete/controllers/dialog/page/bulk/design) to forged requests, allowing a network-accessible attacker to manipulate page design settings on behalf of an authenticated user who visits a malicious link. The Concrete CMS security team assigned a CVSS v4.0 score of 2.3 (Low), reflecting that exploitation requires specific attack prerequisites (AT:P) and user interaction (UI:P), with impact limited to low-severity integrity modifications on the vulnerable system. No public exploit identified at time of analysis, and this CVE is not listed in the CISA KEV catalog.
Cross-site request forgery in Concrete CMS 9.x before 9.5.0 permits a remote unauthenticated attacker to trigger unauthorized event duplication on behalf of an authenticated user by luring that user to an attacker-controlled page. The vulnerable endpoint is `concrete/controllers/dialog/event/duplicate`, which lacks CSRF token validation. The vendor-assigned CVSS v4.0 score of 2.3 reflects genuinely low impact - limited to a low-integrity effect on the vulnerable system - and no public exploit code or CISA KEV listing has been identified at the time of analysis.
Cross-Site Request Forgery in Concrete CMS 9.x allows a remote unauthenticated attacker to trigger unauthorized reordering of Express Object associations by tricking an authenticated user into visiting a crafted page. The vulnerability targets the endpoint concrete/controllers/dialog/express/association/reorder, with impact limited to low-severity integrity modification of the vulnerable system only. No public exploit has been identified at time of analysis, and the low CVSS v4.0 score of 2.3 reflects the combination of required user interaction, specific prerequisite conditions (AT:P), and limited data impact.
Cross-Site Request Forgery in Concrete CMS 9.x allows a remote unauthenticated attacker to forge state-changing requests against the file manager's addFavoriteFolder endpoint on behalf of an authenticated victim. Exploitation results in low-integrity impact - specifically unauthorized modification of a victim's favorite folder state - without any confidentiality or availability consequences. No public exploit has been identified at time of analysis, and the low CVSS v4.0 score of 2.3 reflects the passive user interaction requirement and constrained impact scope.
Cross-Site Request Forgery in Concrete CMS 9.x (versions prior to 9.5.0) allows a remote attacker to trigger the removeFavoriteFolder action on behalf of an authenticated CMS user by tricking them into visiting a malicious page. The affected endpoint is concrete/controllers/backend/file and the impact is limited to low-integrity modification - removal of a favorite folder. No public exploit has been identified and this vulnerability is not confirmed as actively exploited (CISA KEV). The CVSS 4.0 score of 2.3 accurately reflects the constrained, low-impact nature of the flaw.
Cross-Site Request Forgery (CSRF) in Concrete CMS 9.x before 9.5.1 allows a remote unauthenticated attacker to trigger unauthorized file-starring actions on behalf of an authenticated victim by luring them to a malicious page. The vulnerable endpoint is concrete/controllers/backend/file/star(), and successful exploitation results in a low-integrity modification of file bookmark state within the CMS. No public exploit code has been identified at time of analysis, and the Concrete CMS security team assigned this a CVSS v4.0 score of 2.3, reflecting its narrow, low-impact scope.
CSRF vulnerability in Concrete CMS 9.x exposes the backend file rescan controller at concrete/controllers/backend/file to unauthorized state-changing requests. Affecting versions 9.0 through 9.4.x (patched in 9.5.1), an unauthenticated remote attacker can trigger unintended file rescan operations against an authenticated victim's session by luring them to a malicious page. Rated CVSS v4.0 at 2.3 - limited to low integrity impact with no confidentiality or availability consequence - and no public exploit identified at time of analysis.
Cross-Site Request Forgery (CSRF) in Concrete CMS 9.x through 9.5.0 allows a remote unauthenticated attacker to trigger unauthorized file rescanning via the rescanMultiple() function in the backend file controller, provided a logged-in user can be lured to interact with an attacker-crafted page. The integrity impact is limited to the vulnerable component, with no confidentiality or availability consequence. No public exploit or active exploitation has been identified; the Concrete CMS security team assigned a CVSS v4.0 score of 2.3, reflecting the low real-world impact and the prerequisite of user interaction and specific attack conditions.
Cross-Site Request Forgery in Concrete CMS versions 9.0 through 9.5.0 exposes the approveVersion() backend file management endpoint to forged requests, allowing an unauthenticated remote attacker to manipulate file version approval state on behalf of an authenticated victim. The vendor's own CVSS v4.0 scoring assigns a 2.3 (Very Low) severity, reflecting the constrained impact - limited to low integrity change within the vulnerable component with no confidentiality or availability consequence. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, positioning this as a low-priority but legitimately tracked integrity weakness in CMS file workflows.