🚨 GoPlus Security Alert: On October 31, the official Flap and Kintsu websites suffered DNS hijacking attacks. The attacker likely compromised a domain registrar, with more than 10 other domains also hijacked alongside Flap and Kintsu. By manipulating DNS, the attacker redirected traffic from official project domains to malicious clone sites to steal assets. ⚠️ How Funds Are Stolen: Users who click “Connect Wallet” on the clone sites are redirected to a malicious wallet-connection or drainer page. The theft takes two forms, with attack characteristics pointing to the #StepDrainer# group: 1. Direct native-token transfers: Users sign a transaction sending BNB to the attacker’s Safe. 2. ERC-20 approval abuse: Users approve the Safe to spend their tokens. The attacker then calls `transferFrom` to move the tokens. Attacker-controlled Safe recipient address: 0x24497068cA4166ca32a04ae530ce00Cf79755bD5 Safe’s sole owner / execution address: 0x33dfc810365193bff54326812d7df34b3e438da3 🚑 Recovery Status: Kintsu is back online ( Flap is also back online ( with remaining available as an alternative domain. The cause of the DNS hijacking is still under investigation. 🛡️ Security Recommendations: 1️⃣ Stay alert to unusual behavior or anything that differs from the site’s usual behavior. DNS hijacking can redirect you to a malicious clone. 2️⃣ If you signed a suspicious transaction or notice a suspicious transfer, investigate immediately and move your remaining assets to a fresh, secure wallet as soon as possible. 3️⃣ Use tools such as the GoPlus security extension to check for and revoke suspicious token approvals promptly.

DeepScan’s AI audit flagged the @zkLink_Official vulnerability in just 10 minutes. We recommend that project teams use DeepScan AI audits for continuous smart-contract scanning to strengthen contract security and reduce related risks. Full report: Benchmark update:

1/4 ⚠️ Exploit Breakdown: zkLink Nova Ethereum Bridge Attack On October 29, an attacker withdrew 22.43129453 ETH and 11 different ERC-20 tokens from zkLink Nova’s L1 custody contracts in a single transaction. The stolen assets were worth approximately $797,016.48 at the time of the attack. 🔍 Root Cause: The vulnerability was in zkLink Nova’s `Arbitrator.claimMessage`. The function uses `finalizeMessageHash` in transient storage to record the hash of a message just authenticated through a callback from the source chain’s canonical message service. The value was not cleared after the call. The function also did not require a fresh authentication callback for every call, allowing an already-authenticated message to be reused.

⚠️ Exploit Breakdown: Polymarket User Asset Theft On October 29 (UTC), user assets were stolen on Polymarket’s international site, Polymarket[.]com. A supply-chain compromise of third-party performance monitoring provider DebugBear’s RUM script delivered malicious code to user pages. The code abused users’ trading and signing permissions. Onchain analysis shows that the primary attack path involved 710 DepositWallets and 731 addresses, with approximately $2.71 million in losses. Address counts do not represent unique users. Polymarket subsequently stated that it had fixed the issue and restored service, pledging full reimbursement for affected traders. Refer to subsequent official announcements for actual reimbursement progress. 🔍 Attack flow: 1. The malicious script was delivered through: cdn.debugbear[.]com/C7xcKKrjUnXK.js 2. It read Polymarket session and account context, traversing React state to locate the existing trading client and signer. 3. It constructed malicious orders, ERC-1155 batch transfers, or EIP-712 DepositWallet batch messages, requested signatures through the existing signer, and submitted the operations to the Polymarket relayer. 4. USDC.e was swapped into POL through Relay Router and sent to the primary consolidation address hardcoded in the malicious script. 5. Funds were then distributed across multiple addresses. Some were bridged to Ethereum, swapped, and consolidated into ETH. How DebugBear was initially compromised—and exactly which publishing permissions were abused—has yet to be disclosed in an official postmortem. Attacker’s primary consolidation address: 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18 🛡️ Security recommendations: 1️⃣ If you used Polymarket[.]com during the affected window, close old tabs and access the site again on a trusted device through official channels. Do not continue using the trading client from a potentially compromised page. 2️⃣ Preserve evidence and check all assets, including stablecoins, POL, and ERC-1155 positions. Save transaction hashes, signature prompts, and browser records to support subsequent reimbursement and investigation. 3️⃣ Revoke session keys and onchain approvals you no longer need. Check for anomalous ERC-20/ERC-1155 approvals. Revoking approvals cannot recover assets already transferred out. 4️⃣ Watch for phishing scams exploiting the incident. Trust only information published through official channels. Never give passwords, verification codes, private keys, or seed phrases to supposed “reimbursement support,” and never pay “unfreeze” or “verification” fees.

