Full Report
Replay is a cross-chain bridge on Solana. The original design had simple relayers, but the newer version introduces more smart contracts for managing funds. The idea is to transfer funds on one chain and receive the funds on another by order fulfillment via LPs. To initiate a transfer, users must create a transfer on the source chain. On the destination chain, a TransferRequest is signed by a privileged off-chain entity known as the allocator, which releases the funds to the user. To perform signature validation, the native ed25519 program is used and instruction introspection is performed. The program first reads the index of the current instruction and then fetches the previous instruction to perform validation of the signature. The native program contains a lot of information for the data being verified and offsets for exactly what data is being checked. When performing the validation on the instruction itself, it checks that the program is correct and that the signature count is one. The arbitrary offsets and indexes are a powerful feature of the Solana Ed25519 program. The offsets for validation are hardcoded into the relay bridge program, though. In practice, this means that we can specify the proper public key at the hardcoded offset, but then perform the validation at a different offset! By doing this, data can be signed with a different key but still be viewed as valid. The bridge didn't have very much funds at risk. Additionally, since this is a solver protocol and not an actual bridge, only in-flight funds were in the bridge at the time. Another great find by Felix in a major footgun for the Solana ecosystem.
Analysis Summary
# Vulnerability: Bypassing Ed25519 Signature Verification via Hardcoded Offset Manipulation
## CVE Details
- CVE ID: Not explicitly provided in the source material. (Likely assigned privately or pending disclosure based on context.)
- CVSS Score: Not explicitly provided in the source material.
- CWE: CWE-840: Improper Restriction of Access to Indirectly Referenced Data (Related to incorrect reliance on hardcoded instruction offsets).
## Affected Systems
- Products: Replay (Cross-chain bridge on Solana, specifically the newer version utilizing depository contracts).
- Versions: Prior to the implemented patch by the Relay team.
- Configurations: Solana programs utilizing the native ed25519 program and performing instruction introspection with hardcoded offsets for signature verification without proper validation of those offsets.
## Vulnerability Description
The Relay smart contract on Solana used instruction introspection on the preceding instruction (the ed25519 verification instruction) to validate the `TransferRequest` signature provided by the `allocator`. The vulnerability arises because the Relay program hardcoded the *offsets* (e.g., `signature_offset`, `public_key_offset`, `message_data_offset`) used to parse signature components from the attacker-controlled instruction data, relying on the structure expected by the native ed25519 program.
Crucially, while the Solana native ed25519 program allows specifying instruction indices for where to find the signature, public key, and message data, the Relay program did not validate that the offsets pointed to the *correct* locations relative to the input data being verified, only that the instruction index was correct. An attacker could supply a valid signature signed by an arbitrary key, but manipulate the hardcoded instruction offsets such that when the native program performed the verification lookup, it used the attacker's public key (at an arbitrary, controlled offset) instead of the trusted allocator's public key when running the verification check (`pubkey.verify(signature, message)`). If data was arranged correctly, the signature validation would pass, allowing the attacker to forge an allocator signature and drain in-flight funds.
## Exploitation
- Status: The vulnerability was privately disclosed and quickly patched; the article implies exploitation was prevented before funds were lost. (Implied status: **Not exploited / PoC available** as the flaw is clearly demonstrable.)
- Complexity: Medium (Requires deep understanding of Solana instruction layout, instruction sysvar introspection, and the ed25519 program's internal data layout/offsets).
- Attack Vector: Network (Via crafting malicious transaction instructions).
## Impact
- Confidentiality: No direct impact described.
- Integrity: **High**. Successful exploitation would allow an attacker to forge signatures from the privileged `allocator`, leading to unauthorized fund disbursement (double-spending in-flight funds).
- Availability: Low to Medium. Only in-flight funds, being part of a solver protocol, were at risk, not total protocol settlement funds.
## Remediation
### Patches
- The Relay team implemented a swift patch to the affected contracts. (Specific version numbers are not provided, but the fix involved securing the offset validation.) This likely involved ensuring that the instruction data offsets used for signature/pubkey retrieval are properly constrained or validated against expected structures *before* calling the native verification program.
### Workarounds
- No specific workarounds were detailed, as the issue was fixed at the smart contract level. The context implies that users were protected shortly after disclosure.
## Detection
- Indicators of Compromise: Any transaction attempting to finalize a `TransferRequest` using an unauthorized signature that somehow bypasses instruction index checks but uses offsets that appear valid to the hardcoded Relay logic.
- Detection methods and tools: Auditing the instruction introspection logic in Solana programs to ensure that *all* fields read from the signed instruction data (especially offsets and indices) are rigorously validated against expected values or limits, rather than solely relying on the instruction index referencing the correct instruction.
## References
- Vendor advisories: Relay team patched the issue quickly following a private report.
- Relevant links - defanged:
- hxxps://blog.asymmetric.re/wrong-offset-bypassing-signature-verification-in-relay/