Pimcore before 6.2.2 lacks an Access Denied outcome for a certain scenario of an incorrect recipient ID of a notification.

Pimcore before 6.2.2 lacks brute force protection for the 2FA token.

Pimcore is an open source data and experience management platform. Prior to version 10.5.9, the user controlled twig templates rendering in Pimcore/Mail & ClassDefinition\Layout\Text is vulnerable to server-side template injection, which could lead to remote code execution. Version 10.5.9 contains a patch for this issue. As a workaround, one may apply the patch manually.

pimcore is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Path Traversal: '\..\filename' in GitHub repository pimcore/pimcore prior to 10.5.22.

Privilege Defined With Unsafe Actions in GitHub repository pimcore/pimcore prior to 10.5.23.

Impact SQL injections in AssetController due to unsanitized concatenating strings in where clause. The attacker can dump database, alter data or perform dos on the backend database.

Patches Update to version 10.5.21 or apply this patch manually https://github.com/pimcore/pimcore/commit/21e35af721c375ef4676ed50835e30d828e76520.patch

Workarounds Apply patch https://github.com/pimcore/pimcore/commit/21e35af721c375ef4676ed50835e30d828e76520.patch manually.

References https://huntr.dev/bounties/bbf59fa7-cf5b-4945-81b0-328adc710462/

This affects the package pimcore/pimcore before 10.0.7. This issue exists due to the absence of check on the storeId parameter in the method collectionsActionGet and groupsActionGet method within the ClassificationstoreController class.

In Pimcore before 5.7.1, an attacker with limited privileges can trigger execution of a .phar file via a phar:// URL in a filename parameter, because PHAR uploads are not blocked and are reachable within the phar://../../../../../../../../var/www/html/web/var/assets/ directory, a different vulnerability than CVE-2019-10867 and CVE-2019-16318.

In Pimcore before 5.7.1, an attacker with limited privileges can bypass file-extension restrictions via a 256-character filename, as demonstrated by the failure of automatic renaming of .php to .php.txt for long filenames, a different vulnerability than CVE-2019-10867 and CVE-2019-16317.

An issue was discovered in Pimcore before 5.7.1. An attacker with classes permission can send a POST request to /admin/class/bulk-commit, which will make it possible to exploit the unserialize function when passing untrusted values in the data parameter to bundles/AdminBundle/Controller/Admin/DataObject/ClassController.php.

Pimcore before 5.3.0 allows remote attackers to conduct cross-site request forgery (CSRF) attacks by leveraging validation of the X-pimcore-csrf-token anti-CSRF token only in the "Settings > Users / Roles" function.

SQL injection in ElementController.php in GitHub repository pimcore/pimcore prior to 10.3.5. This vulnerability is capable of steal the data

Impact A path traversal vulnerability exists in the AssetController::importServerFilesAction, which allows an attacker to overwrite or modify sensitive files by manipulating the pimcorelog parameter.This can lead to potential denial of service---key file overwrite.

The impact of this vulnerability allows attackers to:

Overwrite or modify sensitive files, potentially leading to unauthorized access, privilege escalation, or disclosure of confidential information.

Tamper with system settings by modifying key files, such as the hosts file in Windows or configuration files for other services.

Cause a denial of service (DoS) if critical system files are overwritten or deleted.

The consequences of exploiting this vulnerability can be detrimental to the confidentiality, integrity, and availability of the affected system. It's crucial to address this vulnerability to protect sensitive data and ensure the proper functioning of the system.

Patches Update to version 10.6.7 or apply this patch manually https://github.com/pimcore/pimcore/commit/58012d0e3b8b926fb54eccbd64ec5c993b30c22c.patch

Workarounds Apply patch https://github.com/pimcore/pimcore/commit/58012d0e3b8b926fb54eccbd64ec5c993b30c22c.patch manually.

An improper SameSite Attribute vulnerability in pimCore v10.5.15 allows attackers to execute arbitrary code.

SQL Injection in GitHub repository pimcore/pimcore prior to 10.5.19.

Impact SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access.

In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior. In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack. It was observed that the reported API endpoint accessible by an authenticated administrator user and is vulnerable to SQL injection via the "filter" POST parameter. The parameter accepts JSON formatted data. The value of JSON key "property" inside "filter" is not sanitized properly and is used in a SQL statement in an unsafe manner, resulting in SQL injection.

Patches Update to version 10.5.21 or apply this patch manually https://github.com/pimcore/pimcore/commit/7e32cc28145274ddfc30fb791012d26c1278bd38.patch

Workarounds Apply patch https://github.com/pimcore/pimcore/commit/7e32cc28145274ddfc30fb791012d26c1278bd38.patch manually.

References https://github.com/pimcore/pimcore/pull/14952

Impact SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. This might include data belonging to other users, or any other data that the application itself is able to access.