🚨 GoPlus Security Alert: Binance Multi-Chain Hot Wallet System Compromised Approximately $5.8B has been stolen from Binance’s multi-chain hot wallet system. Roughly $3B of the stolen funds have been frozen so far. Binance US is an independent platform and is not affected. BNB Chain was not attacked, and no Ethereum or EIP-7702 vulnerability is involved. On-chain evidence strongly supports unauthorized outflows. The attacker obtained valid EIP-7702 authorization signatures for the Binance 14 hot wallet, delegated the wallet to a malicious contract, and then batch-transferred ETH and 63 tokens. The attacker further took control of USDC held in Hot Wallet 34. EIP-7702 was used to increase the efficiency of asset movement. The malicious EIP-7702 delegation on Binance 14 was cleared at 00:10:35 UTC. The root issue appears to be abuse of the signing or withdrawal system. Authorization signatures across 50+ consecutive nonces, direct signed transfers from other wallets, and simultaneous multi-chain theft make “signing infrastructure compromise” more likely than “raw private-key leakage.” Multiple private-key leaks or a software supply-chain attack cannot yet be ruled out. Attacker-related IOCs: Primary attacker address: `0x7C8601d4645b93cea45F71e118A729332e6B5CA0` Malicious EIP-7702 implementation contract: `0x63e842B054Bd624a465454D533C33F573e9c6fAe` Ethereum main consolidation address / Exploiter 2: `0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c` 📌 Security Recommendations: 1. Exchanges, custodians, and high-value wallets should block EIP-7702 authorizations from high-value EOAs by default. When use is required, enforce an implementation-contract allowlist, chain-ID restrictions, independent approvals, and spending limits. Do not sign authorizations for consecutive future nonces. 2. Avoid letting one hot wallet serve as a full operator for other smart wallets. Apply least privilege by target contract, function, asset, amount, and time window. Separate signing policies and approval domains across chains, wallets, and business lines. Limit hot-wallet balances so a single signing authority cannot reach dozens of tokens or billions of dollars in assets. 3. For regular users: watch for phishing that exploits this incident. Trust only official Binance channels. Do not give passwords, verification codes, private keys, or seed phrases to any “compensation support.” When withdrawing, confirm the token and network status, test with a small amount first, and do not switch to unsupported chains out of panic.

⚠️ Unauthorized fund transfers on @predictdotfun, the BNB Chain prediction market. About 400,000 USDT was moved from user wallets without authorization. The team has said it will fully reimburse affected users. Early investigation points to a possible compromise of an API docs site hosted by a third-party provider. Predict[.]fun has taken the docs site offline as a precaution. If you recently used the related API docs or example code, check your accounts and key security now. Stay #SAFU#!

🚨 GoPlus Security Alert At Hexacon 2026, researchers demoed 4 bugs against Apple iOS / iPadOS / macOS ( ). One-click: open a malicious PDF in iMessage or Signal and it can run code, then exfil local messages to a remote server. Appears tied to CoreGraphics CVE-2026-86950. Affected: iOS / iPadOS < 26.7.1 macOS Tahoe < 26.7.1 Sequoia < 15.8.1 Apple shipped emergency updates 26.7.1 / 15.8.1 on Sept 28: ⚠️ Do not open any suspicious PDF. Update iPhone, iPad, and Mac now, and stay on the latest OS.

🚨 UNCX Vesting V2 exploit breakdown: ~$1.5M drained across 4 chains On Oct 14, @UNCX_token Vesting V2 was exploited on Ethereum, BNB Chain, Base, and Robinhood Chain. About $1.5M in total. LP locks and legacy Vesting contracts were not affected. UNCX has put containment in place: higher fees, tighter fee-exemption rules. Affected projects and users should watch the official follow-up on remediation and recovery. 🔍 Root cause: share-accounting bug A flaw in `VestingManager`. The same shares were deducted again by `cancel()` after `release()`, so total shares in the shared pool were over-reduced. Remaining small positions then had outsized withdrawal power. How it worked: - `release()` paid out by a position’s share of the pool, then reduced the pool’s total shares. - A top-up lock minted new shares at the then conversion rate and updated the position’s nominal locked amount. - `cancel()` recalculated vested shares from that updated amount, without covering shares already released. Refunds used the nominal token amount. 📍 Affected Vesting V2 contracts Ethereum `0xa98f06312b7614523d0f5e725e15fd20fb1b99f5` BNB Chain `0x7f3f9f4ed8987b78adc448a840169a0fd5affaab` Base `0x7ca3de7d58a0bcad115184597553485a919320c5` Robinhood Chain `0xb31eaefa2a0bdc53df6d7a7f0f289b6ee1a8aaf3` 🔎 Addresses identified Attacker `0x78c9b11853e4f183a34c63ffd1924d2319a2f5b3` Funded with 3.5 ETH before the exploit by `0x6D2Afff4Fc6FF46564467762c4aA35812680D606` Attack contract `0x6cebdf095172b355121b93962017975c4601f26c` Profit-receiving contract `0xf6d072254eb8a9b06e0ba21221b498332c1bc35e` Copycat attackers and MEV bots also joined in. Follow-on exploits showed up on all four chains. These addresses are not the full set. Sample tx

