Here's my update to the broader community about the ongoing incident investigation. I want to give you the rundown of the situation directly. A Vercel employee got compromised via the breach of an AI platform customer called http://Context.ai that he was using. The details are being fully investigated. Through a series of maneuvers that escalated from our colleague’s compromised Vercel Google Workspace account, the attacker got further access to Vercel environments. Vercel stores all customer environment variables fully encrypted at rest. We have numerous defense-in-depth mechanisms to protect core systems and customer data. We do have a capability however to designate environment variables as “non-sensitive”. Unfortunately, the attacker got further access through their enumeration. We believe the attacking group to be highly sophisticated and, I strongly suspect, significantly accelerated by AI. They moved with surprising velocity and in-depth understanding of Vercel. At the moment, we believe the number of customers with security impact to be quite limited. We’ve reached out with utmost priority to the ones we have concerns about. All of our focus right now is on investigation, communication to customers, enhancement of security measures, and sanitization of our environments. We’ve deployed extensive protection measures and monitoring. We’ve analyzed our supply chain, ensuring Next.js, Turbopack, and our many open source projects remain safe for our community. The recommendation for all Vercel customers is to follow the Security Bulletin closely (https://vercel.com/kb/bulletin/vercel-ap… My advice to everyone is to follow the best practices of security response: secret rotation, monitoring access to your Vercel environments and linked services, and ensuring the proper use of the sensitive env variables feature. In response to this, and to aid in the improvement of all of our customers’ security postures, we’ve already rolled out new capabilities in the dashboard, including an overview page of environment variables, and a better user interface for sensitive env var creation and management. As always, I’m totally open to your feedback. We’re working with elite cybersecurity firms, industry peers, and law enforcement. We’ve reached out to Context to assist in understanding the full scale of the incident, in an effort to protect other organizations and the broader internet. I also want to thank the Google Mandiant team for their active engagement and assistance. It’s my mission to turn this attack into the most formidable security response imaginable. It’s always been a top priority for me. Vercel employs some of the most dedicated security researchers and security-minded engineers in the world. I commit to keeping you updated and rolling out extensive improvements and defenses so you, our customers and community, can have the peace of mind that Vercel always has your back.

Following the KelpDAO hack, we built an open analysis of DVN security configurations across every active OApp on LayerZero over the last 90 days. Of ~2,665 unique OApp contracts: 47% run a 1-of-1 DVN security floor, 45% run 2-of-2, and ~5% run 3-of-3 or higher. As we know, KelpDAO's rsETH sat in the first bucket. Open query, public methodology, feedback welcome: https://dune.com/dune/layerzero-dvn-setu…

This vercel thing is a fucking apocalypse Hundreds possibly thousands of npm, pypi etc tokens not to mention tents of thousands of email, cloud provider keys etc Like why was this not encrypted what the actual fuck

layerzero attack was not rpc poisoning in networking poisoning is when the attacker outside the trust boundary taints a shared lookup (dns, arp, cache). the consumer has no reason to distrust the source. this was not that. the attackers got inside layerzero's trust boundary. they accessed the rpc list, compromised two nodes the dvn depended on, and swapped the op-geth binaries. that's an infra breach within the perimeter. supply-chain shaped, not network shaped. and the payload was surgical. the malicious binary cloaked by ip, served forged payload only to the dvn, told the truth to scan and every other caller, then self-destructed to wipe logs and binaries. rpc poisoning makes it sound like something that happened to the infra from the outside. the real story is a targeted implant operating inside the trust boundary. that's a meaningfully scarier attack than the label suggests.

1/ On April 18, an attacker drained 116,500 rsETH (~$292M) from Kelp's cross-chain bridge. rsETH markets on Aave and other lending venues were frozen shortly thereafter.

Update on rsETH incident: @LlamaRisk has published a report outlining the rsETH incident, the immediate actions taken, its impact on Aave, and potential paths forward. All service providers have been working to assess the two potential bad debt scenarios on the Aave protocol. Aave DAO service providers are also leading an effort with ecosystem participants to address any bad debt. This effort already has several indicative commitments from various parties and we are grateful for the strong support we have received so far. We will share further updates as we have them. In the meantime, the full report can be read here: https://governance.aave.com/t/rseth-inci…

SCOOP: Kelp DAO is preparing a memo blaming LayerZero for Saturday's $292 million rsETH exploit, saying it relied on LayerZero's documentation, default configurations and team guidance when setting up the bridge. CoinDesk has reviewed the memo ahead of publication.

Calling all ETH lenders locked on Aave. We have built a way to exit to any token. While Fluid provides redemption to wstETH/weETH, via our Pathfinder algorithm, you can swap aEthWETH directly into the asset of your choice. aWETH → any token on https://1inch.com/swap?src=1:aEthWETH&am… in one click if you're still stuck.

As much as it pains me, but for the things I have influence over, I will switch to the default: SECURITY > NEUTRALITY A “pause everything” function? A daily limit? An extra safety-net layer that every transaction has to pass through before being processed? Yes!

On April 6, I ran an AI-assisted security scan on Kelp DAO and flagged their LayerZero DVN bridge config as an unresolved risk. 12 days later, that exact attack surface was exploited for $292M. The tool didn't find a code bug. It found something code audits can't catch: a 1-of-1 bridge validator config that Kelp never disclosed publicly. One node compromised = $292M drained. Kelp had 5+ code audits from top firms. None caught it — because it's not a code problem. The tool is open-source. Anyone can run it on any DeFi protocol before depositing. What it checks that code scanners don't: → Bridge validator thresholds → Governance gaps between core contracts and operational configs → Historical attack pattern matching (Ronin, Harmony, Drift) What protocols are you exposed to that haven't disclosed their DVN config?

