CVE-2026-128082: Uncontrolled Recursion and Denial of Service in AutoMapper via Constructor Parameter Mapping

AutoMapper is a widely deployed library in the .NET ecosystem used to transform data between distinct object types, such as mapping incoming Data Transfer Objects (DTOs) from API requests into internal domain models or database entities. Instead of relying on runtime reflection for every mapping operation, AutoMapper builds LINQ Expression Trees during initialization and compiles them into dynamic execution plans (ExecutionPlan). These compiled delegates handle object instantiation, property assignment, and recursion tracking across complex object graphs.

To prevent unbounded execution when processing self-referential or cyclical object hierarchies, AutoMapper provides a recursion depth control mechanism via .MaxDepth(n) on type map configurations, alongside a default recursion depth ceiling of 64 for self-referential mappings. During execution, the compiled mapping plan tracks the current recursion level for each source-destination type pair within the active ResolutionContext. When the recorded depth reaches the configured maximum, AutoMapper halts further descent down that branch and returns a default or null value.

CVE-2026-128082 (also tracked as GHSA-6vhm-j9h7-f9gh) is an uncontrolled recursion vulnerability (CWE-674) located in TypeMapPlanBuilder.cs, the component responsible for assembling the expression tree for individual type mappings. In affected versions (< 15.1.4 and >= 16.0.0, < 16.3.0), the expression that increments the type depth counter (IncTypeDepthInfo) is appended to the execution sequence after the expression that instantiates the destination object (createDestination).

When a destination model is instantiated using a parameterless constructor and populated via mutable property setters, this ordering functions as intended because child properties are mapped after createDestination and IncTypeDepthInfo have both executed. However, if the destination type uses constructor parameter mapping—such as C# positional records (record NodeRecord(NodeRecord Next, int Id)), classes with parameterized constructors taking recursive child types, or custom .ConstructUsing(...) expressions that invoke ctx.Mapper.Map—all constructor arguments must be resolved before the parent constructor can complete. Consequently, child mappings execute recursively inside createDestination before the parent level ever increments the depth counter, rendering MaxDepth completely ineffective and exposing the application to fatal stack exhaustion.

The root cause of CVE-2026-128082 lies in how TypeMapPlanBuilder sequences expressions inside the CreateAssignmentFunc method in src/AutoMapper/Execution/TypeMapPlanBuilder.cs. When AutoMapper compiles a TypeMap, it splits the mapping logic into two primary stages: creating or resolving the destination instance (CreateDestinationFunc) and assigning its members (CreateAssignmentFunc). The CreateAssignmentFunc method receives the createDestination expression as its input parameter and constructs a sequential block of Expression nodes stored in a List<Expression> actions collection.

When _typeMap.MaxDepth > 0 is active, AutoMapper tracks depth state by invoking ResolutionContext.IncTypeDepthInfo with a constant reference to the current _typeMap. Prior to the entry of CreateAssignmentFunc, an outer check (ResolutionContext.OverTypeDepth) verifies whether the current invocation count for _typeMap has already met or exceeded MaxDepth. For OverTypeDepth to evaluate accurately during recursive calls, the parent call must increment the counter in ResolutionContext before any child mapping of the same TypeMap begins.

In the vulnerable implementation, CreateAssignmentFunc initialized the actions list with [createDestination] as the very first element, and subsequently appended the Call(ContextParameter, IncTypeDepthInfo, typeMapExpression) expression as the second element. In C# and the .NET Common Language Runtime (CLR), arguments to a constructor call (NewExpression) or delegate invocation (InvocationExpression) are evaluated eagerly from left to right before the constructor body or method executes.

Because createDestination contains the nested mapping expressions required to satisfy constructor parameters, evaluating createDestination at depth $0$ immediately invokes the mapping plan for depth $1$ while the recorded depth in ResolutionContext is still $0$. Depth $1$ checks OverTypeDepth (which reads $0$), enters its own createDestination, and invokes depth $2$ with the counter still at $0$. The IncTypeDepthInfo call is deferred on the call stack at every level until the leaf node of the input graph is finally reached and instantiated. If the input graph depth exceeds the thread stack capacity before reaching a leaf node, the CLR throws System.StackOverflowException. Furthermore, even on shallower graphs that do not crash the process, MaxDepth is never enforced during the descent phase because the depth counter only increments on the way back up the unwinding stack.

The vulnerability was addressed in commit 4d51a4b8125b4d2302f2f1f455747c9648ad1acb on the main branch (for the 16.3.0 release) and backported via commit 639c2748cb9d3d07df8b86879ba7bcf211675c86 (for the 15.1.4 release). The modification is localized to CreateAssignmentFunc within src/AutoMapper/Execution/TypeMapPlanBuilder.cs.

