Composable Security ⛓️‍💥

Smart Contracts, Off-chain Components and AI Integrations Security Reviews

Worked with: @LidoFinance @UniswapFND @redstone_defi @YieldNestFi @0xOthentic

[Composable Security ⛓️‍💥 @Composable_Sec]

We are proud to announce the release of the updated 𝗦𝗺𝗮𝗿𝘁 𝗖𝗼𝗻𝘁𝗿𝗮𝗰𝘁 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗩𝗲𝗿𝗶𝗳𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 (𝗦𝗖𝗦𝗩𝗦)!

✅ The best and most comprehensive checklist available for Solidity based smart contract projects.

[Composable Security ⛓️‍💥 @Composable_Sec]

@_SEAL_Org Certification is open for live engagements, and the waitlist is the way in.

It evaluates the operational layer behind nearly every major crypto incident this cycle: multisig ops, treasury, incident response, DNS, infra, identity.

Why start now and how to sign up 👇
https://t.co/wGkPyUrgyf

[Composable Security ⛓️‍💥 @Composable_Sec]

@_SEAL_Org Great work! 🙏👏

[Composable Security ⛓️‍💥 @Composable_Sec]

Operational security has been the gap behind most major crypto incidents this cycle.

SEAL Certification is a serious attempt to put a standard on that layer, built openly and with the community.

Proud to be part of the first cohort working through it.

[Security Alliance @_SEAL_Org]

It's finally happening!

SEAL Certifications are now open for business. 🎉

[Damian Rusinek @drdr_zz]

#ClaudeCode Security Notes #3 - when deny = ask

❗️ A deny rule like `permissions.deny: ["Edit(~/)"]` is not a hard block on editing home-directory files.

Example:
You want to block edits to a home-dir file "test":
~/test

Claude Code attempts:
Edit(~/test)

When Claude Code is asked to modify this file, it can fall back to asking for approval.

👉 That means "Edit(~/)" behaves more like "ask" than a real "deny" for the context you wanted blocked.

👉 If you add full tool to the "deny" list: "Edit", it will not block the tool, but ask whether to use it.

Can we really deny it❓
➡️ Block the tool using "hooks", specifically the "PreToolUse" hook:
"hooks": {
"PreToolUse": [
{
"matcher": "Read|Edit",
"hooks":[
{
"type": "command",
"command": "exit 2"
}
]
}
]
},

[Composable Security ⛓️‍💥 @Composable_Sec]

3 high and critical severity findings in the last 2 months. All OFF-CHAIN.

That's what we've reported to bug bounty platforms recently. All in projects that have been audited multiple times.

Oracles, RPCs, validator services, custom relayers. None in the smart contracts on top.

If you own an off-chain component that hasn't been reviewed in the last 12 months, this is where we'd start.

Let us audit your off-chain components

[Composable Security ⛓️‍💥 @Composable_Sec]

https://t.co/pWEyRQAQuP

[Composable Security ⛓️‍💥 @Composable_Sec]

Cursor's command allowlist validates the wrapper, not what runs inside it.

find . -exec python3 -m http.server 8080 \; slips past approval and exposes source, .env files, and API keys.

Read about GTFOBins-style IDE bypass by @drdr_zz

[Damian Rusinek @drdr_zz]

#ClaudeCode Security Notes #1

Using Claude Code sandboxing? Good.
Just make sure it cannot silently stop being sandboxing.

Example config:
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"autoAllowBashIfSandboxed": false
}
}

It is easy to assume that "failIfUnavailable: true" means: “If sandboxing does not work, do not run the command.”

But that is not the full story. If a command is blocked by the sandbox, Claude Code may try to rerun it outside the sandbox.

The setting you probably want is:
{
"sandbox": {
"allowUnsandboxedCommands": false
}
}

If you do not use sandboxing — use it.
If you do — make sure you did not leave Claude an escape hatch.

[Composable Security ⛓️‍💥 @Composable_Sec]

If your only security layer is a newly added feature like Claude Sandbox, you might want to rethink your approach.

@drdr_zz is working on an article that will help you do this better.

Follow us so you don't miss it.

[Composable Security ⛓️‍💥 @Composable_Sec]

https://t.co/9YZZbxR6Uv

[Composable Security ⛓️‍💥 @Composable_Sec]

Prompt injection stops being a chatbot inconvenience the moment an AI agent can sign a transaction, call a tool, or move funds.

