Decide how to handle AutoMapper: 14.x is permanently vulnerable (CVE-2026-32933), 15.x+ is no longer MIT (RPL-1.5 / commercial)

[turbobobbytraykov]

Summary — a decision is needed, not a code fix

Infragistics.QueryBuilder.Executor ships under MIT with a direct, public dependency on AutoMapper. We are currently pinned to 15.1.3 (merged in #22).

We are boxed in between two mutually exclusive constraints:

• Staying on 14.x is not safe. AutoMapper 14.0.0 is inside the affected range of a High / CVSS 7.5 advisory, and no 14.x patch was ever released. There is no "safe 14.x" to fall back to.
• Moving to 15.x (or 16.x) is not MIT. From 15.0.0 onwards AutoMapper is dual-licensed RPL-1.5 (a reciprocal / source-disclosure licence) OR a paid commercial licence from Lucky Penny Software. It is no longer MIT and will not become MIT again.

Because we vendor this package to customers, the licence obligation does not stop with us — it propagates to every consumer who installs Infragistics.QueryBuilder.Executor. This needs a product + legal decision, which is why this is filed as a task rather than fixed directly.

---

1. Why we depend on AutoMapper in the first place

AutoMapper is not incidental here — it is the mechanism that lets a caller run a Query Builder query against EF Core entities and get DTOs back instead of entities.

Where	What it does
QueryExecutor.cs	filteredQuery.ProjectTo<TTarget>(mapper.ConfigurationProvider).Select(projectionExpression) — server-side entity→DTO projection for the "specific ReturnFields" path
QueryExecutor.cs	(IQueryable<object>)filteredQuery.ProjectTo<TTarget>(mapper.ConfigurationProvider) — same, for the "return everything" path
Services/QueryBuilderService.cs	QueryBuilderService<TMyDbContext, TResults>(TMyDbContext db, IMapper mapper, ILogger<...>? logger) — IMapper is a constructor dependency resolved from the consumer's DI container

Specifically we use AutoMapper.QueryableExtensions.ProjectTo<T>(), which translates the mapping configuration into a LINQ Select expression that EF Core turns into SQL. That is the value we're getting: only the projected columns are fetched, rather than materialising full entities and mapping in memory. We also touch AutoMapper.Internal.

Important constraint for any replacement: IMapper is part of our public API surface:

public static object[] Run<TSource, TTarget>(this IQueryable<TSource> source, Query? query, IMapper? mapper = null)

So AutoMapper is not an internal implementation detail we can silently swap — removing or replacing it is a binary- and source-breaking change for consumers, and needs a SemVer major.

---

2. What was wrong with 14.0, and why "just stay on 14.x" is not an option

Advisory	GHSA-rvv3-g6hj-g44x
CVE	CVE-2026-32933
Severity	High — CVSS 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Weakness	CWE-674 (Uncontrolled Recursion)
Affected	< 15.1.1 and >= 16.0.0, < 16.1.1
Patched	15.1.1 and 16.1.1

< 15.1.1 includes the entire 14.x line. The maintainer backported the fix to 15.1.x and 16.1.x only; there is no 14.x release containing the fix, and 14.x is out of support. Any 14.x pin is therefore permanently exposed with no upgrade path inside the major.

What the bug is: when mapping cyclic or self-referential object graphs, AutoMapper recursed without a default depth cap. A sufficiently nested graph (~25,000+ levels) exhausts the thread stack and raises StackOverflowException, which cannot be caught on modern .NET — so the whole process terminates, not just the request. The fix in 15.1.1+ introduces a default MaxDepth of 64.

Relevance to us: QueryExecutor maps whatever entity graph the consumer's DbContext exposes, driven by a Query object that in most deployments originates from an HTTP request (App Builder / Query Builder UI). Consumers whose entity model contains self-referential navigation properties are plausibly in the attack path. This is a real risk for us to be shipping, not a theoretical one.

Confirmed twice, independently:

• GitHub Advisory Database (linked above).
• appmod-cve-assessment (GitHub Security Advisories API) run against our dependency set — AutoMapper@14.0.0 → 1 High finding, recommended fix "Upgrade AutoMapper to 15.1.1 or later / 16.1.1 or later". Re-run against the current set (AutoMapper@15.1.3 + all transitives) → no known CVEs.

So the upgrade in #22 was correct on security grounds. It was raised by Dependabot on 2026-07-14 and merged on 2026-09-01 (commit 24d4ba0); the PR body carries the GHSA-rvv3-g6hj-g44x release note.

---

3. The licence changed at 15.0.0 — and it is not coming back

AutoMapper was MIT through 14.x. Ownership moved to Lucky Penny Software (Jimmy Bogard), and from 15.0.0 the package is dual-licensed:

Your license to Lucky Penny Software source code and/or binaries is governed by the Reciprocal Public License 1.5 (RPL1.5) license as described here: https://opensource.org/license/rpl-1-5/

If you do not wish to release the source of software you build using Lucky Penny Software source code and/or binaries under the terms above, you may use Lucky Penny Software source code and/or binaries under the License Agreement described here: https://luckypennysoftware.com/license

— verbatim from the licence file shipped inside the package we consume: https://www.nuget.org/packages/AutoMapper/15.1.3/License

This is not a 15.x-only situation — 16.x carries the same terms. There is no newer version that restores MIT.

Our own release evidence already records this. The SPDX 2.2 SBOM attached to release 1.0.2-prerelease.37 contains:

{
  "name": "AutoMapper",
  "versionInfo": "15.1.3",
  "licenseConcluded": "RPL-1.5 AND LicenseRef-scancode-unknown-license-reference",
  "externalRefs": [{ "referenceLocator": "pkg:nuget/AutoMapper@15.1.3" }]
}

Every other dependency in that SBOM resolves to MIT. AutoMapper is the sole outlier. (For comparison, the SBOM for 1.0.2-prerelease.29, which still had AutoMapper 14.0.0, recorded no such reciprocal licence.)

---

4. Why this matters for a package we vendor under MIT

1. The obligation propagates to our customers. Anyone who installs Infragistics.QueryBuilder.Executor transitively acquires AutoMapper 15.1.3 and must independently either qualify for the free Community tier or hold a commercial licence. We would be handing customers a licensing obligation that our own MIT LICENSE does not disclose.

2. RPL-1.5 is strongly reciprocal. Unlike MIT/Apache-2.0, it carries source-disclosure obligations that extend to deployed/hosted works. Many enterprise legal teams have RPL on a deny-list. Customers evaluating us against a supply-chain readiness bar are likely to flag it.

3. The Community (free) tier has hard eligibility limits (per https://automapper.io/):

   • Companies/individuals with < $5,000,000 USD annual gross revenue, or registered non-profits with a < $5,000,000 USD annual budget.
   • The entity must never have received more than $10,000,000 USD in outside capital (PE/VC).
   • Government or quasi-government agencies do not qualify at all.

   Infragistics itself is very likely above these thresholds, so our own internal use of AutoMapper 15.x plausibly already requires a paid licence — independently of what we ship. Commercial tiers are listed at $50/mo (1–10 devs), $150/mo (11–50 devs), $400/mo (unlimited).

4. There is runtime licence-key enforcement. 15.x/16.x accept a licence key via cfg.LicenseKey (and, from 16.2.0, an environment-variable fallback), and emit licence messages at runtime. That behaviour surfacing inside a customer's application, originating from an Infragistics package, is a support and perception problem on its own.

5. We currently document none of this. ReadMe.md does not mention AutoMapper at all, and the nuspec declares PackageLicenseExpression = MIT with no third-party notices.

---

5. Links for the decision

Security

• Advisory: GHSA-rvv3-g6hj-g44x
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-32933
• Maintainer advisory: GHSA-rvv3-g6hj-g44x
• Fix releases: v15.1.1 · v16.1.1

Licensing

• Licence text shipped in the package we consume: https://www.nuget.org/packages/AutoMapper/15.1.3/License
• RPL-1.5 full text (OSI): https://opensource.org/license/rpl-1-5/
• Lucky Penny commercial licence agreement: https://luckypennysoftware.com/license
• Licensing FAQ (incl. how developers are counted, consultancy/agency rules, key enforcement): https://luckypennysoftware.com/faq
• Pricing + Community-tier eligibility footnote: https://automapper.io/
• Upstream repo (note the org move from AutoMapper/AutoMapper to LuckyPennySoftware/AutoMapper): https://github.com/LuckyPennySoftware/AutoMapper

---

6. Options

#	Option	Security	Licence	Cost
A	Stay on 15.1.3, buy a commercial licence	✅ Patched	⚠️ Resolves our use. Does not resolve the obligation we push onto customers — a per-entity licence is not sublicensable to them.	Subscription; still needs a customer-facing disclosure
B	Stay on 15.1.3 (or move to 16.1.1+), disclose and accept RPL-1.5	✅ Patched	⚠️ Requires updating ReadMe.md, adding THIRD-PARTY-NOTICES, and telling customers they must self-qualify. Conflicts with an "OSI-approved, non-copyleft dependencies" bar.	Low effort, high customer friction
C	Remove AutoMapper — make IMapper optional/absent	✅ N/A	✅ Back to a fully permissive graph	Breaking change (public API), SemVer major
D	Replace with a permissively-licensed mapper (e.g. Mapperly, Apache-2.0, source-generated)	✅ N/A	✅ Permissive	Breaking change + ProjectTo behaviour must be re-proven against EF Core (server-side projection is the whole point)
E	Pin back to 14.x	❌ Permanently vulnerable, no patch exists	✅ MIT	Not viable — listed only to record that it was considered

Note on C/D: the code already supports mapper == null — BuildQuery falls back to BuildProjectionExpression<TSource, TTarget> / filteredQuery.Cast<object>() when no mapper is supplied. So a mapper-free path already exists and works; the question is whether we are willing to drop or replace the ProjectTo path that customers may already depend on.

---

7. Proposed next steps

• Legal/product review of RPL-1.5 for (a) Infragistics' own use and (b) what we oblige customers to accept. This issue is a factual brief, not legal advice.
• Confirm whether Infragistics qualifies for the Community tier (almost certainly not, given the $5M revenue / $10M capital thresholds).
• Pick an option above and record the rationale on this issue.
• Interim, regardless of the option chosen: disclose the dependency and its licence in ReadMe.md, and ship a THIRD-PARTY-NOTICES file in the nupkg. Today we ship an MIT package whose largest third-party licence obligation is invisible to the consumer.
• Prevent a repeat. .github/dependabot.yml in this repo declares only the github-actions ecosystem — the nuget group update that produced Bump the nuget group with 1 update #22 did not come from this file, so the NuGet update policy is not version-controlled or reviewable here. Consider adding an explicit nuget block with a cooldown and a review gate, so a major bump that changes a dependency's licence cannot land without an informed decision.

---

Evidence appendix

Version history in this repo

• 1436f3f (2025-05-28) — AutoMapper 14.0.0 introduced
• 24d4ba0 / Bump the nuget group with 1 update #22 (opened 2026-07-14, merged 2026-09-01) — 14.0.0 → 15.1.3, Dependabot, dependency-type: direct:production

CVE tool output for the pre-#22 state

CVE-2026-32933 | high | Infragistics.QueryBuilder.Executor.csproj:35
  Affected: AutoMapper@14.0.0
  Recommended fix: Upgrade AutoMapper to 16.1.1 or later / 15.1.1 or later

CVE tool output for the current state — AutoMapper@15.1.3, Microsoft.EntityFrameworkCore@9.0.4, Swashbuckle.AspNetCore.SwaggerGen@8.1.1, Microsoft.IdentityModel.Tokens@8.14.0, Microsoft.IdentityModel.JsonWebTokens@8.14.0, Microsoft.OpenApi@1.6.23, System.Diagnostics.DiagnosticSource@9.0.4 → No known CVE vulnerabilities found.

ClearlyDefined's scan of the 15.1.3 package records LICENSE.md as RPL-1.5 AND LicenseRef-scancode-unknown-license-reference, while the stale lib/**/AutoMapper.xml doc files still carry the historical MIT / "Copyright (c) 2014-2018 Axel Heer" attribution — which is why a naive scanner may still report MIT for this package. The binding licence is the one in LICENSE.md.