What is the CVSS score of CVE-2026-48010?

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

Is there a patch available for CVE-2026-48010?

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

Shopware CVE-2026-48010

MEDIUM

Improper Privilege Management (CWE-269)

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

GHSA-v39m-97p8-gqg7

PHP Privilege Escalation

6.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.5 MEDIUM

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

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 04, 2026 - 19:46 vuln.today

Analysis Generated

Jun 04, 2026 - 19:46 vuln.today

DescriptionGitHub Advisory

UserController::upsertUser() writes user data in SYSTEM_SCOPE and does not filter the admin field. A non-admin API user with user:create or user:update ACL permission can set admin: true on new or existing users, escalating to full admin access.

The Problem

In src/Core/Framework/Api/Controller/UserController.php, line 210-234:

php

public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response
{
    $data = $request->request->all(); // raw request data, no field filtering
    // ...
    $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) =>
        $this->userRepository->upsert([$data], $context)
    );
}

SYSTEM_SCOPE bypasses AclWriteValidator entirely (line 52 of AclWriteValidator::preValidate() returns early for SYSTEM_SCOPE). The admin boolean field is accepted without restriction.

Compare with IntegrationController::upsertIntegration() in the same codebase, which correctly checks:

php

if ((!$source instanceof AdminApiSource)
    || (!$source->isAdmin()
    && isset($data['admin']))
) {
    throw new PermissionDeniedException();
}

UserController is missing this exact check.

Impact

Any API user with the low-privilege user:create permission can create accounts with full admin access, or with user:update can promote any existing user to admin. This is a direct privilege escalation.

Suggested Fix

Add the same isAdmin() check from IntegrationController:

php

$source = $context->getSource();
if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) {
    throw new PermissionDeniedException();
}

Best regards, Keyvan Hardani

AnalysisAI

Privilege escalation in Shopware's Admin API allows authenticated users holding only the low-privilege user:create or user:update ACL to promote any account - including newly created ones - to full administrator access. The flaw exists in UserController::upsertUser() across composer packages shopware/platform and shopware/core, affecting all releases below 6.6.10.18 and the 6.7.x line below 6.7.10.1. Shopware has released patched versions; no public exploit code or CISA KEV listing has been identified at time of analysis, but the attack is straightforward for any user with delegated user-management API access.

Technical ContextAI

Shopware is a PHP-based e-commerce platform. The vulnerable code path is UserController::upsertUser() (src/Core/Framework/Api/Controller/UserController.php, lines 210-234), which accepts raw request data via $request->request->all() without field filtering and then persists it inside Context::SYSTEM_SCOPE. The critical design flaw is that SYSTEM_SCOPE causes AclWriteValidator::preValidate() to return early (line 52), entirely bypassing ACL write validation. This means the admin boolean field - which grants unrestricted platform access - passes through to the user repository unvetted. CWE-269 (Improper Privilege Management) precisely describes the root cause: the application fails to enforce privilege boundaries when a lower-privileged actor supplies a privilege-elevating field. The sibling controller IntegrationController::upsertIntegration() demonstrates the correct pattern by explicitly calling $source->isAdmin() before permitting the admin field, confirming this is an implementation omission rather than an architectural limitation. Affected packages per Composer PURL are pkg:composer/shopware/platform and pkg:composer/shopware/core.

RemediationAI

The primary fix is to 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) via Composer: composer update shopware/platform or composer update shopware/core. Release notes and upgrade guidance are available at https://github.com/shopware/shopware/releases/tag/v6.6.10.18 and https://github.com/shopware/shopware/releases/tag/v6.7.10.1. If an immediate upgrade is not possible, the most effective compensating control is to audit and revoke user:create and user:update ACL permissions from all non-admin API integrations and user accounts, restricting these permissions to fully trusted admin accounts only - this eliminates the attack surface while accepting the operational trade-off of reduced delegation. Additionally, operators should audit existing user accounts for unexpected admin: true flags to detect any prior exploitation. There is no documented network-layer workaround since the API endpoint is legitimately used; access controls at the API permission level are the only viable interim mitigation.