📢GoPlus #DeepScan Comprehensive Upgrade: A New Paradigm of AI-Powered Smart Contract Security. Smart contracts hold funds — and hackers are already using AI to uncover deep-layer vulnerabilities. One-time audits can no longer keep pace with today's attack-defense dynamics. The industry must evolve toward AI-powered, continuous security: higher efficiency, lower cost, full-lifecycle protection. GoPlus DeepScan delivers three interconnected modules forming a closed-loop, continuous security service for the entire smart contract lifecycle: AI Contract Audit, Continuous Security Monitoring, and Token Security Self-Check. Features AI Auditing AI-powered deep analysis of contract source code, permission management, and business logic. Systematically detects syntax vulnerabilities and business-logic flaws, and delivers a structured audit report — including security scores, key findings, issue details, and remediation recommendations. Security Monitoring Post-audit, always-on assurance for live contracts. Tracks newly disclosed vulnerabilities, on-chain attacks, and status changes in external dependencies (oracles, cross-chain bridges) in real time. AI continuously assesses impact, triggers targeted re-reviews, and issues alerts — moving beyond the "audit as finish line" model. Token Security Checking A rapid pre-launch self-inspection tool for tokens preparing to launch or list. Identifies common high-risk characteristics in minutes, including: Honeypot detection, Malicious mint detection, Blacklist mechanism detection, Abnormal buy/sell tax detection, Owner privilege & trading restriction risks. Benchmark An open-source benchmark built from real-world attack incidents. Extracts vulnerable contract source code from attacked projects to systematically evaluate AI capabilities in vulnerability identification, attack-path understanding, contextual reasoning, and audit stability. Nearly 100 real, representative attack cases from May 2025 to date, continuously updated. Use Cases Developers — Cost-effective, high-efficiency security scanning with audit-grade quality, enabling fast, confident innovation. Project Teams — Pre-launch scanning as a complement to traditional audits; continuous auditing and monitoring during operations to stay ahead of attackers. Exchanges — Enhanced pre-listing security review efficiency and capability; continuous monitoring as routine risk control to catch new threats early and minimize post-listing incidents. Get Started GoPlus DeepScan is live — try it now: **deepscan.gopluslabs.io/** AI Auditing Benchmark: github.com/GoPlusSecurity/ai…

🚨 GoPlus Security Alert: Node.js October 2026 Security Updates On Oct 21, Node.js patched 10 vulnerabilities: 4 high-, 3 medium-, and 3 low-severity. CVE-2026-111497 is an out-of-bounds write in the Brotli decoder. It can lead to remote code execution when an app processes untrusted compressed data. The other high-severity issues are `dns.resolve` truncating domain names that contain NUL characters, and two TLS certificate hostname-verification bypasses. The medium- and low-severity issues cover Keep-alive response handling, repeated random values, ZIP file handling, and the permission model. Patched releases: Node.js 22.23.4, 24.22.1, 26.12.1. Affected release lines vary by vulnerability. Running Node.js does not by itself mean there is an exploitable entry point. nodejs.org/en/blog/vulnerabi… ⚠️ Checks and mitigation steps 1. Know what is actually running. Inventory the Node.js executable and image source actually in use across services, nodes, and containers, and check every replica. The version reported by a local `node -v` command may differ from the version used by the application process. 2. Prioritize upgrades based on exposure. Prioritize services that decode Brotli-compressed data from external sources, or that use untrusted input to construct DNS queries or specify HTTPS/TLS connection targets. Move to the patched release for that branch, or a verified vendor backport. Then restart and verify the running version on every node. 3. If you cannot upgrade now, restrict exposed inputs. Restrict the processing of untrusted compressed data, and limit which connection targets can be specified through untrusted input. Review logs for decoding errors, abnormal process behavior, and certificate alerts. These measures do not replace a runtime update.

🚨 GoPlus Security Alert: Two unauthenticated RCE vulnerabilities in PHP PHP’s official security advisory confirms CVE-2026-109618 and CVE-2026-109619 can both lead to unauthenticated remote code execution. Patched releases are available: 8.2.35, 8.3.36, 8.4.27, 8.5.12. php.net/archive/2026.php#202… ⚠️ Checks and mitigation steps 1. Know what is actually running. List each entry point, service, node/container, PHP SAPI, the executable path and PHP version used by each running worker, vendor package or image source, config overrides, and public reachability. 2. Upgrade first. Schedule public-facing mod_php first, then other internet-facing PHP services and any internal service that untrusted requests can reach. Move to the patched release for that branch, or a vendor package with a verified backport. Check compatibility and prepare backups and a rollback plan before upgrading. After the upgrade, restart all workers and verify the running PHP version on every node. 3. If you cannot upgrade now, reduce public exposure. Restrict external access. Review upload and input size limits, and request limits.

South Korean financial firms reported customer data breaches in a row. One attacker, using ARTEX and large models, did alone what took a full team. AI flattened capability costs on both sides. The gap is who inspects their systems first. Act now.

🚨 GoPlus Security Alert At Hexacon 2026, researchers demoed 4 bugs against Apple iOS / iPadOS / macOS ( blog.calif.io/p/iphone ). 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: support.apple.com/en-us/1492… ⚠️ 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 etherscan.io/tx/0x352065378c…

⚠️ 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: docs.papertrade.xyz/#/how/pr… 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. hyperscan.com/tx/0x199de70bc… 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: hyperscan.com/tx/0xfad868110… 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: hyperscan.com/tx/0x2a337b31c… 📌 Addresses Suspected attack / manipulation hyperevmscan.io/address/0x20… Funds receiver / suspected coordinating address hyperevmscan.io/address/0x7e… Final suspected liquidation caller hyperscan.com/address/0x0762… Papertrade trading / settlement contract hyperevmscan.io/address/0x6c… 🛡️ 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: hyperliquid.gitbook.io/hyper… 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

📢 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. bscscan.com/address/0xc35ef0… 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: bscscan.com/tx/0x09f02313958… 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. xitter.cf/79thVault/status/21080…

🚨 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. basescan.org/tx/0x03f0297373… 🔍 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): basescan.org/tx/0xed265fc80e… Attack transaction (first borrow, 1 aBaswstETH): basescan.org/tx/0x0ec75c3be1… Attack transaction (Aave redemption, 1,783.067 wstETH): basescan.org/tx/0x557bfd0e85…