Blog posts by Bien Nguyen

MimeKit Vulnerability and EPiServer.CMS.Core Dependency Update

Tue, 21 Oct 2025 07:01:00 GMT

Hi everyone,

We want to inform you about a critical security vulnerability affecting older versions of the EPiServer.CMS.Core package due to its indirect dependency on MimeKit 3.0.

🔍 What’s the Issue?

Versions of EPiServer.CMS.Core prior to 12.22.4 have a dependency on MailKit 3.0 up to 4.x, which in turn depends on MimeKit 3.0. Unfortunately, MimeKit 3.0 contains a high severity vulnerability, the patch version is 4.7.1.

✅ What We Did

Starting from EPiServer.CMS.Core version 12.22.4, which was released for a couple of months, we updated the dependency range for MailKit to [3.0, 5.0). This change allows you to be able to manually upgrade MailKit and MimeKit to safer versions. Specifically, we recommend upgrading the MailKit package to 4.7.1 or higher which requires the patch version of MimeKit 4.7.1 or higher.

📢 What You Should Do

We strongly advise:

Upgrade EPiServer.CMS.Core to version 12.22.4 or later.
Manually upgrade MailKit to version 4.7.1 or higher.

This will eliminate the vulnerability and align your application with best security practices.

Note: Upgrading MailKit to a new major version (v4) should not cause any issues in CMS. We have already verified compatibility when extending the dependency range in version 12.22.4.
However, if your application directly uses MailKit, please be aware that MailKit v4 introduces changes in public APIs, and you may need to update your implementation accordingly.

🔒 Looking Ahead

Security is a top priority for us. We are actively considering enforcing a higher minimum version of MailKit in future CMS Core releases to ensure all customers benefit from secure defaults.

If you have any questions, please reach out to our support team. Thank you for your continued trust and commitment to secure software practices.

Vulnerability in EPiServer.GoogleAnalytics v3 and v4

Wed, 20 Sep 2023 02:24:19 GMT

Introduction

A potential security vulnerability was detected for Optimizely Google Analytics addon (including EPiServer.GoogleAnalytics and EPiServer.GoogleAnalytics.Commerce), with list of affected versions below. Optimizely websites based on CMS 12 and/or Customized Commerce 14 using the affected packages are affected by this vulnerability that might give an attacker access sensitive data in the application.

Risk

Overall, the risk of the vulnerability is high. The issue was fixed in EPiServer.GoogleAnalytics v4.2.0 (GA-471). Mitigation is in place for all DXP service customers.

Update (September 20): we've re-evaluated the situation and decided to inform that, the risk of this vulnerability is critical!

Affected versions

The versions below of EPiServer.GoogleAnalytics and EPiServer.GoogleAnalytics.Commerce are affected by this vulnerability:

3.0.0 (.netcore version to support CMS12)
3.0.1
4.0.0 (added support for GA4 which replaced the GA UA used in previous versions of EPiServer.GoogleAnalytics)
4.0.1
4.1.0

Remediation

If using affted version of EPiServer.GoogleAnalytics in the list above, please update the to the version 4.2.0 or later.
Updated (September 22): The fix has been also backported to a v3 version (the version 3.0.2). If you are using an affected v3 version in the list above, and don't want to upgrade to the v4.2.0 version (or later) then you can either update the version to 3.0.2 or simply uninstall the addon completely.

Please reach out to our support for further guidance by email to support@optimizely.com or submit a request at https://support.optimizely.com/hc/en-us.

Questions

Please contact the security engineering team at securityeng@optimizely.com.

Risk definitions

Low – little to no potential impact on Optimizely or customer environments/data. Vulnerability has low exploitability, for example: requirement for local or physical system access, zero reachability to/executability within Optimizely products/code.

Medium – some potential impact on Optimizely or customer environments/data. Vulnerability has medium exploitability, for example: requirement to be located on the same local network as the target, requirement for an individual to be manipulated via social engineering, requirement for user privileges, vulnerability achieves limited access to Optimizely products/code.

High – high potential impact on Optimizely or customer environments/data. Vulnerability has high exploitability, for example: achieves high level access to Optimizely products/code, could elevate privileges, could result in a significant data loss or downtime.

Critical – very significant potential impact on Optimizely or customer environments/data. Vulnerability has very high exploitability, for example: achieves admin/root-level access to Optimizely products/code. Vulnerability does not require any special authentication credentials/knowledge of Optimizely products/environments.

New release of AvaTax connector

Fri, 23 Nov 2018 03:55:08 GMT

We've released a new major version of AvaTax connector - an integrated transactional tax compliance add-on for Episerver Commerce from Avalara. You now can easily find the packages on our nuget site. More precisely, the major version is 2.0.0 but the recommended version is the patch 2.0.1 that fixes an installation issue for new integration.

Here are the changes in summary:

It requires Avalara.AvaTax package version 18.5.1.208 or higher
It requires new major version of EPiServer.Commerce: 12.3.0.0 or higher
Since in Commerce 12, all calculations in activities are carried out by calculators, therefore the classes for specific supporting for EPiServer Commerce workflows has been removed (AvataxActivitySupport and AvaCalculateTaxActivity classes). The AvataxConnector registers custom calculators for IOrderFormCalculator, IReturnOrderFormCalculator, IShippingCalculator and ITaxCalculator. See here for more detail on changes in Commercer 12.
Support for caching of asynchronous requests to the AvaTax service has been removed completely (the Implementation.TransactionCaching namespace)

