Skip to content

GHSA-7w52-7jvm-m9vw CVE-2026-48011

Shopware: Timing-attack on admin panel allowing enumeration of administrator usernames

Low Packagist
Severity
3.7 / 10
Low · CVSS 3.1
Exploit chance (EPSS)
0.22%
Chance of exploitation in the next 30 days. Higher than 12.93% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-208 Observable Timing Discrepancy
Fix
Available
2 packages have a fixed version

Description

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

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

Authors

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

Affected versions

Packagist

PackageVulnerableFixed in
shopware/core
>= 6.7.0.0, < 6.7.10.1
6.7.10.1
shopware/core
< 6.6.10.18
6.6.10.18
shopware/platform
>= 6.7.0.0, < 6.7.10.1
6.7.10.1
shopware/platform
< 6.6.10.18
6.6.10.18

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

shopware/core Packagist → 6.7.10.1

composer
composer require shopware/core:^6.7.10.1

shopware/platform Packagist → 6.7.10.1

composer
composer require shopware/platform:^6.7.10.1

Severity breakdown

CVSS 3.1 3.7

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

Weakness

CWE-208: Observable Timing Discrepancy

Two separate operations in a product require different amounts of time to complete, in a way that is observable to an actor and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-gq96-5pfx-f4vc
Shopware: SSRF in Media External-Link Endpoint Bypasses IP Validation
Medium Also affects shopware/core
GHSA-xvhc-gm7j-mhmc
Shopware: Stored XSS via SVG file upload — no SVG sanitization
Medium Also affects shopware/core
GHSA-9v5m-39wh-5chq
Shopware: Unauthorized Payment Trigger for Foreign Orders via /store-api/handle-payment
Medium Also affects shopware/core
GHSA-f8q6-3g5w-jjr6
Shopware: Admin API ACL Bypass in Order State Transition Endpoints
Medium Also affects shopware/core
GHSA-4x3x-869w-xx3m
Shopware SSO referer trust leading to an arbitrary redirect target
Medium Also affects shopware/core
GHSA-v39m-97p8-gqg7
Shopware: Privilege escalation: non-admin user with user:create ACL can create admin accounts
Medium Also affects shopware/core
GHSA-8v9p-g828-v98f
Shopware: Admin Account Takeover via User Recovery Hash Exposure
Medium Also affects shopware/core
GHSA-gv8p-48fr-4fxg
Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass
Medium Also affects shopware/core
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor