# \[CRITICAL\] Unlimited Token Minting via Weaver Session Replay

**URL:** https://ghostforum.org/t/critical-unlimited-token-minting-via-weaver-session-replay/100
**Category:** Remediation in Progress
**Tags:** weaver-pallet
**Created:** [October 2, 2026, 11:16am UTC](https://ghostforum.org/t/critical-unlimited-token-minting-via-weaver-session-replay/100 "2026-10-02T11:16:48Z")
**Posts on this page:** 1
**Showing post:** 5

<div class="post-metadata">

### Author: ![VoidDragon](https://ghostforum.org/user_avatar/ghostforum.org/voiddragon/32/16_2.png) [@VoidDragon](https://ghostforum.org/u/VoidDragon)
#### Post date: [October 5, 2026, 3:48pm UTC](https://ghostforum.org/t/critical-unlimited-token-minting-via-weaver-session-replay/100/5 "2026-10-05T15:48:48Z")

</div>

First of all, thank you for continuing this thread!

The fix you’re proposing will block any historical claims - that is, `pull_thread`s down the road - which is not the expected behavior. For example, the last entry at position 2047 will be written, and then a new session will be spawned instantly on the smart contract side. At any point in time, whenever validators get to the root, they’ll bump `CurrentWeavingSession`, and that last record will become unclaimable.

Also, I don’t see the `poc_replay_v3` you’re referring to - if possible, could you paste it here? Just to make sure we’re both on the same page.

Actually, I believe the core issue here is that `WeavingStates` is not cleared on a successful update of the Merkle tree. So what I think you’re getting is:

1. Do some number of honest `weave_weft` calls.
2. Run `on_initialize` - it will create a `TapestryDraft` [here](https://git.ghostchain.io/ghostchain/ghost-node/src/commit/0162da4604d9931c16d12a0cec40dd85951368c5/pallets/weaver/src/lib.rs#L565).
3. On another `on_initialize`, it will fall into the [first branch here](https://git.ghostchain.io/ghostchain/ghost-node/src/commit/0162da4604d9931c16d12a0cec40dd85951368c5/pallets/weaver/src/lib.rs#L494) and store the hash into `LoomState`.
4. Then, I assume your test is not doing new `weave_weft` calls and instead runs `on_initialize` multiple times right away.
5. Because the `WeavingStates` is not cleared or updated, it will re-apply the sort of cached value into a new session.

Can you confirm I’m on the right track with my understanding of what you’re reporting? The issue is that a previously cached `WeavingStates` value - not cleaned up - automatically falls into the `LoomState` of a new session thus doing duplication of hash for the next session. Please correct me if I’m wrong.

---

_[View the full topic](https://ghostforum.org/t/critical-unlimited-token-minting-via-weaver-session-replay/100)._