Hi Virto Commerce Dev Friends,
We want to be transparent about the recently published AutoMapper Denial of Service vulnerability GHSA-rvv3-g6hj-g44x and share exactly where we stand on this.
If you have a reference to Virto Commerce XAPI dll’s, you can get the following error:
error NU1903: Warning As Error: Package ‘AutoMapper’ 12.0.1 has a known high severity vulnerability, AutoMapper Vulnerable to Denial of Service (DoS) via Uncontrolled Recursion · GHSA-rvv3-g6hj-g44x · GitHub Advisory Database · GitHub
What is the vulnerability?
AutoMapper versions below 16.1.1 are vulnerable to a DoS attack via uncontrolled recursion. When mapping an extremely deeply nested object graph (25,000+ levels), the library can trigger a StackOverflowException.
Our assessment & what we’ve done
We’ve reviewed all Virto Commerce modules and can confirm:
AutoMapper in the Virto Commerce core is not used for mapping network/API request payloads. It is used exclusively for internal DTO and ViewModel mapping from well-defined, shallow data structures — the kind of object graphs that are not realistically exploitable through this attack vector.
This significantly reduces the practical risk for standard Virto Commerce deployments. That said, we take all security advisories seriously and have taken steps to minimise exposure across the platform.
Recommended action if you use AutoMapper in your own modules
1. Suppress the NuGet audit warning
You can suppress the NuGet audit warning in your project file that has a dependency on VirtoCommerce XAPI modules:
<ItemGroup>
<NuGetAuditSuppress Include="https://github.com/advisories/GHSA-rvv3-g6hj-g44x" />
</ItemGroup>
Or suppress it globally across all projects in your solution, add it instead to your Directory.Build.props file in the root of your repository. If this file doesn’t exist yet, create it:
<Project>
<ItemGroup>
<NuGetAuditSuppress Include="https://github.com/advisories/GHSA-rvv3-g6hj-g44x" />
</ItemGroup>
</Project>
2. Set MaxDepth in your mapping profiles
If you have custom Virto Commerce modules that use AutoMapper — particularly in code paths that process external or user-supplied data — we strongly recommend adding a MaxDepth limit to your mapping profiles as a defensive measure:
cfg.CreateMap<MySourceType, MyDestinationType>().MaxDepth(32);
This is a minimal, low-risk code change that effectively mitigates the vulnerability by capping recursion depth before a stack overflow can occur.
Our take: the “High” severity rating deserves some scrutiny
We find this vulnerability a little unusual for a 7.5 High CVSS rating, and we think it warrants a more measured assessment:
- The attack condition is extreme. Triggering this requires crafting an object graph with 25,000+ levels of nesting. This is not something that happens accidentally or through ordinary API usage — it requires deliberate, targeted construction of a pathological payload.
- DoS only — no data at risk. The vulnerability has zero impact on confidentiality or data integrity. It is a pure availability issue, meaning no data can be stolen or tampered with as a result.
- AutoMapper is rarely exposed directly to raw network input. In well-architected applications (including Virto Commerce), AutoMapper sits behind deserialization and validation layers. An attacker would first need to smuggle a 25,000-level deep object through your API’s model binding and validation — which most frameworks and input size limits would reject long before it reaches a mapping profile.
- In practice, it is closer to a Medium risk for the vast majority of real-world deployments. The CVSS score reflects a worst-case theoretical scenario (no auth, no input validation, direct network access to the mapper) that is unlikely in production.
It is also worth noting the broader context here. AutoMapper transitioned to a commercial product in July 2025 (under Lucky Penny Software), with v15.0 being the first commercial release. The patched version — v16.1.1 — is only available under the new commercial/RPL dual license. There are no plans to backport the fix to v12 or any prior MIT-licensed version.
This means teams using the free, MIT-licensed AutoMapper (v12 and below) are effectively being nudged toward purchasing a commercial license to get the official fix. We understand the maintainer’s need to sustain the project commercially, but we think it’s important for the community to be aware of this dynamic when evaluating the urgency of the advisory.
The good news: the vulnerability is fully mitigatable without upgrading, so a commercial license is not required to protect your application.
Our Roadmap: Replacing AutoMapper and MediatR
Separately from this vulnerability, and in light of AutoMapper’s recent transition to a commercial licensing model, we are planning to replace AutoMapper in Virto Commerce modules in an upcoming release.
We’ll share more details on timeline and the chosen alternative as plans are finalized.
We’ll keep this thread updated as we progress.