The get_secret function uses @owner in an equality check and in borrow_global````(@owner)
, but @owner
is not defined anywhere. That makes the authorization check invalid and the code either won’t compile or — if modified incorrectly — will allow unauthorized reads of secrets. More importantly, the intended access control (“only the owner can read their secret”) is not implemented correctly
The bug is located in the get_secret view function:
In Move, @ is an operator, not a variable. The syntax @
is a shorthand for writing an address literal.owner
is not a named address. The code uses @owner
as if owner
were a named address defined in the project's configuration. However, there is no indication that a named address called owner
exists. Without this definition, the compiler has no idea what value @owner
should resolve to.
Likelihood:
This is not a runtime issue that might occur under specific conditions; it is a guaranteed failure at the compilation stage.
Impact:
The module is completely unusable. It cannot be compiled or deployed.
Use owner: &signer
so the runtime verifies the caller genuinely controls that account.
Return vector<u8>
if you want binary-safe storage; otherwise return string::String
.
exists<Vault>(addr)
prevents panic when vault doesn't exist and provides a clear abort code.
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.