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 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 "
Oracle Coherence versions 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0 and 15.1.1.0.0 contain a flaw in the Core component that lets an attacker who already holds a high-privileged account and can log on to the host where Coherence runs make unauthorized updates, inserts or deletions against Coherence-accessible data. The CVSS 3.1 base score is only 1.9 (AV:L/AC:H/PR:H/UI:N, integrity-only), reflecting that exploitation demands local logon, elevated privileges and a difficult-to-achieve condition; confidentiality and availability are not impacted. No public exploit code or CISA KEV entry was present in the supplied intelligence, so this is assessed as a low-priority, defense-in-depth issue rather than an urgent patch item. The vendor-reported nature of the record and the presence of an 'Authentication Bypass' tag that conflicts with the PR:H, integrity-only vector are notable data-quality caveats.
ManabiPocket for Parents 1.2.3 and earlier — an Android companion app for a Japanese parental school-communication service published by NTT Docomo Business, Inc. — exposes at least one application component that is reachable by other apps on the same device. A malicious app the user has already installed can send a crafted Intent to that component and read sensitive data held by the parental app, making this a local information-disclosure issue rather than a remote compromise. Severity is low (CVSS 4.0 base 1.8) because exploitation requires local code execution, user interaction and additional attack requirements; no public exploit code and no CISA KEV entry were identified at time of analysis, and EPSS data was not supplied.
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.