Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file rescanMultiple().
Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file rescanMultiple().
Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/dialog/page/bulk/design.
Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/dialog/event/duplicate.
Concrete CMS 9 through 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/dialog/page/bulk/delete.
Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/dialog/express/association/reorder.
Concrete CMS 9 through 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/dialog/logs/delete.
Concrete CMS 9 through 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/dialog/logs/bulk/delete.
Concrete CMS 9 through 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file addFavoriteFolder($id).
Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file removeFavoriteFolder($id).
Concrete CMS 9 through 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file star().
Concrete CMS 9 before 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file rescan().
Concrete CMS 9 through 9.5.0 is vulnerable to Cross Site Request Forgery (CSRF) at concrete/controllers/backend/file approveVersion().
For Concrete CMS 9.5.0 and below, OAuth 2.0 Authorization-Code Handler Bypasses Account Status. A user with uIsActive=0 (suspended, banned, terminated employee) can still authenticate via OAuth and receive valid API tokens.
In Concrete CMS 9.5.0 and below, the RSS Displayer block accepts a feed URL from any page editor and fetches it server-side without validation enabling redirect-to-internal bypasses.
Concrete CMS 9.5.0 and below is vulnerable to IDOR in AddMessage/UpdateMessage via attachments[] parameter which can lead to file permission bypass. The `AddMessage` and `UpdateMessage` conversation controllers accept user-supplied file attachment IDs and load files directly via `$em->find(File::class, $attachmentID)` without checking per-file permissions (`canViewFile()`). A user who can post in any conversation can reference any file in the CMS file manager by its sequential ID, effectively by
Concrete CMS 9.5.0 and below is vulnerable to unauthorized file deletion due to an Inverted CSRF token check in the DeleteFile controller. The code throws an error when the token IS valid and proceeds with file deletion when the token is invalid or missing. This effectively disables CSRF protection for the file deletion endpoint, allowing cross-site request forgery attacks against users who have permission to edit conversation messages.
Concrete CMS 9.5.0 and below is vulnerable to Stored XSS via external-link page cvName because updateCollectionAliasExternal bypasses being sanitized.
When the `connected-components:*` define specifies an invalid index and out of bound operation will result in an access violation.
A memory leak vulnerability exists in multiple coders that write raw pixel data where an object is not freed. ``` Direct leak of 160 byte(s) in 1 object(s) allocated from: ```
### Summary If a `server.ca` file is present in `LXD_DIR` at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option `core.trust_ca_certificates` defaults to `false`. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's re