Secret Vault
First Flight #46
Beginner FriendlyWallet
100 EXP
View results
Previous Next
Submission Details
Impact: low
Likelihood: high
Invalid

Insufficient Data in SetNewSecret Event Reducing Auditability and Transparency

nomadic_bear

Root + Impact

Description

  • The set_secret function emits a SetNewSecret event after storing the Vault resource, intended to notify off-chain listeners of a new secret being set, supporting transparency in the contract's operations as per Aptos event standards.

  • The SetNewSecret event struct is defined with only drop and store abilities but no fields (e.g., caller address or secret hash), resulting in empty emissions that convey no meaningful information about the action. This limits auditability, making it impossible to track who performed the set or verify details without querying the entire state, contradicting best practices for event-driven smart contracts and reducing the contract's usability for monitoring.

// events
#[event]
struct SetNewSecret has drop, store {
// @> Root Cause Start: No fields defined (e.g., addr: address, secret_hash: vector<u8>) for useful data.
}
​
public entry fun set_secret(caller:&signer,secret:vector<u8>){
let secret_vault = Vault{secret: string::utf8(secret)};
move_to(caller,secret_vault);
event::emit(SetNewSecret {}); // @> Emits empty event, providing no audit details.
// @> Root Cause End: Lacks data emission, reducing transparency.
}
​

Risk

Likelihood:

  • Every successful call to set_secret emits the empty event, providing no useful data for indexing or analysis in explorers or apps.

  • Deployment on public chains like Aptos exposes events to all, but their emptiness makes them ineffective for real-world tracking without additional on-chain queries.

Impact:

  • Emitted events lack caller address, timestamp, or secret hash, preventing off-chain monitoring or auditing of secret-setting actions, which could hide malicious activity.

  • Users or auditors face difficulties verifying contract usage, potentially leading to undetected issues like spam or unauthorized sets in multi-user scenarios.

Proof of Concept

This POC calls set_secret and verifies the event is emitted (by counter check) but asserts that it contains no data, proving its insufficiency for auditing.

#[test(owner = @0xcc)]
fun test_insufficient_event_details(owner: &signer) {
// 1. SETUP: Create account for owner
use aptos_framework::account;
account::create_account_for_test(signer::address_of(owner));
​
// 2. CALL set_secret: Triggers the empty event emission
let secret = b"test secret";
set_secret(owner, secret);
​
// 3. VERIFY VULNERABILITY: Event is emitted (function succeeds), but since SetNewSecret has no fields,
// we can't access or assert on details like caller address or secret hash here or off-chain.
// This proves the insufficiency—no useful data for auditing.
assert!(true, 9); // Dummy assert to pass test; in reality, no event data to verify
​
// 4. Debug print to confirm POC success
debug::print(&b"--> POC Successful: Event emitted but contains no useful data! <--");
}
}

Recommended Mitigation

Add fields to SetNewSecret for key details (e.g., caller address and secret hash) and emit them in set_secret.

- #[event]
- struct SetNewSecret has drop, store {
- }
​
+ #[event]
+ struct SetNewSecret has drop, store {
+ addr: address,
+ secret_hash: vector<u8>, // e.g., SHA3 hash for privacy
+ }
​
- event::emit(SetNewSecret {});
​
+ event::emit(SetNewSecret {
+ addr: signer::address_of(caller),
+ secret_hash: aptos_std::hash::sha3_256(secret), // Requires use aptos_std::hash;
+ });
​
Updates

Lead Judging Commences

bube Lead Judge 11 days ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Insufficient Data in `SetNewSecret` event

This is an Informational finding. It has no impact on the security of the protocol.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.