@OneKeyHQ desktop client has a vulnerability related to "plaintext storage of private keys": The private key of the HyperLiquid proxy wallet is written directly to the local IndexedDB in plaintext JSON (prefixed with |HLP|), and can be read back without the wallet password. Limited harm: Limited to the proxy private key (corresponding to the HyperLiquid transaction sub-account), and requires the attacker to have prior access to the local file (Trojan/physical access/obtaining a backup); not remotely stealable. poc: cat "/Users/xxxxxx/Library/Application Support/@onekeyhq/desktop/WebStorage/4/IndexedDB/indexeddb.leveldb/000004.log"

The free Claude Max 20x subscription vulnerability is being abused.

$FCOW 被攻击，损失61 k。 原理：FCOW 的卖出路径会把调用者名义卖出量当成燃烧基数，在结算前直接从主池 FCOW/USDT Pair 的共享 FCOW 余额里扣币并 sync()，导致池子储备被单边压低、价格基准被提前改写。 漏洞函数：核心在卖出分支里触发的 ffa55a6ca(uint256 a)（由 _transferToken 的 sell path 调用），它会按 a * stor_16 / 100 计算 burn 量，从 __mainPair 扣除 FCOW 并立即执行 ISwapPair(__mainPair).sync()。 利用手法：攻击者先闪借 USDT 买入大量 FCOW 建仓，再通过多个 helper 地址分批卖出；每次卖出都先触发“从 Pair 烧币 + sync”，再按被抬高的价格拿走更多 USDT，重复多轮后还款并获利。

我们分析 #gate 被盗 170 w的资金流向，看起来黑客已经混币了。 分析资金行为，最终发现然后绕了几层，兜兜转转都转移到 0xB88dA2373084e42358E7bBE9b76BdcF734Aaa013 这个地址中。 这个地址可能是一个混币系统的归集地址。 因为这个地址还有其他的大额资金入账。分析这些上一层地址，他们的行为就是接受币，然后转移到 0xB88dA 这个地址。 欢迎网友进行补充。

$JL 被盗50 k USDT。 这个漏洞的根因是：JL 合约在卖出/池子销毁这条结算路径里，把 ammPair 自己持有的 JL 也当成可被本次调用消耗的库存来处理。JL 的隐藏 pair-side burn 入口 0xb1faeac6(uint256)（与 burnPool(uint256) 同族逻辑）会直接减少 ammPair 地址的 JL 余额，随后由 pair 0x565BeCe114D88A1B59DcB0429ebEDa04E1A8663c 调用 sync()，把这个被单边压到 near-zero 的中间态写成新的官方储备；问题不在普通税费，而在共享库存被错误销毁后又被 sync() 固化为价格基准。 黑客先借用了项目白名单 helper 0xeb211... 拿到极小量 JL，再触发上述 pair-side burn，把池子的 JL 几乎烧到只剩 1 wei，并让 pair sync() 后形成 50,000 USDT : 1 wei JL 的极端储备。随后他再通过 Router 走一次极小的反向卖出，虽然真正进入 pair 的净 JL 只有约 0.00000384 JL，却因为储备已经被写坏，最终从池子里换走了接近 50,000 USDT。

RPT(Range Pool Token)被套利3.7k DAI 漏洞原理：add() 和 remove()/removeAll() 都通过 value(amount)、redemptionValue() 和 totalTokens 直接按 token 的原始 amount 记账，没有区分 FRAX/MIM 这类脱锚币和 DAI/LUSD 的真实市场价格。结果是折价稳定币在 add(address token, uint amount) 里会被按满价铸成 RPT，在 remove(address token, uint amount) / removeAll(uint amount) 里又能按满价换出更贵资产。 利用方式：黑客先在外部低价买入 FRAX/MIM，再调用 add() 把它们按 1:1 面值存入池子，拿到被高估的 RPT。随后再用 removeAll() 和多次 remove(DAI) 把池里的 DAI/LUSD/FRAX/MIM 提出来，并在 Curve 卖回 DAI，赚走折价买入和满价赎回之间的价差。 资金来源: Binance

$JB被攻击， 损失50k。核心问题在 poolTransferToDeadAndSync()、tradeRouterBurnPool() 和 poolRewardTransfer()：这些函数会先改写 _ammPair 的库存，再立刻 sync() 把被压歪后的状态固化成新的 AMM 基准。攻击者随后就能利用这个被污染的基准，通过正常的买卖/反向结算路径把另一侧剩余库存兑现出来，形成可获利的单笔或分步套利。

$WHALE 被攻击，损失3.4k。 漏洞原理: WHALE 的 _stagePending() / _settlePendingLpAdd() 与 WHALEHashrate.notifyCredit() 之间存在记账基准错绑：攻击者可以先通过向 Pair 侧写入失衡流动性改写共享池子的实时 basis，再让官方结算路径按这个被改写的 live basis 给自己过度发放 hWHALE/registeredLp 等权益。 漏洞的本质不是普通加池或普通奖励，而是“真实投入”和“后续 credit 使用的结算基准”脱钩，导致协议把本调用刚抬高的池子状态直接当成可记账权益；历史攻击再沿 WHALEHashrate 的奖励兑现轨道变现并卖回外部池子获利。