Node.js Oct 21 vulnerability analysis and a security self-check Skill, now updated: github.com/GoPlusSecurity/se…

php2shell RCE analysis and a security self-check Skill. Check it item by item against your business use case: github.com/GoPlusSecurity/se…

2/2 👇 Vote for the topic you care about most 👇

1/2 🎁 DeepScan Community Nominations · Round 3 | Web3 Security Hot Topics Quantum computing takes another leap. OpenAI’s math results are all over the timeline. The community is asking: Can Bitcoin hold up? Could smart contracts get rekt? CryptoBilis, a Ledger reseller, shipped tampered wallets. About $100M was stolen. Which is safer: a hardware wallet, or an offline iPhone? Binance’s .ai domain is lighting up agentic wallets. How do you use an agent wallet without getting drained? Which topic do you care about most? GoPlus will publish a security research report based on the votes. 🎟️ Giveaway: 10 eligible participants win 10 USDT each. 🗳️ How to enter: 1. Follow @GoPlusSecurity and repost. 2. Vote in the thread post “2/2”. 3. Voting closes October 26 at 23:00 UTC. Winners and the security report will be announced afterward.

🚨 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.

6/6 V. A recurring problem: weak randomness in 2026 1️⃣ Ill Bloom / legacy CryptoJS weak RNG. Multiple thefts from May–Aug 2026. Coinspect found some wallets still used CryptoJS’s weak RNG when generating recovery phrases. Confirmed apps: RRWallet, Bexo, NanChat, Bitcoin Libre, Milo. Loss about $5.7M. coinspect.com/blog/ill-bloom… 2️⃣ Coldcard hardware wallet. On July 30, 2026, weak-entropy seeds from old Coldcard firmware were exploited. 1,816 BTC (~$116M) across 5,200+ addresses. coldcard.com/security/status These cases show the same pattern. In the AI era, the barrier to exploiting cryptographic weaknesses — particularly implementation flaws — is falling rapidly. Audits have to cover the real entropy source at seed creation, the platform RNG, and old dependencies. Checking key length, shipping a new client, or locking down custody after generation cannot eliminate the risk of seeds that were already weak.

5/6 IV. Fix: crypto.getRandomValues(bytes) After the incident, Qubic shipped v4.26.4 (github.com/qubic/wallet/rele…). The updated implementation uses crypto.getRandomValues(bytes) to fill a Uint8Array with random bytes from 0 to 255, drawn from the browser CSPRNG. This fixes insufficient randomness in seed generation.

4/6 III. Attack flow (offline enumeration + on-chain sweep) 1️⃣ Enumerate. The attacker enumerated all 2^32 possible WeakRandom PRNG seeds offline. Each produces one 55-char Qubic seed via the wallet algorithm, then KangarooTwelve derives the private key, public key, and 60-char address. Highly optimized K12 implementations were already available in Qubic’s mining ecosystem, so enumeration was cheap. 2️⃣ Match. Compare enumerated addresses against funded on-chain addresses. A hit means full control of that wallet’s key and funds. 3️⃣ Drain. From 2026-10-17 23:42 UTC, the attacker used victim private keys to transfer balances to 7 consolidation addresses. Mid-attack, some funds were already routed through intermediate addresses to a MEXC deposit address to cash out. The receiving account was later frozen.

3/6 In Sept 2026, public research and tooling on this JavaScriptCore weakness appeared (blog.drstra.in/posts/jsc-ran…). It showed a 32-bit JSC Math.random() seed could be recovered in seconds, and its subsequent outputs predicted. About a month later, that was weaponized against Qubic.

2/6 Math.random() seed strength differs sharply across JS engines. This is why the attack affected only wallets generated on Apple platforms.

1/6 ⚠️ Qubic weak-seed exploit breakdown: 1,404 wallets on Apple platforms drained, ~$1.3M From Oct 17–18, attackers exploited the @Qubic official Web wallet on Apple platforms (WebKit / JavaScriptCore). Seeds were generated with Math.random(). They enumerated all 2^32 possible PRNG seeds offline, matched the derived addresses to 1,404 funded wallets, and drained 2,939,606,531,944 QU (~$1.3M). Qubic then initiated a protective shutdown. 87.1% of the stolen funds are frozen on-chain. The remaining 12.9% was sent to MEXC, where the receiving account was frozen. Web wallet v4.26.4 is out — it switches to crypto.getRandomValues. Affected users should update. I. Who is affected 1,404 wallet addresses. Shared trait: the seed was generated by the official Qubic client in a weak-entropy environment. ▪️ Seeds generated before Oct 18, 2026, in any browser on iPhone / iPad (Safari, Chrome, Firefox — all forced onto WebKit) ▪️ Seeds generated before Oct 18, 2026, in Safari on MacBook / iMac ▪️ Seeds generated before July 2025 in the Qubic iOS App II. Root cause: insufficient entropy from Math.random() A Qubic seed is a 55-char lowercase string. Theoretical space is 26^55 (≈2^258). Actual security depends on the entropy of the PRNG’s internal state that produced it.

🚨 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