Table of Contents

Security Reports

An overview of identified security issues in DynamicWeb products

This page provides an overview of identified security issues in DynamicWeb products. Each report includes a summary of the issue, the affected products, the potential impact, and the recommended remediation. To help customers prioritize, every report also includes a CVSS v3.1 score with both a technical breakdown and a short executive summary.

For security reasons, detailed exploitation steps are not published here, but can be obtained by contacting DynamicWeb directly. Reports are published to help partners and customers assess risk, apply updates, and remain compliant with relevant security and data protection requirements.

For more information on how we handle security fixes, please see our Security Bug Fixing Policy.

January 19th, 2026 - Unauthenticated RCE (Dynamicweb 9 and Dynamicweb 8)

Summary

  • Severity: Critical
  • CVSS v3.1: 10.0
  • Affected product: Dynamicweb 9 and Dynamicweb 8
  • Affected versions: All Dynamicweb 9.* and 8.* versions
  • Fixed in: Dynamicweb 9.19.6, 9.20.3, 9.21.0, and stand-alone hotfix DynamicwebSoftware.Security.DevOps27005.dll
  • Reported by: External security researcher

Description

A security vulnerability has been identified in Dynamicweb 8 and 9 that may allow an unauthenticated remote attacker to execute arbitrary code under certain conditions.

The issue was reported to Dynamicweb through a coordinated disclosure process and has been addressed in accordance with the Dynamicweb security bug fix policy.

Impact

Successful exploitation could allow an attacker to gain unauthorized access to system resources and compromise the affected Dynamicweb installation.

At the time of publication, Dynamicweb is not aware of any active exploitation.

Remediation

Dynamicweb has implemented a fix that restricts access to the affected functionality and ensures proper validation of externally supplied input.

Available fixes

  • Dynamicweb 9.19.6
  • Dynamicweb 9.20.3
  • Dynamicweb 9.21.0
  • DynamicwebSoftware.Security.DevOps27005.dll (stand-alone hotfix for Dynamicweb 8 and 9)

Customers running other Dynamicweb 9 versions and customers running any Dynamicweb 8 version can apply the stand-alone hotfix, delivered as a DLL, which mitigates the vulnerability. The hotfix can be installed on all Dynamicweb 8 and 9 versions and is available on the download page on the old documentation site.

Mitigation until fixed

Customers who have not yet applied the fix or hotfix should ensure that administrative functionality is not publicly accessible and that access to the solution is appropriately restricted.

Dynamicweb Cloud

All solutions hosted on Dynamicweb Cloud for Dynamicweb 8 and 9 received the fix. The rollout to Dynamicweb Cloud was completed on January 19th, 2026.

Credit

Dynamicweb thanks the external security researcher for responsibly reporting this issue.

CVSS Assessment

The vulnerability has been assessed using the CVSS v3.1 Base Score:

  • Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • Score 10.0 (Critical)

Justification:

  • AV:N (Network) – reachable via HTTP
  • AC:L (Low) – no special conditions; a single request chain
  • PR:N (None) – unauthenticated
  • UI:N (None) – no victim interaction
  • S:C (Changed) – compromise of the web app leads to executing code with server-side privileges beyond the web request boundary (practically: you can take over the host / underlying system functions)
  • C:H / I:H / A:H – code execution implies full read/modify/disrupt potential

This categorizes the issue as Critical, primarily due to the ability for an unauthenticated file write to webroot resulting in remote code execution.

See our Security Bug Fixing Policy for further details on how DynamicWeb addresses vulnerabilities.


August 25th, 2025 - Exposure of Customer Information via Payment Callback

Summary

  • Severity: High
  • CVSS v3.1: 7.5
  • Affected product: DynamicWeb 9 and DynamicWeb 10
  • Affected configuration: Solutions using the QuickPayPaymentWindow provider together with an error template that renders personal or order-related information

Description

A vulnerability has been identified in solutions running on both DynamicWeb 9 and DynamicWeb 10 when configured with the QuickPayPaymentWindow payment provider. Under certain conditions, a malicious actor may attempt to spoof the payment callback URL. If an error template is present and configured to render order-related information, this can lead to the unintended exposure of personal customer data.

The vulnerability was identified through security testing. We have no indication that the issue has been exploited in practice.

Impact

If present, this vulnerability may allow unauthorized parties to access customer information such as:

  • Customer name
  • Email address
  • Delivery information
  • Selected delivery and payment method

No payment card data or other financial details are exposed through this vulnerability.

Who is affected

