Where
-Infinity
0
Severity
9.3
EPSS
0.04%
CSRF
AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:N

Overview

A potential security vulnerability discovered in pimcore/admin-ui-classic-bundle version up to v1.3.3 . The vulnerability involves a Host Header Injection in the invitationLinkAction function of the UserController, specifically in the way $loginUrl trusts user input.

Details

The host header from incoming HTTP requests is used unsafely when generating URLs. An attacker can manipulate the HTTP host header in requests to the /admin/user/invitationlink endpoint, resulting in the generation of URLs with the attacker's domain.

In fact, if a host header is injected in the POST request, the $loginURL parameter is constructed with this unvalidated host header. It is then used to send an invitation email to the provided user.

Here is an excerpt from the affected section of UserController.php file: // /src/Controller/Admin/UserController.php public function invitationLinkAction(Request $request, TranslatorInterface $translator): JsonResponse { // ..snip.. $token = Tool\Authentication::generateTokenByUser($user); $loginUrl = $this->generateCustomUrl([ 'token' => $token, 'reset' => true, ]);

try { $mail = Tool::getMail([$user->getEmail()], 'Pimcore login invitation for ' . Tool::getHostname()); $mail->setIgnoreDebugMode(true); $mail->text("Login to pimcore and change your password using the following link. This temporary login link will expire in 24 hours: \r\n\r\n" . $loginUrl); $mail->send(); // ..snip.. } // ..snip.. private function generateCustomUrl(array $params, string $fallbackUrl = 'pimcoreadminlogincheck', int $referenceType = UrlGeneratorInterface::ABSOLUTEURL): string { try { $adminEntryPointRoute = $this->getParameter('pimcoreadmin.customadminroutename');

//try to generate invitation link for custom admin point $loginUrl = $this->generateUrl($adminEntryPointRoute, $params, $referenceType); } catch (\Exception $e) { //use default login check for invitation link $loginUrl = $this->generateUrl($fallbackUrl, $params, $referenceType); }

return $loginUrl; } The $loginUrl variable is constructed using the generateCustomUrl function. If an attacker injects a malicious host header into a POST request, the resulting $loginUrl will include the malicious domain, and this link is then sent via email to the user.

Proof of Concept

Here is an example of a request that exploits this vulnerability: POST /admin/user/invitationlink HTTP/1.1 Host: attacker-domain.evil Cookie: PHPSESSID=test X-pimcore-extjs-version-major: 7 X-pimcore-extjs-version-minor: 0 X-Requested-With: XMLHttpRequest X-pimcore-csrf-token: 961c37cf60edfdc2eec5a705cb048aaa8c32804d

username=[username of a valid user]

The URL in the email will look like: http://attacker-domain.evil/admin/login/login?token=[TOKEN]

Impact

This vulnerability can be used to perform phishing attacks by making the URLs in the invitation links emails point to an attacker-controlled domain.

Remediation

We recommend validating the host header and ensuring it matches the application's domain. It would also be beneficial to use a default trusted host or hostname if the incoming host header is not recognized or is absent.