Vanar Roundtables: Season 1, Episode 6🎙️ Tokenizing Work: Can AI Organisations make Web3 useful again? Web3 has tokenized memes, attention, and speculation. Now the question is whether it can tokenize something more meaningful: real activity, reputation, and work. For years, tokens have been connected to hype, communities, narratives, and market cycles. But AI Organisations may change what tokens can represent. What happens when an Organisation can take orders, deliver services, earn reputation, build a public track record, and prove activity on-chain? Can tokens finally connect to work being done, value being delivered, and reputation being earned? On this roundtable, we’ll explore whether AI Organisations can help move Web3 beyond speculation and create a new model where tokens are connected to execution, proof, services, reputation, and real on-chain business activity. Joining us: @LLMTUNE_IO: Zakaria Tchikadze, COO, @ZTchikadze @demos_network (Demos Agentic Commerce Standard): Jacob Ortiz, Senior AI Blockchain Architect Engineer, @iamjacobi @QoreChain : Liviu Epure, Founder and CTO, @epure_liviu @GoPlusSecurity : Izzet Elpeze, Head of Technical Support, @0xelpeze @moonrush_space : Blazz, CMO 📅 Thursday, 15 October 2026 🕐 13:00 pm UTC 📍 X Spaces:

⚠️ Breakdown: Papertrade BBO oracle manipulation — ~$1.28M taken 8 hours after launch On Oct 10, 2026, HyperEVM perp venue @papertrade_xyz went live, with $85.3M in pre-deposits and TVL reaching $118M within 24 hours. About 8 hours after launch it was hit by an oracle manipulation attack. Loss: ~$1.28M. This was a cross-market oracle and quote-manipulation incident. The suspected attacker first opened oversized synthetic longs and shorts on Papertrade, then used real capital to buy and sell ETH on Hyperliquid, briefly displacing Hyperliquid’s BBO mid. That displaced mid was then used for execution and PnL on Papertrade. The resulting PnL was paid by the Martingaler LP. 🔍 Root cause 1. Instant BBO from one market was the oracle Opens and closes both read the Hyperliquid best-bid/ask mid directly. The official docs explicitly state there is no max-deviation cap, no TWAP, no lookback, and no independent reference price. A non-zero, non-crossed BBO could therefore be accepted even if it had been manipulated. Papertrade’s own risk docs identified “Hyperliquid BBO manipulation” as a major protocol-level risk before launch: 2. 1,000x leverage turned a tiny move into a large payout On hundreds of millions in notional, pushing ETH ~10–14 bps was enough to generate hundreds of thousands of dollars in Papertrade PnL. Trading loss on the external venue was far smaller than the synthetic PnL paid by the LP. 3. The per-position cap was bypassed by splitting The per-position notional cap was ~$10M. The final $297M short was split into 30 positions of ~$9.9M each, just under the limit. Directional OI controls still left ~$1B of headroom, so existing controls did not meaningfully constrain aggregate exposure in this case. 4. LP capital did not match the exposure The Martingaler LP is the sole counterparty, and its pool is largely built from trader losses. Public data showed ~$3.14M in LP against hundreds of millions in notional, up to 1,000x. Available LP capital was severely mismatched with the potential payout. 🔗 Attack flow 1. Displace the upstream BBO The suspected manipulator executed concentrated buying and selling on Hyperliquid, moving the ETH perp’s best bid and ask. Papertrade used that mid as its execution price, so the distorted BBO mid fed directly into Papertrade’s pricing. This activity occurred on HyperCore’s order book and does not map to a single HyperEVM transaction hash. 2. Open the first high-leverage positions Once the upstream BBO had shifted, the suspected manipulator submitted signed orders to the Papertrade relayer. The relayer then called the Exchange contract to open the positions. The relayer appearing in the `from` field should not, by itself, be treated as the attacker. 3. Split positions to bypass the per-position cap The per-position notional cap was ~$10M. The suspected attacker split the exposure into ~30 positions of ~$9.9M each, for total exposure far above the single-position limit. Batch that appears to include ~30 shorts: 4. Trade the other way and close in profit After the Papertrade positions were in place, the suspected manipulator traded in the opposite direction on Hyperliquid so the BBO moved in favor of those positions. With no TWAP, no max deviation, and no lookback, the distorted mid was used directly to close the positions and calculate PnL. 5. Position termination path About 30 related positions were subsequently terminated. This transaction appears to correspond to the batch termination or suspected liquidation path: 📌 Addresses Suspected attack / manipulation Funds receiver / suspected coordinating address Final suspected liquidation caller Papertrade trading / settlement contract 🛡️ Security recommendations Simply blocking the suspected attacker address does not address the root cause. 1. Stop using an instant BBO as the only settlement price. 2. Use Hyperliquid’s multi-venue weighted oracle or mark price as a reference, plus TWAP, deviation limits, and freshness checks. Official oracle docs: 3. Bind total OI, per-address OI, and max payable PnL to LP capital that is actually available. 4. Trigger circuit breakers on rapid long/short reversals by the same address, large trades on external markets, and anomalously high win rates.

