Shardeum Incident Report: Cycle Exploit Postmortem

Introduction

A recent incident on the Shardeum network saw the creation of ~500K SHM as a faulty staking reward. The Shardeum team swiftly identified and resolved the issue, and all of the created SHM was voluntarily returned to the Foundation wallets. This post-mortem offers a detailed analysis of the event and outlines our proactive measures to fortify the network against future occurrences.

What Happened?

On 12th July 2025, our team was notified of a suspiciously high staking reward by a community member via our Discord server. The Shardeum team quickly swarmed on the problem and determined this was the result of a deliberate attack on the Shardeum network. If you are a node operator, you may have noticed changes in the behavior of stakelock over the July 12th weekend. The Shardeum team temporarily increased the stakelock time in an effort to prevent any further malicious activity.

This turned out to not be necessary, but we were taking every precaution to prevent further damage. The attack stemmed from a simple but critical flaw in our validator software – an “off-by-one” error in our certificate validation logic that survived multiple rounds of testing, refactors, and auditing. While the vulnerable code was relatively simple, the attack required to exploit this vulnerability through multiple layers of security checks was sophisticated. The end result of this attack was tricking the Shardeum network into thinking a single node had been active in the network since 2019, resulting in an improper credit of approximately 500K SHM during cycle 111165.

Our investigation confirms this appears to be an isolated incident, and we have found no evidence of further impact across the network’s history. We have already released a mandatory security patch, Validator v1.19.3, which corrects the underlying flaw and implements additional defensive checks.

Technical Root Cause

The Shardeum network operates one “cycle” at a time. Each unique cycle has a “cycle record” that details the state of the L1 at that specific point in time. This includes things like the current cycle number, which validators are active/joining/lost, which archivers are active, the hash of the previous cycle record (called the “cycle marker”), and other things. This information is consensed upon by the network before being added to the chain as a signed “cycle certificate”.

The sharded nature of the network requires multiple candidate cycle certificates to be considered before one is deterministically picked. Each of these candidate cycle certificates is cryptographically verified. That is to say: each candidate cycle certificate should be signed off on by active validators via power-rank consensus in the current cycle attesting to its accuracy. Before any new cycle certificate is even considered, it gets put in an array and every record is validated in this way. Here is the code that implements this critical check:

for (let i = 1; i < certs.length; i++) {
    if (inpMarker !== certs[i].marker) {
        return false
    }
}

TypeScript is a language that starts arrays at 0. If you can get your phony cycle certificate into the 0 element of the array, it gets to skip the marker validation step.

Attack Reconstruction

1. Attacker generated two crafted service queue transactions at cycle 111165 with backdated cycle numbers and extra fields.
2. Reused a valid historical certificate inserted at array index 0.
3. Remaining certificates in the array passed normal validation (loop started at 1), so the recycled cert evaded detection.
4. Consensus scoring selected the attacker’s record; the inflated reward start time flowed into reward accounting.
5. Result: 502,694.51 SHM abnormal reward credit.

Shardeum Response

The Shardeum team’s initial suspicion was an issue with the staking reward mechanism. This prompted us to increase the stakelock time to prevent further reward calculation from occuring while we triaged the issue. As we further investigated and eventually found the issue, we took the following steps to ensure this was the first and only occurrence of this sort of attack:

• Cycle Data Scanner: The primary artifact of this attack was a mismatch between the winning cycle number in the winning record and the actual cycle number. We scanned the entire history of the network for similar artifacts and found none. This can be verified by anyone outside of shardeum using archiver data.
• Archiver Validation Tool: The archivers intake and digest the history of the network. Part of our response was to investigate how the Archiver network handled this malicious cycle certificate that the network said was valid. Our archiver logs show the malicious cycle was detected and the archiver network acted properly in noting the discrepancy and digesting the cycle anyway. This allowed the archiver logs to catch what the validators missed.
• Network Remediation: The Shardeum team deployed a hotfix to the validator software. This hotfix was called 1.19.3 and fixed the array-indexing problem. We have also greatly expanded our network monitoring to look for:
  • Malformed cycle records
  • Malformed cycle certificates
  • Abnormal staking reward amounts
• Reward Accounting Reconciliation: Thankfully, all the SHM received through the exploit was voluntarily returned by the attacker as can be seen via the five transaction hashes below. Since validator rewards are calculated and created upon reward time, the returned SHM will be burned in a transaction to be announced.
  • Transaction 1, Transaction 2, Transaction 3, Transaction 4, Transaction 5

Timeline (UTC)

• 2025-07-12 05:19 hrs => Shardeum Discord user, NoviceCrypto flags abnormal rewards via Discord DM.
• +18 minutes => Internal security triage opens incident ticket; anomaly tagged “reward-outlier-high.”
• Same day => Independent tools spun up: cycle data scanner, archiver data validation tool
• Within 24 hours => Malformed service queue transactions traced to cycle 111165; backdated timestamp observed.
• 24 – 48 hours => Root cause narrowed to certificate validation loop skipping cert[0]; exploit reproduction confirmed.
• 48 hours+ => Hotfix prepared; internal testnet validation passed.
• 2025-07-13 => Patch Validator v1.19.3 published; upgrade instructions announced to the community via official channels including Discord, Telegram and X.

Next Steps

1. Bug Bounty Program: We will be announcing a bug bounty program to encourage responsible disclosure of vulnerabilities to strengthen network security.
2. Community Security Updates: We will soon launch a public security email list to keep developers, node operators, and community members informed of any critical vulnerabilities, patches, or security-related announcements. We encourage all ecosystem participants to subscribe and stay informed.
3. Enhanced Monitoring Setup: We are evaluating the integration of external monitoring and alerting tools (e.g., anomaly detection, on-chain analytics) to improve proactive detection. Implementation will follow based on the technical team’s recommendations.
4. Security Incident Response Playbook: We will formalize and publish an internal Security Incident Response Playbook to streamline detection, triage, communication, and resolution processes during critical events.

Responsible Disclosure and Reporting

Shardeum is a community network and depends on the community for safety and security. If the attacker had reported this critical vulnerability to us rather than exploiting it on the live network, they would have been given our highest tier bounty reward. Therefore, if you identify a potential security issue, you have a few options to get our attention:

• Email security team about bugs confidentially => [email protected]
• Report security bugs confidentially on Github according to our Security Policy
• Report non-security bugs on Github here => https://shm.gg/bug-reporting
• Open a support ticket on Discord
• Do not post exploit details publicly until acknowledged by the Shardeum security team. Eligible issues may qualify for rewards.

FAQ

Does this incident affect regular SHM holders or require any action?

No action is needed. The issue was limited to validator reward accounting and did not impact user balances or transaction data.

What should I know as a validator about this incident? How do I check if my node is patched?

As a validator, it’s important to ensure your node is running the latest patched version. Shardeum team will be monitoring the network for the next 1 to 2 days, after which community nodes will begin rotating into the active validator set. You can check if your validator is updated to the latest version in two ways:

On GUI

The latest version is shown right on the main dashboard under Version Info.

On CLI

Run these commands in your server terminal and look for shardeumVersion in the output. If it matches the latest version, your validator is updated

```bash
cd shardeum
./shell.sh
operator-cli status

Credit and Community Thanks

Huge thanks to the community member NoviceCrypto and others involved who reported and helped monitor the discrepancy quickly. Responsible reporting shortens response time and protects the network.

---