Incorrect Resource Access — Vault Always Borrowed from Deployer

Description

• Normally, in Aptos Move, user-specific resources (like a Vault) are stored under the caller’s address so each user controls their own data.

• The current code incorrectly uses:

• This hard-codes the deployer account (@owner) as the resource owner.

• As a result, every call attempts to read from the deployer’s storage, instead of the caller’s own vault.

• Correct behavior should use the actual signer’s address:

Risk

Likelihood:

• Reason 1: This bug occurs every time a user tries to read their vault, since the function always fetches from @owner.

• Reason 2: It is guaranteed to manifest in multi-user scenarios where accounts other than the deployer interact with the module.

Impact:

• Impact 1: Users cannot read their own secrets — only the deployer’s vault is accessible.

• Impact 2: This centralizes all resource ownership under the deployer, effectively breaking the app’s core functionality and violating decentralization assumptions.

Proof of Concept

Recommended Mitigation

• Always bind global resource access to the caller’s address (signer::address_of(caller)), not the fixed deployer address.

• Add regression tests for multi-user scenarios to ensure users can only access their own resources.