In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior. In some situations, an attacker can escalate an SQL injection attack to compromise the underlying server or other back-end infrastructure, or perform a denial-of-service attack. It was observed that the reported API endpoint accessible by an authenticated administrator user and is vulnerable to SQL injection via the "filter" GET parameter. The parameter accepts JSON formatted data. The value of JSON key "property" inside "filter" is not sanitized properly and is used in a SQL statement in an unsafe manner, resulting in SQL injection

Patches Update to version 10.5.21 or apply this patch manually https://github.com/pimcore/pimcore/commit/c6c80905e58c7724c776f980570a56df7016c6d1.patch

Workarounds Apply patch https://github.com/pimcore/pimcore/commit/c6c80905e58c7724c776f980570a56df7016c6d1.patch manually.

References #14968

Summary

User input passed directly into an SQL statement allows (non-admin) backend users to execute arbitrary SQL statements.

Details

The /admin/object/grid-proxy endpoint calls getFilterCondition() on fields of classes to be filtered for at https://github.com/pimcore/admin-ui-classic-bundle/blob/bba7c7419cb1f06d5fd98781eab4d6995e4e5dca/src/Helper/GridHelperService.php#L311, passing input from the request, and later executes the returned SQL. One implementation of getFilterCondition() is in Multiselect, which does not normalize/escape/validate the passed value: https://github.com/pimcore/pimcore/blob/42b6cfa77c4540205bdd10689893ccb73e4bac8f/models/DataObject/ClassDefinition/Data/Multiselect.php#L285-L312

PoC

Set up an example project as described on https://pimcore.com/docs/platform/Pimcore/GettingStarted/Installation/DockerBasedInstallation (demo package with example content) Enter the backend and add a new user without admin privileges, but the "Objects" permission enabled. Log out and back in with the new user. Grab the X-pimcore-csrf-token header from any request the backend does, as well as the PHPSESSID cookie. Run the following script, substituting the values accordingly: bash #!/bin/bash BASEURL=http://localhost:8084 # REPLACE THIS! CSRFTOKEN="bd89fd7ceb3b541dd63c200fd4fc8c8ea3cc1a05" # REPLACE THIS! COOKIE="PHPSESSID=a0f408f9af7657430a4e6a1608c80277" # REPLACE THIS! SQL="UPDATE users SET admin=1" FILTERJSON="[{\"property\":\"tags\",\"operator\":\"=\",\"type\":\"list\",\"value\":[\"')); ${SQL}; --\"]}]" curl "${BASEURL}/admin/object/grid-proxy?classId=EV&folderId=1119" \ -X POST \ -H "X-pimcore-csrf-token: ${CSRFTOKEN}" \ -H "Cookie: ${COOKIE}" \ --data "filter=$FILTERJSON" Refresh the backend, the user is admin now.

Notes The above process also works with the initial admin user, but for demonstration purposes it is more interesting to use an unpriveleged one. Other important variables to adjust in the above script for other deployments are the classId=EV&folderId=1119 parameters, which must reference an existing class and folder, as well as "property":"tags", which points to a Multiselect field in this class.

Impact

Any backend user with very basic permissions can execute arbitrary SQL statements and thus alter any data or escalate their privileges to at least admin level.

Patches Apply patch manually.

Workarounds Update to version 11.1.1 or apply this patch manually.

Pimcore is an open source data and experience management platform. When a PortalUserObject is connected to a PimcoreUser and "Use Pimcore Backend Password" is set to true, the change password function in Portal Profile sets the new password. Prior to Pimcore portal engine versions 4.1.7 and 3.1.16, the password is then set without hashing so it can be read by everyone. Everyone who combines PortalUser to PimcoreUsers and change passwords via profile settings could be affected. Versions 4.1.7 and 3.1.16 of the Pimcore portal engine fix the issue.

Cross-site Scripting (XSS) - Stored in GitHub repository pimcore/pimcore prior to 10.4.0.

Pimcore is an Open Source Data & Experience Management Platform: PIM, MDM, CDP, DAM, DXP/CMS & Digital Commerce. The upload functionality for updating user profile does not properly validate the file content-type, allowing any authenticated user to bypass this security check by adding a valid signature (p.e. GIF89) and sending any invalid content-type. This could allow an authenticated attacker to upload HTML files with JS content that will be executed in the context of the domain. This issue has been patched in version 10.5.16.

Cross-site Scripting (XSS) - Stored in GitHub repository pimcore/pimcore prior to 10.2.10.

Pimcore is an Open Source Data & Experience Management Platform. Pimcore offers developers listing classes to make querying data easier. This listing classes also allow to order or group the results based on one or more columns which should be quoted by default. The actual issue is that quoting is not done properly in both cases, so there's the theoretical possibility to inject custom SQL if the developer is using this methods with input data and not doing proper input validation in advance and so relies on the auto-quoting being done by the listing classes. This issue has been resolved in version 10.4.4. Users are advised to upgrade or to apple the patch manually. There are no known workarounds for this issue.

