{
  "affected": [
    {
      "affectedData": [
        {
          "product": "shopware",
          "vendor": "shopware",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 6.6.10.18"
            },
            {
              "status": "affected",
              "version": "\u003e= 6.7.0.0, \u003c 6.7.10.1"
            }
          ]
        },
        {
          "product": "platform",
          "vendor": "shopware",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 6.6.10.18"
            },
            {
              "status": "affected",
              "version": "\u003e= 6.7.0.0, \u003c 6.7.10.1"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "Shopware is an open commerce platform. Prior to 6.6.10.18 and 6.7.10.1, the Store API endpoint /store-api/handle-payment in src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php accepts a user-controlled orderId and forwards it to src/Core/Checkout/Payment/PaymentProcessor.php without verifying order ownership or guest-order authentication, allowing a normal customer or guest context to trigger the payment flow for another user\u0027s order while /store-api/order enforces the expected ownership model. This issue is fixed in versions 6.6.10.18 and 6.7.10.1."
    }
  ],
  "id": "CVE-2026-48016",
  "lastModified": "2026-07-17T18:30:01.357",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 4.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-07-17T18:17:16.457",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/shopware/shopware/commit/69dd5b6cb01d3c2aea49ac29dd4512a87836ac3f"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/shopware/shopware/commit/df15f2e607dcf9ebc4a26ec622ffcf452dc25090"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.18"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-9v5m-39wh-5chq"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-639"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T19:33:54Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe 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\u2019s 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.\n\n## Description\n\nShopware 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 guest orders after completing additional verification such as `deepLinkCode`, email address, and postal code. The Store API `/store-api/order` route follows this model: authenticated customers only see their own orders, and guest users are denied access unless guest-order authentication is performed. However, `/store-api/handle-payment` does not follow the same protection model. It only checks whether the supplied `orderId` exists and then directly forwards it into the payment processing flow. As a result, an attacker who cannot read orders through the intended protected route can still trigger the payment retry or payment initiation logic for another customer\u2019s order as long as they know a valid foreign order ID. Although `orderId` is a UUID-based identifier and is not trivially guessable, it is used throughout storefront order flows such as checkout finish, account order pages, payment change flows, and download links. It is therefore a business object identifier, not a secret bearer token. The server must not treat knowledge of a valid `orderId` as sufficient authorization and must instead verify that the caller is entitled to act on the referenced order. This is a backend authorization flaw caused by missing ownership validation on a sensitive order action.\n\n### Expected Behavior\n\n`/store-api/handle-payment` should only be available when the caller is the legitimate owner of the referenced order or, in the case of a guest order, when the required guest-order authentication has been completed. Before processing a supplied `orderId`, the server should verify that the current `SalesChannelContext` belongs to the customer associated with that order, or that the caller has successfully passed the expected guest-order verification flow. At a minimum, it should follow the same object-level authorization model used by the protected `/store-api/order` route.\n\n### Root Cause\n\nThe vulnerable endpoint accepts `orderId`, checks only that the order exists and has a currency, and then forwards it into the payment processor without any ownership validation.\n\n```php\n#[Route(path: \u0027/store-api/handle-payment\u0027, name: \u0027store-api.payment.handle\u0027, methods: [\u0027GET\u0027, \u0027POST\u0027])]\npublic function load(Request $request, SalesChannelContext $context): HandlePaymentMethodRouteResponse\n{\n    $data = [...$request-\u003equery-\u003eall(), ...$request-\u003erequest-\u003eall()];\n    $this-\u003edataValidator-\u003evalidate($data, $this-\u003ecreateDataValidation());\n    /** @var array{orderId: string, finishUrl?: string, errorUrl?: string} $data */\n    $orderCurrencyId = $this-\u003egetCurrencyFromOrder($data[\u0027orderId\u0027], $context-\u003egetContext());\n\n    if ($context-\u003egetCurrencyId() !== $orderCurrencyId) {\n        $context = $this-\u003econtextService-\u003eget(\n            new SalesChannelContextServiceParameters(\n                $context-\u003egetSalesChannelId(),\n                $context-\u003egetToken(),\n                $context-\u003egetLanguageId(),\n                $orderCurrencyId,\n            )\n        );\n    }\n\n    $response = $this-\u003epaymentProcessor-\u003epay(\n        $data[\u0027orderId\u0027],\n        $request,\n        $context,\n        $data[\u0027finishUrl\u0027] ?? null,\n        $data[\u0027errorUrl\u0027] ?? null,\n    );\n\n    return new HandlePaymentMethodRouteResponse($response);\n}\n```\n\nFile: `src/Core/Checkout/Payment/SalesChannel/HandlePaymentMethodRoute.php`\n\nThe internal payment processing path similarly uses the supplied `orderId` to find the current transaction without checking whether the current caller owns the order.\n\n```php\npublic function pay(\n    string $orderId,\n    Request $request,\n    SalesChannelContext $salesChannelContext,\n    ?string $finishUrl = null,\n    ?string $errorUrl = null,\n): ?RedirectResponse {\n    $transaction = $this-\u003egetCurrentOrderTransaction($orderId, $salesChannelContext-\u003egetContext());\n    if (!$transaction) {\n        return null;\n    }\n\n    $response = $paymentHandler-\u003epay($request, $transactionStruct, $salesChannelContext-\u003egetContext(), $validationStruct);\n\n    return $response;\n}\n\nprivate function getCurrentOrderTransaction(string $orderId, Context $context): ?OrderTransactionEntity\n{\n    $criteria = (new Criteria())\n        -\u003eaddFilter(new EqualsFilter(\u0027stateId\u0027, $this-\u003einitialStateIdLoader-\u003eget(OrderTransactionStates::STATE_MACHINE)))\n        -\u003eaddFilter(new EqualsFilter(\u0027orderId\u0027, $orderId))\n        -\u003eaddSorting(new FieldSorting(\u0027createdAt\u0027, FieldSorting::DESCENDING))\n        -\u003esetLimit(1);\n\n    $transaction = $this-\u003eorderTransactionRepository-\u003esearch($criteria, $context)-\u003egetEntities()-\u003efirst();\n\n    if (!$transaction) {\n        $criteria-\u003eresetFilters();\n        $criteria-\u003eaddFilter(new EqualsFilter(\u0027orderId\u0027, $orderId));\n\n        if ($this-\u003eorderTransactionRepository-\u003esearchIds($criteria, $context)-\u003efirstId()) {\n            return null;\n        }\n\n        throw PaymentException::invalidOrder($orderId);\n    }\n\n    return $transaction;\n}\n```\n\nFile: `src/Core/Checkout/Payment/PaymentProcessor.php`\n\nBy contrast, the official order retrieval route explicitly enforces current-context order ownership.\n\n```php\nif ($context-\u003egetCustomer()) {\n    $criteria-\u003eaddFilter(new EqualsFilter(\u0027order.orderCustomer.customerId\u0027, $context-\u003egetCustomerId()));\n} elseif ($deepLinkFilter === null) {\n    throw OrderException::customerNotLoggedIn();\n}\n\nif ($deepLinkFilter !== null \u0026\u0026 !$context-\u003egetCustomer()) {\n    $order = $orders-\u003efirst();\n\n    if ($order === null) {\n        throw OrderException::guestNotAuthenticated();\n    }\n\n    $this-\u003eguestAuthenticator-\u003evalidate($order, $request);\n}\n```\n\nFile: `src/Core/Checkout/Order/SalesChannel/OrderRoute.php`\n\nThe Store API schema also reflects that `/store-api/order` is designed for customer-owned or guest-authenticated order access, while `/store-api/handle-payment` only requires `orderId`.\n\n```json\n{\n  \"summary\": \"Fetch a list of orders\",\n  \"description\": \"List orders of a customer.\"\n}\n```\n\nFile: `src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/order.json`\n\n```json\n{\n  \"summary\": \"Initiate a payment for an order\",\n  \"required\": [\"orderId\"]\n}\n```\n\nFile: `src/Core/Framework/Api/ApiDefinition/Generator/Schema/StoreApi/paths/handle-payment.json`\n\nThe expected model is that both order access and payment initiation are tied to order ownership or guest-order authentication. The implemented model instead trusts a caller-supplied `orderId` and allows a sensitive payment action on a foreign order.\n\n## Impact\n\nThe attacker only needs to be a normal remote Store API user and does not need to be an authenticated backend user. Even a guest context is sufficient. No administrator privileges, backend access, shell access, or other special internal conditions are required. In a realistic scenario, an external user can create a normal guest Store API context through the storefront or Store API and then submit a valid foreign order ID learned through another channel to `/store-api/handle-payment` in order to trigger the payment retry or payment initiation flow for another customer\u2019s order. Here, `orderId` should not be treated as a secret authorization token. While it is not trivially guessable, it is used throughout storefront order-related flows such as checkout finish, account order detail pages, payment update routes, and download links as a business object identifier. Treating possession of a valid `orderId` as sufficient authorization breaks the expectation that only the legitimate order owner, or a properly authenticated guest-order user, may perform payment-related follow-up actions. In practice, this can lead to unauthorized payment attempts, external payment integration calls, customer confusion, and disruption of order processing integrity. The primary impact is on the integrity of order and payment workflows, with potential secondary operational or availability impact depending on the payment integration.\n\n## Patch Recommendation\n\nBefore processing a supplied `orderId`, `/store-api/handle-payment` should enforce the same object-level authorization model used by the order access routes. For authenticated customers, the server should verify that the order belongs to the current customer. For guest orders, it should require and validate the same guest-order authentication conditions used in the official order retrieval flow. In addition, the internal payment processor should not resolve a transaction solely by `orderId`; transaction lookup should be constrained to orders that are authorized for the current sales channel context and caller.",
  "id": "GHSA-9v5m-39wh-5chq",
  "modified": "2026-06-04T19:33:54Z",
  "published": "2026-06-04T19:33:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-9v5m-39wh-5chq"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware: Unauthorized Payment Trigger for Foreign Orders via /store-api/handle-payment"
}