Concrete CMS package, file, and block boundary checks¶

Source: hourly offensive-security scan, 2026-06-23, updated 2026-06-24 with adjacent Concrete CMS authorization, file, package-control, survey, OAuth, conversation, summary-template, log, RSS-fetch, file-manager, and Express association advisories. Primary entries: GitHub Advisory Database GHSA-r42c-3rr2-jrfp, GHSA-pv2v-6w2v-97x6, GHSA-4g7q-44qp-cc5c, GHSA-645j-cm4x-3xvw, GHSA-p8p9-5953-h9jw, GHSA-chfm-cm6h-q5x7, GHSA-fqg3-8w8r-8g94, GHSA-66rg-92q4-6m8q, GHSA-4c8m-6fwx-m7xq, GHSA-jr5g-qv3g-rxxx, GHSA-5rj5-gfmr-hrc3, GHSA-prxr-vjgc-2cq9, GHSA-g7xp-jf3x-wcx4, GHSA-46xh-7854-f568, GHSA-v7c7-658v-hh7v, GHSA-56c9-xq5g-xrf9, GHSA-8c7c-h7px-267g, GHSA-f54h-78c9-c24h, GHSA-f73j-pm2c-rxvr, GHSA-wmw3-3fv3-h54w, GHSA-vpgr-cwfx-pwfw, GHSA-2xp7-rpvc-pjwc, GHSA-qv3x-mffx-9gw8, GHSA-xpgc-7vc2-8725, GHSA-58c8-vvqw-cm7m, GHSA-pcrh-gj77-j4mw, and GHSA-gjwq-9v8p-47w7.

These Concrete CMS advisories are durable for operators because they expose reusable CMS trust boundaries: CSRF-able package, log, file-manager, and Express association actions, REST/JSON type coercion into serialized block state, unauthenticated file/page/conversation metadata disclosure, template path traversal from page-type composer controls, public-widget ID pivots into restricted surveys/calendars, OAuth account-status drift, profile mass assignment, trusted-render HTML sinks, and editor-supplied RSS URLs crossing into server-side fetches. Validate only against owned labs or explicitly scoped CMS instances.

What changed¶

Operator triage¶

1. Confirm Concrete CMS ownership first. Collect version, role model, marketplace connection status, installed packages, and whether REST API and dashboard routes are reachable in scope.
2. Prioritize package and block editors. Users who can install packages, edit page types, add blocks, or call REST block APIs sit near code/file boundaries even when they are not full server admins.
3. Treat file IDs as recon pivots. If file usage dialogs lack auth, enumerate only lab-created file IDs or target-approved synthetic files; the value is discovering route/permission drift, not scraping private page maps.
4. Look for parser differentials. Compare dashboard form submissions with REST JSON bodies for the same CMS object, especially where booleans, serialized arrays, template names, or block options are stored.
5. Keep CSRF proofs inert. A package-download CSRF proof should use a harmless marketplace/package ID in a disposable lab and stop at demonstrating the missing token/state change.

June 24 Concrete CMS authorization and package-control update¶

Late GitHub Advisory Database updates added a second Concrete CMS 9.5.0-and-below cluster. Promote it with the same operator frame: public or low-privilege CMS routes crossing into private file/form/calendar objects, group membership changes, or package/core update execution. Keep proofs to lab users, canary files, synthetic form entries, harmless package controllers, and route/token decision tables.

Added validation boundaries¶

• File-ID and form-entry IDOR: Seed one public and one restricted canary file or Express entry. From a low-privilege account, reference only the known restricted ID through conversation attachments, download routes, and Express detail routes. Evidence is the controlled marker crossing the expected permission boundary, plus a patched or access-denied negative control.
• Token polarity and missing validation: For file deletion, package install/update, remote upgrade prep, and core update routes, capture three requests: valid token, invalid token, and no token. A vulnerable route either ignores token state or accepts the invalid/missing token. Use only disposable attachments and inert package/update markers.
• Package execution-adjacent routes: If package install/update behavior must be proven, use a local lab package whose install/upgrade controller writes a benign marker file under a temp lab path. Do not use production package handles, marketplace accounts, shells, or destructive updates.
• Group assignment drift: Test only a lab group and disposable accounts. Capture the route, authenticated role, before/after membership table, and denied negative control; never remove real administrators or grant persistent production privileges.
• Calendar event route checks: Use synthetic public/private calendars and event titles that are safe to screenshot. Stop at marker disclosure; do not enumerate real event IDs or attendee data.

