set_secret
always calls move_to<Vault>(caller, …)
. In Move, move_to
aborts if a Vault
resource already exists under that account. After the first write, all subsequent updates will abort, making rotation or correction of the secret impossible.
No exists<Vault>(addr)
branch.
No borrow_global_mut<Vault>(addr)
path to modify an existing resource.
Likelihood:
After the first successful set_secret
, every subsequent call triggers the existing-resource abort in move_to
.
Normal usage expects multiple updates over time (typos, rotation, new values), so the failure will be routinely hit.
Impact:
Owner cannot rotate or update their secret.
Usability failure and security weakness (rotation is a standard hardening practice).
Forces workarounds (e.g., migrate to a new account), which is impractical.
#[expected_failure] test_set_secret_aborts_on_update
demonstrates the second set_secret
call aborts.
Update in place when the resource exists; otherwise create it.
(Note: acquires Vault
is required for functions that borrow_global(_mut)
or move_from
, but not for move_to
. Add acquires Vault
to set_secret
after this change.)
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.