Phala Network — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Phala Network, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Phala Network reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, across Other, EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Phala Network
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Phala Network: Limited availability of `balance_of(...)` method
Phala Network's Pink contract runtime documents the balance_of chain-extension as callable by any contract, but the implementation adds an ensure_system guard that restricts invocation to the system contract alone. As a result, ordinary user contracts that call balance_of receive a BadOrigin dispatch error and cannot query balances, breaking documented functionality for downstream contracts. The report proves this with a Rust unit test that deposits funds and calls direct_balance_of through a non-system checker, which fails with BadOrigin, and recommends deleting the guard so the method matches its documented any-contract availability.
Phala Network: A cache that times out can be recovered
Phala Network's Pink chain-extension provides a local KV cache for contracts performing off-chain computations. The `LocalCache::set_expire` entry point only triggers deferred garbage collection via `maybe_clear_expired`, so expired keys are not guaranteed to be purged on any given call; they remain discoverable in `storages` and can have their `expire_at` reset into the future. This lets a caller who can reach `set_expire` revive or perpetually extend stale cached values even though `get` treats the same key as expired and returns `None`. Because the cache is intended to store volatile off-chain data such as API responses rather than authoritative on-chain assets, the practical impact depends heavily on how individual contracts use it, and the judge set severity to Medium.
Phala Network: An attacker can crash the cluster system by sending an HTTP request with a huge timeout
Phala's pink chain-extension exposes `batch_http_request`, whose `timeout_ms` is user supplied and unchecked. The extension builds `Duration::from_millis(timeout_ms + 200)`, and since Rust's `+` operator panics on overflow, a caller passing a timeout above `u64::MAX - 200` crashes the worker process rather than returning an error. Because the request is free to send, an attacker can repeat it across all workers to shut down the cluster with a zero-cost denial of service. The Phala maintainer acknowledged the bug but contested the severity, and the proposed fix is to clamp the addition with `saturating_add`. On code4rena the finding itself was assessed as an invalid validation despite the confirmation.
Phala Network: An attacker can bloat the Pink runtime storage with zero costs
Phala's Pink runtime sets its Existential Deposit to a single base unit despite one PHA being divisible into 1e12 base units. Because an account stays alive with just 1e-12 PHA, an attacker can mass-create dust accounts at near-zero cost to bloat runtime storage and drive up storage fees for all users. The sponsor confirmed the finding in the Code4rena 2024-03 Phala contest. A diff raising the ED to one CENTS is the recommended mitigation, which returns the deposit to its intended anti-dust-abuse purpose.