Full Report
Superfluid.sol was the host contract of this whole infrastructure. Superfluid “agreements” are the rules that Super Tokens operate under. In order to have a trusted and shared state across agreements, a ctx for context was used. This contains all of the context for the agreement function, such as the sender of the call. The usage of the ctx was not done securely though. Because it was user provided input that was being deseralized, it was likely this could be abused. Although they tried setting this up correctly, an attacker could inject their own malicious ctx when using multiple agreements at once. There is a hash check for the ctx, but this was forgotten about on the Host contract. Since this context is trusted, an attacker could inject malicious calls and add other users as the pseudo msg.sender. By doing this, the attacker was able to steal money from the contract and all of its users. Overall, a obvious but interesting attack.
Analysis Summary
# Incident Report: Superfluid Context Deserialization Exploit
## Executive Summary
In February 2022, an attacker exploited a critical vulnerability in the Superfluid smart contract related to the handling of user-provided context (`ctx`) across multiple agreements. By injecting a malicious, deserialized context designed to spoof the transaction sender (`msg.sender`), the attacker was able to execute unauthorized token transfers, resulting in the theft of approximately $13 million in cryptocurrency from the protocol and its users.
## Incident Details
- **Discovery Date:** Not explicitly stated, incident reported in February 2022.
- **Incident Date:** February 2022
- **Affected Organization:** Superfluid (Ethereum-based money streaming protocol)
- **Sector:** Decentralized Finance (DeFi) / Smart Contracts
- **Geography:** Blockchain/Ethereum Network
## Timeline of Events
### Initial Access
- **Date/Time:** February 2022 (Exact time unknown)
- **Vector:** Smart Contract Vulnerability (Deserialization of untrusted input leading to context spoofing).
- **Details:** The attacker utilized the `callAgreement` function within the Superfluid Host contract. By packaging calldata with two versions of the context (`ctx`)—a legitimate placeholder and an attacker-injected malicious value—they forced agreements to deserialize the malicious context first.
### Lateral Movement
- **Date/Time:** During the exploit execution phase.
- **Vector:** Spoofed `msg.sender` via malicious `ctx`.
- **Details:** The attacker's injected `ctx` contained a source address belonging to another party. Because the Superfluid Host contract, which was considered "trusted," did not perform a required hash check on the provided `ctx`, the malicious context was accepted as valid across subsequent agreement executions.
### Data Exfiltration/Impact
- **Date/Time:** During the exploit execution phase.
- **Vector:** Unauthorized token draining.
- **Details:** The accepted malicious `ctx` caused downstream agreements to execute transfers believing the transaction originated from the spoofed, legitimate address, allowing the attacker to drain tokens from other users' accounts secured by Superfluid.
### Detection & Response
- **Date/Time:** Post-theft/During analysis (specific detection method not detailed).
- **Vector:** External analysis or internal monitoring indicated unauthorized fund movement.
- **Details:** The core issue was identified as the failure to validate the incoming hash of the `ctx` argument when called from the trusted Host contract, despite this validation existing for other entry points. Response actions were focused on addressing the exploited vector (details not provided in the text).
## Attack Methodology
| Attack Phase | Method/Technique Used |
| :--- | :--- |
| **Initial Access** | Forging specially crafted calldata containing dual `ctx` parameters. |
| **Persistence** | Not applicable (Single, decisive execution phase). |
| **Privilege Escalation** | Context Spoofing: Manipulating the deserialization process to set the pseudo `msg.sender` to any arbitrary desired address. |
| **Defense Evasion** | Bypassing existing validation logic by exploiting a blind spot within the "trusted" Host contract caller path. |
| **Credential Access** | Not applicable (Smart contract logic exploitation, not credential theft). |
| **Discovery** | Not applicable (Direct exploitation of known contract logic flow). |
| **Lateral Movement** | N/A (Movement was conceptual: using the spoofed sender address to authorize transfers between user accounts). |
| **Collection** | N/A |
| **Exfiltration** | Unauthorized drawing of Super Tokens based on the spoofed authorization sequence. |
| **Impact** | Direct financial loss due to unauthorized state changes authorized by the compromised context. |
## Impact Assessment
- **Financial:** Approximately $13 million in cryptocurrency stolen.
- **Data Breach:** Confidential data theft not applicable. Loss of protocol funds/user assets.
- **Operational:** Disruption to the Superfluid service and user trust.
- **Reputational:** Significant negative impact following the public disclosure of the vulnerability.
## Indicators of Compromise
- **Network Indicators:** N/A (On-chain activity, not traditional network IOCs).
- **File Indicators:** N/A
- **Behavioral Indicators:** Execution of `callAgreement` functions with non-zero, unexpected `ctx` values, leading to unbalanced token flows originating from previously legitimate addresses.
## Response Actions
- **Containment measures:** (Not detailed in the text, but would have involved pausing vulnerable functions or upgrading contracts).
- **Eradication steps:** (Implied remediation of the context validation logic).
- **Recovery actions:** (Implied steps to address affected user funds, though not specified how).
## Lessons Learned
- **Key Takeaways:** The crucial danger of assuming trust even for internal or "trusted" contracts (like the Host contract) when handling input that affects security-sensitive state variables.
- **What could have been done better:** The existing `Superfluid.isCtxValid` check needed to be enforced universally, regardless of the calling contract's perceived trust level (adherence to Zero Trust principles).
## Recommendations
- Implement **Zero Trust Security** principles across the entire Smart Contract architecture. All external or cross-contract inputs, even those originating from supposedly trusted infrastructure components, must be explicitly validated (always "trust but verify").
- Ensure cryptographic validation checks (like hash checks on context) are mandatory for any data structure that dictates authorization or state transitions, regardless of the execution path.
- Conduct security reviews specifically targeting serialization/deserialization logic and context handling when composability across multiple functions or agreements is implemented.