AutoMapper: Denial of Service via uncontrolled recursion that bypasses MaxDepth

Summary

The default and explicit MaxDepth limits added for CVE-2026-32933 don't apply to several mapping paths. Mapping a deeply nested source through any of them recurses without bound and throws a StackOverflowException, which can't be caught and terminates the process.

Affected paths

• Polymorphic maps: derived type maps (Include / IncludeBase) didn't inherit the base map's MaxDepth, and the default limit for self-referential maps was only applied to the base map. A chain of derived objects was mapped without a limit, even with MaxDepth set on the base map.
• Runtime-typed members: members typed as object or an interface aren't seen by self-reference detection, so the default limit isn't applied.
• Dictionary and dynamic sources: mapping a nested Dictionary<string, object> or ExpandoObject (for example, deserialized JSON) onto typed destinations recurses with no depth tracking. MaxDepth has no effect.
• Recursive type converters: ConvertUsing that calls context.Mapper.Map ignores MaxDepth.

Impact

An application that maps attacker-influenced, deeply nested data through one of these paths can be crashed. On a 1 MB stack (the Windows default), a few thousand levels of nesting are enough.

Fix

• Derived type maps inherit MaxDepth, and the default limit is applied to them.
• Every runtime map call checks for sufficient stack, and fails with a catchable InsufficientExecutionStackException instead of overflowing.

Workarounds

Set MaxDepth explicitly on derived maps and on maps reached through object or interface members. There is no configuration workaround for dictionary or dynamic sources, or for recursive type converters, other than limiting input depth before mapping.

Related

• CVE-2026-32933 (GHSA-rvv3-g6hj-g44x)
• GHSA-6vhm-j9h7-f9gh: MaxDepth not enforced through constructor parameters and positional records, fixed in the same releases.