Full Report
Axelar is a cross-chain protocol similar to Wormhole and Layer Zero. Normally, with finalization, the Axelar network sends a message to the core contract. Then, the calling contracts checks to see if the command exists and can be executed. With the Express functionality, all of this changes. Axelar includes an express feature that executes transactions before finalization is triggered. Practically, this means that some actor is fronting the funds, assuming they will be repaid. Since there's no command ID saved on Axelar because it's before the command has been sent, how do we know it's valid? We don't! So, the express functionality is a super-duper trusted action. CrossCurve used the expressExecute() interface. It checks whether a commandId already exists and rejects the command if the ID exists. There's still no validity of the message though. So, an attacker could simply call the expressExecute() with whatever data they wanted to execute cross-chain actions. On Twitter, sujith posted a screenshot of them submitting this issue to Axelar on Immunefi. This appears to be a poorly designed feature: the relayer in this model is a trusted entity, but it isn't included in the standard contracts to inherit from. MixBytes has a good tweet discussing the issue as well. I understand Axelar expects additional layers of authentication. The CrossCurve team attempted this but failed. Personally, I think this vulnerable by default pattern is bad. Good write-ups explaining the root cause of the issue.
Analysis Summary
# Vulnerability: Unauthenticated Arbitrary Payload Execution via Axelar ExpressExecute Functionality
## CVE Details
- CVE ID: Not explicitly assigned in the context (Described as an implementation bug in a specific protocol integration)
- CVSS Score: Not explicitly calculated (Severity is implicitly **High** given the $1.4M loss)
- CWE: CWE-284 (Improper Access Control), CWE-668 (Improper Use of Notification Mechanism)
## Affected Systems
- Products: CrossCurve Protocol (specifically the `ReceiverAxelar` contract integrating Axelar)
- Versions: Vulnerable version is the one containing the flawed Axelar integration logic.
- Configurations: Systems utilizing Axelar's `expressExecute()` interface with a confirmation threshold set to 1.
## Vulnerability Description
The vulnerability exists in CrossCurve's implementation of Axelar's express execution feature (`expressExecute()`) within the `ReceiverAxelar` contract. The standard Axelar pattern relies on finalization to validate commands. The express feature allows immediate execution before finalization, relying on the calling actor fronting funds.
Crucially, the vulnerability stems from:
1. **Publicly Callable Function:** The `expressExecute()` function was publicly callable.
2. **Weak Validation:** The only check performed was whether the supplied `commandId` had *already* been executed. An attacker could supply a fresh, unused `commandId`.
3. **Misconfigured Threshold:** The confirmation threshold was set to 1, effectively disabling necessary multi-guardian validation required for trusted cross-chain actions.
This combination allowed an attacker to supply arbitrary, malicious ABI-encoded payloads, spoof metadata (`sourceChain`, `sourceAddress`), and trigger minting/transfer of assets (e.g., $1.4M worth of EYWA tokens) without legitimate cross-chain authorization. While Axelar's general design implies trust in the relayer for the express path, the implementation failed to secure the entry point sufficiently.
## Exploitation
- Status: **Exploited in the wild** (Resulted in a \$1.4M loss at CrossCurve).
- Complexity: **Low** (Attacker only needed to generate a unique `commandId` and craft a malicious payload calling the accessible function).
- Attack Vector: **Network** (Remote transaction submission).
## Impact
- Confidentiality: Minimal (Data exposure unlikely).
- Integrity: **High** (Arbitrary payload execution leading to mass token minting/theft).
- Availability: Medium (Contracts were paused post-exploit).
## Remediation
### Patches
- The context does not specify the exact patch version, but the mitigation involved pausing contracts and likely implementing stronger access control and/or authentication checks before allowing payload execution via `expressExecute()`.
- Secure implementation requires verifying the authenticity of the message/command ID against the Axelar core network evidence, rather than just checking if the ID is *new*.
### Workarounds
- Contract pausing (implemented by CrossCurve).
- Reviewing and increasing the confirmation threshold for cross-chain operations to enforce multi-signature or quorum validation for express transactions.
- Disabling or restricting the use of the public `expressExecute()` path until proper authentication layers (that the failing integrator attempted to add) are fully secured.
## Detection
- Indicators of Compromise: Sudden, massive minting or transfer events initiated via a function named similar to `expressExecute()` linked to cross-chain relayers. Unusually high volume of transactions originating from an EOA directed at cross-chain receiver contracts with unique `commandId` parameters.
- Detection Methods and Tools: Monitoring transaction gas consumption relative to standard operations; analyzing contract event logs for unauthorized internal state changes post-execution of express functions.
## References
- Vendor Advisories: CrossCurve provided post-mortem updates via X/Twitter.
- Relevant links (Defanged):
- hxxps://www.quillaudits.com/blog/hack-analysis
- Discussion by MixBytes on Twitter regarding the known design flaw pattern.
- sujith's submission to Immunefi.