Below is the annotated diff from commit 4d51a4b8125b4d2302f2f1f455747c9648ad1acb showing the transition from the vulnerable expression ordering to the patched sequence:

@@ -207,15 +207,17 @@ private Expression CreateDestinationFunc()
 
     private Expression CreateAssignmentFunc(Expression createDestination)
     {
-        List<Expression> actions = [createDestination];
+        List<Expression> actions = [];
         Expression typeMapExpression = null;
         var hasMaxDepth = _typeMap.MaxDepth > 0;
         if (hasMaxDepth)
         {
+            // Count this level before creating the destination, constructor parameters map child objects there
             typeMapExpression = Constant(_typeMap);
             actions.Add(Call(ContextParameter, IncTypeDepthInfo, typeMapExpression));
         }
 
+        actions.Add(createDestination);
         AddBeforeMap(actions);
         AddPropertyMaps(actions);
         AddPathMaps(actions);

In the patched version, actions is initialized as an empty list []. If hasMaxDepth is true, the Call(ContextParameter, IncTypeDepthInfo, typeMapExpression) expression is inserted at index 0 of actions, and actions.Add(createDestination) is placed immediately after the conditional block. Later in CreateAssignmentFunc, a try...finally expression block wraps the execution so that ResolutionContext.DecTypeDepthInfo is called when exiting the current mapping frame.

// Conceptual view of the compiled expression tree after the patch:
try
{
    if (context.OverTypeDepth(typeMap))
    {
        return default;
    }
    
    // 1. Depth is now incremented BEFORE constructor arguments are evaluated
    context.IncTypeDepth(typeMap);
    
    // 2. Recursive calls inside constructor arguments now observe the incremented depth
     destination = new CtorNode(Map<CtorNode>(source.Next, context));
    
    // 3. Property and path maps execute (if any)
    return destination;
}
finally
{
    context.DecTypeDepth(typeMap);
}

With regards to fix completeness, moving IncTypeDepthInfo ahead of createDestination comprehensively resolves the bypass across all three constructor-based instantiation mechanisms supported by AutoMapper: standard parameterized constructors bound by convention or .ForCtorParam(...), C# positional records, and custom .ConstructUsing((src, ctx) => ...) delegates that re-enter ctx.Mapper.Map. Because createDestination encapsulates all destination instantiation pathways in TypeMapPlanBuilder, no variant constructor path within CreateAssignmentFunc executes prior to depth registration.

Exploiting CVE-2026-128082 requires an application endpoint that accepts hierarchical or recursive data structures (such as JSON, XML, YAML, or GraphQL inputs) and maps the deserialized source object into a destination model using AutoMapper where the destination relies on constructor parameter mapping. Because C# positional records (public record CategoryDto(string Name, CategoryDto Parent);) have become standard practice in modern .NET applications for immutable DTOs and domain models, this pattern is frequently exposed on public and authenticated API surfaces.

An attacker can trigger the vulnerability by constructing a deeply nested payload where each node contains a child node of the same recursive type. One common operational nuance in ASP.NET Core applications is that System.Text.Json enforces a default MaxDepth of 64 during JSON deserialization. However, if the application uses a serializer without a low default depth limit (such as Newtonsoft.Json prior to custom configuration, protobuf, custom model binders, or explicitly raised JsonSerializerOptions.MaxDepth), or if the recursive graph is constructed in memory from flat relational identifiers before calling mapper.Map, the deeply nested structure reaches AutoMapper intact.

The regression test suite introduced in commit 4d51a4b8125b4d2302f2f1f455747c9648ad1acb (src/UnitTests/Bug/ConstructorMaxDepth.cs) illustrates the three primary code patterns that fail to enforce MaxDepth in vulnerable releases:

namespace AutoMapper.UnitTests.Bug;
 
public class ConstructorMaxDepth
{
    public class CtorNode
    {
        public CtorNode(CtorNode next) => Next = next;
        public CtorNode Next { get; set; }
    }
 
    public class Node { public Node Next { get; set; } public int Id { get; set; } }
    public record NodeRecord(NodeRecord Next, int Id);
 
    static CtorNode CtorChain(int length)
    {
        var root = new CtorNode(null);
        var current = root;
        for (int i = 0; i < length; i++)
        {
            current.Next = new CtorNode(null);
            current = current.Next;
        }
        return root;
    }
 
    // 1. Standard Constructor Parameter Recursion
    [Fact]
    public void Should_honor_explicit_max_depth_through_constructor_parameters()
    {
        var mapper = new MapperConfiguration(cfg => 
            cfg.CreateMap<CtorNode, CtorNode>().MaxDepth(10)
        ).CreateMapper();
 
        // In vulnerable versions, all 100 levels are mapped despite MaxDepth(10).
        // Increasing chain length to ~10,000-20,000 crashes the process with StackOverflowException.
        var result = mapper.Map<CtorNode>(CtorChain(100));
    }
 
    // 2. C# Positional Records
    [Fact]
    public void Should_honor_max_depth_through_positional_record_parameters()
    {
        var mapper = new MapperConfiguration(cfg => 
            cfg.CreateMap<Node, NodeRecord>().MaxDepth(10)
        ).CreateMapper();
    }
 
    // 3. Recursive ConstructUsing Delegate
    [Fact]
    public void Should_honor_max_depth_when_construct_using_maps_recursively()
    {
        var mapper = new MapperConfiguration(cfg => 
            cfg.CreateMap<Node, NodeRecord>().MaxDepth(10)
                .ConstructUsing((src, ctx) => new NodeRecord(
                    src.Next == null ? null : ctx.Mapper.Map<NodeRecord>(src.Next), 
                    src.Id))
                .ForAllMembers(o => o.Ignore())
        ).CreateMapper();
    }
}

When mapper.Map executes against a chain of sufficient depth (typically between 5,000 and 25,000 levels depending on the size of the stack frames and whether the thread is running with a 256 KB, 512 KB, or 1 MB stack allocation), the thread exhausts its stack space. In the .NET runtime (starting with .NET Framework 2.0 and continuing through all versions of .NET Core and modern .NET), System.StackOverflowException cannot be caught by user-defined try...catch blocks or global ASP.NET Core exception handling middleware. The CLR immediately aborts the entire worker process (dotnet.exe or IIS w3wp.exe).

CVE-2026-128082 is scored at 7.5 (High) under CVSS v3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The vulnerability is network-exploitable (AV:N) with low attack complexity (AC:L), requires no privileges (PR:N) or user interaction (UI:N) when exposed on a public endpoint, and does not impact confidentiality (C:N) or integrity (I:N). The severity derives entirely from the high availability impact (A:H).

Unlike standard unhandled exceptions in .NET web applications—which are caught by the Kestrel or IIS request pipeline to return an HTTP 500 Internal Server Error while keeping the server online—an unhandled System.StackOverflowException terminates the entire host OS process immediately. All active in-flight HTTP requests across all concurrent users sharing that worker process are abruptly dropped, in-memory caches and session states held within the process are lost, and background IHostedService tasks running in the same process are terminated without graceful shutdown.

> [!NOTE] > In containerized environments (such as Kubernetes) or IIS Application Pools configured with Rapid-Fail Protection, repeated exploitation by an attacker sending periodic requests can trigger crash-loop backoff states or cause IIS to disable the application pool entirely after a small number of crashes (typically 5 crashes within 5 minutes by default), extending the outage duration well beyond individual request processing times.

At the time of publication, the Exploit Prediction Scoring System (EPSS) has not assigned an active probability score (0%), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, functional proof-of-concept test harnesses exist publicly in the upstream repository's unit test suite.

The primary remediation for CVE-2026-128082 is to upgrade the AutoMapper NuGet package to a patched release that sequences IncTypeDepthInfo prior to destination instantiation. Lucky Penny Software has published fixes across both active major release branches:

• AutoMapper 15.x Series: Upgrade to version 15.1.4 or later.
• AutoMapper 16.x Series: Upgrade to version 16.3.0 or later.

After upgrading, confirm that self-referential or cyclical mappings either rely on AutoMapper's default self-referential depth limit (64) or specify an explicit .MaxDepth(n) threshold appropriate for the application's thread stack constraints.

If an immediate dependency upgrade is not feasible, development teams can apply two defense-in-depth workarounds to mitigate the risk of stack exhaustion:

1. Refactor Destination Models to Property-Based Mapping: Where recursive types are mapped, replace C# positional records or parameterized constructors on the destination type with a parameterless constructor and standard mutable properties (public Node Next { get; set; }), and remove recursive .ConstructUsing(...) calls. Standard property mappings execute after createDestination and IncTypeDepthInfo, allowing existing MaxDepth configurations to function properly in older AutoMapper versions.
2. Enforce Strict Deserialization Depth Limits: Ensure that all input formatters and deserializers enforce a strict maximum depth before objects are passed to AutoMapper. For example, if using Newtonsoft.Json (which historically defaulted to no depth limit prior to v13.0.1, or where MaxDepth may have been overridden), explicitly configure JsonSerializerSettings.MaxDepth = 32 or 64 in the request pipeline. If recursive structures are assembled from flat database or API arrays prior to mapping, validate the maximum tree depth iteratively before invoking IMapper.Map.