State divergence enables unauthorized access
A state divergence bug in Provenance Blockchain's marker module allowed any user to bypass access control checks on non-fixed supply markers. The authorization function accountControlsAllSupply compared a stale stored supply field (always zero for non-fixed markers) against the caller's balance, producing an unconditionally true result when both were zero. This let an attacker grant themselves admin, mint, and withdraw permissions in a single transaction, then mint arbitrary tokens or drain escrowed assets in a second transaction. 82 markers on mainnet were affected, with approximately $500,000 in escrowed nhash at direct risk.
Detection / Hunteropenrouter
What Happened
Researchers found a flaw in the Provenance Blockchain that let anyone take control of digital asset accounts without owning any tokens. The flaw was in a permission check that compared two values that were both stuck at zero, so the check always passed. This affected 82 accounts holding real financial assets on the blockchain, including stablecoins, tokenized mortgages, and grant funds. About $500,000 in escrowed funds was directly at risk. The vulnerability has been fixed in version 1.28.0. Organizations running Provenance Blockchain nodes or holding assets on the chain should upgrade to the fixed version and audit their marker accounts for unauthorized changes.
Key Takeaways
- A bug in Provenance Blockchain's marker module allowed any user to grant themselves admin, mint, and withdraw permissions on non-fixed supply markers without holding any tokens.
- 82 active markers on mainnet were vulnerable, representing live financial assets including tokenized loans, bridged stablecoins, and consortium deposits.
- Approximately $500,000 in escrowed nhash was directly at risk across three Provenance Foundation governance markers.
- Root cause was state desynchronization: the authorization check read a stale supply field (always zero for non-fixed markers) instead of the live bank module supply, causing a 0 == 0 comparison that always evaluated to true.
- Fixed in v1.28.0 (May 1, 2026) by reading live supply from the bank module and adding an explicit zero-guard.
Affected Systems
- Provenance Blockchain versions before 1.28.0
- Cosmos SDK-based chains using a similar marker module pattern with non-fixed supply markers
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Reconnaissance: Attacker queries mainnet via Provenance CLI or REST API to identify non-fixed supply markers with a stored supply of zero
- Privilege Escalation: Attacker submits a MsgAddAccessRequest transaction targeting a vulnerable marker, requesting ACCESS_ADMIN, ACCESS_MINT, and ACCESS_WITHDRAW permissions for their own address
- Authorization Bypass: The accountControlsAllSupply function compares the stale stored supply (0) against the attacker's balance (0), evaluating to true and passing the authorization check
- Exploitation: Attacker submits either a MsgMintRequest to mint new tokens of the marker's denomination or a MsgWithdrawRequest to drain assets held in the marker's escrow balance
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules are provided in the article. The article includes code snippets showing the vulnerable and fixed functions, and references PR #2627 and PR #2734 for the fix.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | None | This is a blockchain smart contract vulnerability. Traditional endpoint detection tools do not have visibility into on-chain transaction logic or marker module state. |
| Network Visibility | Low | Transactions are submitted to the blockchain via REST API or CLI. Network monitoring could observe transaction submissions but cannot inspect the authorization logic or determine whether a transaction exploits the vulnerability. |
| Detection Difficulty | Hard | Detecting exploitation requires correlating on-chain MsgAddAccessRequest transactions against marker supply state. The attacker's transaction looks identical to a legitimate access grant. Defenders would need to identify markers where stored supply diverges from bank module supply and flag any access grants on those markers. |
Required Log Sources
- Provenance Blockchain node logs
- On-chain transaction history for MsgAddAccessRequest messages
- Marker module state queries showing supply field vs bank module supply
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for MsgAddAccessRequest transactions on markers where the stored supply field is zero but the bank module reports a non-zero circulating supply, as these are the markers vulnerable to the bypass. | On-chain transaction logs and marker module state queries | Privilege Escalation | Medium — legitimate access grants on newly created markers before funding could appear similar, but the fix in v1.28.0 blocks these. |
| Consider hunting for MsgWithdrawRequest transactions that withdraw assets from marker escrow balances where the withdrawing address was granted permissions within the same block or shortly before the withdrawal. | On-chain transaction history with block-level timestamps | Exfiltration | Low — rapid permission grant followed by withdrawal is unusual for legitimate operations. |
| Consider hunting for MsgMintRequest transactions where the minting address received ACCESS_MINT permission via a MsgAddAccessRequest from an address that is not the marker's designated manager. | On-chain transaction history correlating access grants with subsequent mint operations | Impact | Low to Medium — legitimate admin transfers could trigger this, but correlation with non-manager grant sources narrows the scope. |
Control Gaps
- Traditional network and endpoint security tools cannot detect or prevent on-chain authorization bypass vulnerabilities.
- Blockchain transaction validation occurs at the consensus layer, which is outside the scope of conventional security monitoring.
- Without on-chain monitoring of marker state divergence, exploitation would go undetected by standard SOC tooling.
Key Behavioral Indicators
- MsgAddAccessRequest transaction submitted by an address that is not the marker's designated manager and does not already hold ACCESS_ADMIN
- Rapid sequence of MsgAddAccessRequest followed by MsgWithdrawRequest or MsgMintRequest from the same address
- Marker accounts where the stored supply field on the marker struct differs from the bank module's live circulating supply
False Positive Assessment
Low — The vulnerability is specific to non-fixed supply markers with a stored supply of zero. Detection based on state divergence between the marker struct and bank module would produce few false positives. However, legitimate access grants on newly created markers before funding could appear similar to exploitation attempts.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. If operating a Provenance Blockchain node, upgrade to v1.28.0 or later to apply the fix.
- Consider auditing all marker accounts on your chain for unauthorized access grants by reviewing historical MsgAddAccessRequest transactions against markers with non-fixed supply.
- If applicable, review escrow balances on affected markers for any unauthorized withdrawals that may have occurred before the fix was deployed.
Infrastructure Hardening
- Consider implementing on-chain monitoring that alerts when the marker struct's stored supply diverges from the bank module's live supply, as this state divergence was the root cause.
- Evaluate whether property-based testing or fuzzing should be integrated into the CI pipeline for Cosmos SDK modules to catch authorization predicate failures before deployment.
- If developing on Cosmos SDK, consider formal specification of access control rules to ensure authorization predicates cannot be satisfied from a default or zero state.
User Protection
- If holding assets on Provenance Blockchain, consider verifying that your markers are running on nodes upgraded to v1.28.0 or later.
- Evaluate whether your marker accounts use fixed or non-fixed supply models, as non-fixed markers were the vulnerable class.
Security Awareness
- Consider incorporating lessons from this vulnerability into developer training: authorization checks that compare two values which can both default to zero are trivially bypassable.
- Where applicable, roll into existing secure development training the principle that authorization predicates must never be satisfiable from an attacker's default state.
