Concrete CMS (previously concrete5) before 9.2 is vulnerable to possible Auth bypass in the jobs section.

A Server-Side Request Forgery vulnerability was found in concrete5 < 8.5.5 that allowed a decimal notation encoded IP address to bypass the limitations in place for localhost allowing interaction with local services. Impact can vary depending on services exposed.CVSSv2.0 AV:A/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N

An issue was discovered in Concrete CMS through 8.5.5. Path Traversal leading to RCE via external form by adding a regular expression.

Concrete CMS Versions 9.0.0 through 9.0.2 and 8.5.7 and below can download zip files over HTTP and execute code from those zip files which could lead to an RCE. Fixed by enforcing ‘concretesecure’ instead of ‘concrete’. Concrete now only makes requests over https even a request comes in via http. Concrete CMS security team ranked this 8 with CVSS v3.1 vector: AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H Credit goes to Anna for reporting HackerOne 1482520.

Concrete CMS before 8.5.13 and 9.x before 9.2.2 allows unauthorized access because directories can be created with insecure permissions. File creation functions (such as the Mkdir() function) gives universal access (0777) to created folders by default. Excessive permissions can be granted when creating a directory with permissions greater than 0755 or when the permissions argument is not specified.

Concrete CMS 9.5.0 and below fails to sanitize path traversal sequences in the ptComposerFormLayoutSetControlCustomTemplate field when saving page type composer form layouts. An authenticated rogue administrator with composer form editing rights can exploit this to include arbitrary readable files on the server. Combined with the file uploader's extension-only validation (which permits PHP code in files saved with image extensions like .png), this can result in authenticated remote code execution. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 9.4 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H   Thanks Yonatan Drori (Tenzai) for reporting.

An issue was discovered in Concrete CMS through 8.5.5. Arbitrary File deletion can occur via PHAR deserialization in isdir (PHP Object Injection associated with the wakeup magic method).

Concrete 8.5.7 and below as well as Concrete 9.0 through 9.0.2 allow traversal in /index.php/ccm/system/file/upload which could result in an Arbitrary File Delete exploit. This was remediated by sanitizing /index.php/ccm/system/file/upload to ensure Concrete doesn’t allow traversal and by changing isFullChunkFilePresent to have an early false return when input doesn't match expectations.Concrete CMS Security team ranked this 5.8 with CVSS v3.1 vector AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H. Credit to Siebene for reporting.

Concrete CMS below version 9.4.8 is vulnerable to Remote Code Execution by stored PHP object injection into the Express Entry List block via the columns parameter. An authenticated administrator can store attacker-controlled serialized data in block configuration fields that are later passed to unserialize() without class restrictions or integrity checks.

