Fixed validation denial of service through fragment cycles and fragment bombs - #624

Problem

Two documents could take any server down through validation alone:

• query Q { hello } subscription S { ...F } fragment F on Query { ...F } crashed the process with a stack overflow in validateSubscriptionSingleRootField, even with Q selected and no subscription type in the schema.
• A fragment bomb of 20 fragments (821 characters), each spreading the next one twice, took 31.5 seconds in CreateExecutionPlan, because the validation context inlines every fragment spread per path. Fragments spreading each other in a cycle grew factorially in the same way.

Changes

• Size and depth check before validation. measureDocument counts, in linear time and iteratively, the selections that inlining fragment spreads produces over all operations and fragment definitions, and the nesting depth. The count of each fragment is computed once, as in Apollo Server's RecursiveSelectionsLimit. validateDocument rejects documents over DocumentLimitsDefaults.MaxRecursiveSelections (25 000) or MaxNestingDepth (128) before building anything else.
• Error limit. Validation stops after DocumentLimitsDefaults.MaxValidationErrors (100) errors and adds "Too many validation errors, error limit reached. Validation aborted.", as graphql-js does.
• Fragment cycles. The cycle rule uses Tarjan's algorithm (iterative, linear). Spreads of cyclic fragments are no longer inlined by the validation context or the @defer/@stream rules.
• Subscription root field rule. Collects each fragment once per operation, so it terminates on cycles. It also counts the fields selected before a fragment spread, which it used to drop.
• Unused variable rule. Searches each fragment once instead of once per path.
• ValidationResult.collect. Accumulates errors in linear time instead of copying the accumulated list on every step.

The 25 000 default keeps validating and planning a document at the limit under a second. At 100 000 selections, planning alone takes about two seconds.

Behavior changes (in the release notes)

• Documents over the limits are rejected.
• Errors inside the spreads of cyclic fragments are no longer reported; the cycle error is.
• The cycle rule reports each fragment of a cycle once, including fragments with an unknown type condition, and no longer reports fragments that only spread a cycle.

Tests

ValidationDoSTests.fs contains 24 xUnit tests. Stack-sensitive tests run on a 1 MiB thread with a timeout. Some documents are ported from Hot Chocolate's and Apollo Server's tests (MIT, attributed).

• The original crash document, through Executor.CreateExecutionPlan.
• Fragment bombs, an unused fragment bomb, a fragment of 1 000 fields shared by 200 operations, and fragments that all spread each other.
• Hot Chocolate's recursive fragment, traversal bomb and expansion bomb (CVE-2025-32032) and deep fragment expansion documents.
• Apollo's recursive selection threshold documents.
• A 10 000-fragment chain, the nesting limit and the error limit.
• 50 000 errors in linear time and a 200 000-field document.

The full FAKE pipeline passes locally: 788 unit tests (5 skipped, as before) and 108 integration tests.

🤖 Generated with Claude Code