The get_secret
function should gracefully handle cases where no vault exists for the requested address, providing clear error messages and meaningful feedback to users about why the operation failed.
The get_secret
function calls borrow_global<Vault>(@owner)
without first checking if the resource exists, causing uncontrolled aborts with cryptic error messages when no vault has been created. This results in poor user experience where users receive technical error codes instead of clear feedback about the system state.
Likelihood:
Any call to get_secret
before set_secret
triggers the error
New users will encounter this immediately upon trying to read non-existent data
The calling order determines success/failure unpredictably
No mechanism exists to check vault existence before calling
Impact:
Poor user experience: Users receive cryptic technical error messages
Unpredictable behavior: Function success depends on hidden state and calling order
Development friction: Developers cannot easily handle the "no data" case
Support burden: Users need help interpreting technical error codes
API inconsistency: No way to distinguish between different failure scenarios
The following tests demonstrate the missing existence checks vulnerability:
There is no security impact on the protocol, therefore this is an Informational finding. Also, it is a user mistake, if the user calls `get_secret` without first calling `set_secret`.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.