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.