The SAP Commerce (Testweb Extension), versions- 6.6, 6.7, 1808, 1811, 1905, does not sufficiently encode user-controlled inputs, due to which certain GET URL parameters are reflected in the HTTP responses without escaping/sanitization, leading to Reflected Cross Site Scripting.

The SAP Commerce (SmartEdit Extension), versions- 6.6, 6.7, 1808, 1811, is vulnerable to client-side angularjs template injection, a variant of Cross-Site-Scripting (XSS) that exploits the templating facilities of the angular framework.

SAP Commerce Cloud (Public Cloud) does not allow to disable unencrypted HTTP (port 80) entirely, but instead allows a redirect from port 80 to 443 (HTTPS). As a result, Commerce normally communicates securely over HTTPS. However, the confidentiality and integrity of data sent on the first request before the redirect may be impacted if the client is configured to use HTTP and sends confidential data on the first request before the redirect.

A race condition vulnerability exists in the SAP Commerce cloud. Because of this when an attacker adds products to a cart, it may result in a cart entry being created with erroneous product value which could be checked out. This leads to high impact on data integrity, with no impact on data confidentiality or availability of the application.

SAP Commerce Cloud exposes multiple API endpoints to unauthenticated users, allowing them to submit requests to these open endpoints to retrieve sensitive information that is not intended to be publicly accessible via the front-end. This vulnerability has a low impact on confidentiality and does not affect integrity and availability.

SAP Commerce (Backoffice) uses the deprecated X-FRAME-OPTIONS header to protect against clickjacking. While this protection remains effective now, it may not be the case in the future as browsers might discontinue support for this header in favor of the frame-ancestors CSP directive. Hence, clickjacking could become possible then, and lead to exposure and modification of sensitive information.

SAP Commerce, by default, sets certain cookies with the SameSite attribute configured to None (SameSite=None). This includes authentication cookies utilized in SAP Commerce Backoffice. Applying this setting reduces defense in depth against CSRF and may lead to future compatibility issues.

In SAP Commerce, valid user accounts can be identified during the customer registration and login processes. This allows a potential attacker to learn if a given e-mail is used for an account, but does not grant access to any customer data beyond this knowledge. The attacker must already know the e-mail that they wish to test for. The impact on confidentiality therefore is low and no impact to integrity or availability

SAP Commerce Cloud (Accelerator Payment Mock), versions - 1808, 1811, 1905, 2005, allows an unauthenticated attacker to submit a crafted request over a network to a particular SAP Commerce module URL which will be processed without further interaction, the crafted request leads to Server Side Request Forgery attack which could lead to retrieval of limited pieces of information about the service with no impact on integrity or availability.

SAP Commerce (Backoffice Search), versions - 1808, 1811, 1905, 2005, 2011, allows a low privileged user to search for attributes which are not supposed to be displayed to them. Although the search results are masked, the user can iteratively enter one character at a time to search and determine the masked attribute value thereby leading to information disclosure.