Similar vulnerability (CVE-2024-23648) has been fixed in this project (https://github.com/pimcore/admin-ui-classic-bundle/commit/70f2205b5a5ea9584721d4f3e803f4d0dd5e4655)

Credit

Discovered by @v0lck3r (Oussama RAHALI), Feb 2024.

1 / 2
Source: GitHub
First published (updated )
Severity
9.1
EPSS
0.06%
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Impact You can create, delete etc. tags without having the permission to do so. This vulnerability allows an attacker to perform broken access control and add tags to admin panel and add dumy data. One can do this as intruder and add text parameters with random numbers and this will effect integrity and availability.

Patches Available in version 1.3.3.

Workarounds Apply this pull request manually: https://github.com/pimcore/admin-ui-classic-bundle/pull/412

References -

1 / 2
Source: GitHub
First published (updated )
Severity
8.8
EPSS
0.09%
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Summary

The password reset functionality sends to the the user requesting a password change an email containing an URL to reset its password.

The URL sent contains a unique token, valid during 24 hours, allowing the user to reset its password. This token is highly sensitive ; as an attacker able to retrieve it would be able to resets the user's password.

It was identified during the audit that the reset-password URL is crafted using the "Host" HTTP header of the request sent to request a password reset.

This way, an external attacker could send password requests for users, but specify a "Host" header of a website that they control. If the user receiving the mail clicks on the link, the attacker would retrieve the reset token of the victim and perform account takeover.

Details

This attack required the server to serve Pimcore on arbitrary "Host". This configuration would be plausible if the attacker is already behind the reverse proxy. During the assessment of my client, their instance was accepting any Host header, and they did not received security recommendations that they should restrict this while installing Pimcore.

From what I understood of Pimcore, the vulnerability is in the "admin-ui-classic-bundle", in the file src/Controller/Admin/UserController.php.

The following screenshots provide evidences of the vulnerability. The environment of the test is : dockerized Pimcore v11.1.1 on default configuration (https://pimcore.com/docs/platform/Pimcore/GettingStarted/Installation/DockerBasedInstallation/).

PoC !image !image

Remediation Create a variable that sets the server host. Don't enable password reset functionality while this variable is not set ; or make sure that the administrator knows what they are doing.

I believe that just documenting that the server should not serve on any Host would not be enough to enforce a remediation to this vulnerability.

The Snipe-IT project managed this same issue by creating a "APPALLOWINSECUREHOSTS" variable, and retrieving the app absolute URL from a config file : https://github.com/snipe/snipe-it/commit/0c4768fd2a11ac26a61814cef23a71061bfd8bcc

Impact Could lead to a 1-click account takeover

1 / 2
Source: GitHub
First published (updated )
Severity
8.8
EPSS
0.06%
SQL Injection, CSRF
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Summary The application allows to create zip files from available files on the site. The parameter "selectedIds", is susceptible to SQL Injection.

Details downloadAsZipJobsAction escape parameters, but downloadAsZipAddFilesAction not. The following code should be added: foreach ($selectedIds as $selectedId) { if ($selectedId) { $quotedSelectedIds[] = $db->quote($selectedId); } }

PoC

- Set up an example project as described on https://github.com/pimcore/demon (demo package with example content) - Log In. Grab the X-pimcore-csrf-token header from any request to the backend, as well as the PHPSESSID cookie. - Run the following script, substituting the values accordingly: #!/bin/bash BASEURL=http://localhost # REPLACE THIS! CSRFTOKEN="5133f9d5d28de7dbab39e33ac7036271284ee42e" # REPLACE THIS! COOKIE="PHPSESSID=4312797207ba3b342b29218fa42f3aa3" # REPLACE THIS! SQL="(selectfrom(select(sleep(6)))a)"

curl "${BASEURL}/admin/asset/download-as-zip-add-files?dc=1700573579093&id=1&selectedIds=1,${SQL}&offset=10&limit=5&jobId=655cb18a37b01" \ -X GET \ -H "X-pimcore-csrf-token: ${CSRFTOKEN}" \ -H "Cookie: ${COOKIE}" - The response is delayed by 6 seconds.

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.

1 / 2
Source: GitHub
First published (updated )
Severity
6.9
EPSS
0.04%
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Description Summary

Pimcore Admin Classic Bundle allows attackers to enumerate valid accounts because the Forgot password functionality uses different messages when the account is valid vs not.

Details -> error message discloses existing accounts and leads to user enumeration on the target via "Forgot password" function. since no generic error message is being implemented.

PoC !image

Enter first a valid account email address and click on submit !image

A green message validating the account exists is shown and a login link is sent to the email !image

now go back and use a random email from temp-mail to test with a non existant account !image

!image

click on submit and get an error in red that a problem occured !image

Impact user enumeration is a confidentiality threat , that could potentially lead to an attacker to enumerate valid accounts and maybe taking over accounts in case combined with credential stuffing on an organisation .

A remedition would be to change the error message in both cases ( valid and invalid emails ) to what we call a "synchronised error " it would be for example : " if the given email address is linked to an account , then a login link would be sent to that email " or something along those lines

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
XSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Summary

Unauthenticated HTML Injection / XSS Possible. Conditions: 2factor authentication must not set before

Vulnerable Endpoint: /admin/login/2fa-setup

Vulnerable Param: error= How it works, So basically any admin, who has not setup 2 factor authentication before is vulnerable for this attack, without need for any form of privilege, causing the application to execute arbitrary scripts / HTML Contents.

Another potential attack vector, as it's a 2fa page and it has QR Code, attacker can replace this QR Code with something he has, leading to increase threat to the admin.

This attack can be used to execute arbitrary scripts or HTML Injection, causing the target application to execute these resulting in cookie steeling, defacement or Injecting phishing URLs on the target application.

Patches Update to version 1.0.3 or apply this patches manually https://github.com/pimcore/admin-ui-classic-bundle/commit/5fcd19bdc89a3fe4cb8ad8c356590e1e4740c743.patch

Workarounds Apply patches manually: https://github.com/pimcore/admin-ui-classic-bundle/commit/5fcd19bdc89a3fe4cb8ad8c356590e1e4740c743.patch

References https://huntr.dev/bounties/1fa1cc3b-75ff-4d34-99ae-4a705eb623e7/

1 / 2
First published (updated )
Severity
4.3
EPSS
0.00%
CSRF
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Summary The API endpoint for listing Predefined Properties in the Pimcore platform lacks adequate server-side authorization checks. Predefined Properties are configurable metadata definitions (e.g., name, key, type, default value) used across documents, assets, and objects to standardize custom attributes and improve editorial workflows, as documented in Pimcore's official properties guide. Testing confirmed that an authenticated backend user without explicit permissions for property management could successfully call the endpoint and retrieve the complete list of these configurations. This exemplifies Broken Access Control (OWASP Top 10 A01:2021), enabling unauthorized access to administrative features and potentially violating role-based access controls inherent to Pimcore's multi-user environment.

Details The backend user without permission was still able to list "Predefined Properties" item

Step to Reproduce the issue login as Admin (full permission) and clicked "Predefined Properties" <img width="1493" height="862" alt="Screenshot 2025-12-10 at 10 11 31 PM" src="https://github.com/user-attachments/assets/005d2704-347c-4aa1-b415-d52ab3794c99" />

Then, captured and saved the request: - List API <img width="922" height="797" alt="Screenshot 2025-12-10 at 10 39 53 PM" src="https://github.com/user-attachments/assets/2ee3e0e1-06da-442f-b2c7-0dfa8360c04a" />

Next, login a backend user with no permission <img width="1219" height="744" alt="Screenshot 2025-12-10 at 9 06 12 PM" src="https://github.com/user-attachments/assets/1dada4c4-d907-4477-9773-70dea3ef5816" />

The copy the "Cookie" and "X-Pimcore-Csrf-Token" <img width="1902" height="971" alt="Screenshot 2025-12-10 at 9 10 47 PM" src="https://github.com/user-attachments/assets/63221682-fa14-429b-8665-fc9dd8bed890" />

After that, pasted the copied "Cookie" and "X-Pimcore-Csrf-Token" to captured request

-List API !Uploading Screenshot 2025-12-10 at 10.55.23 PM.png…

Impact Exploitation allows low-privileged users to enumerate all Predefined Properties, exposing internal metadata schemas, default values, and configuration details that may reveal business logic, data classification strategies, or sensitive defaults (e.g., proprietary keys or select options). In a PIM system like Pimcore, this could facilitate reconnaissance for further attacks, such as targeted data manipulation or privilege escalation, leading to unauthorized alterations of asset/object properties. For organizations handling regulated content (e.g., e-commerce catalogs under GDPR or PCI DSS), such exposure risks compliance breaches, intellectual property leakage, and operational inconsistencies from unintended property overrides.

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203