Root + Impact

Description

• Normally, the vault owner should be able to rotate or update their secret multiple times to maintain security best practices and accommodate changing requirements.

• The current implementation uses move_to directly, which aborts if a Vault resource already exists at the account address. This prevents any subsequent secret updates after the initial storage, creating a permanent lockout situation where the owner cannot modify, rotate, or correct their secret once it's been set.

Risk

Likelihood:

• This occurs immediately after the first successful secret storage operation when the owner attempts any subsequent update.

• Every call to set_secret after the initial one will abort due to the existing resource constraint in Move's resource model.

Impact:

• Owner cannot rotate, update, or replace their secret, violating security best practices for credential management.

• Permanent denial of service for secret management functionality after first use.

• System becomes unusable for real-world secret storage requirements where periodic rotation is essential.

Proof of Concept

Recommended Mitigation

Check if a Vault resource already exists and update it in-place using borrow_global_mut, otherwise create a new one with move_to:

Ths enables safe secret rotation and prevents permanent lockout after the initial secret storage.