The Concrete CMS security team thanks YJK ( @YJK0805 https://hackerone.com/yjk0805 ) of ZUSO ART https://zuso.ai/  for reporting.

Concrete CMS 9.5.0 and below is vulnerable to Remote Code Execution due to insecure deserialization occurring in the ExpressEntryList block controller. An rogue administrator with privileges to add blocks to an area can bypass the intended protection mechanism (fromCIF === true), which normally restricts malicious inputs over form POST requests, by leveraging the REST API functionality. Because the REST API parses requests using jsondecode(), the string "true" is evaluated as a strict PHP Boolean(true).  This bypass allows the attacker to inject a malicious serialized payload  into the block's filterFields database column. The payload will subsequently be executed when the block's data is viewed or edited by an administrator leading to complete server takeover (RCE).The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 8.9 with a vector of CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.  Thanks Nguyễn Văn Thiện https://github.com/Thien225409  for reporting

SQL injection vulnerability in Concrete5 5.7.3.1.

Privilege escalation from Editor to Admin using Groups in Concrete CMS versions 8.5.6 and below. If a group is granted "view" permissions on the bulkupdate page, then users in that group can escalate to being an administrator with a specially crafted curl. Fixed by adding a check for group permissions before allowing a group to be moved. Concrete CMS Security team CVSS scoring: 7.1 AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:HCredit for discovery: "Adrian Tiron from FORTBRIDGE ( https://www.fortbridge.co.uk/ )"This fix is also in Concrete version 9.0.0

A cross-site request forgery vulnerability exists in Concrete CMS <v9 that could allow an attacker to make requests on behalf of other users.

An issue was discovered in Concrete CMS through 8.5.5. Authenticated path traversal leads to to remote code execution via uploaded PHP code, related to the bFilename parameter.

An issue was discovered in Concrete CMS through 8.5.5. The Calendar is vulnerable to CSRF. ccmtoken is not verified on the ccm/calendar/dialogs/event/add/save endpoint.

Concrete CMS is vulnerable to CSRF due to the lack of "State" parameter for external Concrete authentication service for users of Concrete who use the "out of the box" core OAuth.

Concrete CMS 9.5.0 and below does not validate a CSRF token before processing requests to /dashboard/extend/update/doupdate/<pkgHandle>. The doupdate() method in concrete/controllers/singlepage/dashboard/extend/update.php checks only canInstallPackages() before executing upgradeCoreData() and upgrade() on the named package's controller. Because the endpoint is a state-changing GET route with no token enforcement, an attacker can force an authenticated administrator to trigger a package upgrade via a single cross-site navigation.In order to be vulnerable, the victim must be passing canInstallPackages() and and a target package must already be already installed. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks  https://github.com/maru1009  for reporting.

Concrete CMS 9.5.0 and below emits a CSRF token in the localavailableupdate.php view ($token->output('doupdate')) but the corresponding doupdate() method in concrete/controllers/singlepage/dashboard/system/update/update.php never calls $this->token->validate('doupdate'). The form is rendered as a POST form, meaning the token reaches the browser, but because the controller discards it without verification, an attacker can craft a cross-site POST that triggers a core CMS update to an attacker-specified version string.  In order to be vulnerable, theictim must be passing canUpgrade()anda valid update version must be present under DIRCOREUPDATES. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.

Concrete CMS 9.5.0 and below does not validate a CSRF token before processing requests to /dashboard/extend/install/download/<remoteId>. The download() method in concrete/controllers/singlepage/dashboard/extend/install.php checks only the canInstallPackages() permission before fetching a remote marketplace package and writing it to the server's DIRPACKAGES directory. Because the endpoint is a state-changing GET route with no token enforcement, an attacker who can cause an authenticated administrator to visit a crafted page can force an arbitrary marketplace package to be downloaded. In order to be vulnerable, the victim must be passing canInstallPackages() and the site must be connected to the Concrete marketplace. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks  https://github.com/maru1009  for reporting.

Concrete CMS 9.5.0 and below contains a CSRF vulnerability in the installpackage() method of concrete/controllers/singlepage/dashboard/extend/install.php.  An attacker who can cause an authenticated administrator to visit a crafted page,  and who has placed or caused a package to be present under DIRPACKAGES/<handle>/, can force the installation of that package without any CSRF protection. Package installation executes the package controller's install() method as the web server user, enabling remote code execution.  In order to be vulnerable, the victim must be passing canInstallPackages. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks  https://github.com/maru1009  for reporting.

Concrete CMS 9.5.0 and below does not validate a CSRF token before processing requests to /dashboard/extend/update/prepareremoteupgrade/<remoteMPID>. An attacker who controls the remote package returned for a known marketplace item ID can overwrite the package PHP on disk and force its upgrade() method to execute in a single browser navigation. This results in remote code execution as the web server user.   In order to be vulnerable, the victim must be passing canInstallPackages, victim site must be connected to the Concrete marketplace; and the attacker controls the package returned for a marketplace item ID already installed on the victim site. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks https://github.com/maru1009 for reporting.

Concrete CMS 9.5.0 and below is vulnerable to missing authorization in the bulkuserassignment.php which can lead to privilege escalation to Administrative Group. Any authenticated user with access to the bulk user assignment dashboard page can add any user email to any group and can remove legitimate admins. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.5 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Vincent55 for reporting.

Concrete CMS (formerly concrete5) versions 8.5.6 and below and version 9.0.0 allow local IP importing causing the system to be vulnerable toa. SSRF attacks on the private LAN servers by reading files from the local LAN. An attacker can pivot in the private LAN and exploit local network appsandb. SSRF Mitigation Bypass through DNS RebindingConcrete CMS security team gave this a CVSS score of 3.5 AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:NConcrete CMS is maintaining Concrete version 8.5.x until 1 May 2022 for security fixes.This CVE is shared with HackerOne Reports https://hackerone.com/reports/1364797 and https://hackerone.com/reports/1360016Reporters: Adrian Tiron from FORTBRIDGE (https://www.fortbridge.co.uk/ ) and Bipul Jaiswal

Unauthorized individuals could view password protected files using viewinline in Concrete CMS (previously concrete 5) prior to version 8.5.7. Concrete CMS now checks to see if a file has a password in viewinline and, if it does, the file is not rendered.For version 8.5.6, the following mitigations were put in place a. restricting file types for viewinline to images only b. putting a warning in the file manager to advise users.Credit for discovery: "Solar Security Research Team"Concrete CMS security team CVSS scoring is 5.3: AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:NThis fix is also in Concrete version 9.0.0

In Concrete CMS (formerly concrete 5) below 8.5.7, IDOR Allows Unauthenticated User to Access Restricted Files If Allowed to Add Message to a Conversation.To remediate this, a check was added to verify a user has permissions to view files before attaching the files to a message in "add / edit message”.Concrete CMS security team gave this a CVSS v3.1 score of 4.3 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:NCredit for discovery Adrian H

An issue was discovered in Concrete CMS through 8.5.5. Path Traversal can lead to Arbitrary File Reading and SSRF.

An issue was discovered in Concrete CMS through 8.5.5. There is an SVG sanitizer bypass.

Concrete CMS 9.5.0 and below has Stored XSS on the height parameter. The controller does not validate or sanitize $height. Any user with editor privileges can inject malicious JavaScript that executes in the context of any visitor's browser, potentially leading to session hijacking, credential theft, or other malicious actions. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Alfin Joseph for reporting.

Concrete CMS 9.5.0 and below is vulnerable to Stored XSS via OAuth integration name. The OAuth authorize template renders the integration name (admin-controlled) through Concrete's t() translation helper as a sprintf-style format. The <strong>...</strong> wrap is built by PHP string interpolation before t() runs, so the integration name lands in the translated output as raw HTML. A rogue admin could potentially snoop on login submissions.The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N  Thanks Yonatan Drori (Tenzai) for reporting.

Concrete5 through 8.5.5 deserializes Untrusted Data. The vulnerable code is located within the controllers/singlepage/dashboard/system/environment/logging.php Logging::updatelogging() method. User input passed through the logFile request parameter is not properly sanitized before being used in a call to the fileexists() PHP function. This can be exploited by malicious users to inject arbitrary PHP objects into the application scope (PHP Object Injection via phar:// stream wrapper), allowing them to carry out a variety of attacks, such as executing arbitrary PHP code.