What is the CVSS score of EUVD-2026-36120?

EUVD-2026-36120 has a CVSS 3.1 base score of 3.7 (Low). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for EUVD-2026-36120?

Yes, a patch is available for EUVD-2026-36120. Update the affected software to the latest version immediately.

Shopware EUVD-2026-36120

| CVE-2026-48011 LOW

Observable Timing Discrepancy (CWE-208)

2026-06-04 https://github.com/shopware/shopware

GHSA-7w52-7jvm-m9vw

PHP Information Disclosure

3.7

CVSS 3.1 · Vendor: https://github.com/shopware/shopware

Severity by source

Vendor (https://github.com/shopware/shopware) PRIMARY

3.7 LOW

AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Primary rating from Vendor (https://github.com/shopware/shopware) · only source for this CVE.

CVSS VectorVendor: https://github.com/shopware/shopware

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 04, 2026 - 20:01 vuln.today

Analysis Generated

Jun 04, 2026 - 20:01 vuln.today

DescriptionCVE.org

Summary

There is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.

Details

The faulty code exists in src/Core/Framework/Api/OAuth/UserRepository.php:

public function getUserEntityByUserCredentials(
        string $username,
        #[\SensitiveParameter]
        string $password,
        string $grantType,
        ClientEntityInterface $clientEntity
    ): ?UserEntityInterface {
        if ($this->loginConfigService->getConfig()?->useDefault === false) {
            // never allow login via password if the default login is disabled (e.g. using SSO only)
            return null;
        }

        $builder = $this->connection->createQueryBuilder();
        $user = $builder->select('user.id', 'user.password')
            ->from('user')
            ->where('username = :username')
            ->setParameter('username', $username)
            ->fetchAssociative();

        // PATH 1: EARLY RETURN WHEN USERNAME IS NOT FOUND
        if (!$user) {
            return null;
        }

        // PATH 2: VERIFY PASSWORD IF USER IS FOUND
        if (!password_verify($password, (string) $user['password'])) {
            return null;
        }

        return new User(Uuid::fromBytesToHex($user['id']));
    }

Subroutine getUserEntityByUserCredentials() is called when an auth request is send to api/oauth/token. If the given username is not found an early return is done (PATH 1). Only if the user is found we verify the password using password_verify.

PHP method password_verify by default uses hashing algorithm Argon2id which by design is intentionally 'slow' by introducing a timing cost to an attempt to bruteforce hashes more costly.

Since password_verify has a notable executable time, PATH 2 where an user is found and verified will be slower on average then PATH 1 where we do an early return for non-existing users.

Proposed fix

Before doing the early return, password_verify a dummy hash.

Impact

More targeted dictionary/bruteforce attacks.
Spear phishing / eases social engineering.
Credential stuffing from other data leaks.

Authors

Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)

AnalysisAI

Timing-based administrator username enumeration in Shopware's OAuth token endpoint exposes valid admin accounts to unauthenticated remote attackers. The flaw exists in shopware/platform and shopware/core packages across the 6.6.x and 6.7.x branches, where the API endpoint api/oauth/token responds measurably faster for non-existent usernames than for valid ones due to skipping the Argon2id password_verify() call. A publicly available proof-of-concept exploit exists; while not confirmed actively exploited in CISA KEV, the POC lowers the barrier for targeted brute-force, credential stuffing, and spear phishing campaigns against Shopware admin panels. CVSS rates this 3.7 (AC:H), reflecting that reliable exploitation requires statistical timing analysis across many requests.

Technical ContextAI

The root cause is CWE-208 (Observable Timing Discrepancy) in src/Core/Framework/Api/OAuth/UserRepository.php within the getUserEntityByUserCredentials() method. When a login request hits api/oauth/token, PATH 1 (unknown username) returns immediately without calling password_verify(), while PATH 2 (valid username) incurs the measurable cost of PHP's password_verify() using the Argon2id algorithm - which is intentionally slow by design to resist brute-force. The differential in execution time between the two code paths is statistically significant and observable over the network, leaking whether a given username belongs to an administrator account. Affected Composer packages are shopware/platform and shopware/core (CPE: pkg:composer/shopware_platform and pkg:composer/shopware_core), covering all Shopware 6.x deployments running password-based (non-SSO) login. The proposed and implemented fix is to invoke password_verify() against a dummy hash before the early return, ensuring constant-time behavior regardless of username validity.

RemediationAI

Upgrade shopware/platform or shopware/core to version 6.6.10.18 (for 6.6.x deployments) or 6.7.10.1 (for 6.7.x deployments) - both are vendor-released patches confirmed via GitHub release tags. The fix normalizes response timing by calling password_verify() against a dummy hash prior to the early return, eliminating the observable discrepancy. Full release notes and upgrade guidance are available at https://github.com/shopware/shopware/releases/tag/v6.6.10.18. As a compensating control for organizations unable to patch immediately, disabling password-based login in favor of SSO-only mode (setting useDefault to false in the login configuration) fully prevents exploitation of this endpoint, though this has the trade-off of requiring an external identity provider and locking out any admins not enrolled in SSO. Rate-limiting or CAPTCHA enforcement on the api/oauth/token endpoint reduces the ability of attackers to collect sufficient timing samples for statistical analysis, but does not eliminate the underlying timing discrepancy.