The issue affects DynamicWeb 9 and DynamicWeb 10 installations that use the QuickPayPaymentWindow provider with an error template that renders personal order information.

There are two ways to mitigate the vulnerability:

  • Review whether an error template is used in the QuickPayPaymentWindow setup.
  • If such a template is present, ensure that it does not render any personal or order-related information.
  • Templates should only display generic error messages that cannot be used to infer customer data.

In DynamicWeb 9:

  • Go to Settings -> Ecommerce -> Orders -> Payment
  • Locate payment methods using "Quickpay payment window"
  • Edit each payment method using "Quickpay payment window"
  • In the "Parameters" section, set the "Error template" field to "Nothing selected", or update the template to ensure it does not render customer information

In DynamicWeb 10:

  • Go to Settings -> Commerce -> Order management -> Payment
  • Locate payment methods using "Quickpay payment window"
  • Edit each payment method using "Quickpay payment window"
  • On the "Provider" tab, in the "General" section, set the "Error template" field to "Nothing selected", or update the template to ensure it does not render customer information
  • Update the QuickPayPaymentWindow CheckoutHandler provided by DynamicWeb.
  • The updated handler will ensure that the error template is not rendered when an invalid or spoofed callback URL is received. This prevents exposure of personal data in error responses.

In DynamicWeb 9:

  • The new DLL can be rolled out into production as a drop-in replacement for the existing QuickPayPaymentWindow and requires no rebuild.
  • Alternatively, in custom projects, update the QuickPayPaymentWindow package reference to version 3.1.2:
dotnet add package Dynamicweb.Ecommerce.CheckoutHandlers.QuickPayPaymentWindow --version 3.1.2
  • Deploy the update to your production environment

In DynamicWeb 10:

  • Go to Apps -> Installed apps
  • Locate "Quickpay payment window" and update QuickPayPaymentWindow to version 10.1.2
  • If the checkout handler is installed using NuGet in a project, update it using the dotnet CLI. See the NuGet package page.
dotnet add package Dynamicweb.Ecommerce.CheckoutHandlers.QuickPayPaymentWindow --version 10.1.2

Choosing between the two options

The short-term mitigation is the fastest option because it can be implemented without deploying additional code. For most DynamicWeb 9 solutions, this is the least intrusive approach and can usually be completed quickly.

The main drawback is that the issue can be reintroduced later if the error template is changed and starts exposing customer information again.

The long-term product fix takes a little longer to roll out on some DynamicWeb 9 solutions, but it prevents future template changes from reintroducing the issue.

For DynamicWeb 10, updating the QuickPayPaymentWindow is straightforward and is the recommended option.

CVSS Assessment

The vulnerability has been assessed using the CVSS v3.1 Base Score:

  • Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
  • Score: 7.5 – High

Justification:

  • Attack Vector (AV:N): Exploitable over the network (web).
  • Attack Complexity (AC:L): Low – order IDs are guessable/sequential.
  • Privileges Required (PR:N): None – no authentication required.
  • User Interaction (UI:N): None required.
  • Scope (S:U): No cross-boundary effect.
  • Confidentiality (C:H): High – personal customer data exposed.
  • Integrity (I:N): None – data cannot be modified.
  • Availability (A:N): None – no impact on service availability.

This categorizes the issue as High Severity, primarily due to the exposure of personal data without authentication.

See our Security Bug Fixing Policy for further details on how DynamicWeb addresses vulnerabilities.

Next steps

  • Customers are advised to immediately review their configuration to confirm whether error templates are in use and whether they contain personal data.
  • DynamicWeb has released an update to the QuickPayPaymentWindow handler that enforces safe handling of invalid callbacks. Customers are strongly encouraged to apply this update.
  • As a precaution, customers may also wish to review access logs for unusual callback traffic that could indicate attempts to exploit this issue.

GDPR Considerations

Since the vulnerability concerns the unintended disclosure of personal data, it could potentially be considered a GDPR-relevant incident. As no actual exploitation has been observed, it is up to each customer to assess—together with their legal and compliance teams—whether notification to the supervisory authority (Datatilsynet or relevant local DPA) is necessary.

Suggested Notification Text (Optional)

For customers who decide to notify the authorities, the following Notification Text template can be used:

During a penetration test of our webshop, a vulnerability was identified that, under certain conditions, could allow unauthorized access to limited customer data (including name, email, address, and delivery preferences). The issue was discovered by an external security expert, and we have no indication that it has been exploited in practice. We have taken steps to remediate the vulnerability and are reporting this proactively in accordance with GDPR requirements.

To top