Normal behavior:
The module secret_vault::vault
stores a Vault
resource under the caller’s account when set_secret(&signer, secret: vector<u8>)
is called. The Vault
struct contains a String secret
field. The get_secret
view function was intended to control who can read this secret.
Specific issue:
On Aptos, all on-chain resources are publicly readable using standard node APIs or CLI commands such as aptos account list --account <address>
. This means that anyone can directly query the Vault
resource of an account and read the secret
field in plaintext — completely bypassing get_secret
and its intended access control.
Likelihood: Certain
Any user can run aptos account list --account <target>
and retrieve all resources, including Vault
.
This is a guaranteed behavior of the Aptos blockchain; all resources are globally readable by design.
Impact: Severe
The secret is exposed to anyone without needing to call get_secret
.
The module’s intended access control is ineffective — private data is irreversibly public.
Any sensitive information (passwords, keys, personal data) stored in the vault is compromised immediately.
Here the command line to set a secret and then query the explorer to retrieve it
Reference: https://aptos.dev/build/cli/trying-things-on-chain/looking-up-account-info\
Design guidance:
On Aptos (and most blockchains), anyone can read any resource; Move’s type system does not provide data confidentiality.
Store only non-reversible commitments (hashes, salted hashes) or encrypted data prepared off-chain.
If privacy is critical, keep sensitive material off-chain and use the blockchain only as a verifier or reference.
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.