Crestal Network — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Crestal Network, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Crestal Network reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Signature replay, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Signature replay findings disclosed against Crestal Network
- Access control findings disclosed against Crestal Network
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Crestal Network: Signature Replay attack possible on `updateWorkerDeploymentConfigWithSig()` in Blueprintcore.sol which leads to users lose the funds
Crestal Network's BlueprintCore.sol exposes updateWorkerDeploymentConfigWithSig(), which verifies a signer against a digest built by getRequestDeploymentDigest. Because that digest omits any per-user nonce, timestamp, or chain ID, a validly signed configuration-update message can be replayed indefinitely. Each replay re-runs updateWorkerDeploymentConfigCommon and its payWithERC20 fee logic, repeatedly draining the deployment owner's approved token balance to the fee collection wallet, with the protocol lacking any refund path. The protocol team fixed the issue by binding a per-user nonce into the signed digest and incrementing it after each call.
Crestal Network: Lack of access control in `setWorkerPublicKey()` in BlueprintCore.sol which results users to lose funds
Crestal Network's BlueprintCore.sol exposes setWorkerPublicKey() as an unrestricted public function, allowing any address to register itself in the workersPublicKey mapping and workerAddressesMp list. Because user-facing functions select a worker address for private deployments and the encrypted proposal payload is tied to that worker's public key, a malicious actor can register a fake key and have users' deployment payments and encrypted data routed to them. The protocol has no refund path for tokens already forwarded to feeCollectionWalletAddress, so affected users lose their funds. The issue was acknowledged and fixed via a commit in crestal-omni-contracts.
Crestal Network: Anyone who is approving `BlueprintV5` contract to spend ERC20 can get drained because `Payment::payWithERC20`
Crestal's BlueprintV5 agent-creation flow relies on an internal `Payment::payWithERC20` helper to move the payment token from a user to the protocol. The function is declared `public` and accepts arbitrary `fromAddress`, `toAddress` and `amount`, with only trivial address/amount sanity checks and no caller authorization. Consequently any user who has granted an ERC20 allowance to BlueprintV5 (for example by creating an agent) can have that approved balance silently drained by anyone, because an attacker simply calls `payWithERC20` and names the victim as `fromAddress` and themselves as `toAddress`. The protocol team acknowledged the finding and fixed it by restricting the function's visibility, protecting users' unlocked token allowances.