Commerce 12 release

Tue, 17 Apr 2018 05:26:16 GMT

It's my honor to annouce that, in update 210, we shipped a version 12 release of Commerce. This is a major release of Commerce in 2018, as part of our continuous release process. The main focus is on improvements to the order system of Commerce. There is also an improvement related to the catalog system. These improvements require breaking changes to our public API.

Order calculators improvements

There is a new setting added on market and order group, indicating whether prices include tax.

And the order calculations will take that setting into account. So now Episerver Commerce supports both US tax style (prices exclude taxes) and European tax style (prices include taxes).

The calculators are also re-structured to make them work more efficiently. The tax calculator calculates only the sales tax and shipping tax for a line item - the lowest level of order. The tax calculation for shipment, order form and order group are moved to corresponding calculators: shipping calculator, order form calculator and order group calculator. The default implementation of calculators are also improved. So that it reduces unnecessary calls to calculators when getting tax values of order entities or getting shipping cost of shipments, which was inefficient especially when using an external tax/shipping services.

Still on the tax improvements, a small one, the tax category which is almost not changed during the order processing is now stored in a line item. So that we don’t need to retrieve it from DB/cache system each time calculating order. One more benefit is that even if the product of the line item of an order was removed, or was no longer taxed after the order had been made, when the order needs to be recalculated, the price of that line item should not be changed.

Workflows improvements

All calculations in activities are now done by using calculators. So that it will ensures the order calculations are consistent between workflow system and no-workflow system.

Catalog system improvements

The events raised when changes to Catalog DTO:s are about saved, the Updating events (e.g CatalogEntryUpdating), are no longer replicated on the remote event channel. The events raised when the change transaction completes, the Updated events (e.g CatalogEntryUpdated), are still replicated.

API improvements

8 bug fixes (public bugs listed on the Commerce 12 release notes).
New properties have been added: MarketId, MarketName, and PricesIncludeTax to IOrderGroup. The Market property has been obsoleted. Therefore a saved order should be complete without any real need to reference other tables/entities.
Remove obsoleted APIs.

Planned Breaking Changes in Commerce 2018

Mon, 05 Feb 2018 12:19:56 GMT

We are working on a number of changes in Commerce which are considered breaking since that will change some behaviors and APIs and therefore will be released as a new major version of Commerce.

Here is a short summary of what we are considering, the details will be announced at a later stage:

Improved calculators

The calculators will be re-structured to make them work more efficiently. The tax calculator will calculate only tax values at the lowest level – line item. The tax calculation for shipment, order form, and order group will be moved to corresponding calculator. The default implementations for calculations will be also improved so that it will reduce unnecessary calls to calculators when getting tax values of order entities or getting shipping cost of shipments.

Re-worked how to use taxes in Commerce

The current default implementations for calculations is done based on the assumption that prices are excluding tax and tax is added at the end. And if your catalog has prices including taxes (mostly in Europe), you have to re-implement the entire tax calculation or use a third party service. Now, a setting indicating whether prices includes tax will be added on market, and the calculations will take that setting into account.

Adding market info on order group for completeness

A saved purchase order or cart should be as complete as possible, without any real need to reference other tables / entities. Currently we only have a reference to the market but that will not be needed anymore, an order group will just have the info what it needs about market, not the whole market entity.

Clean Up Previously Deprecated APIs

There are a number of APIs that have been marked as obsolete for a long time, and will now be removed.

The current estimate for this new major version is Q1 2018.

Payment providers source code are now available on GitHub

Thu, 14 Sep 2017 08:54:27 GMT

The source code for payment providers, including PayPal, DIBS, DataCash have been released to GitHub. These projects were upgraded to work with latest version of Commerce (11.2.2) and other components, that contains a few fixes and refactoring. They're now open-source and you might be great contributors :). We'll continue to update them. It means that we'll do continuous releases for them but they might be updated less frequently (than Commerce packages). It also means that we won't provide source code packages for those projects (.zip files) from the release 11.2.2. If you need the source codes, you can download from GitHub.

So now with the /nSoftware payment gateways, which has been available on GitHub from about 1 year, we have now 4 payment provider projects on GitHub. Please visit the repository on GitHub for more detail.

All documentation related to installation/configuration are still on EPi World.

[Authorize.Net payment gateway] Enable the Transaction Details API setting requirement

Tue, 07 Mar 2017 01:48:58 GMT

In the next EPiServer Commerce release (10.4.0), we've done some improvements for the Authorize.Net built-in payment gateway. Now when processing a payment, we send request to the authorize.net server to get transaction details of the payment. It helps us to know what status of the transaction is, that has never been done before. So that in case the transaction is processed manually on the Authorize.net web page, for example if the transaction was already captured or settled, then we don't need to process it in the gateway. Therefore it requires to enable the Transaction Details API on Authorize.Net accounts, including yours. Please enable it by following these simple steps:

1) Log on to the Merchant Interface at https://account.authorize.net .
2) Select Settings under Account in the main menu on the left.
3) Click the Transaction Details API link in the Security Settings section. The Transaction Details API screen opens.
4) If you have not already enabled the Transaction Details API, enter the answer to your Secret Question, then click Enable Transaction Details API.
5) When you have successfully enabled the Transaction Details API, the Settings page displays.

Regards.