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

EUVD-2026-45240 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 · Vendor: https://github.com/shopware/shopware

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Obtain non-admin API credentials with user:create ACL
Delivery

Craft Admin API upsert request with admin: true payload
Exploit

Submit POST to UserController::upsertUser() endpoint
Execution

SYSTEM_SCOPE bypasses AclWriteValidator
Persist

Admin account created or promoted
Impact

Attacker authenticates as full admin

Vulnerability Assessment

Weakness	CWE CWE-269 OWASP Top 10:2025 A06:2025 - Insecure Design ASVS 5.0 V8 - Authorization Least privilege enforcement MITRE ATT&CK 1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	The attacker must hold valid Shopware Admin API credentials for an account that has been granted the `user:create` ACL permission (to create a new admin account) or `user:update` ACL permission (to promote an existing account). These are standard delegated permissions assigned to API integrations or restricted staff accounts in multi-operator Shopware deployments. The Shopware instance must be reachable over the network (CVSS AV:N confirmed). Full admin access is not required - the vulnerability is specifically triggered by the absence of an `isAdmin()` check in `UserController` that exists in `IntegrationController`. Exploitation is limited to environments where non-admin API access has been delegated; single-operator Shopware instances where only full admins hold API keys are not practically affected. No special platform configuration, plugin, or non-default feature flag is required beyond the presence of a non-admin API user with the noted ACL.
Impact	The CVSS 3.1 base score of 6.5 with vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N reflects network reachability, low complexity, and high confidentiality and integrity impact - but the PR:H (High Privileges Required) designation warrants scrutiny. The CVE description states that `user:create` is described explicitly as a 'low-privilege' ACL permission; any account delegated user-management duties carries this permission in normal administrative workflows. PR:H in CVSS typically implies admin-equivalent access, which understates how broadly this permission may be distributed in practice - CVSS likely scores the API authentication requirement as high-privilege. Real-world risk is therefore higher than the 6.5 score implies for organizations that delegate user management to non-admin staff or automated integrations. No EPSS score was provided in the source data. No CISA KEV listing exists, and no public exploit code has been identified, which moderates urgency. However, the exploit requires no special tooling - a single crafted API POST with `admin: true` in the body is sufficient - making this trivially reproducible by any actor who understands the Shopware API. The vendor's own advisory confirms both the vulnerability and the fix, providing high confidence in the technical claims.
Exploit ScenarioDerived	An attacker who has obtained API credentials for a Shopware integration or non-admin user account holding the `user:create` ACL sends a POST request to the Admin API user upsert endpoint, including `"admin": true` alongside normal user fields. Because `UserController::upsertUser()` passes raw request data directly into `SYSTEM_SCOPE` without filtering, the repository write succeeds and the attacker's target account (or a newly created one) immediately acquires full admin privileges. No public exploit code has been identified, but the attack requires only knowledge of the Admin API structure, which is publicly documented.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).

Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 04, 2026

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.

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.

Affected VersionsENISA

shopware < 6.6.10.18

shopware 6.7.0.0, < 6.7.10.1

platform < 6.6.10.18

platform 6.7.0.0, < 6.7.10.1

Affected Packages

composer shopware/core fix: 6.6.10.18, 6.7.10.1

composer shopware/platform fix: 6.6.10.18, 6.7.10.1

euvd platform fix: 6.6.10.18, 6.7.10.1

euvd shopware fix: 6.6.10.18, 6.7.10.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 4 packages in composer, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when PHP gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

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

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

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

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

DescriptionCVE.org

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

Threat Intelligence Overview

EPSS Score

0.0%

Top 90% exploitable

Threat Intel

1 source

Data Quality

5 sources

Confidence: Medium

EUVD

NVD

CVE.org

EPSS GHSA

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity MEDIUM

CISA KEV No

Public POC No

EPSS 0.0%

Patch available Yes

Active threat No

Deciding rule

MEDIUM severity (CVSS 4.0-6.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Human Impact· derived

Medium

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +32

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Privilege Escalation HIGH

Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.