Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
LOW severity

Shopware: Timing-attack on admin panel allowing enumeration of administrator usernamesGHSA-7w52-7jvm-m9vw

LOW

GHSA-7w52-7jvm-m9vw is a low-severity (CVSS 3.7) CWE-208 vulnerability in shopware/platform. A fix is available for shopware/platform — see the affected versions and patch details below.

Also known asCVE-2026-48011
Published
Updated
Affected
4 pkgs
Patched
4 / 4
Exploits
None indexed
Exploitation data as of Oct 16, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-7w52-7jvm-m9vw.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs28th percentile — riskier than 28% of all scored CVEsHighest risk
0.00%0.29%0.57%0.85%0.2%0.2%0.2%0.4%0.4%Jul 26Sep 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-7w52-7jvm-m9vw by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 390,400 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

4 pkgs affected
🐘shopware/platform🐘shopware/platform🐘shopware/core🐘shopware/core

Real-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

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 Packages

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistshopware/platform≥ 6.7.0.0&&< 6.7.10.16.7.10.1composer require shopware/platform:^6.7.10.1
🐘Packagistshopware/platformall versions6.6.10.18composer require shopware/platform:^6.6.10.18
🐘Packagistshopware/core≥ 6.7.0.0&&< 6.7.10.16.7.10.1composer require shopware/core:^6.7.10.1
🐘Packagistshopware/coreall versions6.6.10.18composer require shopware/core:^6.6.10.18

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopware/platform, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update shopware/platform to 6.7.10.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7w52-7jvm-m9vw is resolved across your whole dependency graph.

  3. 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.

Frequently Asked Questions

### 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`](https://github.com/shopware/shopware/blob/trunk/src/Core/Framework/Api/OAuth/UserRepository.php): ``` public function getUserEntityByUserCredentials( string $username, #[\SensitiveParameter] string $password, string $grantType, ClientEntityInterface $clientEntity ): ?UserEntityInterface { if ($this->lo
O3 Security · Impact-Aware SCA

Is GHSA-7w52-7jvm-m9vw in your dependencies?

Find it across Packagist, including transitive dependencies.

Shopware: Timing-attack on admin panel allowing…