Part 2

Summary

The load function is incorrectly marked as pure while directly interacting with storage using inline assembly. This misclassification breaks Solidity’s security guarantees and can lead to unintended storage access, potentially exposing sensitive data or causing logical errors in contract execution.

Vulnerability Details

The load function, which retrieves a withdrawalRequest from storage, is declared as pure, implying it neither reads nor modifies blockchain state. However, it uses inline assembly to directly access storage by assigning a slot in memory. Solidity’s type system does not enforce pure restrictions within assembly, allowing unintended state interactions.

• pure functions should not read or modify storage, but load does.

• Developers may incorrectly assume load has no storage interaction, leading to security oversights.

• If used in sensitive contexts, this could bypass security assumptions about contract state access.

Calling this function gives the illusion of "safe" execution while interacting with contract state.

Impact - MEDIUM

• Breaks Solidity’s function classification, leading to misleading assumptions.

• Could expose sensitive data if used improperly in access-controlled logic.

• Potential storage access manipulation, increasing risk in upgradeable contracts.

Likelihood Explanation - LOW

• Any contract using load under incorrect assumptions is vulnerable.

• Inline assembly bypasses Solidity’s safety checks, making this issue subtle but impactful.

• No direct exploit, but risk escalates in complex contract interactions.

Tools Used

Recommendations

Change pure to view

This prevents the compiler and developers from assuming load() has no storage interaction.