Late June 24 survey, conversation, OAuth, log, and RSS update¶

A later GitHub updated-feed wave added more Concrete CMS 9.5.0-and-below issues. They stay on this page because they are the same CMS boundary family: public widgets and unauthenticated helpers accepting object IDs, low-privilege profile or OAuth paths crossing account-state controls, trusted dashboard/report render sinks, state-changing log deletion without token enforcement, and editor-controlled feed URLs causing server-side fetches.

Added validation boundaries for the late wave¶

• Survey and conversation object-ID pivots: Seed public and restricted survey options plus public, restricted, and moderation-queue conversation messages. Exercise only known canary IDs through optionID, get_rating, message_page, and message_detail; evidence is expected-deny versus actual marker disclosure or state change.
• OAuth and profile account-state drift: Use an inactive disposable user and a normal active user. Compare authorization-code token issuance, password-change requirements, and whether profile POSTs accept auth-hardening flags that are absent from the visible form.
• Summary and file-usage recon: Create restricted pages with distinctive titles/descriptions and synthetic file references. Request only their known summary/template and usage routes while unauthenticated; stop at metadata fields, not content scraping.
• Log CSRF and trusted render sinks: For log deletes, capture valid-token, invalid-token, and no-token requests against lab log rows. For legacy pagination or external-link names, use inert DOM markers and record the exact trusted origin where they render.
• RSS fetch SSRF: Configure the RSS Displayer with an owned callback URL, then with an owned redirector pointing to a synthetic lab-only internal canary. Evidence is callback timing and request metadata; never target cloud metadata, production admin panels, or unrelated internal services.

Later June 24 file-manager and Express association CSRF update¶

The GitHub updated feed added another adjacent Concrete CMS 9.x cluster after the first June 24 update. These are lower-severity by themselves, but useful for operators because they widen the same token-enforcement harness from package/log routes into file-manager metadata actions and Express association ordering.

Added validation boundaries for file-manager CSRF¶

• File-manager token matrix: For approveVersion, rescan, rescanMultiple, star, addFavoriteFolder, and removeFavoriteFolder, capture baseline same-origin requests, then replay no-token and invalid-token requests from an inert cross-origin harness. Evidence is the route/method, token state, response, and a lab marker such as version approval state, rescan timestamp, star flag, or favorite-folder membership.
• Express association ordering: Seed two disposable Express objects and a visible association order. Attempt only known canary IDs through the reorder dialog with valid, invalid, and missing tokens. Evidence is before/after ordering plus a patched negative control where available.
• No destructive file proofs: Do not rescan production libraries, approve real user uploads, reorder live business records, or alter persistent editor favorites outside a disposable lab account. These routes prove token-boundary drift; they do not require file disclosure or executable payloads.

Replayable validation boundaries¶

Package-download CSRF¶

• Preconditions: Concrete CMS lab, marketplace-connected site, administrator or package installer test account, and a harmless package or remote ID approved for the lab.
• Capture a normal dashboard package-download request and verify whether it is a GET state change.
• Replay from a same-browser cross-origin HTML page or image/link trigger and confirm whether no CSRF token is required.
• Positive evidence: request/response pair, package directory marker, and a negative control on a patched build or token-enforced route.
• Do not force production admins to install packages or write files under live package directories.

ExpressEntryList REST-to-serialized-block control¶

• Preconditions: lab site, rogue-admin/block-editor account, disposable ExpressEntryList block, and an inert serialized canary object or marker string.
• Submit equivalent dashboard-form and REST JSON updates and compare how _fromCIF, boolean fields, and filterFields are parsed and stored.
• Positive evidence: database/config diff showing the canary serialized state accepted through REST where the form path rejects it.
• Stop before loading real gadget chains or executing production PHP code; if execution validation is explicitly approved, use only a benign marker in a clone.

File usage disclosure¶

• Preconditions: lab file manager with public and restricted synthetic pages referencing known canary files.
• Request /ccm/system/dialogs/file/usage/{fID} unauthenticated for only those canary file IDs.
• Positive evidence: response showing page IDs, handles, or URLs for the synthetic restricted page while the page itself remains permission-protected.
• Do not enumerate real customer file IDs, restricted URLs, or page maps outside scope.

Composer template traversal¶

• Preconditions: lab account with page-type composer form editing rights, an uploaded benign canary file, and a safe readable marker path.
• Save ptComposerFormLayoutSetControlCustomTemplate values with baseline template names, then controlled traversal to a canary template or marker file.
• Positive evidence: server attempts to include or render only the canary target, plus patched rejection if available.
• Do not read system files, database credentials, keys, or uploaded user content as proof.