The model doesn't need to be "hacked" - it only needs to be misled by a document, a webpage, or a tool output it had no reason to distrust.

Our latest article covers the controls that actually reduce that risk in production

Link in the comment 👇

[Damian Rusinek @drdr_zz]

I’ve fulfilled my responsibility as an ETHSecurity Badge holder. 💪

From a large pool of applicants, I selected projects that I believe can meaningfully improve security across the Ethereum ecosystem and deserve funding.

My focus was primarily on projects I personally use or would like to use, teams backed by people I trust, contributors with a proven track record, and/or promising security initiatives that are valuable but difficult to monetize.

I was also glad to see many projects going beyond source code security, with strong work in areas like opsec and education. That is a very positive signal: Ethereum security is broadening beyond contests, audits, and bug bounties alone.

[Damian Rusinek @drdr_zz]

A client recently reminded us that, during an audit a while back, we flagged their LayerZero 1/1 DVN setup as unsafe and recommended adding more DVNs.

That change meant they wouldn’t have been exposed to the same failure mode that later cost KelpDAO $300M.

Small config choices matter 💪

[Paul Kuryłowicz @wh01s7]

Most small teams are sitting on a goldmine they can’t search.

We’re building an internal LLM knowledge base at Composable Security, inspired by Andrej Karpathy’s idea.

And it’s already changing how we work.

The biggest win isn’t “AI productivity” in the abstract.

It’s this:

When a new client asks, “Have you done something similar before?”, we can quickly surface relevant past audits, comparable scopes, lessons learned, and examples of how we approached similar problems.

That used to depend on memory.

Now it becomes infrastructure.

For a small team, this is where LLMs get really interesting:

Not replacing expertise.

Making accumulated expertise instantly reusable.

[Composable Security ⛓️‍💥 @Composable_Sec]

We’re proud to share that @drdr_zz is among the ETHSecurity Badge holders.

TheDAO’s mission is to make Ethereum safer, and ETHSecurity is how they recognize the researchers capable of contributing to that goal.

The ETHSecurity badge distribution from @thedaofund is now complete.

[Composable Security ⛓️‍💥 @Composable_Sec]

We’re proud to share that @drdr_zz is among the ETHSecurity Badge holders.

TheDAO’s mission is to make Ethereum safer, and ETHSecurity is how they recognize the researchers capable of contributing to that goal.

The ETHSecurity badge distribution from @thedaofund is now complete.

[thedao.fund @thedaofund]

The final 100 ETHSecurity Badge holders are in!

That brings us to 200 security experts, guiding how TheDAO allocates its funds and also coordinating behind the scenes to make Ethereum safer.

Big thanks to everyone who engaged with the process and helped shape it, and to @bonfiresai for building the tooling that made it possible.

[Damian Rusinek @drdr_zz]

🚨 Summary of @LayerZero_Core / @KelpDAO hack based on different sources (links in comments): what happened, what happened next and what are the possible next steps.

What happened ❓

On April 18, 2026 at 17:35 UTC, an attacker forged a LayerZero cross-chain message on Kelp’s Unichain -> Ethereum rsETH route, which was configured as a 1-of-1 DVN path.
That let Ethereum release 116,500 rsETH from the Ethereum-side adapter without a matching burn on the source chain, breaking the bridge’s backing invariant.
A second forged packet for another 40,000 rsETH was verified too, but its execution reverted after Kelp froze the recipient; 40,373 rsETH remained in the adapter afterward.

This was not a smart-contract exploit in Aave and not described as a direct break of LayerZero’s core protocol logic; it was an **attack on the offchain verification** path used to validate cross-chain messages.
@LayerZero says the attacker poisoned downstream RPC infrastructure, compromised two RPC nodes, then DDoSed clean RPCs so the DVN failed over to poisoned ones and attested to transactions that never happened.
@KelpDAO's statement likewise frames it as an attack on LayerZero infrastructure, and says Kelp’s own systems were not compromised.

Where the sources differ is responsibility❗️
Kelp argues the 1/1 DVN setup was the documented/default configuration shipped for new OFTs, so the real root problem was LayerZero’s infrastructure and default assumptions.
LayerZero and SEAL/Radar argue the opposite emphasis: the fundamental issue was the single point of failure, and a multi-DVN setup with independent validators would likely have prevented the exploit from succeeding.

Why this matters now❓

The attacker quickly spread the stolen rsETH across addresses and used a large portion as collateral on Aave, which is why Aave treated this as a major downstream risk event even though its own contracts kept working normally.
Aave froze rsETH/wrsETH markets and then froze WETH in several deployments to stop risk from spreading.

