Memory regression in HotChocolate 15.1.14+ and 16.x after CVE-2026-40324 parser fix - cache controls don't prevent leak

[bn-lroumiantseva]

Product

Hot Chocolate

Version

15.1.14+ and 16.x

Link to minimal reproduction

Cannot provide - issue occurs in proprietary enterprise application under sustained load. Extensive version comparison testing (6 different HC versions) and evidence provided below.

Steps to reproduce

1. Deploy ASP.NET Core 10.0 GraphQL API with HotChocolate 15.1.14+ or 16.x
2. Configure GraphQL server with:
   • Projections, Filtering, Sorting enabled
   • RegisterDbContextFactory for EF Core integration
   • In HC 16: Set OperationDocumentCacheSize=25, PreparedOperationCacheSize=16
3. Execute GraphQL queries at sustained rate (~68 queries/minute)
4. Monitor memory usage over 20+ minutes

Note: Issue is LOAD-DEPENDENT. Does not manifest in low-traffic environments.

• Dev with HC 16.0.11 (low load): Stable at 225-230 MiB ✅
• QA with HC 16.0.11 (68 queries/min): Grows to 575-588 MiB ❌
• QA with HC 15.1.14/15/16 (68 queries/min): Grows to 432-539 MiB ❌
• Production with HC 15.1.10 (1,201 queries/min - 34x higher): Stable at 280 MiB ✅

The leak appears only in versions 15.1.14+ and only under sustained query load.

What is expected?

Memory should remain stable similar to HotChocolate 15.1.10 behavior observed in QA:

• QA environment with HC 15.1.10: ~300-330 MiB stable over 11 hours

For context: Production runs HC 15.1.10 at 1,201 queries/min (34x higher than QA's
68 queries/min), indicating the version handles high load well, though we don't have
production memory metrics to share.

Cache size controls in HC 16 should bound memory growth from query plan caching.

What is actually happening?

Memory grows continuously and never stabilizes in versions 15.1.14+ and 16.x:

QA Environment (68 queries/min, 20 minutes):

• HC 15.1.10: 300-330 MiB stable ✅
• HC 15.1.14: 500+ MiB growing ❌
• HC 15.1.15: 528-539 MiB growing ❌
• HC 15.1.16: 432-491 MiB growing ❌
• HC 16.0.11 (cache 100/50): 575-588 MiB growing ❌
• HC 16.0.11 (cache 25/16 minimum): 463-488 MiB @ 5min, still growing ❌

Even with minimum allowed cache sizes (PreparedOperationCacheSize=16,
OperationDocumentCacheSize=25), memory leak persists. This proves cache
controls don't prevent the issue.

Graph shows continuous upward trajectory - never plateaus.

Relevant log output

Additional context

Root Cause Hypothesis:
The MaxAllowedRecursionDepth tracking added in CVE-2026-40324 fix (v15.1.14)
appears to accumulate memory overhead outside of cache configuration.
The leak:

• Manifests under sustained query load (not in low-traffic scenarios)
• Is NOT bounded by OperationDocumentCacheSize or PreparedOperationCacheSize
• Accumulates proportionally to query execution rate
• Requires ~2x memory limits compared to 15.1.10

We have another service using HC 15.1.16 and doesn't have leak:
It's stable at 256-363 MiB. Differences:

• Different query patterns/complexity
• Lower execution rate
• Suggests leak is query-pattern or load-pattern specific

Impact:
Cannot upgrade from 15.1.10 to patch CVE-2026-40324 (Critical, CVSS 9.1)
without additional memory allocation (not sure even how much: it seems doubling is not enough).
Need either:

1. Fix for memory regression in 15.1.14+/16.x
2. Guidance on additional configuration to mitigate
3. Confirmation this is expected and memory limits should be 2x/...

Configuration:
.AddGraphQLServer()
.AddMutationType()
.RegisterDbContextFactory()
.AddProjections()
.AddFiltering()
.AddSorting()
.ModifyRequestOptions(opt => opt.ExecutionTimeout = TimeSpan.FromSeconds(30))
.ModifyOptions(options => {
options.OperationDocumentCacheSize = 25;
options.PreparedOperationCacheSize = 16;
});

Framework: .NET 10.0
Packages: HotChocolate.AspNetCore, HotChocolate.Data.EntityFramework, HotChocolate.Types

[tobias-tengler]

Hey :) Thanks for the report.

Is the memory you're monitoring the process RSS or the .NET managed heap size? Did you capture it via dotnet-counters?

I've audited the commits between 15.1.10 and 15.1.14 and I wasn't able to find anything that could obviously be leaking. The CVE fix in particular just adds two int fields to a ref struct parser and resets per parse, so it can't accumulate.

It would be helpful if you could verify that it's actually the heap size that is growing and take/analyze snapshots while its growing.

[bn-lroumiantseva]

Hi Tobias, Thank you for prompt response. Analysis with dotnet gcdump has identified the root cause - this is NOT a HotChocolate issue. The memory growth is from JsonSchema.Net 9.2.0 (used in Kafka schema validation) accumulating parsed schema objects: - Json.Schema.KeywordData: 51 MiB → 161 MiB (+110 MiB) - Json.Schema.JsonSchemaNode: 58 MiB → 182 MiB (+124 MiB) 234 MiB of 245 MiB growth is JsonSchema objects. Apologies for the false alarm. The correlation with HotChocolate 16 upgrade was coincidental (we also upgraded EF Core and common-helpers-library at the same time). Please close the issue. From: Tobias Tengler ***@***.***> Sent: June 1, 2026 4:17 PM To: ChilliCream/graphql-platform ***@***.***> Cc: Lilia Roumiantseva ***@***.***>; Author ***@***.***> Subject: [EXTERNAL] Re: [ChilliCream/graphql-platform] Memory regression in HotChocolate 15.1.14+ and 16.x after CVE-2026-40324 parser fix - cache controls don't prevent leak (Issue #9814) [Image removed by sender.]tobias-tengler left a comment (ChilliCream/graphql-platform#9814)<#9814 (comment)> Hey :) Thanks for the report. Is the memory you're monitoring the process RSS or the .NET managed heap size? Did you capture it via dotnet-counters? I've audited the commits between 15.10.0 and 15.14 and I wasn't able to find anything that could obviously be leaking. The CVE fix in particular just adds two int fields to a ref struct parser and resets per parse, so it can't accumulate. It would be helpful if you could verify that it's actually the heap size that is growing and take/analyze snapshots while its growing. — Reply to this email directly, view it on GitHub<#9814?email_source=notifications&email_token=A5UGWPU2IPUQPDY7MACI5JT45XQETA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZGYYTINJXGU4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4596145758>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A5UGWPVL3PGJ7AJDLWJ7B2D45XQETAVCNFSM6AAAAACZWAUTDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKOJWGE2DKNZVHA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/A5UGWPUSF2SSIY4EIDYMRBL45XQETA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZGYYTINJXGU4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android<https://github.com/notifications/mobile/android/A5UGWPUF6P5LUNPCZ4Z3DND45XQETA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJZGYYTINJXGU4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***> Cover the blind spots in your cybersecurity. Check out Barracuda Managed XDR <https://www.barracuda.com/products/managed-xdr?utm_medium=signature&utm_source=signature&utm_campaign=xdr_sign&utm_content=cover-the-blind-spots+> DISCLAIMER: This e-mail and any attachments to it contain confidential and proprietary material of Barracuda, its affiliates or agents, and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.