Limit XDR nesting depth when decoding contract spec/meta sections by fnando · Pull Request #2668 · stellar/stellar-cli

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

fnando · 2026-08-04T17:10:35Z

What

Decode a contract's contractenvmetav0, contractmetav0, and contractspecv0 sections with an explicit XDR depth limit (SPEC_XDR_DEPTH_LIMIT = 500) instead of Limits::none().

Why

These sections come from attacker-authored contract WASM, and ScSpecTypeDef is a recursive XDR type. Decoding with Limits::none() (depth u32::MAX) lets a deeply-nested type definition recurse until it exhausts the stack and aborts the process. Capping the depth turns that crash into a clean DepthLimitExceeded error. The value 500 matches soroban-env-host's DEFAULT_XDR_RW_LIMITS, so any spec the network would accept still decodes, while deeper input is rejected. Tests cover both a deeply-nested spec that must be rejected and a normally-nested spec that must still decode.

Known limitations

N/A

Copilot

Pull request overview

Limits XDR decoding depth for attacker-controlled contract metadata and specs, preventing stack exhaustion.

Changes:

Adds a depth limit of 500 to relevant XDR decoders.
Adds tests for deeply and normally nested specifications.

…n recursive specs `Spec::arg_value_name` threads a `depth` counter but never checks it. A contract whose spec contains a recursive type — e.g. `struct TreeNode { children: Vec<TreeNode> }`, which the SDK and the network accept — sent the resolver into unbounded recursion, overflowing the stack on every `contract invoke` against the contract, including `-- --help`. Anyone can deploy such a contract, so this crashed the CLI of anyone who tried to interact with it. UDTs are the only types resolved by name, so any cycle must pass through the `ScType::Udt` arm; cap the expansion depth there and render the type's name past the cap. Returning `None` instead would erase the whole value name, since `None` propagates through the `?` in every caller. `example_udts` already bounds example rendering the same way. Complements stellar#2668, which capped XDR decode depth for deeply-nested specs; a cycle through UDT name references never nests deeply in the encoded XDR, so it needs this separate guard. Fixesstellar#2445

Limit nesting depth when reading contract details.
5947081

CopilotAI balanced review requested due to automatic review settings August 4, 2026 17:10

github-project-automationBot added this to DevX Aug 4, 2026

github-project-automationBot moved this to Backlog (Not Ready) in DevX Aug 4, 2026

Copilotstarted reviewing on behalf of fnando August 4, 2026 17:11 View session

CopilotAI reviewed Aug 4, 2026
View reviewed changes

leighmcculloch approved these changes Aug 4, 2026
View reviewed changes

Merge branch 'main' into bound-xdr-decode-depth-contract-spec
1a2714d

fnando merged commit 19c395a into mainAug 4, 2026
229 of 230 checks passed

fnando deleted the bound-xdr-decode-depth-contract-spec branch August 4, 2026 22:21

github-project-automationBot moved this from Backlog (Not Ready) to Done in DevX Aug 4, 2026

Galmanus mentioned this pull request Aug 14, 2026
Cap UDT expansion depth in arg_value_name to prevent stack overflow on recursive specs #2679
Open