Bridge Security · Incident Response
Cross-Chain Bridge Incident Response Playbook
A field-tested runbook for bridge exploit scenarios: contain exposure fast, coordinate validator actions, preserve evidence, and restore user trust with controlled recovery.
This guide focuses on cross-chain failure paths and explains how validation, containment, and recovery controls must work together.
Why bridge incidents are uniquely hard?
Bridge incidents do not behave like normal single-chain smart-contract events. They unfold across two or more chains, involve asynchronous message processing, and often include third-party validators or relayers that have different control planes. That means responders are dealing with moving parts that can keep producing damage after the first alarm, even if one component is already paused. In a token approval incident, freezing one spender may be enough to contain immediate loss. In bridge incidents, partially stopping the system can still leave a queue of signed, valid messages that execute later if you do not actively drain or invalidate them.
Another reason these incidents are hard is social velocity. Attack news spreads through Telegram, X, Discord, and aggregators within minutes. Users rush to withdraw, bridge operators scramble to communicate, and attackers often exploit that panic with fake “recovery” links and impersonation campaigns. This makes communication quality part of technical containment, not a separate PR activity. If your security team is precise but your user messages are vague, the incident keeps creating harm through phishing and confusion.
Bridge response is a distributed systems problem first, and a code problem second.
How Does The 6-phase response model Work?
We use a six-phase model because ad hoc “pause everything” reactions usually miss one or more execution lanes. Every phase has a specific owner and evidence output so the team can transition from chaos to controlled operations.
| Phase | Goal | Primary Owner | Required Output |
|---|---|---|---|
| 1. Detect | Confirm exploit pattern and blast radius | Monitoring/SecOps | Incident declaration + affected contracts |
| 2. Contain | Stop additional unauthorized value movement | Bridge Ops | Pause matrix, validator action log |
| 3. Stabilize | Freeze queue semantics and prevent replay | Protocol Engineering | Queue state snapshot + nonce locks |
| 4. Investigate | Collect forensic facts without mutating evidence | Security Engineering | Timeline with transaction IDs |
| 5. Recover | Reopen minimal-safe functionality | Incident Commander | Controlled reopen checklist |
| 6. Learn | Ship hardening fixes and publish post-mortem | Leadership + Security | Remediation backlog with owners |
What Should Teams Know About Containment in the first 30 minutes?
The first 30 minutes decide whether losses remain bounded. The objective is not to answer every question; it is to reduce attacker optionality. Start by classifying paths that can still move value: active bridge deposits, outbound message relays, delayed settlement queues, admin-controlled withdrawal paths, and any emergency mint/burn routines. Then apply controls in descending order of impact. Disable new ingress first, then freeze egress relays, then lock privileged paths. Teams that do this in reverse often lose additional funds while they debate architecture details.
Use a containment matrix, not chat messages. Each control should include: target component, action owner, executed time (UTC), transaction hash or admin operation ID, and verification method. If you cannot prove an action happened, treat it as not done. This sounds strict, but under stress assumptions leak into incident channels quickly, and those assumptions become expensive mistakes.
Do not skip communications in this window. Publish a short “safety holding statement” that confirms ongoing investigation and warns users not to trust DMs or unofficial links. Link only to your known-good domain pages and security updates. This reduces opportunistic phishing and gives support teams a single source of truth.
What Should Teams Know About Queue and nonce control: where many teams fail?
Bridge logic often includes merkle roots, nonces, message IDs, and replay checks across chains. During incidents, responders sometimes pause front-end deposits but leave message processors accepting pre-existing signed payloads. Attackers then exploit this gap by replaying or sequencing stale messages through still-valid validation paths. Containment is incomplete until queue semantics are explicitly controlled.
Practical controls include nonce floor bumping, emergency signer rotation, merkle root invalidation, and explicit queue drains under auditable script control. If your bridge architecture supports message expiration windows, tighten them immediately and reject aged payloads. If not, annotate that limitation in the incident report and prioritize it in post-incident remediation. Future auditors will ask for this.
For teams building stronger baseline controls, see our related guidance on allowance revoke workflow hardening, wallet threat modeling, and post-incident exploit pattern analysis. Those controls reduce exploit surface before incident day.
What Should Teams Know About Decision rights and incident command?
Bridge incidents collapse quickly when nobody knows who can make high-impact decisions. Define command structure before incidents happen: incident commander, technical lead per chain, validator coordination owner, communications owner, and legal/compliance liaison. This role map should be in your runbook and tested quarterly.
Decision rights should include explicit thresholds. Example: if active unauthorized movement exceeds a defined TVL threshold, emergency signer rotation can execute without waiting for full executive sign-off. If public disclosure obligations trigger, communications can publish predefined advisories without waiting for a perfect root-cause narrative. These thresholds shorten reaction time while keeping accountability intact.
The objective is not centralization. The objective is to prevent decision deadlock. A bridge incident is an operations race against attacker adaptation, and delays are usually irreversible.
What Should Teams Know About Forensics and evidence preservation?
Good incident reports are built during the incident, not after it. Capture all event data as immutable logs: transaction hashes, block numbers, contract addresses, signer key IDs, role changes, and access-path changes. Preserve both onchain and offchain artifacts, including relay logs and signer service telemetry. If you later need insurance, legal response, or regulator-facing narratives, this evidence is foundational.
Separate investigation channels from execution channels. The team applying controls should not be blocked by active forensic debate, and forensic analysts should not mutate production state while collecting data unless assigned to containment tasks. This separation reduces accidental side effects and keeps timelines coherent.
If you need a practical post-compromise structure, our social engineering incident report shows an evidence-first communication pattern that adapts well to bridge events.
What Should Teams Know About Recovery without reintroducing risk?
Recovery is not a binary “bridge on/bridge off” switch. Reopen by risk tier. First re-enable low-risk lanes with capped value and stricter confirmations. Then expand limits only after telemetry shows stable behavior for a pre-defined observation period. Publish these thresholds before reopening so users understand constraints are intentional safety controls, not downtime artifacts.
During recovery, increase monitoring sensitivity. Alert on queue size anomalies, signer distribution changes, validator disagreement, and unusual route concentration by destination chain. Attackers frequently test partial recoveries with low-volume probes before launching larger attempts. Treat those probes as intelligence, not noise.
From a trust perspective, users value clarity more than speed. Explain what is restored, what remains paused, and what milestones govern the next unlocks. Link back to your security hub at Security Research so updates are discoverable and consistent.
What Should Teams Know About QA checklist before publishing any incident update?
- Every claim references verifiable evidence (transaction hash, log ID, or monitored metric).
- No speculative attacker attribution in public copy.
- User instructions contain only first-party links.
- Updated status includes timestamp in UTC and next communication checkpoint.
- Open risks are listed explicitly, not implied.
This checklist prevents accidental overconfidence and reduces legal/compliance cleanup later.
What Should Teams Know About FAQ?
Should we pause the entire bridge immediately?
Pause ingress and high-risk egress paths immediately, then decide on full pause based on current exploit path and queue semantics. Blanket pauses can be correct, but they should be deliberate and logged.
What is the biggest mistake during bridge incidents?
Assuming front-end pauses equal containment. If message queues and signer paths remain active, attackers may still move value.