Reporting notes¶

• Lead with the exact boundary: GET package install without CSRF, REST JSON type coercion into serialized block config, unauthenticated file-usage route, composer template path traversal, file/form/calendar/survey/conversation IDOR, token polarity or missing CSRF validation, package/core/log/file-manager/Express association state change without server-side token validation, bulk group assignment without authorization, inactive account to OAuth token, profile mass assignment of auth controls, summary-template hidden-page metadata disclosure, trusted dashboard/page-name render sink, or editor-controlled RSS URL to server-side fetch.
• Include Concrete CMS version, role, route, request method, object ID, expected permission/token decision, actual decision, and disposable canary evidence.
• Keep all proof artifacts synthetic: lab package IDs, marker blocks, canary files, and controlled page paths. Avoid real marketplace installs, production secrets, private pages, and executable payloads.

September 21 follow-up: DNS-pin reuse SSRF, anonymous user-enumeration oracle, CSRF-scope and destination-side authz drift (8 GHSAs, Concrete CMS ≤ 9.5.2 → 9.5.3)¶

A fresh Concrete CMS cluster published 2026-09-21T18:32Z adds three reusable axes to this page.

• GHSA-fmfq-8qcq-wrx4 / CVE-2026-18424 — remote file import SSRF via cross-port reuse of a validated DNS pin. When several remote URLs share a host, only the first ValidatedRemoteUrl is retained and reused for every later URL with that host; the unpinned download leg then follows a DNS-rebinding name that resolved public at validation time and private at fetch time, saving loopback/metadata responses into the file manager. Durable rules: a validation-time DNS pin is only sound if the resolved IP is pinned for the actual connection, per-URL and per-port — "validated once per host" is a TOCTOU; and file-import features that save the fetched bytes are non-blind SSRF read channels (the saved file is the response oracle). Two-URL same-host battery (public first, rebinding second) on any importer with owned DNS records.
• GHSA-7hmf-f7jv-m4xw / CVE-2026-18110 — unauthenticated full backend-account enumeration via /ccm/system/user/autocomplete. The selector's "access token" is bound to display options, not the caller, and is handed to anonymous visitors; empty query = match-all filter, paginated → every user's ID, username, and email including super-admin. Durable rules: UI-component CSRF-style tokens minted anonymously are not authorization; test every selector/picker/autocomplete endpoint with the token from an anonymous page render and an empty query; and user-enumeration oracles are the precondition artifact for password-spray/reset-flow campaigns — report as an identity-surface finding with role breakdown, not just "info disclosure".
• Authorization-scope drift octet: Express Form block control-management actions rely on a CSRF token bound to user+action but not to the specific block/page/form → token from your own form authorizes control edits on foreign forms, incl. HTML-rendered control = stored XSS (GHSA-g5mv-jcqh-ch66 / CVE-2026-18426); sitemap reorder checks only the global access_sitemap task permission, no per-page edit check, no CSRF token (GHSA-rvm5-mg98-27w7 / CVE-2026-18425); multilingual page assignment checks source-side permission only — no destination-side authorization check, bind/delete foreign-locale translation pairs (GHSA-hch9-r5fg-6p72 / CVE-2026-18422); Express saved-search preset delete/edit gated only on view permission of any entity (GHSA-7vc7-m9pm-w64f / CVE-2026-18423). Sweep rules: for every token, ask what object it is bound to (user+action ≠ user+object); for every relationship write (assign/reparent/share), check authorization on BOTH endpoints; and run the low-role IDOR sweep over admin sub-dialogs, not just list routes.
• Render-sink pair: colliding page paths echoed unmodified by the check endpoint and inserted as raw HTML by the client into the duplicate-path dialog (GHSA-994m-pc89-jhp9 / CVE-2026-81926) — API check-echo → client innerHTML is a two-leg chain where neither leg's author notices the other; and user-supplied custom date format rendered into conversation messages, delivered via CSRF-less auto-submit POST (GHSA-3mw6-rrq3-376v / CVE-2026-81925) — format strings are code to a date library, and "POST-only" endpoints without tokens are still deliverable cross-origin.

Proof boundaries unchanged: disposable CMS installs, two lab roles (low-priv editor vs foreign owner), owned DNS records with short-TTL rebinding to a lab canary port, synthetic accounts/presets/translations, inert structural XSS markers. Never enumerate real accounts on a client target without written scope, and never import production-reachable metadata endpoints.