Pimcore is an open source data and experience management platform. Prior to version 10.5.19, since a user with 'report' permission can already write arbitrary SQL queries and given the fact that this endpoint is using the GET method (no CSRF protection), an attacker can inject an arbitrary query by manipulating a user to click on a link. Users should upgrade to version 10.5.19 to receive a patch or, as a workaround, may apply the patch manually.

Pimcore is an open source data and experience management platform. Prior to version 10.5.19, quoting is not done properly in UUID DAO model. There is the theoretical possibility to inject custom SQL if the developer is using this methods with input data and not doing proper input validation in advance and so relies on the auto-quoting being done by the DAO class. Users should update to version 10.5.19 to receive a patch or, as a workaround, apply the patch manually.

Unrestricted Upload of File with Dangerous Type in Packagist pimcore/pimcore prior to 10.2.7.

Pimcore is an open source digital experience platform. In Pimcore before version 6.8.5 it is possible to modify & create website settings without having the appropriate permissions.

Cross-site Scripting (XSS) - Stored in GitHub repository pimcore/pimcore prior to 10.5.18.

Details 1. All Imagick supported Fileformats are served without filtering

The Thumbnail endpoint does not check against any filters what file formats should be served. We can transcode the image in all formats imagemagick supports. With that we can create Files that are much larger in filesize than the original. For example we can create a .txt file for all thumbnails, and we get the text representation of the image.

We can demonstrate that with the pimcore demo:

This Thumbnail is found on the Frontend: https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89.avif (12kb Filesize)

We can generate a text representation by simply changing the file extension: https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89.txt (4.59mb Filesize)

Other (large) fileformats we tested: ftxt, dip, bmp, bmp3, bmp2, farbfeld, cmyk, cmyka, ycbcr, ycbcra and many more (just check imagemagick supported formats)

With that we can fill the available space of a server really easy.

With formats like yaml or json we can also expose exif data of the original image file - could be a concern with gps data in user uploaded images.

TLDR

- we can generate all imagemagick supported formats with all thumbnail configs - all configs were the format is set to "auto (Web-optimized)" are vulnerable - private (exif) data can be exposed. - We can flood the the server with a bunch of files that are a multiple magnitudes of the original thumbnail size (see txt example), for all thumbnail configs, with every image that we find (scriptable)

Proposed Solution

Implement a list of allowed formats that the developer can modify if needed, if a file is requested in another format than listed, pimcore should return either "/bundles/pimcoreadmin/img/filetype-not-supported.svg" or a 404.

yaml pimcore: thumbnails: allowedformats: ['jpg', 'png', 'avif', 'webp', 'gif']

For non-maintained Pimcore versions (<11), the webserver config could be used to only serve files that should be allowed.

2. Non Web optimized file formats (ORIGINAL, JPG, PNG) creates duplicated files on Server

With Thumbnail config that are configured to serve non web optimized file formats (such as ORIGINAL, jpg, png, print, etc) we can create files with arbitrary file formats that are saved to disk.

For example, the thumbnail configuration "printbackgroundimage" (in the pimcore demo) can be used to create files such as:

https://demo.pimcore.fun/Car%20Images/jaguar/3/image-thumb3printbackgroundimage/auto-3095119.aaa https://demo.pimcore.fun/Car%20Images/jaguar/3/image-thumb3printbackgroundimage/auto-3095119.aab https://demo.pimcore.fun/Car%20Images/jaguar/3/image-thumb3printbackgroundimage/auto-3095119.aac

Each request creates a new copy of the original (jpg) thumbnail file. The server can be flooded with a bunch of files.

Code for this mechanism is here: https://github.com/pimcore/pimcore/blob/11.x/models/Asset/Service.php#L621-L623

Proposed Solution

Use same filtered list from "All Imagick supported Fileformats are served without filtering" and do not copy the arbitrary file to disk, just serve the original image file under the "new" name.

3. Scaling Factor is not limited and can be modified via url

We can scale each thumbnail to an arbitrary factor with @<float>x added to the request url.

For example:

https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89@1x.avif https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89@1.01x.avif https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89@1.08x.avif https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89@2x.avif

If the thumbnail config allows "forced" resizing, we could also do something like:

https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89@192x.avif

Each request will create a new file, flooding the server with more files. If the factor is big enough, we can also max out the CPU with a single request for quite some time (only really a problem with "forced")

In combination with the first vulnerability we can also generate (large) text files for scaled images:

https://demo.pimcore.fun/Sample%20Content/Background%20Images/317/image-thumb317standardTeaser/11.8c64bd89@4x.txt (6.6 mb filesize)

Proposed solution

Limit scale factors with an allowlist:

yaml pimcore: thumbnails: allowedscalefactors: [1.25, 1.5, 2, 4]

Impact All Pimcore Instances are affected, as far as we can see, also all versions