The key unresolved question is who ultimately eats the loss. Aave models two main paths:
1️⃣ if losses are socialized across all rsETH, it estimates about $123.7M of bad debt;
2️⃣ if losses are isolated to bridged L2 rsETH, it estimates about $230.1M, concentrated mainly on Mantle and Arbitrum.
That means the biggest decision still ahead is how Kelp updates accounting, redemption treatment, and exchange-rate/oracle handling for rsETH after the bridge break.

Possible next steps ❗️

The most immediate next step is continued containment and recovery. SEAL says it has been coordinating response efforts since shortly after the incident; LayerZero says the affected RPC nodes have been replaced, the DVN is operational again, it is working with law enforcement, and it will no longer sign/attest for apps still using 1/1 configurations.

A second likely next step is a forced migration away from 1/1 DVN setups. Radar explicitly recommends at least two required validators, checking that multiple DVNs are not run by the same entity, cross-checking results across multiple RPC gateways, and using local nodes for highly sensitive decisions. In other words, the likely security response is broader than “patch one bug”; it is a shift toward redundancy at both the validator and RPC layers.

🚨 For Kelp specifically, the biggest open decision is whether it will recapitalize the loss itself, socialize losses across all rsETH, or ring-fence the impairment to bridged L2 rsETH. That choice will drive whether pain is spread more broadly across the rsETH holder base or concentrated in L2 markets and protocols like Aave.

For Aave, the likely next steps are to keep affected markets frozen, monitor WETH liquidity/liquidation capacity, and prepare different governance actions depending on which loss-allocation scenario becomes real.
Its report specifically recommends pausing the WETH Umbrella module as a precaution if the “uniform socialization” scenario looks likely; if losses stay isolated to L2s, Aave says the hole would instead need to be handled through treasury support, Kelp recovery, or governance action rather than the Umbrella module.

🚨One additional development outside your three links: on April 21, 2026, Arbitrum said its Security Council had frozen 30,766 ETH linked to the exploit, which suggests at least some partial fund recovery path is already underway and adds a lot of controversy about blockchain fundamentals.

📝 Bottom line

This was essentially a bridge-verification failure caused by concentrated trust in one verifier path. The incident now moves from “what happened” to “who absorbs the loss, how much can be recovered, and how quickly the ecosystem removes similar single points of failure.”

[Damian Rusinek @drdr_zz]

DoS was a critical part of the @KelpDAO / @LayerZero_Core hack.

Just reminding for some projects that are interested only in "funds drain" impact.

[Damian Rusinek @drdr_zz]

When you joke that you were hacked (it was April Fools joke) and become a real victim 13 day later. Don't do that.

Now a real exploit reportedly came from a flaw in Merkle proof verification that accepted a forged request from the governance to change admin for an asset - DOT.

Next was the mint of 1B of DOT and swapping it for ~108 ETH (~236k USD) through OdosRouterV3 and UniswapV4. So the first victims were the liquidity providers.

MEV bots already caught it and there is one with nearly 100% of the total supply (see comment).

In bridges, proof logic is critical as it's the only way to say that the message is valid or not, and sometime the only layer of authorization.

[Paul Kuryłowicz @wh01s7]

@OpenAI and @paradigm developed a benchmark evaluating the ability of AI agents to detect, patch, and exploit high-severity smart contract vulnerabilities.

Here are my takeaways from the EVMbench paper:

1⃣ Security Researcher
- In-depth human audits are still irreplaceable, and AI serves best as an assistive tool.
- The main bottleneck lies in finding the vulnerability, rather than exploiting it.
- Top researchers with a good intuition for where a bug might be are already faster and more effective than ever before
- If you are a beginner, reconsider your carrier path.

2⃣ Security AI Agent Builders
- Using different tools and frameworks for the same base models drastically changes the agent's final results.
- Focus on multi-stage audits and narrowing down the search space.
- Build specialized tools.
- Remember that one update can instantly make your product worthless.

3⃣ Developers
- The time window to react and deploy a patch after vulnerable code is published is shrinking drastically.
- The better your test suites are, the more effective the AI-suggested patches will be, reducing the chance of errors.
- The risk of exploitation increases regardless of your exposure, as the time barrier required for an attacker to understand the project no longer exists.
- This is the moment when saving time and money on development should be spent on security (both internal security practices and external providers services).