Binance, Robinhood, and Coinbase are shipping AI advisors and trading agents for exchanges and wallets. The race is no longer whose model is smarter — it’s who lets an agent use real funds inside a provable, auditable, revocable, loss-capped boundary.

#Ledger# devices bought through reseller CryptoBillis were tampered. Funds deposited on those units were drained. Loss is about $90M. This is not a one-off. GoPlus reminder: buy hardware wallets only from official channels → check the packaging and seal → verify authenticity and activation status on the official site. Wallet makers should also ship tamper-response as standard — including wiping keys if the device is opened — to cut off this class of risk. Main attacker addresses (per Specter and tanuki42): Bitcoin： bc1qjqgwejnp8dc0x2938x9n9954hj97t82unx49dl bc1qqnkwurxs99xkx5t4yffqhq3u6qwy0qpjyujtm9 bc1qgqheemzla77pesl227hdtgf5ykz62d0zvld26n Tron： TK6DWNpNe1w2iJRNFpU8aHdrPTATxvXT6C TBkcUMYC7CkTK99tkTnaStQVBastfrs9d9 TCGE3xp6YGRKXxDZiLfysgJW3f22KfMNsW TSDWtuZ2pARUVz4v3PkL2hi3iXPjowAr5a EVMs： 0x69c8f401cfc6cd40ac94691d6d7c48e3b7a47841 0x033636e45d519bebb7b5c2520ca6ce56fbdb4f7a 0x83aeac166f6832ae3500000a24510a95a052a599

🥷 Hack or insider? Security analysis of the $12.5M loss at 79thVault BNB Chain project @79thVault lost about $12.5M after a privileged admin address was used without authorization. Close to 10,000 holders are affected. A leaked operator key and insider activity are both still open. 1. Root cause — privileged function + operator key compromise (or an insider) The 79AU contract has a function restricted to `OPERATOR_ROLE` (selector `0x2a2c5923`; source unverified on BscScan). On-chain calls show it can move $79AU from a chosen address — this time the 79AU/USDT pair — to any recipient, then call `sync()` to update the pair’s recorded reserves. Effect is backdoor-like. 2. Key leak, or insider? `OPERATOR_ROLE` was held by `0x019bD8ED017D11AF0eB24d28DCdd0f9930c85cA3`. No multisig. No timelock. In the incident window (UTC 07:25–08:19, almost an hour) that address executed 7 privileged calls and moved 2.01M $79AU (10K / 100K / 100K / 300K / 500K / 500K / 500K) to `0xc3E90f78A918594a605d584887b2775F4b80A099`. The transfers coincided with a sharp spike in the $79AU price. The role was revoked after the incident. 3. Fund flow The receiving address sold the $79AU into the pool and drained the USDT, then converted the proceeds to 16,249 BNB and consolidated them to `0x629B368c6BF1a9f190e38f21235033FEcE8A6231`. Aside from several smaller transfers of 10–15 BNB each, purpose still unclear, most of the funds now sit at `0xa9537B40b02Af7Af8f1543aea3691992B2174F89` — 14,394.92 BNB (~$11.03M). No further movement yet. 4. Points in question The contract is not open-sourced, and it contains a privileged function with backdoor-like effect. Centralized-control risk was high. The on-chain “bounty negotiation” message was sent from the same privileged address involved in the incident. Using that address to talk to an attacker would be unusual, and the message’s authenticity is still in question: The project’s X post only called it a vague “system upgrade.” No detailed note yet on the suspected key compromise, the role-revocation tx, or the loss breakdown. That limited disclosure leaves open whether users have been given enough information.