OK — Kelpdao hacker, how much you want? Let’s just talk. With KelpDAO’s help, of course. It’s simply not worth it to sacrifice both Aave and KelpDAO and let them go down over this hack. You can’t spend $300 million anyway.

because the final allocation of losses between rsETH on Ethereum (which is technically "fully backed") and external chains is still tbd, i can only read this as a statement of Aave Labs' preference - they would rather rsETH on mainnet to have zero haircut, and for rsETH on L2s/external chains to bear the full loss (essentially zeroed out) ultimately, the allocation of losses will be mostly decided by Kelpdao team (and lawyers) but we can consider why this outcome would be aave labs' preference, and what would be the impact on users if this is how it ends up working out # aave labs preference aave core market on ethereum is covered by umbrella insurance module, and is also explicitly covered by aave dao backstop (eg dao committed to using treasury to backstop against bad debt). so if rsETH on ethereum ends up with no haircut, then not only are umbrella users completely unaffected (other than potentially GHO stakers to cover unbacked GHO on external chains), but the aave treasury remains intact aave core is also the primary money-maker for the aave protocol, and preserving this is probably top priority for labs team # user impacts if rsETH on Ethereum has no socialized losses/haircut, users on Aave core would end up being mostly unimpacted however, certain L2 networks would face an extremely heavy burden, with WETH suppliers taking a direct hit from unbacked rsETH current rsETH collateral across external chains includes: - Base: $71 million - Arbitrum: $152 million - Mantle: $116 million - Ink: $21 million - Linea: $1.4 million in some cases, rsETH backed loop positions may comprise a large share of the backing of aWETH, meaning that any assets borrowed against ETH may also be at risk of a haircut (USDC and USDT0 markets) mantle, arbitrum, and base seem to have the highest risk here, with mantle in particular having the majority of aWETH backed by potentially zero value rsETH. it is possible that Aave could successfully maneuver these chains into bailing out their markets (this may be part of the reason why Aave Labs prefers no loss socialization on Ethereum, to force the issue with relatively better capitalized chain ecosystems) we also note that ethena has a material deposit amount in the mantle USDT pool (https://debank.com/profile/0xB8734a14fBD… which may face a haircut, potentially exceeding their excess capital buffer. if this is the case, then this would become another vector of contagion risk into Aave markets including Core and Plasma (which has been relatively less affected as it had no rsETH exposure at the time of the hack) # comparison with full socialization personally, i think that concentrating losses on external chains is actually a worse outcome for Aave in the case where losses are spread evenly including Ethereum users, this would engage Umbrella ETH depositors (roughly $50 million) and also enable using rsETH collateral on Aave Core to repay part of the debt, likely reducing the uncovered loss on Ethereum mainnet to an amount lower than Aave's current treasury reserves the loss levels on external chains would then be at much more manageable levels, with less risk of cascading spillover into large haircuts on stablecoin markets or impairment to other key aave collateral assets like USDe awaiting further updates from the Kelpdao team to see how this will play out in practice

Aave Sees $5.4B ETH Outflows as rsETH Exploit Raises Concerns According to Lookonchain, the Kelp DAO exploit has left Aave saddled with bad debt after the attacker deposited rsETH to drain ETH. This has sparked a massive whale exodus, with over $5.4 billion fleeing the protocol in a panic. Justin Sun alone yanked 65,584 ETH (~$154M) from the platform. Driven by this mass flight, Aave's ETH utilization rate has now maxed out at 100%.

we're now seeing some negative secondary effects of illiquidity in Aave stablecoin markets (in this example, Aave Core USDT on Ethereum) because users cant withdraw due to 100% utilization, there has been a ~$300 million increase in borrowing with USDT collateral in just the past day since the rsETH exploit with a 75% max LTV, users with stuck USDT deposits can take out up to 3/4 of the value of their aave position. but this ends up reducing liquidity in other markets, with USDC and USDe markets now at 100% utilization as well i think aave should consider immediately prevent new borrowing with illiquid collateral assets (eg setting LTV=0 for USDT, USDC, USDe on Aave Core, and relevant assets on other markets/chains, or alternatively disabling borrows across the board on all assets)

Update on rsETH incident: According to our analysis, rsETH on Ethereum mainnet is fully backed. Out of an abundance of caution, rsETH remains frozen across Aave V3 and V4 and exposure to the incident is capped. WETH reserves also remain frozen across affected markets including Ethereum, Arbitrum, Base, Mantle, and Linea. Aave is actively validating information and assessing potential resolutions.

I'm dropping a thread of all the protocols that had to freeze their interop because of LayerZero being compromised. Let's go:

Due to rsETH LayerZero infrastructure being hacked, we decided to pause Curve LayerZero infrastructure before more understanding about the root causes is obtained, out of precaution. This affects: * CRV bridging from chains: bnb, sonic, avalanche, fantom, etherlink, kava. Other chains use native bridging; * crvUSD fast bridge (slow bridging for L2s still works).

We’ve identified a security incident that involved unauthorized access to certain internal Vercel systems, impacting a limited subset of customers. Please see our security bulletin: https://vercel.com/kb/bulletin/vercel-ap…