SseRex: Practical Symbolic Execution of Solana Smart Contracts

SseRex : Practical Sym b olic Execution of Solana Smart Con tracts T obias Clo osters 1 [ 0009-0008-3682-0197] , P ascal Winkler 1 [ 0009-0002-8324-4993] , Jens-Rene Giesen 1 [ 0009-0004-0685-6237] , Ghassan Karame 2 ⋆ [ 0000-0002-2828-4071] , and Lucas Da vi 1 [ 0000-0002-7322-2777] 1 Univ ersity of Duisburg-Essen, Essen, Germany . {firstname.lastname}@uni-due.de 2 Ruhr Universit y Bo c hum, Boch um, Germany . ghassan@karame.org Abstract. Solana is rapidly gaining traction among smart contract de- v elop ers and users. How ev er, its growing adoption has b een accompanied b y a series of ma jor securit y incidents, which ha ve spurred researc h into automated analysis techniques for Solana smart con tracts. Unfortunately , existing approac hes do not address the unique and complex account mo del of Solana. In this pap er, we prop ose SseRex , the first symbolic execution vulnerabilit y detection approac h for finding Solana-sp ecific bugs suc h as missing owner c hecks, missing signer chec ks, and missing key c hecks, as well as arbitrary cross-program inv o cations. Our ev aluation of 8 , 714 bytecode-only con tracts shows that our approach outp erforms existing approaches and iden tifies p oten tial bugs in 467 differen t contracts. A dditionally , w e analyzed 120 op en-source Solana pro jects and conducted in-depth case studies on four of them. Our findings rev eal that subtle, easily o verlooked issues often serve as the ro ot cause of severe exploits, further highlighting the need for sp ecialized analysis to ols like SseRex . 1 In tro duction The Solana blo ck c hain is gaining p opularit y due to its abilit y to provide smart con tract functionality with high transaction throughput and lo w transaction fees [ 35 , 56 ]. Solana smart con tracts, also called pr o gr ams , are usually written in Rust and compiled to an eBPF-based bytecode [ 19 ]. Unlike the Lin ux kernel’s eBPF, it lacks the con trol-flow verification mec hanism [ 13 ]. This lack of v alidation has led to numerous Solana exploits in recent years [ 12 , 27 , 59 ], resulting in a loss of more than $523 million. The exploited contracts exhibited bugs ranging from logical errors, lik e missing input data v alidation [ 27 , 59 ], to missing signature v erification, as seen in the W ormhole exploit [ 7 ]. Solana programs separate data from logic to emplo y concurrent transaction execution [ 9 , 21 ], requiring the full con text state in every Solana transaction. As this context is created by a p oten tially malicious creator of the transaction, there ⋆ The author was additionally affiliated with NEC Lab oratories Europe at the time of writing. is a significan t risk that such a con text is manipulated. T o mitigate this, the Solana run time pro vides trustw orth y metadata—v alidated a priori—suc h as public keys, accoun t owners, accoun t signatures, and cryptographically deriv ed accounts—so- called program-deriv ed addresses (PDAs). While automated v alidation exists, effectiv e v alidation remains highly dep enden t on the contract’s specifi c goal. As a remedy , the Anc hor [ 1 ] framework employs Rust types and macros to automatically c heck accounts and metadata. Y et, Anchor cannot co ver the full space of attacks; developers m ust still manually p erform signer chec ks and verify data dep endencies such as authority ownership of a given wallet. Recen tly , several approaches hav e b een prop osed to detect vulnerabilities in Solana. VRust [ 15 ] analyzes source co de for sp ecific bug patterns; how ev er, source co de is largely una v ailable for Solana contracts. F urther, VRust suffers from a high false p ositiv e rate, e.g., only one of the 108 rep orted bugs was indeed a missing key chec k. F uzzDelSol [ 44 ] applies fuzzing to a custom Solana runtime to detect bugs during program execution. F uzzing fundamentally prioritizes sp eed and is limited by the high computational ov erhead required to implement effectiv e oracles, and its sensitivity to “magic bytes” in the input—suc h as public keys and t yp e identifiers—whic h are essential for exploring meaningful execution paths . In general, curren t analysis approaches hav e a limited view of the e xecution con text and cannot holistically ev aluate a contract’s co de. F or instance, VRust’s patterns need explicit adaptation to find errors in Anchor programs, whereas F uzzDelSol cannot analyze Anc hor contracts, which currently make up at least 43 % of deplo yed contracts. In this pap er, we introduce SseRex , the first symb olic exe cution fr amework for vulnerability detection in Solana programs. Symbolic execution, b y design, comprehensiv ely captures data flows and program constraints [ 25 , 49 ]. As our approac h demonstrates, it enables precise tracking of all account verifications and their relations, without sacrificing generality , as evidenced by its abilit y to analyze Anc hor con tracts (in contrast to previous w ork [ 15 , 44 ]). SseRex coun teracts path explosion via static pre-analysis to resolv e account deserialization and string formatting. F urther, w e develop hybrid symbolic lengths, which av oid sym b olic p oin ters but allow symbolic data lengths. W e design sp ecialized oracles for Solana- sp ecific issues—missing key , owner, or signer chec ks—that ev aluate whether an execution path leads to unexp ected or unsafe b eha vior. Particularly , they flag critical actions—such as cross-program inv o cations or state-mo difying account writes—o ccurring without prop er v erification of the inv olved entities. W e comprehensively ev aluate SseRex on al l deploy ed Solana contracts, a dataset of 8 , 714 bytecode-only contracts, 120 pro jects with source co de from the Anc hor registry , and previous approaches’ datasets [ 15 , 44 ]. Our results sho w that SseRex significan tly reduces false p ositiv es and discov ers more vulnerabilities than previous work. In particular, the large-scale study identifies 467 vulnerable con tracts. W e p erformed intensiv e manual analysis of a sample of 30 rep orted bugs, and verified 26 as true bugs ( 87 % true positive rate). Finally , we also presen t four detailed case studies to show case the challenges of finding bugs in Solana. 2 , owns seed Program Account Data Account Attacker-generated T ransaction Malicious Data Account Unsigned User Account Malicious Program owns System Program PDA Account Missing Owner Check Arbitrary CPI Missing Signer Check Fig. 1: Malicious attack transactions in Solana and their targets. T o foster researc h on the security of Solana programs, we will release all comp onen ts of SseRex publicly on GitHub. 2 Bac kground Solana uses an accoun t-based model with stateless execution, where accoun ts store program b yteco de or data [ 20 ]. Solana programs receive all data via instructions and cannot access any external state. Programs commonly dispatc h logic based on instruction bytes, as in the Anchor framework [ 1 ]. The runtime pro vides metadata for each accoun t—including owner, signer field, executable flag, and balance in lamp orts (1 bn lamp orts = 1 SOL) [ 48 ]. The signer field indicates that the account signed the transaction [ 22 ]. Programs can in teract via cross-program inv ocation (CPI) [ 46 ] and delegate access using Program Derived A ddresses (PDAs) deterministically derived from program ID and arbitrary seed b ytes [ 47 ]. 2.1 Solana’s Threat Mo del Since the creator of a transaction can freely select input data, programs m ust carefully v alidate inputs b efore p erforming critical actions, e.g., transferring funds, writing data to an accoun t, or p erforming CPI [ 33 ]. As shown in Figure 1, there are three strategies to manipulate the execution context. First, an attack er ma y imp ersonate another user and authorize a transaction due to a missing signer chec k (MSC) [ 3 , 33 , 43 ]. F or example, in Figure 1, the attack er supplies an unsigned user accoun t and authorizes access to the data account of the imp ersonated user, as the program lacks an explicit signer chec k. As illustrated in Listing 1, lines 11–14, the contract verifies the authority k ey but omits an is_signer c heck that confirms priv ate key control for the authority . Without the signer chec k, any one can supply the correct key . Second, attack ers might craft accoun ts containing coun terfeit state. In this case, a missing owner chec k (MOC) can tric k the program into p erforming critical actions [ 3 , 43 ]. Listing 1, lines 7– 9 read data of the vault_account whic h is supplied as an argument to the instruction. Ho wev er, as shown in Figure 1, a program account o wns the data 3 1 pub fn process_instruction(program_id: & Pubkey , accounts: &[ AccountInfo ], ix_data: &[ u8 ],) -> ProgramResult { 2 let vault_account = &accounts.iter_mut().nth(0)?; // vault state [owner check] 3 let authority_account = &accounts.iter_mut().nth(1)?; // admin [signer check] 4 let target_program = &accounts.iter_mut().nth(2)?; // target program [acpi] 5 let cpi_accounts: Vec< AccountInfo > = accounts_iter.cloned().collect(); // cpi args 6 7 // MOC assert_eq!(vault_account.owner, program_id); 8 let data = vault_account.try_borrow_data()?; // trusts unverified account 9 let balance = u64 :: from (&data[0..8].into()); // data from unverified account 10 11 // MSC if !authority_account.is_signer { return Err(...) } 12 let expected_authority = ...; // often from another account 13 if authority_account.key != &expected_authority { return Err(...);} 14 // attacker supplies correct key without needing the private key 15 16 let cpi_ix = solana_program ::instruction::Instruction { 17 program_id: *target_program.key, // unvalidated CPI target 18 accounts: cpi_accounts, // attacker-controlled accounts 19 data: ix_data.to_vec()}; // attacker-controlled CPI data 20 invoke(&cpi_ix, &cpi_accounts)?; // attacker can manipulate program and accounts 21 // ... Listing 1: The contract exhibits multiple vulnerabilities that an attack er can exploit. accoun t. Without v erifying that the data read originates from an accoun t owned b y the program, the program trusts un verified data. Third, improp er use of CPI allo ws malicious programs to gain unauthorized privileges [ 3 , 43 ]. Listing 1 lines 16–20 in vok e a CPI solely on an address given b y the attack er. As the accoun ts given to the CPI are all attac ker-con trolled, it is p ossible to manipulate or even write into those accoun ts and call arbitrary programs. Since programs can delegate privileges to call targets, an attack er can call their own malicious program but with the caller’s privileges. That is, using a malicious arbitrary CPI (ACPI) target, an attack er gains control ov er the program’s PDA accounts. In general, the design of Solana requires dev elop ers to add sev eral sp ecific c hecks ev en for simple use cases, e.g., a program requires an owner chec k once it reads the ID of an authorit y from its storage accoun t. The actual v alidation of the authorit y subsequently needs to chec k the public key and signer flag. This makes errors and missing chec ks very likely . Apart from missing chec ks and A CPI, Solana suffers from other securit y issues that w e omit in our research. Solana programs receive all accounts as un t yp ed serialized bytes. Hence, programs ha v e to scrutinize the exact data structure and type. Accoun t confusion o ccurs when an attac ker sends an account that is assumed to b e the correct type due to common serialized forms but actually is of a different type, leading to unintended b eha vior. Second, integer ov erflows and underflows o ccur when in tegers gro w past their natural bit b oundaries. While Rust mitigates them in debug mo de, the release mo de optimizes ov erflo ws and wrapping behavior. So, paths in b yteco de that result in ov erflo ws may b e pruned by the compiler resulting in many incorrectly detected or missed integer o verflo ws. Additionally , the Solana VM uses o verflo ws explicitly to clear registers at run time. Th us, w e ignore integer ov erflo ws to reasonably reduce false negativ es. Finally , reen trancy-like attac ks reenter the 4 original contract. While Solana hinders Ethereum-like reen trancy , a versatile attac ker could route through multiple contracts to reenter a call. How ever, due to Solana’s CPI depth limit of 4 calls, the pseudo reentrancy will only work once as direct recalls are not allow ed. F urther, reen trancy attacks are only feasible in sp ecific setups where the initial caller controls owner chec ked accounts of the victim as otherwise, writing in to the data of the account is stopp ed by Solana. 2.2 Differences to Ethereum Unlik e Ethereum, where trusted v ariables like msg.sender guaran tee transaction origin, Solana requires explicit signer and o wner chec ks for each account, as programs can receiv e any account via instructions. Third-party accoun ts and CPI targets are selected by index rather than by key , creating risks of accoun t confusion and missing authorization chec ks that can lead to vulnerabilities. Solana forbids the infamous Reen trancy vulnerability by limiting the depth of nested calls to 4 and disallowing direct reentran t calls. While this technically still allo ws v arious Reentrancy attacks, these are mitigated in practice due to data ownership and decoupled con tract logic. 3 Related W ork Prior research has explored smart contract security , yet few approac hes address the unique c hallenges of Solana’s account-based, stateless execution. 3.1 V ulnerability Detection in Ethereum Ongoing smart con tract security research largely targets Ethereum. Static analysis approac hes [ 6 , 8 , 24 , 50 , 53 ] face scalability limits and often miss complex data/con trol-flow vulnerabilities, such as reentrancy [ 10 ]. Dynamic techniques lik e fuzzing [ 38 , 42 , 57 ] are effective for div erse bugs, but face challenges on Solana programs as describ ed in Section 3.2. Sym b olic execution has gained traction for Ethereum due to small contract sizes [ 14 , 23 , 29 , 31 , 32 , 34 , 45 , 52 , 55 ]. T o ols like Man ticore [ 32 ] and h ybrid metho ds, which combine symbolic execution with fuzzing [ 14 ] or large-language mo dels [ 45 ] pro vide comprehensive path exploration. How ever, none of these approac hes transfer to Solana due to its distinct programming mo del and vulnerabilities (see also Section 2.2). Other lines of w ork include run time monitoring [ 37 , 51 ], which requires platform mo difications, and machine-learning-based analysis [ 26 , 40 , 54 ]. These metho ds show promise but rely on large datasets and reliable ground truth, which are curren tly unav ailable for Solana. 3.2 V ulnerability Detection in Solana As Solana’s p opularit y grows, ensuring its security is paramount. Existing to ols lik e VRust [ 15 ] and F uzzDelSol [ 44 ] cannot analyze all programs comprehensively . 5 Sym b olic Execution Engine Sym b olic Preparations Critical A ction Initial Sym b olic A ccoun t Structure Mer ge Deserialization Sym b olize A ccoun t Length Skip string_format Lifting BN IL Solana Blo c k c hain Relo cations Lift sBPF Rep ort V ulnerabilit y Analysis A CPI Chec k Signer Chec ks Owner Chec ks Exit Chec k Sym b olic Exploration Strategies CPI Main Random Exploit Concretize Input Generate Exploit Fig. 2: Architecture of SseRex VRust relies on Rust’s MIR and requires source co de, which is una v ailable for 98 % of deploy ed programs [ 44 ], and raises many false p ositives—only 12 of 160 rep orted issues in eigh t pro jects w ere actual bugs [ 15 ]. Some bug oracles cov er v ery sp ecific cases (e.g., unchec ked Solana Program Library contract IDs), while others rely on small whitelists, raising completeness concerns. F uzzDelSol [ 44 ] integrates fuzzing into Solana’s run time and does not require source co de, but cannot handle complex input structures of Anchor-based con tracts used b y 43 % of deploy ed programs. Solana’s stateless nature mak es fuzzing challenging: all input data—including multiple accoun ts and instruction fields—m ust b e generated precisely to achiev e meaningful cov erage, otherwise, fuzzing risks l o w precision. F uzzDelSol ignores account trustw orthiness in arbitrary CPI and requires extra kno wledge of vulnerable functions for its missing k ey c heck (MKC) oracle [ 44 ]. Recen t efforts apply formal verification to Solana [ 58 ], but they target the underlying eBPF runtime and therefore face an entirely differen t class of vulnerabilities than Solana programs. Andreina et al. combined a developer study with static analysis of Solana b yteco de [ 2 ]. The analysis finds few bugs and only targets arbitrary program inv o cations, while the study shows developers often neglect securit y , highlighting the need for b etter vulnerability detection. The bug detection mec hanism is central to any vulnerabilit y scanner, yet, existing to ols’ bug oracles v astly differ. The bug oracles’ limitations sho w that Solana vulnerabilities are complex and often undecidable, leading to large v ariations in the results. 6 4 Design of SseRex This section presen ts the design of SseRex , the first symbolic execution framew ork for effectively detecting diverse vulnerabilities in Solana contracts. Our main goal is to av oid state explosion while at the same time achieving high co verage. F urther, w e aim to cov er the full set of con tracts, meaning that we can analyze contracts for which source co de is unav ailable and contracts created with Anc hor. As a result, our approach tackles the k ey limitations of previous w ork in this field [ 15 , 44 ], and raises few er false alarms. A t a high level, the functionality of SseRex is separated into four phases, whic h are illustrated in Figure 2: (1) Lifting: W e dump the blo c kc hain contracts’ ELF files containing sBPF bytecode instructions and prepare the files using Binary Ninja, i.e., lift the bytecode to IL and apply relo cations; (2) Symbolic Preparations: W e load the lifted bytecode into the symbolic execution engine and prepare the symbolic state optimized for Solana programs; (3) Sym b olic Exploration: Our symbolic exploration strategies adv ance the sym b olic state to wards critical actions, where attack ers may influence the contract’s state on the block chain; (4) V ulnerabilit y Analysis: Up on reaching p oin ts of critical actions, the symbolic state is ev aluated to assess the vulnerability and a rep ort is generated if missing chec ks are detected. Last but not least, the detailed rep ort facilitates automatic exploit generation, i.e., constructing pro of-of-concept exploits. SseRex can automatically synthesize exploit transactions for reported vulnerabilities. These exploits are v alid for the analyzed path constraints, but they dep end on a compatible initial blo c k chain state. Hence, in practice, exploitabilit y dep ends on whether such a state is reachable on-chain. In future work, one could extend the capabilities of SseRex to generate full precondition-establishing transaction c hains, including interactions with additional con tracts. By fo cusing on exploit generation rather than transaction chains, SseRex isolates and exp oses securit y-critical b eha viors with high precision. 4.1 Initial Sym b olic Accoun t Structure Initially , we prepare the sym b olic state and optimize the computationally exp ensiv e sym b olic p oin ters and string op erations as follows. Deserialization. All Solana contracts deserialize account data from the input, p osing t wo c hallenges for symbolic execution. First, deserialization pro duces man y similar states, e.g., an account’s signer field is either true or false. Just from the three b oolean account fields (signer, writable, executable), 2 3 = 8 states are created. F or example 10 accounts result in (2 3 ) 10 ≈ 10 9 states. W e address this b y merging similar states into a single state during deserialization (Section 5.2), lev eraging common deserialization routines from the Solana framework. Second, the accoun t data structure contains fields of v ariable length, in particular its main data field, whic h causes the deserialized state to con tain v ariably p ositione d buffers. The serialized data stores accounts sequentially , making each account’s start dep end on preceding lengths. The symbolic pointers 7 to the account data would accumulate these lengths, e.g., the p ointer for the tenth accoun t will b e the sum of all nine preceding buffer lengths plus a constant, which w ould exceed the solving capabilities of the symbolic engine. W e av oid v ariably p ositioned buffers by using a constant maxim um size during deserialization and sym b olizing the lengths afterw ard in the deserialized state (cf. Section 5.3). String F ormatting. String op erations are a challenge for symbolic execution, in particular, formatting n umbers. The bytecode to conv ert a symbolic num ber to its decimal string representation produces complex dep endencies b et ween the sym b olic bits and the resulting string. Consequen tly , when this string is used, the solver has to solv e for a string represen tation that satisfies the constrain ts of the sym b olic n umber, which often stalls the execution engine. How ever, Solana programs almost exclusively use string formatting for logging, which do es not affect the outcome of transactions. Therefore, w e search for string format/logging calls and skip these functions. Here, our starting point is the Solana system call used for logging and the string format function of Rust, which is v ery stable and can be identified from its b yteco de. Then, we analyze the calls to these functions and iden tify sequences of format , log , and string deallo cation to ensure that the formatted string is only used for logging. When all chec ks succeed, we skip this call to format during sym b olic execution. 4.2 Exploration for Critical Actions During the main analysis stage, w e use several exploration strategies to prioritize execution paths in the contracts that are more likely to b e security-critical, which decreases the time for bug discov ery . That said, given sufficient time, SseRex will still analyze the complete contract. In general, our exploration strategies prefer uncov ered paths and prune paths that deterministically lead to abort (cf. Section 5.1). F urther, switching strategies and selecting different execution paths preven ts stalling of the sym b olic exploration in complex states. F or SseRex , w e developed three strategies to target critical actions within Solana programs. (1) The CPI exploration only follows paths that are statically determined to reac h the Solana system call for CPI . (2) The Main exploration identifies the core switch tree, whic h Solana programs commonly emplo y to dispatch the desired high-lev el instruction num b er to its bytecode, and leads the symbolic execution into the leav es of this tree. This is where most con tracts implement their logic. (3) The R andom exploration extends cov erage b ey ond common co de paths, selecting paths at random. This is esp ecially useful to guide the symbolic executor through co de sections that the other strategies might not consider interesting. In our ev aluation, w e leverage all explorations and apply eac h strategy uniformly to uncov er diverse bugs. Specifically , we execute each of the three exploration strategies round-robin until a critical action is found, or at most for 10 min . This time limit has prov en sufficient for progress while remaining small enough to a void stalling in undecidable path constraints. F urther, a strategy is skipp ed if its target cannot b e reac hed (e.g., a syscall for CPI). 8 4.3 V ulnerability Analysis The symbolic exploration of SseRex analyzes the control flow to find critical actions that are vulnerable without prop er v alidation. When such a state is reac hed, we test for the conditions described in this section and generate a rep ort if v alidation is missing. SseRex reacts to unin tended program b eha vior that results in security-critical actions, regardless of whether the root cause is a missing v alidation, flaw ed access-con trol logic, incorrect state transitions, or subtle memory-safety violations. The underlying symbolic execution reasons ab out full program b eha vior and can still exp ose traditional low-lev el ro ot causes (e.g., memory corruption effects) when they manifest as vulnerable Solana critical actions. W e b egin by outlining the types of chec ks we assess , follow ed b y criteria for iden tifying when a missing chec k constitutes a vulnerability in the con text of certain critical actions. Signer Chec ks. Ev ery input account may b e a signer, indicated by the signer field. SseRex c hecks which signer flags are required b y the path constraints for eac h critical action. A program function without any signer chec k can b e called b y an yone, whic h is usually not desired (cf. Section 7), so we consider this a missing signer chec k bug. Since full business logic is unav ailable (without source co de), it is not p ossible to precisely identify whic h accounts require signer chec ks. Th us, we consider a single signer chec k on any account to b e sufficien t. Since paths may branch on the signer field without affecting the b ottom line (similar to deserialization, cf. Section 4.1), we double-chec k and re-execute the path to the current state with the same constraints as b efore, but all signer fields set to false. Thus, we can confiden tly ev aluate if any signer fields are chec k ed on the path to the critical action, and if not, report a Missing Signer Che ck (MSC) . Owner and Key Checks. There are m ultiple wa ys to verify the authenticit y of an account. (1) Ev ery account has a unique address/ID, b ound to its key pair. This can b e used to identify an account uniquely . (2) A ccounts hav e an o wner, either a contract, or the system program in the case of user accounts. Solana programs can v erify the o wnership of accounts, in particular, that the con tract itself owns an accoun t. (3) Programs ma y cryptographically deriv e related accounts (PDAs) using one accoun t’s public k ey . Since an attac ker cannot con trol the address of the PD A, this account is also considered trustw orth y . (4) An account that is written to is considered trustw orthy b ecause accounts can only b e mo dified by the owner. As a result, c hanging account data implies an o wner c heck. This also holds if an account write o ccurs after the critical action, as the runtime discards any c hanges when encountering an exception. Consequently , the accoun ts vulnerable to missing owner chec ks are only read. In the first tw o cases, the owner or key field is compared to other data. Since the bytecode do es not do cumen t which v alue a key/o wner field must b e compared with, we consider any chec k on the key/o wner v alid. The fourth case, implicit o wner chec ks, requires the execution of the contract from the entry p oint until 9 the contract gracefully terminates. Hence, we gather account write op erations not only un til we reach a critical action but also contin ue to collect them afterward. Authorit y Chec ks. Con tracts frequently implemen t authority v erification b y combining owner chec ks and signer chec ks, i.e., they v alidate that a truste d accoun t has signe d the transaction. In this con text, w e consider an account trusted if the con tract has v alidated its public key against either a constant v alue or the data stored in an owner-c hec ked accoun t. W e consider this authority chec k sufficien t to protect a transaction from manipulated data. Assessing more complex scenarios, such as multi-authorit y sc hemes, requires additional information ab out the purp ose of each account, which is not av ailable at the bytecode level. 4.4 V ulnerabilities V ulnerabilities arise when critical actions are performed without adequate input v alidation. In the follo wing, w e describ e critical actions and how we v alidate the c hecks to identify vulner able critic al actions . W e fo cus on generic oracles that can b e applied to a wide range of contracts. In particular, we exclude oracles for vulnerabilities that are already fully mitigated by current to olc hains: The safe- math option of Rust generates co de safe from integer o verflo ws, t yp e confusion is a verted by serialization libraries that use t yp e IDs, and the up dated Solana SDK mitigates the missing system account chec k kno wn from the W ormhole incident. Unc heck ed A ccoun t W rites. Modifying p ersisten t data stored on the blo c k chain, i.e., writes to account data, is a critical action. This includes metadata fields lik e the account’s lamp ort balance as well as contract-specific data stored in data accoun ts, such as token balances. W e consider accoun t writes vulnerable if they lack sufficien t o wner/key c hecks (MOC) or are p erformed without a signer c heck (MSC). In addition, the execution path must exit gracefully; otherwise, the run time will rollback and in v alidate the transaction. W e consider any account chec ked for which an y of the follo wing is true: (1) Owner field compared (2) Public k ey compared to constant v alue (3) Data field written or changed (4) PDA derived from public k ey . If there is any used but unchec ked accoun t ( r e ad_ac c ounts \ che cke d_ac c ounts ), and there is no trusted signer ( authority che ck ), w e classify this as a missing o wner chec k vulnerability . Both chec ks ma y also b e missing in com bination (MOC/MSC), whic h grants even more freedom to an attack er. Arbitrary Cross-Program Inv o cation (ACPI). A CPI is a (privileged) delegated call of a Solana program to other contracts. This is a critical action b ecause it allows the target to p erform state mo difications on b ehalf of the caller. SseRex tests each CPI to determine if the target is arbitrary , whether the source of the target address is not owner-c hec ked (MOC), and if there is no signer c heck (MSC). If all these conditions are met, we consider this a vulnerability . If either an MOC or an MSC is present, the CPI may still be vulnerable. How ever, analyzing such cases requires access to the source co de and a deep understanding of the con tract’s business logic. 10 5 Implemen tation Implemen ting SseRex required substantial engineering efforts. First, we added b yteco de lifting ( 400 lo c ) to the reverse-engineering to olkit Binary Ninja [ 4 , 39 ] including precise instruction seman tics and calling conv entions for automated sym b olic execution. Next, we built symbolic execution for Solana atop the SENinja [ 5 ] AMD64 framew ork, requiring 3 klo c , forming the foundation for implemen ting Solana-specific oracles and vulnerabilit y detection ( 4 klo c ). The implemen tation follows the design in Section 4 to search critical actions using custom sym b olic exploration and vulnerabilit y oracles. W e also optimized the symbolic exploration to handle v ariable data lengths (Section 5.3) and string formatting (Section 5.4). F or example, the Neodyme w orkshop examples (Section 6.1) print formatted log strings, which caused a path explosion and never reached the critical actions. F urther, Anchor contracts p erform input-length chec ks; fixed lengths fail the c heck and fully symbolic lengths cause a constrain t explosion. The h ybrid sym b olic length a voids b oth issues (Section 5.3). 5.1 Exploration and Static Path Pruning Exploration. SseRex begins exploration at the entry p oin t, executing instructions until the next sym b olic branch. This is when the subsequen t instruction is ambiguous, e.g., due to a conditional jump that dep ends on a sym b olic v alue, which causes a state fork in to tw o or more program states to execute. Similar states may b e merged (cf. Section 5.2), but generally , the executor m ust select one state to follo w. Effective selection or pruning of states can greatly impro ve symbolic exploration efficiency . SseRex keeps track of cov ered instructions and selects the state to execute as follo ws: (1) Contin ue executing the current state if its instructions are not y et cov ered. (2) Select any uncov ered deferred state. (3) Contin ue executing the current state if it is not at the program exit or in an unsatisfiable condition. (4) Select the most recen tly forked state. (5) Select a state at random. P ath Pruning. The exploration strategies CPI and Main select specific addresses in the con tract executable, which are more likely to contain vulnerabilities. During exploration, the active states are ev aluated to determine whether the targets are still reac hable using the control-flo w and caller graphs. First, a state may dominate and directly reac h a target. Second, a state may b e within a caller of a target, hence, the target is reachable if the call to the target function is reac hable. Third, a parent function in the curren t call stack may b e within the caller graph, hence, the target is reachable if the curren t state can return. Otherwise, a state is rejected and not follow ed by the execution strategy . Notably , this av oids common panic! error handling paths that merely print a message and abort the execution. These paths cannot reach the targets nor return to a function that can. 11 for i in 0..number_of_accounts account[i].is_signer = 1 if read_serialized_signer () == 0 account[i].is_signer = 0 Listing 2: The listing shows the decompiled bytecode of the signer field’s deserialization. 5.2 State Merging after Deserialization Sym b olic state merging combines different states’ path constraints into a single state with memory constrain ts [ 41 ]. Executing Listing 2, symbolic execution creates tw o states, one where is_signer is 1 and the condition w as assumed false, and the other where the if branc h was taken and is_signer is 0. State merging com bines these tw o states into one conditional memory expression, i.e., is_signer is read_serialized_signer() == 0 ? 0 : 1 . This eliminates many redundan t states, e.g., deserializing three b o olean fields for 10 input accounts, reduces the redundancy b y (2 3 ) 10 ≈ 10 9 , significan tly easing main analysis. T o optimize state merging, we identify the p oin t in the control flow where states differ minimally , as with the signer field in the example ab ov e. W e detect the lo op deserializing accounts and merge states after ev ery lo op. Our algorithm analyzes the entry function and its callees for the characteristic comparison ( jeq/jne r*, 0xff ) of the constant first byte in the account structure. Then, it trav erses the control-flo w graph to find the enclosing lo op that iterates all accoun ts. Lastly , we find the exit condition in the basic blo c ks of the lo op, which will b e the p oin t for state merging. Usually , this yields a single deserialization lo op, and otherwise, state merging is disabled. 5.3 Hybrid Sym b olic Data Length The serialized transaction context, containing all account fields, is parsed into Rust ob jects. T o a void symbolic p oin ters—which pro duce complex constraints that ov erload the solver—w e limit account data lengths during deserialization ➀ and release these constraints afterw ard ➁ (Figure 3). Symbolic v ariables represent data lengths, constrained to the maximum supp orted length. Deserialization creates Rust strings with fixed p oin ters, and once all accoun ts are deserialized, the length constrain ts are remov ed to allow v ariable data sizes. 5.4 String F ormat Detection String op erations are a challenge for symbolic execution, in particular, formatting n umbers. The bytecode to con v ert a symbolic num b er to its decimal string represen tation produces complex dep endencies b et ween the symbolic bits and the resulting string. Consequen tly , when this string is used, the solver has to solv e for a string representation that satisfies the constrain ts of the symbolic 12 meta data storage data accoun t 1 meta data storage data accoun t 2 fi xed1 v ariable1 fi xed2 v ariable2 *data_ptr = fixed1 + variable1 + fixed2 data_len = variable2 R ust: accoun t 2 use max use sym b ol 1 2 Fig. 3: The position of the second accoun t is symbolized with the fixed offset of all preceding fixed metadata sizes and each account’s maximum storage data size. n umber, which often stalls the execution engine. How ev er, Solana programs almost exclusively use string formatting for logging, which do es not affect the outcome of transactions. Therefore, w e search for string format/logging calls and skip these functions. Here, our starting point is the Solana system call used for logging and the string format function of Rust, which is v ery stable and can be identified from its b yteco de. Then, we analyze the calls to these functions and iden tify sequences of format , log , and string deallo cation to ensure that the formatted string is only used for logging. When all chec ks succeed, we skip this call to format during sym b olic execution. 6 Ev aluation W e ev aluate the correctness of SseRex using op en-source contracts and prior datasets with kno wn vulnerabilities. 6.1 V ulnerability Oracles Because source code is una v ailable for most public con tracts, large-scale measuremen ts alone are insufficient to v alidate findings against dev elop er inten t. Therefore, we establish a baseline for SseRex ’s oracles by analyzing known vulnerabilities from the Neo dyme workshop and from the datasets of VRust [ 15 ] and F uzzDelSol [ 44 ]. Overall, the ev aluation shows that SseRex detects kno wn true p ositiv es while rep orting substantially fewer false p ositives. Neo dyme. Eac h Neo dyme W orkshop con tract demonstrates one specific vulnerabilit y . Level 0 implements a wallet service that stores user lamp orts in con tract-managed wallets. The contract contains a missing o wner chec k, allowing attac kers to steal funds from other users. During withdraw als, four entities m ust b e v erified: The V ault holds all user assets and is identified from w allet data. When lamp orts decrease, the run time implicitly enforces deduction p ermissions. The Authority o wns the funds and m ust authorize the transaction via a signature c heck. The Pa y out destination receiv es lamp orts and is not further v alidated 13 b ecause pay out is already authorized by the user/o wner. The W allet links these en tities and stores user ID, balance, and v ault ID. How ev er, b ecause w allet o wnership is not v erified, attack ers can construct counterfeit wallets for arbitrary v ault o wners and withdraw all managed funds. SseRex detects that wallet accoun t data is c heck ed, but wallet owner field is not, and rep orts this vulnerabilit y . Lev el 1 demonstrates a missing signer chec k: wallet o wnership is v erified, but the authorit y signature is not, allowing unauthorized withdraw als from existing w allets. SseRex detects this as a (lamp ort) state mo dification without a signer c heck. Lev el 2 and 3 address integer ov erflo ws and type confusion, which are mitigated b y compiler-generated safe math and type identifiers. Consequently , we did not implemen t corresp onding oracles and SseRex did not detect an error. Lev el 4 contains an arbitrary cross-program inv o cation vulnerability: attack ers directly con trol the CPI target and can inject arbitrary logic into the control flo w. SseRex rep orts this when the call target is neither constan t-chec ked nor read from an o wner-chec ked account. VRust. The static source-code analysis to ol VRust reports results for eigh t pro jects. According to the authors, VRust found 30 in teger ov erflo ws (21 FP), 3 key chec k errors (2 FP), and 2 vulnerable CPIs. W e analyze the same pro jects and v ersions with SseRex . First, we consider integer ov erflo ws out of s cope for b yteco de analysis (cf. Sections 3 and 4). VRust’s o wn results indicate that in teger-ov erflo w detection is unreliable; even with source code, the false-positive rate is 70 % ( 92 % b efore manual triage). Second, VRus t reports “one wrong k ey c heck in spl-go vernance” [ 15 ], but the raw rep ort lists 11 missing key c hecks with tw o patterns. In the first case, the owner chec k is done after the p oten tially unsafe read, which is fine in Solana. In the other case, result data is written back to an accoun t, thus it is implicitly o wner-chec k ed by the runtime. Hence, analysis to ols m ust account for both p ost-action chec ks and implicit runtime chec ks. Third, SseRex attests that all system CPIs are correctly v alidated when using the up dated Solana program library . SseRex further rep orts 11 missing signer chec ks and one arbitrary cross- program inv o cation in spl-instruction-padding [ 30 ]. Because that program in tentionally wraps arbitrary inv o cations, this b eha vior is exp ected. Additionally , spl-go vernance [ 30 ] allows unsigned version-n umber up dates. While this is not directly exploitable on its own, it can b e used in downgrade or type-confusion attac ks. The transfer-lamports example in the Solana program library [ 30 ] is in tentionally minimal and contains no chec ks, lea ving it vulnerable and con tract- o wned accounts drainable by attack ers. F uzzDelSol. F uzzDelSol is the state-of-the-art fuzzer for Solana programs. W e analyze the same contracts rep orted b y F uzzDelSol [ 44 ]. As shown in T able 1a, SseRex classifies these contracts as vulnerable and largely matc hes the rep orted bug t yp es. Note that F uzzDelSol’s results are based on a large-scale study of all contracts on the block chain with a timeout of 5 minutes p er con tract. In comparison, SseRex ’s large-scale study iden tified 467 con tracts with missing 14 (a) Comparison of SseRex to F uzzDelSol Type 3od3X. . .nsW 3VtjH. . .q8v 3w57i. . .bPW 4hPkN. . .P5N 4M2fa. . .Stx 6Lanq. . .zqi 7FWEc. . .p7p 9a5di. . .ZP9 9tSWs. . .1yy 9WoLn. . .49B GQ6qc. . .u6K H5rpf. . .PSG ACPI F ✓ ✓ ✓ ✓ ✓ S ✓ ✓ ✓ ✓ ✓ MSC F ✓ ✓ ✓ S ✓ ✓ ✓ ✓ ✓ IO F ✓ ✓ × ✓ ✓ ✓ MOC F S ✓ ✓ ✓ ✓ ✓ ✓ F : F uzzDelSol S : SseRex (b) Anchor Contract T ransparency Program Pro ject Anchor SseRex Manual Analysis quarry-registry ✓ MSC Deterministic data serum-dex × MSC Zeroed account sol-did ✓ MOC Pot. Exploitable spl-token-2022 × MSC F resh account (c) Large-scale Analysis of SseRex Contracts T otal Analyzed 8 , 714 Unchec k ed Account W rite 374 – Missing Owner Check (MOC) 117 – Missing Signer Check (MSC) 241 – MOC/MSC 33 Arbitrary Cross-Program Inv ocation 100 T otal Rep orted 467 T able 1: The tables show the ev aluation results of SseRex . c hecks (cf. T able 1c). Since both analyses are greyb o x techniques, source co de w as unav ailable for manual ground-truth verification. Anc hor Contract T ransparency Program. The Anchor pro ject provided a registry of verified Solana con tracts from April to Nov ember 2022, containing 666 builds from ab out 120 pro jects. 90 % of the pro jects in this registry are Anchor- based. Because Anchor provides strong built-in mitigations, we use this registry as a baseline to assess the false-p ositive rate of SseRex . Only four vulnerabilities w ere rep orted across 120 pro jects (T able 1b). The most notable rep ort concerns the Anc hor-based pro ject sol-did [ 28 ], whic h manages decentralized iden tities in DidAccounts . Solana requires accounts to maintain a minimum rent -exempt balance determined by accoun t size. The function resize in sol-did allows users to gro w or shrink their DidAccounts as needed. Because resizing c hanges required rent , Anchor adjusts balances automatically and pa ys out surplus rent . How ever, SseRex found that the resized DidAccount is not verified, allowing arbitrary resizing. Our manual analysis confirms this observ ation. In sol-did, the secp256k1 signature used for Ethereum authorit y chec ks is constructed solely from the requested DidAccount size. Hence, an attac ker can impersonate an Ethereum authorit y and resize DidAccounts . Enlarging foreign DidAccounts is unattractiv e b ecause the attac ker must pa y additional rent . Anc hor also preven ts zeroing an account by enforcing that accoun t metadata still fits. Y et attack ers can shrink accounts to the minimum 15 size and collect surplus ab o ve the low er rent -exemption threshold, including by racing transactions after a user increases accoun t size. Man ual analysis of the remaining contracts shows that these functions are indeed unchec k ed and correctly rep orted by the oracle, but their practical impact is often constrained b y business logic or deplo yment context. W e discuss suc h c hallenges that arise in automatically examining logic-related vulnerabilities in more detail in Section 7. 6.2 Large-scale Analysis W e analyze 8 , 714 con tracts deplo yed on the Solana blo c kc hain of whic h 3 , 763 ( 43 . 2 % ) are Anc hor-based. T o the b est of our kno wledge, this is the largest vulnerability study in Solana as of no w. W e run SseRex on tw o machines with 240 GB RAM each, pro cessing contracts in groups of 8 parallel jobs. W e limit the time per job to 2 h to k eep the ov erall analysis time feasible. Our results in T able 1c suggest that a notable share, about 5 . 4 % , of the deploy ed con tracts contain at least one vulnerability . Note that T able 1c counts con tracts, so categories ov erlap. Since most of these con tracts are deploy ed anonymously , w e examined a set of 11 contracts in detail p ertaining to 6 op en-source pro jects (cf. Section 7). T o further assess oracle v alidit y , w e manually analyze a random sample of 30 anon ymous contracts. W e exclude contracts with just the deploymen t transaction, so we can use information from the transaction history to infer the use cases of the contracts. Since source co de is una v ailable, we com bine m ultiple signals to infer con tract purp ose: SseRex ’s rep ort, similar op en-source co de, b yteco de insp ection, and historical transaction data. Our results, whic h are describ ed in detail in the artifact, show that for the 30 contracts, we discov ered 87 % true bugs. W e note that several contracts currently do not o wn or manage targetable accoun ts or lamp orts. F or example, some con tracts contain an ACPI vulnerabilit y that allows attack ers to mo dify priv ate accounts. How ever, since the con tracts do not rely on these accounts, they exhibit only b enign b eha vior—ev en in the presence of the bug. Similarly , we observed con tracts with tec hnically v alid draining paths where no relev ant con tract-owned assets were presen t in practice. During this ev aluation, we did not observe false p ositives caused by incorrect oracle predicates. How ever, some rep orts describ e vulnerabilities that are technically present but context-dependent in impact. F or example, a contract ma y exp ose a path that can drain contract-o wned accounts, while the observed deplo yment do es not hold targetable assets. W e further observe 14 missing signer c hecks, i.e., attack ers can imp ersonate legitimate users and p erform restricted actions. 6.3 Co verage Figure 4 shows the co v erage during our large-scale analysis, whic h follows the t ypical progression of binary analysis. Most basic blo c ks are cov ered early , then co verage grows incrementally un til reaching a plateau. Upon termination of the 16 0 1000 2000 3000 4000 5000 6000 7000 Time [s] 0.0 0.2 0.4 0.6 0.8 1.0 Coverage Coverage over time per contract 1 0 2 1 0 3 1 0 4 Contract size Fig. 4: Cov erage ratio ov er time p er contract. Violins summarize the individual runs at eac h p oint in time. Color encodes total contract size in basic blo cks. analysis, SseRex reached a mean cov erage of 33 % ( σ = 18 . 5 % ). F or binary-only analysis, co verage p ercen tages must b e interpreted carefully b ecause bytecode con tains unreachable co de, e.g., unused functions from link ed libraries such as string-formatting routines. F urther, SseRex excludes paths for error handling that ab ort the transaction (cf. Section 5.1). An analysis of 239 con tracts, where SseRex cov ered all relev an t paths, indicates a mean unreachable co de ratio of 84 . 6 % ( σ = 18 . 6 % ). 7 Case Studies and Lessons Learned for Solana V ulnerabilit y Analysis This section presents three case studies and discusses their ro ot causes, securit y impact, and implications for automated analysis. The first t wo case studies presen t previously unkno wn vulnerabilities detected by SseRex . In the third case study , W ormhole, w e discuss limitations of automated oracles. 7.1 Case Study: Censo Solana W allet The Censo [ 11 ] Solana W allet program (formerly Strik e W allet) provides multi- signature wallets through an m -of- n signature scheme. Our analysis rep orts a missing signer c hec k in the Censo Solana W allet program, whose source co de 17 1 pub fn handle (program_id: & Pubkey , accounts: &[ AccountInfo ]) -> ProgramResult { 2 let accounts_iter = & mut accounts. iter (); 3 let wai = next_wallet_account_info (accounts_iter, program_id)?; 4 let cai = next_program_account_info (accounts_iter, program_id)?; 5 let rrai = next_account_info (accounts_iter)?; 6 + assert !(rrai.is_signer); 7 · · · 8 collect_remaining_balance (cai, rrai)?; 9 Ok (()) 10 } Listing 3: The co de shows Censo’s cleanup handler in Rust. While the program p erforms sev eral sanity chec ks, the transaction signer is never chec ked. W e highlight a p ossible fix in green. w as av ailable until recently . The program is written against Solana’s plain Rust SDK, i.e., it do es not use Anc hor. Through source co de analysis, we found t wo vulnerabilities caused by this missing signer chec k. First, wallets may be terminated without authorization, which still pa ys out to the rightful owner. Because the attack er cannot directly profit, this is a griefing attack. Second, the w allet upgrade function allo ws c hanging the recipient of the termination pay out. Com bined, the second bug escalates the griefing attack into a profitable attack. Unauthorized W allet T ermination. When a multi-signature w allet data accoun t is created, one authority pays the ren t and stores its address for reim bursement when the wallet is deleted. Censo wallet’s cleanup handler (cf. Listing 3) requires three accoun ts: (1) the multi-signature wallet, (2) the account to b e deleted, and (3) the rent return account, i.e., the authority’s w allet account. Ideally , only the wallet authorit y should call this handler, but the missing signer c heck allows any one to delete accoun ts. Since the rent return account is v alidated, the attac ker receives no direct profit (griefing attack). Unauthorized Migration. The second vulnerabilit y is an unauthorized migration, shown in Listing 4. When the contract data structure changes, the Censo W allet migration handler up dates all accoun ts. W e disco vered that the migration handler uses the caller’s public key as the rent return account instead of preserving the original v alue. Because it also lacks a signer chec k, an attack er can migrate accounts and insert their o wn address as ren t return accoun t. In com bination with the unauthorized w allet termination bug, this allo ws attack ers to profit from un-migrated wallet accounts. Note that b oth the migration from v ersion 2 to 3 and the migration from version 3 to 4 are affected, as the migration functions do not include an y chec ks. 7.2 Case Study: Elusiv Elusiv [ 17 , 18 ] enables priv ate tok en transfers via zero-kno wledge proofs and m ultiparty computation [ 16 , 36 ]. Elusiv consists of the core proto col, the W arden, and the ZEUS protocol. Users dep osit tokens in the core tok en p o ol, where the 18 1 fn migrations () -> BTreeMap < u32 , MigrationFunction > { 2 BTreeMap :: from ([ 3 (MIGRATION_TEST_VERSION, migration_test as MigrationFunction ), 4 (2, v2_to_v3_add_name_to_signers as MigrationFunction ), 5 (3, v3_to_v4_add_latest_activity_at as MigrationFunction ), 6 ]) 7 } 8 9 pub fn handle (program_id: & Pubkey , accounts: &[ AccountInfo ]) -> ProgramResult { 10 let accounts_iter = & mut accounts. iter (); 11 let sai = next_program_account_info (accounts_iter, program_id)?; 12 let dai = next_program_account_info (accounts_iter, program_id)?; 13 let rrai = next_account_info (accounts_iter)?; 14 + assert !(rrai.is_signer); 15 · · · 16 if let Some (migrator) = migrations (). get (&source_version) { 17 migrator( 18 &sai.data. borrow (), 19 & mut dai.data. borrow_mut (), 20 rrai.key,); 21 Ok (()) 22 · · · } Listing 4: The co de shows Censo’s migration handler in Rust. W e highlight a p ossible fix in green. 1 pub fn compute_base_commitment_hash ( 2 hashing_account: & mut BaseCommitmentHashingAccount , 3 _hash_account_index: u32 ,) -> ProgramResult { 4 guard !(hashing_account. get_is_active (), 5 ElusivError :: ComputationIsNotYetStarted ); 6 compute_base_commitment_hash_partial ( hashing_account) 7 } Listing 5: The code shows Elusiv’s vulnerable function in Rust. While the program c hecks that the hashing account is active, the transaction signer is never chec ked. funds are hidden among other tok ens and track ed via commitments. Receivers withdra w funds from the po ol using a zero-knowledge pro of. The ZEUS protocol v erifies b enign users to blo c k malicious actors, while the W arden pro cesses requests and prev ents flagged users from interacting with the core proto col. Listing 5 shows the vulnerable contract co de. SseRex rep orts a missing signer c heck in Elusiv’s compute_base_commitment_hash . This function initializes hashing for a BaseCommitmentHashingAccount , which is a crucial step in tracking user funds. Because the function does not v erify the signer for the trac k ed funds, an y v alid account suffices; an attac ker who pays the transaction fee can start hashing an y commitment. Normally , con tracts pro cess only user-authorized accounts. Here, the attack er triggers a deterministic calculation on trusted data using their o wn funds, so we classify this bug as lo w risk. Even with high transaction volume, it is unlikely to affect Elusiv’s p erformance or exp ose sensitiv e commitment data. 19 1 // The previous ix must be a secp verification instruction 2 let secp_ix_index = (current_instruction - 1) as u8 ; 3 let secp_ix = solana_program :: sysvar :: instructions :: load_instruction_at ( 4 secp_ix_index as usize , 5 &accs.instruction_acc. try_borrow_mut_data ()?, 6 ). map_err (|_| ProgramError :: InvalidAccountData )?; Listing 6: The listing shows the vulnerability that led to W ormhole accepting an arbitrary secp256k account. A t bytecode level, the oracle correctly flags an unauthorized mo dification of foreign data. Y et, the contract logic renders this bug harmless. This case study demonstrates that ev aluating real user impact still requires a deep understanding of con tract logic. 7.3 Case Study: W ormhole W ormhole is a cross-chain bridge that transfers assets b et ween blo ck c hains such as Solana and Ethereum. In 2022, W ormhole w as exploited through a missing key c heck in load_instruction_at . This allow ed an attack er to supply a counterfeit system account and forge the pa ymen t-signature context, creating Solana tokens without corresp onding paymen ts. Listing 6 shows the vulnerable function. Because contracts for different instructions are indep enden t and stateless, load_instruction_at reads from a sp ecial system account that stores previous instruction data. W ormhole verifies the secp256k signature from prior paymen t transactions and then pro cesses the paymen t. Ho wev er, the contract did not verify that this accoun t was the intended system account, allowing an attack er to provide coun terfeit secp256k instruction data to the vulnerable load_instruction_at call. T o mitigate this vulnerability , W ormhole should ha ve chec ked that the public k ey of the given account matched the exp ected system-account key . This vulnerabilit y is b eyond the scop e of generic oracles. VRust [ 15 ] and F uzzDelSol [ 44 ] implemen t sp ecial oracles tailored to this contract’s vulnerability only . The W ormhole function prop erly v alidates relev an t owner and signer fields except one system-account k ey; therefore, the generic oracles of VRust, F uzzDelSol, and SseRex do not detect this vulnerabilit y . A t b oth b yteco de and source-co de level, a system accoun t is structurally indistinguishable from other accounts. Without explicit key chec k, there is no indicator for automated to ols that a user accoun t might b e unin tended. This is also true at source-co de lev el. The only hin t that a system accoun t is intended can be found in a comment, not in the co de itself. Therefore, generic oracles of automated bytecode or source-co de analysis cannot detect this bug. An analysis that includes comments might b e possi ble now, but also requires at least op en- source con tracts. 20 8 Conclusion SseRex is the first efficient and practical symbolic execution framew ork for Solana programs. Based on a large-scale ev aluation, w e show that SseRex significan tly outp erforms previous approaches. SseRex operates directly on b yteco de con tracts, supp orts complex Anchor-based sp ecifications, and is carefully optimized to reduce false p ositiv es. W e identified 374 missing key chec ks (e.g., o wner and signer c hec ks) and 100 arbitrary CPI bugs. These findings sho w that SseRex is a crucial step to ward enabling developers to deploy secure contracts on a rapidly gro wing blo c kc hain. A ckno wledgemen ts. This work has been partially funded b y the Deutsche F orsc hungsgemeinsc haft (DFG, German Researc h F oundation)—SFB 1119 (CR OSSING) 236615297 within pro ject T1, EXC 2092 (CASA) 39078197—, the Europ ean Union (ER C, CONSEC, No. 101042266, and Horizon 2020 R&I, D YNABIC, No. 101070455). The views and opinions expressed are those of the authors only and do not necessarily reflect those of the Europ ean Union or the Europ ean Research Council Executiv e Agency . Neither the Europ ean Union nor the gran ting authority can b e held resp onsible for them. References [1] Anc hor Developmen t T eam. Anchor – Intr o duction . 2024. url : www . anchor - lang.com . [2] Sébastien Andreina, T obias Clo osters, Lucas Davi, Jens-Rene Giesen, Marco Gutfleisc h, Ghassan Karame, Alena Naiakshina, and Houda Na ji. “ Defying the Odds: Solana’s Unexp ected Resilience in Spite of the S ecurit y Challenges F aced b y Developers”. In: Pro c e e dings of the 2024 on ACM SIGSA C Conferenc e on Computer and Communic ations Se curity . CCS ’24. Salt Lak e Cit y , UT, USA: Asso ciation for Computing Machinery, 2024, pp. 4226–4240. isbn : 9798400706363. doi : 10 . 1145 / 3658644 . 3670333 . url : https : / / doi . org / 10 . 1145 / 3658644 . 3670333 . [3] AuditFirst. “ Common V ulnerabilities in Solana Programs (Smart Contracts)”. In: Me dium (2022). Accessed: 2024-07-10. url : medium . com / @auditfirst . io / common - vulnerabilities - in - solana - programs - smart - contracts - bd59af774022 . [4] Binary Ninja . binary.ninja/ . V ector 35 Inc. [5] Da vide Borzacchiello. SENinja: Symb olic exe cution plugin for Binary Ninja . https://github.com/borzacchiello/seninja . [6] Priy ank a Bose, Dipanjan Das, Y anju Chen, Y u F eng, Christopher Kruegel, and Gio v anni Vigna. “ SAILFISH: V etting Smart Contract State-Inconsistency Bugs in Seconds”. In: 2022 IEEE Symp osium on Se curity and Privacy (SP) . 2022, pp. 161–178. doi : 10.1109/SP46214.2022.9833721 . [7] Julien Bouteloup. W ormhole – REKT . Accessed: 2024-07-09. 2022. url : rekt . news/wormhole- rekt/ . 21 [8] Lexi Brent, Anton Jurisevic, Michael K ong, Eric Liu, F rancois Gauthier, Vincent Gramoli, Ralph Holz, and Bernhard Scholz. V andal: A Sc alable Se curity Analysis F r amework for Smart Contr acts . 2018. arXiv: 1809.03981 . [9] Irvin Steve Cardenas and Y ugart Song. L ol lip op: SVM R ol lups on Solana . 2024. arXiv: 2405.08882 [cs.DC] . url : . [10] Ethan Cecchetti, Siqiu Y ao, Haobin Ni, and Andrew C. Myers. “ Comp ositional Securit y for Reentran t Applications”. In: 2021 IEEE Symp osium on Security and Privacy (S&P) . 2021, pp. 1249–1267. doi : 10.1109/SP40001.2021.00084 . [11] Censo . web . archive . org / web / 20230701182015 / https : / / www . censo . co/ . A ccessed: 2024-06-11, arc hived on 2023-07-01. 2023. [12] CertiK. 2022 Solana Exploits Overview . Accessed: 2024-04-25. 2022. url : www . certik.com/resources/blog/2022- solana- exploits- overview . [13] The kernel developmen t communit y. eBPF verifier . Accessed: 2024-07-10. url : docs.kernel.org/bpf/verifier.html . [14] Consen ys. Mythril: Se curity analysis to ol for EVM byte c o de. Supp orts smart c ontr acts built for Ether eum, He der a, Quorum, V e chain, R o otsto ck, T r on and other EVM-c omp atible blo ckchains. 2024. url : github.com/ConsenSys/mythril . [15] Siw ei Cui, Gang Zhao, Yifei Gao, Tien T avu, and Jeff Huang. “ VRust: Automated V ulnerability Detection for Solana Smart Contracts”. In: Pr o c e e dings of the 2022 ACM SIGSAC Confer enc e on Computer and Communic ations Se curity . 2022. [16] Eiger. Elusiv: Bringing Privacy T o Solana . A ccessed: 2024-07-04. 2023. url : eiger.co/blog/elusiv- bringing- privacy- to- solana . [17] Elusiv . elusiv.io/ . Accessed: 2024-06-11. 2023. [18] Elusiv Priv acy. elusiv-privacy/elusiv: Elusiv Solana pro gr am libr ary . github.com/ elusiv- privacy/elusiv . Accessed: 2024-06-11. 2023. [19] Solana F oundation. Pr o gr ams – Solana . Accessed: 2024-07-10. 2024. url : solana. com/docs/core/programs . [20] Solana F oundation. Solana A c c ount Mo del . A ccessed: 2024-07-02. 2024. url : solana.com/de/docs/core/accounts . [21] Solana F oundation. Solana A c c ount Mo del – Solana . A ccessed: 2024-07-10. 2024. url : solana.com/de/docs/core/accounts . [22] Solana F oundation. T r ansactions and Instructions . A ccessed: 2024-07-02. 2024. url : solana.com/de/docs/core/transactions . [23] Jo el F rank, Cornelius Aschermann, and Thorsten Holz. “ ETHBMC: A Bounded Mo del Check er for Smart Contracts”. In: USENIX Se curity Symp osium, USENIX Se curity 2020 . 2020. [24] Neville Grech, Lexi Brent, Bernhard Scholz, and Y annis Smaragdakis. “ Gigahorse: thorough, declarative decompilation of smart contracts”. In: IEEE/A CM International Confer enc e on Softwar e Engine ering (ICSE) . 2019. [25] Jingxuan He, Mislav Balunović, No dar Ambroladze, Petar T sank ov, and Martin V echev. “ Learning to F uzz from Symbolic Execution with Application to Smart Con tracts”. In: Pr o c e e dings of the 2019 ACM SIGSAC Confer enc e on Computer and Communic ations Se curity . CCS ’19. London, United Kingdom: Asso ciation for Computing Machinery, 2019, pp. 531–548. isbn : 9781450367479. doi : 10 . 1145/3319535.3363230 . url : https://doi.org/10.1145/3319535.3363230 . 22 [26] T eng Hu, Xiaolei Liu, Ting Chen, Xiaosong Zhang, Xiaoming Huang, W eina Niu, Jiazhong Lu, Kun Zhou, and Y uan Liu. “ T ransaction-based classification and detection approach for Ethereum smart contract”. In: Information Pr o c essing & Management 58.2 (2021), p. 102462. issn : 0306-4573. doi : https : / / doi . org/ 10.1016/j.ipm.2020.102462 . url : https://www.sciencedirect.com/science/ article/pii/S0306457320309547 . [27] Louis Husney. Mango Markets Madness: A Case Study On The Mango Markets Exploit . Accessed: 2024-07-09. 2023. url : infotrend . com / mango - markets - madness- a- case- study- on- the- mango- markets- exploit/ . [28] Iden tity .com. identity-c om/sol-did: Sp e cific ation for the did:sol metho d . github. com/identity- com/sol- did . 2023. [29] Johannes Krupp and Christian Rossow. “ teEther: Gna wing at Ethereum to Automatically Exploit Smart Con tracts”. In: USENIX Se curity Symp osium (USENIX Se curity 2018) . 2018. [30] Solana Labs. solana-labs/solana-pr o gr am-libr ary: Solana Pro gr am Libr ary . github. com/solana- labs/solana- program- library . Accessed: 2024-06-11. 2023. [31] Loi Luu, Duc-Hiep Chu, Hrishi Olick el, Prateek Saxena, and A quinas Hobor. “ Making Smart Contracts Smarter”. In: Pr o c e e dings of the 2016 ACM SIGSAC Confer enc e on Computer and Communic ations Se curity . CCS ’16. Vienna, Austria: Asso ciation for Computing Machinery, 2016, pp. 254–269. isbn : 9781450341394. doi : 10 . 1145 / 2976749 . 2978309 . url : https : / / doi . org / 10 . 1145 / 2976749 . 2978309 . [32] Mark Mossb erg, F elip e Manzano, Eric Hennenfent, Alex Gro ce, Gustav o Grieco, Josselin F eist, T ren t Brunson, and Artem Dinaburg. “ Manticore: A User-F riendly Sym b olic Execution F ramew ork for Binaries and Smart Con tracts”. In: 2019 34th IEEE/ACM International Conferenc e on Automate d Software Engine ering (ASE) . 2019, pp. 1186–1189. doi : 10.1109/ASE.2019.00133 . [33] Neo dyme. Solana Smart Contracts: Common Pitfal ls and How to Avoid Them . Neo dyme Blog. Accessed: 2024-07-10. 2024. url : neodyme.io/en/blog/solana_ common_pitfalls/ . [34] An ton P ermenev, Dimitar Dimitro v, P etar T sank ov, Dana Drachsler-Cohen, and Martin V echev. “ V erx: Safety v erification of smart contracts”. In: IEEE Symp osium on Se curity and Privacy (S&P) . 2020. [35] Giusepp e Antonio Pierro and Rob erto T onelli. “ Can Solana b e the Solution to the Blo c kc hain Scalability Problem?” In: 2022 IEEE International Confer enc e on Softwar e A nalysis, Evolution and R e engine ering (SANER) . 2022, pp. 1219–1226. doi : 10.1109/SANER53432.2022.00144 . [36] Quikno de. How to Enable T oken Privacy on Solana with Zer o-Know le dge Pr o ofs fr om Elusiv . Accessed: 2024-07-04. 2024. url : quicknode.com /guides/ solana- development/3rd- party- integrations/privacy- with- elusiv . [37] Mic hael Ro dler, W enting Li, Ghassan Karame, and Lucas Davi. “ Sereum: Pro- tecting Existing Smart Con tracts Against Re-Entrancy Attac ks”. In: Pr o c e edings of the Network and Distribute d System Se curity Symp osium (NDSS) . 2019. [38] Mic hael Rodler, Da vid Paaßen, W enting Li, Luk as Bernhard, Thorsten Holz, Ghassan Karame, and Lucas Davi. “ EFCF: High Performance Smart Contract F uzzing for Exploit Generation”. In: 2023 IEEE 8th Eur op e an Symp osium on Se curity and Privacy (Eur oS&P) . 2023, pp. 449–471. doi : 10.1109/EuroSP57164. 2023.00034 . 23 [39] Otter Security. otter-se c/bn-ebpf-solana . github . com / otter - sec / bn - ebpf - solana . [40] Christian Sendner, Haoyu Chen, Hamed F ereido oni, Luk as P etzi, Johannes K önig, Julian Stang, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, and F arinaz K oushanfar. “ Smarter Contracts: Detecting V ulnerabilities in Smart Contracts with Deep T ransfer Learning”. In: Pr o c e e dings of the Network and Distribute d System Se curity Symp osium (NDSS) . NDSS Symposium. 2023. [41] Y an Shoshitaishvili, Ruoyu W ang, Christopher Salls, Nick Stephens, Mario Polino, Audrey Dutcher, John Grosen, Siji F eng, Christophe Hauser, Christopher Kruegel, and Giov anni Vigna. “ SoK: (State of ) The Art of W ar: Offensive T ec hniques in Binary Analysis”. In: IEEE Symp osium on Se curity and Privacy . 2016. [42] Chaofan Shou, Shangyin T an, and Koushik Sen. “ ItyF uzz: Snapshot-Based F uzzer for Smart Contract”. In: Pr o c e e dings of the 32nd ACM SIGSOFT International Symp osium on Softwar e T esting and Analysis . ISST A 2023. Seattle, W A, USA: Asso ciation for Computing Machinery, 2023, pp. 322–333. isbn : 9798400702211. doi : 10 . 1145 / 3597926 . 3598059 . url : https : / / doi . org / 10 . 1145 / 3597926 . 3598059 . [43] Slo wMist. Solana Smart Contr act Se curity Best Pr actic es . GitHub rep ository. A ccessed: 2024-07-10. 2024. url : github . com / slowmist / solana - smart - contract- security- best- practices . [44] Sv en Smolk a, Jens-Rene Giesen, Pascal Winkler, Oussama Draissi, Lucas Davi, Ghassan Karame, and Klaus Pohl. “ F uzz on the Beach: F uzzing Solana Smart Con tracts”. In: Pr o c. of the ACM Confer enc e on Computer and Communic ations Se curity (CCS) . K op enhagen, Denmark, Nov. 2023. [45] Sun b eom So, Seong joon Hong, and Hakjo o Oh. “ SmarT est: Effectively Hunting V ulnerable T ransaction Sequen ces in Smart Contracts through Language Mo del- Guided Sym b olic Execution”. In: 30th USENIX Se curity Symp osium (USENIX Se curity 21) . USENIX Asso ciation, Aug. 2021, pp. 1361–1378. isbn : 978-1- 939133-24-3. url : https : / / www . usenix . org / conference / usenixsecurity21 / presentation/so . [46] Solana F oundation. Cr oss Pr o gr am Invo c ation (CPI) . Solana Do cumen tation. A ccessed: 2024-07-10. 2024. url : solana.com/de/docs/core/cpi . [47] Solana F oundation. Pr o gr am Derive d A ddr ess (PDA) . Solana Do cumen tation. A ccessed: 2024-07-10. 2024. url : solana.com/de/docs/core/pda . [48] Solana F oundation. T erminolo gy - L amport . Solana Do cumen tation. Accessed: 2024-07-10. 2024. url : solana.com/de/docs/terminology#lamport . [49] Ting Su, Zhoulai F u, Geguang Pu, Jifeng He, and Zhendong Su. “ Combining Sym b olic Execution and Mo del Chec king for Data Flow T esting”. In: 2015 IEEE/ACM 37th IEEE International Confer enc e on Softwar e Engineering . V ol. 1. 2015, pp. 654–665. doi : 10.1109/ICSE.2015.81 . [50] Sergei Tikhomirov, Ek aterina V oskresensk ay a, Iv an Iv anitskiy, Ramil T akhaviev, Evgen y Marchenk o, and Y aroslav Alexandrov. “ SmartCheck: static analysis of ethereum smart con tracts”. In: Pr o c e e dings of the 1st International W orkshop on Emer ging T rends in Softwar e Engine ering for Blo ckchain . WETSEB ’18. Gothen burg, Sweden: Asso ciation for Computing Machinery, 2018, pp. 9–16. isbn : 9781450357265. doi : 10 . 1145 / 3194113 . 3194115 . url : https : / / doi . org / 10 . 1145/3194113.3194115 . 24 [51] Christof F erreira T orres, Mathis Baden, Rob ert Norvill, and Hugo Jonker. “ ÆGIS: Smart Shielding of Smart Contracts”. In: Pr o c e e dings of the A CM SIGSA C Confer enc e on Computer and Communic ations Se curity, CCS 2019 . 2019. doi : 10.1145/3319535.3363263 . [52] Christof F erreira T orres, Julian Sch ütte, et al. “ Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts”. In: 34th A nnual Computer Se curity Applic ations Confer enc e (ACSA C18) . 2018. [53] P etar T sanko v, Andrei Dan, Dana Drac hsler-Cohen, Arth ur Gerv ais, Florian Buenzli, and Martin V echev. “ Securify: Practical security analysis of smart con tracts”. In: Pro c e e dings of the ACM SIGSAC Confer enc e on Computer and Communic ations Security . 2018. [54] Yin W u, Xiaofei Xie, Chen yang P eng, Dijun Liu, Hao W u, Ming F an, Ting Liu, and Haijun W ang. “ AdvSCanner: Generating Adv ersarial Smart Contracts to Exploit Reen trancy V ulnerabilities Using LLM and Static Analysis”. In: Pr o c e e dings of the 39th IEEE/A CM International Confer enc e on Automate d Softwar e Engine ering . ASE ’24. Sacramento, CA, USA: Asso ciation for Computing Machinery, 2024, pp. 1019–1031. isbn : 9798400712487. doi : 10 . 1145 / 3691620 . 3695482 . url : https://doi.org/10.1145/3691620.3695482 . [55] Yinxing Xue, Mingliang Ma, Y un Lin, Y ulei Sui, Jiaming Y e, and Tiany ong Peng. “ Cross-contract static analysis for detecting practical reentrancy vulnerabilities in smart con tracts”. In: Pr o c e e dings of the 35th IEEE/ACM International Confer enc e on Automate d Software Engine ering . ASE ’20. Virtual Even t, Australia: Asso ciation for Computing Machinery, 2021, pp. 1029–1040. isbn : 9781450367684. doi : 10 . 1145 / 3324884 . 3416553 . url : https : / / doi . org / 10 . 1145 / 3324884 . 3416553 . [56] Anatoly Y ako venk o. Solana: A new ar chite ctur e for a high per formanc e blo ckchain . Whitepap er. Solana, 2018. url : https://solana.com/solana- whitepaper.pdf . [57] Mingxi Y e, Xingwei Lin, Y uhong Nan, Jia jing W u, and Zibin Zheng. “ Midas: Mining Profitable Exploits in On-Chain Smart Contracts via F eedback-Driv en F uzzing and Differential Analysis”. In: Pr o c e e dings of the 33r d ACM SIGSOFT International Symp osium on Softwar e T esting and A nalysis . ISST A 2024. Vienna, Austria: Association for Computing Machinery, 2024, pp. 794–805. isbn : 9798400706127. doi : 10 . 1145 / 3650212 . 3680321 . url : https : / / doi . org / 10.1145/3650212.3680321 . [58] Shenghao Y uan, Zh uoruo Zhang, Jiayi Lu, David Sanan, Rui Chang, and Y ongwang Zhao. “ A Complete F ormal Semantics of eBPF Instruction Set Arc hitecture for Solana”. In: Pro c. A CM Pr o gr am. L ang. 9.OOPSLA1 (Apr. 2025). doi : 10.1145/3720414 . url : https://doi.org/10.1145/3720414 . [59] Aleksandra Y udina. 2022 Solana Hacks Explaine d: Cashio . Accessed: 2024-07-09. 2023. url : ackee.xyz/blog/2022- solana- hacks- explained- cashio/ . 25