📢 GoPlus Service Update #Abstract# (chain ID 2741) and #Blast# (chain ID 81457) are shutting down. GoPlus will end Token Security API support for both chains on October 19, 2026. Token Security API coverage on all other chains is unchanged.

🥷 Hack or insider? Security analysis of the $12.5M loss at 79thVault BNB Chain project @79thVault lost about $12.5M after a privileged admin address was used without authorization. Close to 10,000 holders are affected. A leaked operator key and insider activity are both still open. 1. Root cause — privileged function + operator key compromise (or an insider) The 79AU contract has a function restricted to `OPERATOR_ROLE` (selector `0x2a2c5923`; source unverified on BscScan). On-chain calls show it can move $79AU from a chosen address — this time the 79AU/USDT pair — to any recipient, then call `sync()` to update the pair’s recorded reserves. Effect is backdoor-like. 2. Key leak, or insider? `OPERATOR_ROLE` was held by `0x019bD8ED017D11AF0eB24d28DCdd0f9930c85cA3`. No multisig. No timelock. In the incident window (UTC 07:25–08:19, almost an hour) that address executed 7 privileged calls and moved 2.01M $79AU (10K / 100K / 100K / 300K / 500K / 500K / 500K) to `0xc3E90f78A918594a605d584887b2775F4b80A099`. The transfers coincided with a sharp spike in the $79AU price. The role was revoked after the incident. 3. Fund flow The receiving address sold the $79AU into the pool and drained the USDT, then converted the proceeds to 16,249 BNB and consolidated them to `0x629B368c6BF1a9f190e38f21235033FEcE8A6231`. Aside from several smaller transfers of 10–15 BNB each, purpose still unclear, most of the funds now sit at `0xa9537B40b02Af7Af8f1543aea3691992B2174F89` — 14,394.92 BNB (~$11.03M). No further movement yet. 4. Points in question The contract is not open-sourced, and it contains a privileged function with backdoor-like effect. Centralized-control risk was high. The on-chain “bounty negotiation” message was sent from the same privileged address involved in the incident. Using that address to talk to an attacker would be unusual, and the message’s authenticity is still in question: The project’s X post only called it a vague “system upgrade.” No detailed note yet on the suspected key compromise, the role-revocation tx, or the loss breakdown. That limited disclosure leaves open whether users have been given enough information.

🚨 GoPlus Security Alert: On Base, a vault contract that no project team has publicly claimed was hit. 1,783.067 aBaswstETH was taken out, then redeemed on Aave V3 for about 1,783 wstETH. Loss is roughly $6 million. The vault holds a position on Aave V3 Base, sized in the tens of millions. Aave’s core lending contracts and Base itself were not attacked. 🔍 Root Cause: multisig governance and access-control failure. The exploit contract (0xcdFE9130…) was added to the vault’s borrow allowlist through a Safe multisig. The Safe flow may have been socially engineered or phished, or this was insider collusion. The team had not executed any Safe transaction for 25 days. These two were executed suddenly. Most concerning: about $31.7 million in assets is still sitting in the vault, at risk. Someone even sent the attacker an on-chain message pushing them to withdraw the rest and asking for a tip. Still zero response and zero announcement from the project team. Attacked vault: 0xD1895f2019c2152FC2b9022D57f19198c4CFCABC Attacker: 0x0B5126e1bc27C0de77e02e97945760A674EdB034 Related addresses: 0xcdFE91301356da873562EF513828a60dba1F569d 0xC73448432a05deeA5Ea18a07D3b5d9ccf6297f8D Malicious authorization (Safe execution): Attack transaction (first borrow, 1 aBaswstETH): Attack transaction (Aave redemption, 1,783.067 wstETH):

🚨 GoPlus Security Alert: A user got drained for ~$170K in $LINK after signing a malicious #Permit2# transaction. Victim: 0x71619d71474F8D0AAa9C18a757be7617686B499b Phisher wallets: 0x0000db5c8B030ae20308ac975898E09741e70000 0x0000cdCa01087D340e8fA4339b121B69a8aE0000 0xA6809aeDEbFA10A0C2dbcF3363cB0Ff37866f73D 🛡 Security Tips: 1. Follow the #GoPlus# Anti-Phishing “4 Don’ts”: 🚫 Don’t click unknown links 🚫 Don’t install unverified software 🚫 Don’t sign transactions you don’t fully understand 🚫 Don’t send funds to unverified addresses 2. Install the GoPlus Security extension to block phishing links, risky signatures, malicious approvals, and suspicious transactions in real time 👉