Root + Impact

Description

Under the project’s README, only the Owner is allowed to set and retrieve their secret:

“Owner – Only the owner may set and retrieve their secret.”

However, the on-chain implementation of set_secret lacks any access control. Any signer can call the function, which writes a Vault resource under the caller’s account and emits a SetNewSecret event—creating on-chain noise that appears indistinguishable from an owner action.

This behavior diverges from the documented security model (“Owner-only”) and enables anyone to produce events that look like authoritative secret updates, potentially confusing users, monitoring, and analytics.

Risk

Likelihood: High

• Any externally signed transaction that invokes set_secret will succeed because the function is public entry and performs no authorization checks.

Impact: Low

• The unauthorized call does not overwrite the owner’s secret; it only writes a Vault under the caller’s own account. Core confidentiality/integrity of the owner’s data is not directly compromised.

• The practical impact is event/log pollution and user confusion (e.g., UIs, explorers, or alerting that rely on SetNewSecret may imply the owner updated their secret when they did not).

Recommended Mitigation

Enforce owner-only access and keep the storage target consistent with the documented model. A simple guard using the owner’s address (e.g., a module constant) ensures only the owner’s signer can call this function.