Skip to main content

HospoWise: The "Public Burn" Liquidity Drain (February 2026)

In February 2026, the HospoWise token protocol was exploited, leading to a coordinated drain of ETH from its primary liquidity pools on Uniswap. This incident stands as a definitive case study in Simple Access Control Failure yielding catastrophic economic results.

Technical Overview​

The HospoWise token contract included an administrative burn function intended for supply management. In standard Solidity development, such functions are strictly internal or protected by an onlyOwner modifier. However, the HospoWise implementation declared the burn(address account, uint256 amount) function as public/external without any associated access control modifiers or visibility restrictions.

Exploit Mechanism: Inflation through Destruction​

The attacker leveraged the unprotected burn function to manipulate the price invariants of the token within Automated Market Maker (AMM) pools.

  1. Pool Target: The attacker identified the HospoWise/ETH pool on Uniswap.
  2. Anonymous Burn: The attacker called the burn function, specifying the Uniswap Pool address as the target account from which to destroy tokens.
  3. Liquidity Destruction: Because the function was public and lacked parity or permission checks, the contract allowed the attacker to destroy the HospoWise tokens sitting inside the liquidity pool.
  4. Artificial Price Spike: AMMs determine price based on the ratio of two assets (for example, $Token / ETH$). By burning the tokens in the pool while leaving the ETH reserve untouched, the attacker caused the token's fair market value within the pool to skyrocket.
  5. Reaping the Arbitrage: The attacker (or a front-running bot) then performed a swap, trading a small amount of HospoWise tokens—purchased before the burn or held in a separate wallet—for the pool's remaining ETH reserves at the artificially inflated price.

Why This Matters (The "Security 101" Gap)​

The HospoWise exploit underscores that despite the rising complexity of DeFi architecture, fundamental Access Control gaps remain a primary threat. A single missing modifier on a powerful function (like burn) can invalidate the security of the entire protocol and its associated liquidity.

Mitigation Strategies​

  • Explicit Visibility & Modifiers: Always use the most restrictive visibility possible (internal or private). If a function must be public, apply standardized access control frameworks like OpenZeppelin's Ownable (using onlyOwner) or AccessControl.
  • Static Analysis Integration: Basic security scanners like Slither or Aderyn would have instantly flagged a public state-modifying function lacking access control. These tools should be mandatory in the CI/CD pipeline.
  • Unit Testing for Permissions: Specifically write test cases that attempt to call administrative functions from a non-privileged address and assert that they revert.
  • LP Supply Monitoring: Implement on-chain monitoring to flag sudden, large-scale decreases in token balances within known LP addresses that do not correspond to standard liquidity withdrawals.

Conclusion​

The HospoWise incident is a sobering reminder that "obvious" bugs can still reach production. For security researchers, scanning for unprotected administrative logic in new deployments remains a highly effective method for identifying critical vulnerabilities before they are weaponized.