Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
73 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The /api/action/media/external-link endpoint allows authenticated admin users to make server-side HTTP HEAD requests to arbitrary internal IP addresses. While the parallel uploadFromURL flow validates target IPs against private/reserved ranges via FileUrlValidator, the linkURL flow only performs a URL format check (regex for http:// or https:// prefix), allowing SSRF to internal network services and cloud metadata endpoints. Details The vulnerability is an inconsistency between two URL-handling flows in MediaUploadService. Vulnerable path (external-link): MediaUploadV2Controller::externalLink() at src/Core/Content/Media/Api/MediaUploadV2Controller.php:66 takes a user-supplied url parameter and passes it to MediaUploadService::linkURL() at src/Core/Content/Media/Upload/MediaUploadService.php:134. linkURL() calls getContentSizeFromValidExternalUrl($url) at line 159, which only validates via validateExternalUrl(): Then makes a server-side HEAD request with no IP filtering:…
Recommended action: Upgrade to 6.7.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SVG files are in the allowedextensions whitelist and can be uploaded by any admin user via the media manager. There is zero SVG content sanitization anywhere in the upload pipeline. A malicious SVG with JavaScript (onload, <script, <foreignObject) executes in the context of the Shopware domain when accessed. The Problem In src/Core/Framework/Resources/config/packages/shopware.yaml, line 194: SVG is whitelisted. The upload path (MediaUploadController → FileSaver → TypeDetector) recognizes SVG as ImageType with VECTORGRAPHIC flag, but no code strips JavaScript, event handlers, or external entity references from the SVG XML. A search of the entire codebase for SVG sanitization returns — no DOMPurify, no svg-sanitize, no striptags on SVG content, nothing. Impact Stored XSS affecting all users who view the uploaded SVG. In an e-commerce context, this can lead to admin account takeover, customer data theft, or malicious plugin installation. Suggested Fix Either: 1. Remove SVG from…
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Shopware Store API endpoint /store-api/handle-payment contains an object-level authorization flaw that allows a low-privileged external user with a normal customer or guest context to trigger the payment flow for another user’s order by supplying a foreign orderId. The affected functionality is the Store API payment initiation and retry flow. The root cause is that the endpoint forwards the user-controlled orderId into the payment processing logic without verifying that the caller owns the referenced order or has passed the required guest-order authentication. As a result, payment attempts for foreign orders are accepted by the server, which can compromise the integrity of order and payment workflows. Description Shopware exposes /store-api/handle-payment to initiate or retry the payment flow for an already created order. Under the normal order access model, customers should only be able to view or act on their own orders, and guest users should only be able to access…
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is a vertical authorization bypass in the Admin API affecting order state transition features (/api/action/order/{orderId}/state/{transition} and similar transaction/delivery transition routes). The root cause is that the transition action routes do not declare required server-side ACL privileges, allowing low-privileged users to pass the authorization boundary. As a result, authenticated users without order:update can still change order states, causing real security impact such as operational integrity loss, automation workflow misuse, and fulfillment/settlement/support process disruption. Description Shopware’s permission model requires server-side enforcement independent of UI guards. However, the dedicated order-state transition action endpoints are missing ACL metadata, so accounts without regular order update privileges can still submit transition requests that are processed by the backend. In real reproduction, the same low-privileged account receives 403 on the…
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This report describes an open redirect in Shopware's public SSO entry point at GET /api/oauth/sso/auth. When the endpoint is reached without the expected SSO session state, the application falls back to the request's Referer header and uses that value as the redirect destination. In the validated behavior, the server does not restrict that fallback target to same-origin URLs, does not require a relative path, and does not reject dangerous schemes such as javascript:. As a result, an unauthenticated request can turn this endpoint into a reusable redirect primitive whose destination is fully controlled by attacker-supplied request metadata. The security problem is not limited to a harmless navigation mismatch. The endpoint sits under /api/oauth/, which gives the redirect a trustworthy application-controlled origin and makes it suitable for phishing chains, branded redirect abuse, and cases where client software automatically follows redirects issued by a trusted host. The…
Recommended action: Upgrade to 6.7.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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 passwordverify. PHP method passwordverify 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 passwordverify 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, passwordverify a dummy hash. Impact 1. More targeted dictionary/bruteforce attacks. 2. Spear phishing /…
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
UserController::upsertUser() writes user data in SYSTEMSCOPE 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: SYSTEMSCOPE bypasses AclWriteValidator entirely (line 52 of AclWriteValidator::preValidate() returns early for SYSTEMSCOPE). The admin boolean field is accepted without restriction. Compare with IntegrationController::upsertIntegration() in the same codebase, which correctly checks: 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: Best regards, Keyvan Hardani
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A low-privilege admin user with userrecovery:read ACL can take over any admin account. The attacker triggers password recovery for the victim (unauthenticated endpoint), reads the recovery hash from the Admin API search endpoint, then uses the hash to reset the victim's password (another unauthenticated endpoint). The recovery hash — intended to be secret and delivered only via email — is fully readable through the standard entity search API. OWASP: A01:2021 — Broken Access Control Root Cause The userrecovery entity exposes its hash field through the Admin API search endpoint (POST /api/search/user-recovery). The hash field lacks ApiAware(false) or ReadProtection, so any user with userrecovery:read ACL can read it. The password recovery flow assumes the hash is delivered exclusively via email. The Admin API provides an alternative channel to obtain it, breaking this assumption. Three endpoints combine to form the attack: 1. POST /api/action/user/user-recovery — triggers…
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 1. AclWriteValidator — checks entity-level ACL (integration:create is sufficient) 2. EntityProtectionValidator — checks WriteProtection on entity definitions, but IntegrationDefinition has none The admin field in IntegrationDefinition is a plain…
Recommended action: Upgrade to 6.7.10.1 or 6.6.10.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
We identified and fixed a vulnerability in the Shopware app registration flow that could, under specific conditions, allow attackers to take over the communication channel between a shop and an app. By abusing app re‑registration, an attacker could redirect app traffic to an attacker‑controlled domain and potentially obtain API credentials intended for the legitimate shop. We have no evidence that this vulnerability has been exploited. --- Affected Scope - All apps (public and private) that use a registrationUrl in their app manifest and rely on the legacy HMAC‑based registration flow. - Both on‑premise and cloud installations are affected until updated to a fixed Shopware version or protected by the latest Shopware Security Plugin. - Shopware services and first‑party apps using the affected SDKs were reviewed and patched. The vulnerability does not affect core storefront or administration authentication; it is limited to the app system’s registration and re‑registration…
Recommended action: Upgrade to 6.7.8.1 or 6.6.10.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Store API login endpoint (POST /store-api/account/login) returns different error codes depending on whether the submitted email address belongs to a registered customer (CHECKOUTCUSTOMERAUTHBADCREDENTIALS) or is unknown (CHECKOUTCUSTOMERNOTFOUND). The "not found" response also echoes the probed email address. This allows an unauthenticated attacker to enumerate valid customer accounts. The storefront login controller correctly unifies both error paths, but the Store API does not — indicating an inconsistent defense. CWE - CWE-204: Observable Response Discrepancy Description Distinct error codes leak account existence The login flow in AccountService::getCustomerByLogin() calls getCustomerByEmail() first, which throws CustomerNotFoundException if the email is not found. If the email IS found but the password is wrong, a separate BadCredentialsException is thrown: The two exception types produce clearly distinguishable API responses: Email not registered: Email registered,…
Recommended action: Upgrade to 6.7.8.1 or 6.6.10.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An insufficient check on the filter types for unauthenticated customers allows access to orders of other customers. This is part of the deepLinkCode support on the store-api.order endpoint. Details Data Exposure Depending on the order payload configuration, attackers may retrieve: - Customer names - Billing address - Shipping address - Email addresses - Ordered products - Order values - Order numbers - Order dates - Payment method information - Shipping method information - More customs, depending on the given associations in the request Security Impact This vulnerability allows: - Unauthorized access to foreign customer order data - Mass enumeration of recent orders - Potential scraping of customer personal information Limitation No limitation, but only orders from the past 30 days are checked for changeable means of payment (unrelated). Impact The code is present since ~2021. Likely every version since then is impacted for every store.
Recommended action: Upgrade to 6.7.8.1 or 6.6.10.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Refunds in general can be enabled through the administration setting core.cart.enableOrderRefunds (in the cart panel).Which visually shows and hides the button. However, using a custom crafted request, a customer can still cancel his own orders.As this is not checked inside the route (and also not in the controller): https://github.com/shopware/shopware/blob/trunk/src/Storefront/Controller/AccountOrderController.php#L98 https://github.com/shopware/shopware/blob/trunk/src/Core/Checkout/Order/SalesChannel/CancelOrderRoute.php To mitigate this, a check should be added to the CancelOrderRoute which verifies that the feature is enabled.
Recommended action: Upgrade to 6.7.3.1 or 6.6.10.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Malicious actors can exploit this finding to export sensitive customer information from a Shopware application, including password hashes and password reset tokens. In SaaS deployments, this primarily affects customer accounts. In on-premise deployments, however, it also includes the hashes and recovery tokens of administrator-level accounts, which increases the potential impact. This risk is noteworthy because users may reuse the same or similar passwords across different services. In such cases, exposed hashes could allow attackers to recover credentials that might also be valid outside of Shopware. Description Sensitive information disclosure occurs when an application inadvertently displays sensitive information to its users. Depending on the context, websites can leak all kinds of information including: • Data regarding other users, such as usernames and/or e-mail addresses • Sensitive commercial data such as customer names • Technical details about the website and/or the…
Recommended action: Upgrade to 6.7.3.1 or 6.6.10.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability allows malicious actors to force the application server to send HTTP requests to both external and internal servers. In certain cases, this may lead to access to internal resources such as databases, file systems, or other services that are not supposed to be directly accessible from the internet. The overall impact of this vulnerability is considered limited, as the functionality is highly restricted and only processes IMG tags. Description Server-Side Request Forgery (SSRF) is a vulnerability that enables a malicious actor to manipulate an application server into performing HTTP requests to arbitrary domains. SSRF is commonly exploited to make the server initiate requests to its internal systems or other services within the same network, which are typically not exposed to external users. In some cases, SSRF can also be used to target external systems. A successful SSRF attack can result in unauthorized actions or access to data within the organization, the…
Recommended action: Upgrade to 6.7.3.1 or 6.6.10.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Malicious actors can exploit this vulnerability to write files within arbitrary directories on the filesystem of the Shopware web container. This could allow them to gain persistent shell access by uploading a PHP-shell file to an accessible folder. It is important to note that this vulnerability is only present on on-premises installation of Shopware and not present on the SaaS installation due to additional security checks being implemented on the uploaded plugin files. Description A path traversal vulnerability allows malicious actors to access files and folders that are outside the folder structure accessible to the affected function. This vulnerability occurs when an application uses unfiltered user input to point to the path of a specific file and retrieve it. This can result in gaining read/write access to sensitive information, application code, back-end systems and other (critical) files on the operating system. In certain cases, it is even possible to store arbitrary…
Recommended action: Upgrade to 6.7.3.1 or 6.6.10.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Shopware core and platform versions before 6.6.10.7 and 6.7.3.1, media visibility restrictions applied by MediaVisibilityRestrictionSubscriber are not enforced for aggregation API requests. Authorization filters are only injected during standard entity reads; aggregation queries can be constructed to bypass these checks and enumerate private media records such as invoices or other restricted documents. A low‑privilege backend user (e.g., product editor) can chain normal business flows (creating or viewing orders) with aggregation queries to disclose sensitive customer data including addresses and payment-related information contained within associated private media. The issue is resolved in 6.6.10.7 and 6.7.3.1.
Recommended action: Upgrade to 6.7.3.1 or 6.6.10.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Currently the default settings for double-opt-in allow for mass unsolicited newsletter sign-ups without confirmation. Default settings are: Newsletter: Double Opt-in - active Newsletter: Double opt-in for registered customers - disabled Log-in & sign-up: Double opt-in on sign-up - disabled With these settings, anyone can register an account on the shop using any e-mail-address and then check the check-box in the account page to sign up for the newsletter. The recipient will receive two mails confirming registering and signing up for the newsletter, no confirmation link needed to be clicked for either. In the backend the recipient is set to “instantly active”. Patches Update to Shopware 6.6.10.3 or 6.5.8.17 Workarounds For older versions of 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Recommended action: Upgrade to 6.7.0.0-rc2 (pre-release), 6.6.10.3 or 6.5.8.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It's possible to guess the deepLinkCode of an Document to open documents of other customers Patches Update to Shopware 6.6.10.3 or 6.5.8.17 Workarounds For older versions of 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Recommended action: Upgrade to 6.7.0.0-rc2 (pre-release), 6.6.10.3 or 6.5.8.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Shopware application API contains a search functionality which enables users to search through information stored within their Shopware instance. The searches performed by this function can be aggregated using the parameters in the “aggregations” object. The ‘name’ field in this “aggregations” in nested object is vulnerable SQL-injection and can be exploited using SQL parameters. Patches Update to Shopware 6.6.10.3 Workarounds For older versions of 6.5 or 6.4 corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. Credit Redteam Pentesting
Recommended action: Upgrade to 6.7.0.0-rc2 (pre-release), 6.6.10.3 or 6.5.8.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It's possible to pass long passwords that leads to Denial Of Service via forms in Storefront forms or Store-API. Patches Update to Shopware 6.6.10.3 or 6.5.8.17 Workarounds For older versions of 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Recommended action: Upgrade to 6.7.0.0-rc2 (pre-release), 6.6.10.3 or 6.5.8.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Through the store-api it is possible as a attacker to check if a specific e-mail address has an account in the shop. Using the store-api endpoint /store-api/account/recovery-password you get the response which indicates clearly that there is no account for this customer. In contrast you get a success response if the account was found. Patches Update to Shopware 6.6.10.3 Workarounds For older versions of 6.5 or 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Recommended action: Upgrade to 6.7.0.0-rc2 (pre-release), 6.6.10.3 or 6.5.8.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Shopware application API contains a search functionality which enables users to search through information stored within their Shopware instance. The searches performed by this function can be aggregated using the parameters in the “aggregations” object. The ‘name’ field in this “aggregations” object is vulnerable SQL-injection and can be exploited using SQL parameters. Patches Update to Shopware 6.6.5.1 or 6.5.8.13 Workarounds For older versions of 6.1, 6.2, 6.3 and 6.4 corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. Credit LogicalTrust
Recommended action: Upgrade to 6.6.5.1 or 6.5.8.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The context variable is injected into almost any Twig Template and allows to access to current language, currency information. The context object allows also to switch for a short time the scope of the Context as a helper with a callable function. Example call from PHP: This function can be called also from Twig and as the second parameter allows any callable, it's possible to call from Twig any statically callable PHP function/method. It's not possible as customer to provide any Twig code, the attacker would require access to Administration to exploit it using Mail templates or using App Scripts. Patches Update to Shopware 6.6.5.1 or 6.5.8.13 Workarounds For older versions of 6.1, 6.2, 6.3 and 6.4 corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Recommended action: Upgrade to 6.6.5.1 or 6.5.8.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Shopware has a new Twig Tag swsilentfeaturecall which silences deprecation messages while triggered in this tag. It accepts as parameter a string the feature flag name to silence, but this parameter is not escaped properly and allows execution of code. Patches Update to Shopware 6.6.5.1 or 6.5.8.13 Workarounds For older versions of 6.2, 6.3, and 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Recommended action: Upgrade to 6.6.5.1 or 6.5.8.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.