Root Cause
An attacker reportedly gained access to Swell's oracle bot private keys — the hot operational keys authorised to update exchange rates for the liquid staking tokens swETH and rswETH. With these keys the attacker can call the rate-setting functions without any corresponding ETH backing.
// Conceptual: attacker holds hot key and inflates rate at protocol's max cap
swETH.setTokenRate(inflatedRate); // no ETH deposit required
Additionally, four malicious upgrade contracts were deployed to addresses linked to the compromised key. If these are queued through Swell's proxy admin and executed after the timelock, they could redirect contract logic and drain the underlying ETH pools. As of Oct 22 reporting they had not entered the multisig execution queue.
The key compromise may be connected to a separate Oct 21 breach at Railway, a cloud deployment platform, where an attacker drained ~$371,000 from wallets whose private keys were stored as plaintext environment variables. This link is unconfirmed by Swell.
Attack Steps
| Step | Action | Detail |
|---|---|---|
| 1 | Hot key compromise | Oracle bot keys for swETH/rswETH obtained (possible Railway/cloud infra leak) |
| 2 | Rate inflation | Exchange rates raised at max allowed cap (~1%/hr) with no ETH deposited |
| 3 | Rate divergence | swETH inflated ~3% above 1.133254 ETH/share; rswETH ~2% above 1.082464 ETH/share |
| 4 | Malicious contracts deployed | Four upgrade contracts deployed targeting proxy admin rights |
| 5 | Potential drain | If upgrades queued + executed via timelock: |
Impact
- Confirmed loss: None as of Oct 22, 2026. Swell confirmed no ETH has been withdrawn from or deposited into affected contracts.
- At-risk exposure: ~2,513 ETH could be drained if the malicious upgrade contracts are executed via multisig.
- Rate manipulation risk: Traders or protocols that use swETH/rswETH exchange rates during the inflation window may receive less ETH than expected when redeeming.
- Protocol status: Swell states the protocol remains fully operational and users should take no action.
Lessons for Auditors
- Hot keys with oracle write-access are critical attack surface. Any key that can push exchange rates — even under a rate-change cap — must be held in an HSM or MPC wallet, never as plaintext in cloud environment variables.
- Separate oracle update rights from proxy admin rights. The oracle bot key should only be able to update rates; it must never also control proxy upgrades or admin calls.
- Rate-of-change caps provide detection time, not protection. The 1%/hr cap creates a window for defenders to respond, but only if continuous monitoring of oracle divergence is in place.
- Infrastructure secrets (CI/CD, cloud platforms) are in-scope for smart contract security. If a service account stored in Railway or AWS Secrets Manager can sign oracle updates or admin transactions, it is a privileged key — threat-model it accordingly.
- Monitor governance and upgrade queues continuously. The time between deploying malicious upgrade contracts and their timelock execution is the defender's window; automated alerts on proxy upgrade proposals are essential.