CVE-2026-26267
Stellar Rs-Soroban-Sdk ≤ 22.0.10
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-26267 is a high-severity Always-Incorrect Control Flow Implementation (CWE-670) vulnerability in Stellar Rs-Soroban-Sdk. Its CVSS base score is 7.5 (High).
Operationally, ranked at the 24th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-26267 is a vulnerability in the soroban-sdk, a Rust SDK for Soroban contracts, specifically affecting the `#[contractimpl]` macro in versions prior to 22.0.10, 23.5.2, and 25.1.1 of soroban-sdk-macros. The macro incorrectly generates code that invokes functions using `MyContract::func()` syntax even when processing trait implementations. If an inherent `impl MyContract` block defines functions with the same names as those in an `impl Trait for MyContract` block marked with `#[contractimpl]`, the generated Wasm-exported entry points call the inherent functions instead of the trait versions, bypassing any security checks present only in the trait functions, such as caller authorization verification.
The vulnerability can be exploited by anyone interacting with the affected smart contract through its public interface, requiring no privileges (AV:N/AC:L/PR:N). Attackers achieve high integrity impact (CVSS 7.5) by triggering the public entry point, which silently resolves to the unprotected inherent function, enabling unauthorized actions that the trait implementation would otherwise prevent.
Patches are available in soroban-sdk-macros versions 22.0.10, 23.5.2, and 25.1.1, which modify the generated code to use `<Type as Trait>::func()` syntax, ensuring correct resolution to the trait function regardless of inherent implementations. Users must upgrade to these versions and recompile their contracts. As a workaround, developers can avoid naming conflicts by renaming or removing inherent functions that match trait function names. Details are provided in the GitHub security advisory GHSA-4chv-4c6w-w254 and related pull requests.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-7975
Vulnerability Data
soroban-sdk is a Rust SDK for Soroban contracts. Prior to versions 22.0.10, 23.5.2, and 25.1.1, the `#[contractimpl]` macro contains a bug in how it wires up function calls. `#[contractimpl]` generates code that uses `MyContract::value()` style calls even when it's processing…
more
the trait version. This means if an inherent function is also defined with the same name, the inherent function gets called instead of the trait function. This means the Wasm-exported entry point silently calls the wrong function when two conditions are met simultaneously: First, an `impl Trait for MyContract` block is defined with one or more functions, with `#[contractimpl]` applied. Second, an `impl MyContract` block is defined with one or more identically named functions, without `#[contractimpl]` applied. If the trait version contains important security checks, such as verifying the caller is authorized, that the inherent version does not, those checks are bypassed. Anyone interacting with the contract through its public interface will call the wrong function. The problem is patched in `soroban-sdk-macros` versions 22.0.10, 23.5.2, and 25.1.1. The fix changes the generated call from `<Type>::func()` to `<Type as Trait>::func()` when processing trait implementations, ensuring Rust resolves to the trait associated function regardless of whether an inherent function with the same name exists. Users should upgrade to `soroban-sdk-macros` 22.0.10, 23.5.2, or 25.1.1 and recompile their contracts. If upgrading is not immediately possible, contract developers can avoid the issue by ensuring that no inherent associated function on the contract type shares a name with any function in the trait implementation. Renaming or removing the conflicting inherent function eliminates the ambiguity and causes the macro-generated code to correctly resolve to the trait function.
- CWE(s)
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V9.2.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation at post-design stages directly exercises control-flow paths and reveals mismatches between implemented and intended behavior.
Requiring a documented development process and supporting tools reduces the chance that incorrect control-flow logic is introduced in the first place.
Flaw identification and remediation processes can locate and correct control-flow errors once they manifest as incorrect runtime behavior.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly prevent incorrect control-flow implementations via reviews, testing, and static analysis.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance can detect paths that deviate from intended logic.
Secure development lifecycle processes can catch incorrect control-flow logic during design and code review.
Secure coding standards and reviews directly target flawed control-flow implementations.
Change-management gates may prevent deployment of flawed logic but do not address the coding defect itself.