An important update from the C4 team. 🧵

This one has a bit of story behind it. Less than 12h after the report was submitted, it was confirmed by the team. The team didn’t even try to argue about how catastrophic the impact was. They were fast responsive and professional and transparent with their users, something I really admired. They simply straight told me because of a large hack last year that they suffered from they’re struggling financially and they’re letting a lot of their people go. The direct impact was around 7 million dollars. They were honest and I like honesty so instead of the normal 700k bounty, I accepted the 300k, I don’t regret my decision and I hope the project bounces back even stronger during these hard times, I admire them and their security standards and I wish them the best.

🚨 AAVE ORACLE GLITCH TRIGGERS $26M IN WRONGFUL LIQUIDATIONS A pricing oracle error on Aave caused about $26million in wstETH positions across 34 accounts to be unfairly liquidated after the system reported an incorrect exchange rate, with affected users set to be compensated.

Congrats to the winners @mathrielx and @SolidityDev 🎉

Security researcher ily2 has just earned a staggering $3,000,000 from submitting a critical smart contract bug via Immunefi. That's the largest single payout in web3 security in recent memory. In total, he's submitted 3 reports. All 3 were paid. 100% accuracy. His leaderboard update is coming soon, but you can pledge IMU to him now and earn when he finds the next one: immunefi.com/pledge/ily2

🚨 Excited to launch Valves Security! 🛡️ Our mission is simple: stop the theft of millions of dollars every year. We’re putting all our effort into protecting protocols, preventing exploits, and losses for innocent users and protocol teams.

I've created a site to share some ideas. My first post is about being a professional whitehat, and how I evaluate potential rewards to decide where to hunt. whitehatmage.github.io/posts…

Welcome back to Sherlock’s Vulnerability Spotlight, where we highlight an impactful vulnerability uncovered during a Sherlock audit. This week, we examine a signature malleability vulnerability found by @0xSimao in the @crestalnetwork Contest. This vulnerability has already been fixed following the contest, far before the launch of mainnet contracts. Summary of the Vulnerability Several “WithSig” entrypoints recover the signer from an EIP-712 digest that only commits to: - projectId - base64RecParam / base64Proposal - serverURL The typed data does not include other calldata inputs that materially affect execution, such as: - tokenAddress (determines what token is charged and the cost mapping used) - tokenId (which NFT gets consumed / marked as used) - privateWorkerAddress (affects which worker the request is privately routed to) Attack Steps 1) User produces a valid signature for a deployment request The user signs getRequestDeploymentDigest(projectId, base64Proposal, serverURL) (only these 3 fields) 2) Signature becomes observable (ERC-4337 relayer/bundler mempool) When routed via an AA service (e.g., Biconomy), user operations are commonly broadcast to a bundler mempool, making the signature available to third parties monitoring it. 3) Attacker re-submits onchain with malicious unsigned parameters Because the signature does not commit to additional calldata: Token route: attacker calls createAgentWithTokenWithSig(...) with: - same projectId/base64Proposal/serverURL/signature - but a different tokenAddress (still “enabled” and possibly more expensive) - and/or a different privateWorkerAddress (invalid or attacker-chosen) NFT route: attacker calls createAgentWithSigWithNFT(...) with: - same signed fields - but a different tokenId (any NFT the user owns), consuming/locking it via nftTokenIdMap[tokenId] = Pickup - and/or a different privateWorkerAddress, forcing a wrong/censoring worker path Root Cause Signed message is incomplete: the EIP-712 deployment request struct only includes (projectId, base64RecParam, serverURL) and omits execution-critical inputs like tokenAddress, tokenId, and privateWorkerAddress. Digest reuse across multiple entrypoints: multiple “WithSig” functions rely on getRequestDeploymentDigest() while taking additional calldata, enabling parameter substitution and even cross-function replay (same digest, different semantics). What’s the Impact? Forced/incorrect payments: in createAgentWithTokenWithSig, attacker can select a different tokenAddress (among enabled tokens) so the user pays a cost they did not agree to. Persistent DoS / censorship: - attacker can lock an unintended NFT tokenId as “used” (Status.Pickup), preventing legitimate future use - attacker can supply malicious privateWorkerAddress to misroute or break private deployments, harming liveness and enabling worker censorship incentives User intent violation: users can be forced to create agents with parameters they never authorized, breaking trust assumptions around signature-based flows. Mitigation Sign all parameters that affect execution, at minimum: - privateWorkerAddress - tokenId - tokenAddress We are proud to have helped secure @crestalnetwork through this discovery. When it absolutely needs to be secure, Sherlock is the right choice.