Post-mortem: Landing Page Incident
Executive Summary
On March 8, 2026, an attacker compromised the compound.finance landing page by leveraging a stale service account key in the cloud hosting infrastructure. The attacker replaced specific frontend components to redirect users to a phishing site designed to harvest off-chain signatures (ERC-20 permits, Comet authorizations, and COMP delegation). No user funds appear to have been stolen.
Background
The Compound protocol’s landing page (compound.finance) is a static website hosted on a cloud storage bucket. The site contains a link to the main application interface (app.compound.finance) through which users interact with the protocol’s smart contracts. The landing page source code is maintained in a private repository and deployments are managed via a dedicated service account.
The Attack
The attacker obtained access to a service account (the deployment bot) by acquiring its API key. Since this account had Storage Admin privileges on the cloud hosting bucket, the attacker was able to replace files served by compound.finance.
The modified landing page redirected users to a lookalike phishing domain (compoond.finance) mimicking the legitimate application interface. When interacting with the phishing site, users were prompted to sign off-chain messages granting the attacker broad permissions over their assets:
-
ERC-20 Permit (EIP-2612): An off-chain signature approving the attacker’s address as a spender with unlimited allowance. If executed, the attacker could later call
transferFromto drain the token without requiring an on-chain approval transaction from the victim. -
Comet allowBySig: An off-chain signature granting the attacker manager privileges over the victim’s Compound III positions, enabling withdrawal of collateral and base tokens.
-
COMP delegateBySig: An off-chain signature delegating the victim’s COMP voting power to the attacker for protocol governance.
The attacker’s address is 0x9840932804BBb794A68Ce742AA565d9d39d7686E.
Timeline of Events
All times are approximate and in EST (UTC−5).
| Timeframe (EST) | Event | Metric |
|---|---|---|
| 7 Mar, evening | Attacker deploys a phishing site at a lookalike domain. | |
| 7 Mar, late evening* | Attacker replaces landing page assets in cloud storage, redirecting compound.finance visitors to the phishing domain. | |
| 8 Mar, morning | The security response team is notified of the compromise through community reports. Ecosystem partners (wallet security providers, block explorers) are contacted and blacklist the attacker’s address. Security monitoring vendor publicly confirms the frontend compromise. Malicious landing page assets are replaced with the legitimate version. | Time to detection: ~10–12 hours |
| 8 Mar, afternoon | A compromised service account (deployment bot) is identified as the attack vector. Full credential rotation is completed across all infrastructure providers. Public announcement posted on the Compound governance forum confirming the issue is resolved. | Time to containment: ~3–4 hours after detection Time to remediation: Same day |
Root Cause Analysis
The direct cause of the incident was the compromise of a cloud service account API key that had Storage Admin privileges on the landing page’s hosting bucket. This service account was originally provisioned for automated deployments but had not been actively used for a long time.The exact method by which the attacker obtained the API key remains under investigation. Requests for detailed access logs have been submitted to the relevant infrastructure providers. The service account key was never rotated or revoked after it fell out of active use, violating the principle of least privilege and standard credential lifecycle management practices.
A secondary root cause is the delayed notification to the security team. This was a contributing factor, resulting from a technical issue with a sub-vendor’s alerting system, which prevented Compound from being promptly alerted to the issue.
Impact Assessment
Based on the available evidence, no user funds were stolen. On-chain analysis of the attacker’s address shows no incoming transfers from victims. However, it is important to note that the phishing site solicited off-chain signatures (permits and delegations). These signatures do not appear on-chain until they are used. It is therefore possible that the attacker collected valid signatures that have not yet been submitted. Users who interacted with the phishing site during the incident window should revoke any outstanding approvals and authorizations as a precaution using revoke.cash or similar tools.
Incident Response
Actions Taken
-
The community was informed via public channels and social media.
-
Wallet security providers were contacted to blacklist the attacker’s address. The address was flagged and blocked within hours.
-
Block explorers flagged the attacker’s address.
-
The compromised service account was identified and its access was revoked.
-
All API keys and credentials across the infrastructure stack were rotated.
-
Support tickets were opened with all relevant infrastructure providers to obtain detailed audit logs and additional forensic information.
Lessons Learned
What Went Well
-
No user funds were stolen.
-
Once notified, the security team coordinated effectively to identify the attack vector and revoke access to the compromised credential.
-
Ecosystem partners (wallet security vendors, block explorers) were responsive to our requests and took swift action to mitigate potential harm.
What Needs Improvement
-
There was a delay in the notification of the malicious redirection due to a technical issue in a sub-vendors alert system.
-
Access control on the cloud infrastructure had not been properly maintained, allowing stale credentials with excessive permissions to persist.
What Will Change Going Forward
-
We are working closely with our security partners to assess the effectiveness of the tooling used to scan our public facing infrastructure for issues. We are also expanding our ruleset to include detecting changes to more aspects of our infrastructure. We recognise the fast-paced nature of these attacks and the best-in-class systems needed to protect our users.
-
A full infrastructure review is already underway. The affected service account has had all credentials rotated or revoked. All other critical infrastructure is being reviewed to ensure regular rotation of credentials occurs and other security best practices are being enforced.
-
We are optimizing the access Compound security personnel have to resources by balancing continuous infrastructure hardening with the core principle of least privilege. Our goal is to maintain effective incident response by conducting frequent testing to build muscle memory for high velocity situations.
Conclusion
The compound.finance frontend redirect incident of March 8, 2026 was a supply-chain compromise in which an attacker leveraged a stale cloud service account key to replace frontend assets on the protocol’s landing page, redirecting users to a phishing site. While no user funds appear to have been lost, this outcome owes more to the attacker’s failure to attract victims than to a timely defensive response.
This incident highlighted the need for a thorough audit of the protocol’s off-chain infrastructure to identify and remediate stale credentials and excessive permissions before they can be exploited again.
The action items outlined above represent the minimum necessary steps to harden the protocol’s off-chain infrastructure against similar attacks. The Security Service Providers will work with the Foundation to ensure these are implemented promptly and verified independently. A follow-up update will be provided once the action items have been completed.