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

CVE-2026-48008 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-48008?

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

Shopware CVE-2026-48008

MEDIUM

Missing Authorization (CWE-862)

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

GHSA-gv8p-48fr-4fxg

PHP Authentication Bypass

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:47 vuln.today

Analysis Generated

Jun 04, 2026 - 19:47 vuln.today

DescriptionGitHub Advisory

Summary

A non-admin API user with integration:create ACL privilege can escalate to full administrator by creating an integration with admin: true through the Sync API (POST /api/_action/sync). The regular integration endpoint (POST /api/integration) correctly blocks this, but the Sync API bypasses the controller-level check by writing directly through the DAL EntityWriter. The integration entity definition lacks WriteProtection, and the admin field has no field-level restriction flag.

OWASP: A01:2021 - Broken Access Control

Root Cause

IntegrationController::upsertIntegration() checks $source->isAdmin() before allowing the admin field to be set. However, SyncController::sync() routes writes through SyncService → EntityWriter, which only applies:

AclWriteValidator - checks entity-level ACL (integration:create is sufficient)
EntityProtectionValidator - checks WriteProtection on entity definitions, but IntegrationDefinition has none

The admin field in IntegrationDefinition is a plain BoolField with no WriteProtection or special flag. The Sync API writes it without restriction.

Vulnerable code path:

src/Core/Framework/Api/Controller/SyncController.php → SyncService → EntityWriter::upsert()
Missing protection: src/Core/Framework/Integration/IntegrationDefinition.php - admin field has no WriteProtection(Context::SYSTEM_SCOPE)

Working protection (bypassed):

src/Core/Framework/Integration/IntegrationController.php:46-56 - isAdmin() check only applies to the dedicated controller endpoint

Impact

Complete admin API access - the escalated integration has full read/write on every entity: users, customers, orders, system configuration, integrations, plugins
PII exfiltration - read all customer records (names, emails, addresses, order history)
Persistent backdoor - the admin integration survives password changes and user deactivation

Remediation

Add WriteProtection(Context::SYSTEM_SCOPE) to IntegrationDefinition, matching how UserDefinition and AclRoleDefinition are already protected:

php

// src/Core/Framework/Integration/IntegrationDefinition.php
(new BoolField('admin', 'admin'))
    ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)),

AnalysisAI

Privilege escalation in Shopware's Sync API allows an authenticated API user holding the integration:create ACL to self-elevate to full administrator by posting admin: true via POST /api/_action/sync. The dedicated IntegrationController correctly enforces an admin-only guard on this field, but the Sync API routes writes through SyncService → EntityWriter::upsert(), which only validates entity-level ACL and WriteProtection flags - neither of which are present on the admin BoolField in IntegrationDefinition. Affected are shopware/platform and shopware/core prior to 6.6.10.18 and prior to 6.7.10.1; no public exploit or CISA KEV listing is confirmed at time of analysis, though the attack is mechanically trivial for any credential holder with the prerequisite ACL.

Technical ContextAI

Shopware is a PHP-based e-commerce platform built around a Data Abstraction Layer (DAL) where entity definitions declare fields along with optional flag annotations such as WriteProtection(Context::SYSTEM_SCOPE). The root cause maps to CWE-862 (Missing Authorization): IntegrationDefinition defines the admin field as a plain BoolField with no WriteProtection flag, unlike the analogous UserDefinition and AclRoleDefinition which already carry this protection on their sensitive fields. The Sync API (SyncController::sync()) bypasses the controller-level $source->isAdmin() guard in IntegrationController::upsertIntegration() by delegating writes directly to the EntityWriter, which applies only two validators: AclWriteValidator (satisfied by integration:create ACL) and EntityProtectionValidator (which enforces WriteProtection flags - absent here). The CVSS vector AV:N/AC:L/PR:H/UI:N reflects network-reachable exploitation with no interaction required once credentials are in hand. Affected packages are composer/shopware/platform and composer/shopware/core.

RemediationAI

Update to the vendor-released patched versions: shopware/platform or shopware/core version 6.6.10.18 for 6.6.x installations, or 6.7.10.1 for 6.7.x installations, via composer update shopware/platform or composer update shopware/core. Release artifacts and changelogs 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 immediate patching is blocked, the primary compensating control is to audit all API integrations and revoke integration:create ACL from any non-admin or third-party integrations that do not strictly require it - this eliminates the prerequisite for exploitation but may disrupt legitimate provisioning workflows. A secondary network-layer control is to restrict access to POST /api/_action/sync at the WAF or reverse proxy for untrusted clients, with the trade-off that this endpoint is also used for legitimate bulk-write operations and blanket blocking may break integrations. The code-level fix confirmed by the advisory is to add ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)) to the admin BoolField in src/Core/Framework/Integration/IntegrationDefinition.php, consistent with the pattern already applied in UserDefinition and AclRoleDefinition.