Self-published audit of $7.5B Hyperliquid bridge flags four critical flaws

What the report says

A post published on dev.to on 23 September 2026 presents itself as a security audit of the Hyperliquid bridge, the cross-chain contract that the report says held roughly $7.5 billion in total value locked at the time. The review concentrates on two areas, reentrancy and access control, across the bridge's entry and exit functions, token locking, mint and burn logic, admin governance, and upgradeability mechanisms.

According to the post, the bridge earns an overall risk score of 7 out of 10, described as high, and in a worst-case scenario that combines the identified weaknesses with other attack vectors, around $1.2 billion of assets could be exposed. The executive summary counts four critical and six medium-severity findings, with several lower-severity items appearing in the detailed table.

The critical findings

The dev.to report attributes two of the four critical issues to reentrancy in BridgeRouter:

• lockTokens transfers a user's ERC-20 tokens before updating its internal lockedBalances mapping. A malicious token whose transfer triggers a callback could re-enter the function, double-count the lock, and mint twice on the L2 side.
• releaseTokens pays tokens to the recipient before clearing the pendingRelease flag, letting a hostile token re-enter and force a second transfer.

The other two critical findings concern privileged access:

• setValidatorSet on ValidatorManager is protected only by onlyOwner, and the report describes the owner as a single externally owned account. A compromised key could install an attacker-controlled validator set and then forge L2 state proofs.
• The bridge's upgradeable proxy lets its admin swap the implementation instantly, with no timelock or governance vote, which the report calls a single point of failure.

The author sketches a combined attack chain: compromise the owner key, replace the validator set, forge a proof for a fake mint event, call releaseTokens, and exploit the reentrancy bug to double-release assets. In the report's words, the result would be effectively unlimited minting of bridged tokens on Ethereum.

Medium and low severity issues

Among the medium findings, the report lists a withdrawal finaliser that forwards ETH before incrementing a nonce, a pause function that emits no event and therefore hampers off-chain monitoring, and a fee-recipient setter whose role is tied to a contract that can be upgraded without a timelock. Lower-severity items cover a rewards claim function that lacks a reentrancy guard, a deposit cap setter with no bounds check that could freeze deposits if abused, and an emergency withdraw function gated by a multisig with no time lock.

Recommended fixes

The remediation list is conventional. The report recommends adding OpenZeppelin's nonReentrant modifier to all external state-changing functions, reordering state updates ahead of external calls under the checks-effects-interactions pattern, and moving the owner to a multisig such as a Gnosis Safe behind a timelock, with a 2-of-3 signature scheme and a 48-hour delay suggested for validator set changes. It also proposes replacing the instant proxy upgrade with a two-step, timelocked process built on OpenZeppelin's TimelockController, plus explicit pause events and whenNotPaused enforcement on user-facing functions.

Reasons for caution

The document warrants scrutiny before being treated as authoritative. It appeared on a personal dev.to blog rather than from a named audit firm, and it includes no independent verification, response from Hyperliquid, or on-chain confirmation. Contract addresses in the text are truncated. The internal dates also conflict: the post is dated 23 September 2026 yet describes an audit window of 12 to 26 October 2026, after the publication date, and the executive summary's count of six medium issues does not match the mixed medium and low severities in its own findings table. Until a recognised party corroborates the work, it is best read as one engineer's review rather than an official audit.

Why it matters

Bridges holding billions in user assets are among the most attractive targets in crypto, and the failure modes named here, single-key admin control, untime-locked upgrades, and transfer-before-state-update patterns, are exactly the weaknesses security engineers treat as must-fix in any bridge design. If the findings are accurate, remediation is urgent given the value at stake. Even if they are not, the episode illustrates how unverified audit claims can circulate widely on developer platforms, and why both users and protocol teams benefit when audits come from identifiable, accountable reviewers with reproducible methodology.