注册并分享邀请链接,可获得视频播放与邀请奖励。

SlowMist 的个人资料封面
SlowMist 的头像

SlowMist (@SlowMist_Team)

@SlowMist_Team
0 正在关注    0 粉丝
🚨 Apple has released an important security update for iOS/iPadOS 26.7.1, addressing CVE-2026-86950, an out-of-bounds write vulnerability that may lead to arbitrary code execution. As we previously reported, this update is highly relevant to the iOS attack activity we have been tracking. Apple confirmed that the vulnerability may have been exploited in highly sophisticated attacks targeting specific individuals on iOS versions before iOS 27. For crypto users, this is especially concerning given the iOS exploitation activity we have observed targeting sensitive wallet data. 🔐 Please: • Update your iPhone, iPad, Mac and other Apple devices to the latest available security updates. • Avoid installing apps from unknown or untrusted sources. • Do not open suspicious links in Safari or in-app browsers. • Treat unexpected files, links and app installation prompts with caution. Stay alert and keep your devices updated. Apple Security Update:
显示更多
We’re working closely with @bitget on the ongoing investigation. For further details, please refer to Bitget’s official updates.
[UPDATES] We are currently working with independent third-party experts Mandiant and SlowMist for a full investigation. Our first priority is our users. User balances remain intact, and Bitget's User Protection Fund covers the impact on this platform-wide incident. Bitget Wallet operates as a self-custodial wallet on a completely separate and independent infrastructure from Bitget Exchange and was not affected by this incident. Bitget Wallet users' assets remain onchain under users' control and remain unaffected. The Bitget Exchange platform continues to operate normally. Withdrawals are still temporarily paused while we complete additional security checks, and we will restore them as soon as we are confident that it is safe to do so. We know that during an incident like this, users want answers quickly. We will provide timely updates through Bitget's official channels.
显示更多
🚨 SlowMist TI Alert 🚨 MemTensor's AI memory tooling has been compromised: MemoryOS (PyPI), the company's open-source long-term memory library for LLM and AI agents, and memtensor/memos-cloud-openclaw-plugin (npm), the official plugin connecting it to the OpenClaw agent runtime. Affected versions bundle cross-platform Go binaries that execute when the package is loaded or imported: MemoryOS==2.0.34 on PyPI, and plugin versions 0.1.21, 0.1.23 and 0.1.25 on npm. You are affected if the PyPI version has been imported in your environment, or if the npm plugin is installed and the OpenClaw gateway has been started. Potential attacker actions include harvesting npm/PyPI tokens, GitHub/GitLab credentials, AWS keys, SSH keys, API tokens, environment secrets, and other developer credentials, with data sent to infrastructure under skyleen[.]fr. The affected npm plugin may also expose user prompt content. Users should remove or downgrade affected packages to known-good versions (0.1.20 for npm and 2.0.33 for PyPI), terminate sckit processes, block associated infrastructure, review network activity, and rotate credentials accessible from affected environments. You can also visit to check for free whether the npm packages, pip packages, domains, or IPs you use are safe. Reference: As always, stay vigilant!
显示更多
Thanks to @Cointelegraph for covering our investigation into the FomoPeek App Store poisoning and iOS kernel exploitation, conducted together with the @wallet security team. 🫡 We appreciate the opportunity to share our findings and help users better understand the risks and recommended response. 🌟 Read more 👉:
显示更多
🚨 On September 6, 2026, @Liquid_BTC was affected by a cache key collision vulnerability in rangeproof verification. An attacker minted ~3,998.5 L-BTC with no corresponding peg-in. Within minutes, the unbacked L-BTC was pegged out into real BTC on the Bitcoin mainnet. About 3,400 BTC was later returned to the federation peg wallet, while ~598.5 BTC remains under the attacker’s control. The SlowMist Security Team traced the fund flows on the #Bitcoin# side using @MistTrack_io and fully analyzed the incident. 🧩 Attack flow: 1️⃣ Two setup transactions first landed valid rangeproofs and commitments, while embedding a crafted payload in the locking script to seed node caches. 2️⃣ A follow-up minting output reused a colliding cache key — the same raw concatenation of proof, commitment, asset commitment, and scriptPubKey, but with different field boundaries. 3️⃣ On a cache hit, nodes skipped secp256k1_rangeproof_verify and min-value checks, accepted an unbacked commitment, and minted ~3,998.5 L-BTC. The fake UTXOs were consolidated and pegged out within minutes. ⚙️ Root Cause: The Elements rangeproof cache key concatenated variable-length fields without length prefixes. Distinct argument tuples could hash to the same key, so a positive cache hit meant skipping cryptographic verification. 🛡️ SlowMist Insight: A positive-result cache in a consensus verification path is itself a cryptographic primitive. Every field the verifier reads — and every field boundary — must be unambiguously bound into the key. Treat cache-key integrity as a mandatory item in consensus-layer audits. Full analysis👇
显示更多
🚨SlowMist TI Alert🚨 We first reached out to the team privately to responsibly disclose the issue before making any public statement. 💸 @ether_fi Loss: ~15.45 ETH 🔍 Root Cause: `AtomicQueue.solve()` lacks access control on the caller-supplied `solver` — there is no `solver == msg.sender` check, nor any signature, registration, or consent verification. The attacker first created a maliciously crafted `AtomicRequest` using the `updateAtomicRequest()` function, then forced a victim address to act as the `solver`. AtomicQueue subsequently called `finishSolve` on the victim and executed `want.transferFrom(solver, users[i], assetsToUser)`, abusing the victim's pre-existing ERC-20 allowance to drain funds. 📌 Attacker: `0xa5cc6e490bce9185fa47b421f2eac677a83b64ea` 📌 Vulnerable Contract (AtomicQueue): `0xd45884b592e316eb816199615a95c182f75dea07` Powered by Tx:
显示更多
🚨SlowMist TI Alert🚨 💸 @BeatXswap Loss: 2,984,557 BTX (~$77,512) 🔍 Root Cause: The `LiquidityVestingConvert` contract calculates BTX quotes via `_calculateQuote()`, which reads `IUniswapV3Pool.slot0()` spot price as the sole oracle. No TWAP protection, no sanity check, no deviation limit. An attacker borrowed 6,000,000 BTX via flash loan, dumped it into the V3 pool to crash `sqrtPriceX96`, then called `deposit()` twice (10,000 + 2,000 USDT), triggering `POSITION_MANAGER.mint()` at the manipulated spot price and draining BTX from LP positions. 📌 Attacker: 0x67B2f08683A735cfE6f6E57fA86909b62218C2a1 📌 Victim: 0x1e647FAADb05f2124BFCcFC003EDc06D1A90bf5D 0x9a7A92240FBAc4030b65A6E61239928d6Bcc716F 📌 Vulnerable Contract: 0x1e647FAADb05f2124BFCcFC003EDc06D1A90bf5D Powered by Tx:
显示更多
🚨SlowMist TI Alert🚨 💸 @EnsoBuild Loss: ~5.6 ETH 🔍 Root Cause: An oracle price calculation error occurred in the Enso Finance / DPI Strategy Vault. In `Controller.deposit()`, the EnsoOracle's `estimateStrategy()` is called before and after the user tokens are transferred, and shares are minted on the difference: `mint = amountAdded * totalSupply / valueBefore`. The valuation chain — EnsoOracle → ItemEstimator → `ProtocolOracle.consult()` — prices tokens via UniV3 `pool.observe()`, but the registry's `fee` field is reused as `secondsAgo`, producing a near-spot TWAP window. Due to the absence of TWAP consistency checks or price range validation—combined with the fact that the liquidity in the Uniswap v3 pool used for price calculation was inherently imbalanced—an attacker was able to swap 0.683 WETH for 268.42 FARM tokens on Uniswap v2 in a single transaction, while the imbalanced v3 pool incorrectly valued that amount at 6.3 WETH (~ 9.2x). Subsequently, an excessive number of shares were minted at an incorrect price and redeemed for profit. 📌 Attacker: `0x3196398321D77a2511d369DCB6eCa9d2aD87b73A` 📌 Victim (Strategy): `0x890ed1ee6d435a35d11051d9ed97ff457ce53b5942` 📌 Vulnerable contract: Controller impl: `0xd8D22509C1fe47516D8F82A28CFd728111F57Ef1` Oracle: `0xAb7505eB360cE0D63e8E88f7853677EcD5537DC0` Powered by Tx:
显示更多
🚨 Threat Intelligence | The StealC Info-Stealing Chain Behind the Qwen Impersonation Repository SlowMist Security Team identified a #GitHub# repository impersonating local quantized weights for Qwen 3.8 27B. A real Q4_K_M 27B package should exceed 16 GB. The asset delivered was only 487 KB — no GGUF weights, just three files: Application.cmd, a renamed LuaJIT interpreter, and an obfuscated Lua script disguised as cert.txt. The official #Qwen# project was not compromised. The repo kept the look of a normal offline model project, while the malicious ZIP sat in assets/. After deobfuscation, the script collects host data, takes a screenshot, and POSTs them to C2. When the hardcoded server fails, it reads a fallback C2 from a Polygon contract via eth_call, so operators can rotate infrastructure with a single on-chain transaction. Preserved C2 responses then delivered an inner payload we attribute to #StealC#, targeting: 🔹 Browser logins, cookies, and history — including a Chrome App-Bound Encryption bypass 🔹 Email, WinSCP, and Steam credentials 🔹 Wallet-related files and extension data, dispatched by server-side tasks MistEye reconstructed the multi-stage chain and compared 29 similar ZIPs across 23 repositories using the same Lua delivery stack. Between two collection dates, repositories, filenames, the outer PE, and the AES key had already rotated. A 27B model that downloads in 487 KB is not a model. Inspect asset size and unpack downloaded packages before running them. Read the full analysis 👇
显示更多
🚨SlowMist Alert🚨 💸 @MoonwellDeFi Loss: ~$8.7M USD 🔍 Root Cause: The protocol relied on a MAMO price from a thin market. The attacker manipulated this price, making the collateral appear far more valuable than it really was. This allowed the attacker to borrow funds from the mUSDC and mcbBTC markets and profit from the inflated collateral value. 📌 Attacker: 0x719eae70d4a83f35bf82a2740699f5db84be919d 📌 Vulnerable Contract: 0xf877acafa28c19b96727966690b2f44d35ad5976 📌 Collateral Market: 0x2f90bb22eb3979f5ffad31ea6c3f0792ca66da32 Powered by Tx:
显示更多
🚨 Recently, @COLDCARDwallet suffered a major private key vulnerability. Multiple waves of attacks resulted in at least 1,719 BTC (~$111M) in losses, involving over 5,200 addresses. Using Mk3 firmware 4.1.9 as an example, the SlowMist Security Team fully reproduced the attack chain and uncovered the truth behind the theft of thousands of bitcoins. 🧩 Attack flow: 1️⃣ After power-on, the remaining unpredictable state is reduced primarily to a single enumerable 32-bit pad (UID ^ SysTick), with the remaining state values either fixed or coming from very small enumerable spaces. 2️⃣ Attackers precisely model the three typical button-press consumption profiles (retail first-boot, empty-NVRAM, paper wallet) that advance the PRNG before seed generation. 3️⃣ From the weak random_bytes(32), the full deterministic pipeline (SHA-256 → BIP-39 → PBKDF2-HMAC-SHA512 → BIP-32 → address derivation) is reproduced offline. 4️⃣ GPU clusters brute-force the candidate pad space and button-count variations, then match the derived addresses against the global set of single-signature P2WPKH addresses to identify vulnerable wallets and sweep their funds. ⚙️ Root Cause: A build configuration error set MICROPY_HW_ENABLE_RNG to 0, disabling the STM32 hardware TRNG. The random number generation path silently fell back to the non-cryptographic Yasmarang software PRNG, whose state was almost entirely predictable, reducing effective entropy to ~40 bits (Mk2/Mk3) or ~72 bits (Mk4/Mk5/Q). 🔒 SlowMist Insight: Affected users should immediately upgrade to the patched firmware, generate a completely new seed, transfer a small amount of funds as a test, confirm the new address works correctly, then migrate all remaining funds. Full analysis 👉
显示更多
🚨SlowMist TI Alert🚨 💸 @LienFinance Loss: ~542k USD 🔍 Root Cause: The `exchangeEquivalentBonds` function in BondMakerCollateralizedEth lacks proper multiset integrity checks. It only counts total exception occurrences instead of verifying each bondID's appearance per group. By repeating a single exception bondID in the output group, attackers consumed the exception count twice, masking a missing input exception. This allowed minting new non-exception BondTokens without burning the corresponding input bonds, which were then sold for USDC from a pre-approved victim address. 📌 Attacker: 0x0d7d9023531ad1a88414e216ee2715f63561808a 📌 Victim: 0xa961684a3a654fb2cca8f8991226c0cefc514d80 📌 Vulnerable Contract: 0xda6fc5625e617bb92f5359921d43321cebc6bef0, 0x843225cf6e663e4454732d6b551a737ac7b47de0 Attackers exploited the flawed exception-counting logic to mint unbacked bond tokens, swapped them for USDC via three pre-authorized endpoints, and drained 542,144.628604 USDC from the victim. Powered by Tx:
显示更多
🚨 SlowMist TI Alert 🚨 💸 @VerusCoin Loss: ~$7.5M ⚠️ Unlike the prior 0x6990…b321 exploit, which decoupled the validated proof from the executed transfer payload, this attack hash-bound the transfers to the CCE but failed to validate the CCE’s economic backing; both exploit flawed cross-chain import validation. 🔍 Root Cause: `VerusProof.checkExportAndTransfers` verified selected CCE fields—including `hashReserveTransfers` against attacker-supplied serialized transfers and the source/destination IDs—but did not enforce the CCE’s accounting semantics. It failed to parse or validate `totalamounts`, `totalfees`, `totalburned`, CTxOut `nValue`, or whether the prior CCE outpoint carried sufficient value and assets to cover the claimed transfers. As a result, a matching transfer hash was incorrectly treated as authorization to release bridge assets, rather than merely a commitment to the requested transfers. 📌 Attacker EOA: 0xbda71b58cec0b1c20a8f87ccd52fa0679747855c 📌 Victim Bridge: 0x71518580f36feceffe0721f06ba4703218cd7f63 📌 Vulnerable Contract: 0x54e03a1682fd0bb065b669f6296f97028dcfd4ce 📌 Fund Receiver: 0xcfd0a20703cd11e0b9f665e1c3f1ef989c142d54 Impact: The attacker submitted a successor CCE anchored to an accepted Verus state root, containing a hash commitment to eight attacker-defined reserve transfers. Because the bridge did not verify whether the CCE’s economic fields backed those transfers, it executed eight payouts from bridge custody to the attacker-controlled receiver—releasing ETH, DAI, USDC, USDT, and four additional tokens without enforced cross-chain asset backing. Powered by Tx:
显示更多
🚨SlowMist TI Alert🚨 💸 @42dao_official Loss: ~ 912k USD 🔍 Root Cause: Attackers exploited an abnormally low BTCB oracle price from Median Oracle via Spotter `poke` and Dog `bark`. The spotter lacked price deviation checks, max drawdown limits, and minimum price protections, allowing immediate write of the low spot into Vat. The dog module then used this updated spot without any liquidation delay or oracle price validation, enabling instant liquidation of multiple BTCB vaults. 📌 Attacker: 0x9d8dd9f2d734675e2bfcc142d1c7a45609ca213c 📌 Victim: 0x973a722fd8bcd4b81f4c5c1ac687073e44aa9a0c 📌 Vulnerable Contract: 0x849dc2416cbe54995a1d725afe526c0e38829228 (Spotter) & 0x00101ae4467d72e83ef68df447c41de0c71f634e (Dog) Impact: A single-transaction combo exploited the missing price protection and liquidation delay in Maker-style system, allowing an attacker to liquidate multiple BTCB vaults using an abnormally low oracle price and profit from the arbitrage. Powered by Tx:
显示更多
🚨 Threat Intelligence | On-Chain Backdoor in a Malicious TRAE Extension Following @Will42W’s warning about TRAE IDE extension supply chain risks, SlowMist investigated the malicious extension juannegro.solidity. Although removed from Open VSX, the extension was still available through the TRAE marketplace as of July 18, 2026. It impersonated a legitimate Solidity plugin and acted as a cross-platform malware dropper. Our analysis found that it: 🔹 Impersonates a legitimate Solidity extension and uses the marketplace as the initial malware delivery channel 🔹 Automatically executes after IDE startup and establishes persistence across platforms 🔹 Uses an Ethereum smart contract to store and retrieve dynamic C2 configurations 🔹 Allows attackers to update C2 endpoints and payload delivery without republishing the extension This incident highlights how extension marketplaces can become initial infection vectors, while blockchain infrastructure can be abused for dynamic C2 management. Users who installed juannegro.solidity should remove the extension and check their systems for potential compromise. Full analysis👇
显示更多
Previously, we analyzed Grok CLI’s data upload behavior and found that its repository upload mechanism could send git bundles containing sensitive files such as .env files and RSA private keys. Following that analysis, we continued auditing Grok Build CLI’s security model after it was open-sourced. Within 24 hours, we identified two attack chains that can lead to arbitrary code execution without explicit user approval. The root cause is not a single bug, but a fragmented trust model: project-level files can influence AI Agent instructions and permission decisions without sufficient validation. Key findings: 🔹 cargo check was incorrectly classified as a safe command. Combined with malicious AGENTS.md instructions, attackers can trigger execution and achieve code execution. 🔹 .claude/settings.json with bypassPermissions can override permission checks and enable unrestricted tool execution. 🔹 Grok Build CLI inherits Claude Code CLI’s permission configuration model, exposing similar risks. 🔹 .mcp.json introduces additional project-level attack surfaces through MCP configuration. These findings highlight a broader issue: When #AI# coding agents trust project-level files too much, opening a project can become equivalent to granting shell access. 📖 Full technical analysis: 👉 Previous analysis:
显示更多
🚨SlowMist TI Alert🚨 💸 @Ostium Loss: ~11,862,445 USDC 🔍 Root Cause: An authorized oracle signer was used to submit malicious price reports through a registered forwarder. The attacker provided validly signed but manipulated oracle data, which was accepted by the oracle verification mechanism. By repeatedly opening and closing trades with artificially favorable prices, the attacker generated artificial profits and drained funds from the OstiumVault. 📌 Attacker Address: 0xd1794196f0fc99c7f27970e661597d77d9a85869 📌 Victim Address: 0x20d419a8e12c45f88fda7c5760bb6923cee27f98 (vault) 📌 Vulnerable Contract: 0x0aebc4094b60ea4e21e937e80dafdd58c07c5ebb (OstiumPrivatePriceUpKeep impl) & 0xd456939e54f68ef9b0be62abb2ec4a37397cb814 (OstiumVerifier) Impact: The attacker exploited compromised oracle privileges to submit manipulated price reports and execute repeated profitable trades, draining ~11.86M USDC from the vault. Powered by Tx:
显示更多
✍️ Technical Analysis Published: Telegram Account Compromised, Wallet Swapped: How Does macOS Malware Break Through Your Defenses? Our latest investigation reconstructs how a single malware sample chains together Telegram session theft, wallet database exfiltration, offline decryption and fake wallet applications into a complete account takeover workflow. Our analysis shows: 1️⃣Stolen Telegram Desktop and Telegram for macOS session files can be restored on another Mac without re-entering a phone number, verification code or 2FA password 2️⃣For Telegram for macOS, even after server-side security mechanisms respond, cached chat history may remain accessible instead of being cleared by a forced logout 3️⃣Wallet databases can be paired with passwords collected from Keychain, browsers and Apple Notes for offline decryption, without interacting with the victim's device 4️⃣Fake Ledger and Trezor desktop apps are actually WKWebView-based loaders that replace trusted wallet interfaces with attacker-controlled phishing pages The malware doesn't rely on a single technique—it combines authenticated sessions, encrypted wallet data and credential material into one attack chain. 💡 Defense tip: Protect your local Telegram session by enabling a Telegram Passcode and using a strong, unique password. Full analysis and practical mitigation guidance👇
显示更多
🚨SlowMist TI Alert🚨 💸 @dripsnetwork Loss: 24,882.99 DAI 🔍 Root Cause: Integer type conversion flaw in `DaiDripsHub`'s `give(address,uint128)` function. The function converts `uint128 amt` to `int128` without validating `amt <= type(int128).max`. Attackers pass `2^128 - reserveBalance` (exceeding int128 max), causing `int128(amt)` to become a negative value. `-int128(amt)` then becomes positive, flipping the transfer direction from "user pays" to "reserve withdraws to user," draining DAI. 📌 Attacker: 0x84da7a5e2315eb798f04b75554aeb15047269cce 📌 Victim Contract (DaiReserve): 0xf9bbb2df44cfe46e501cf91c99b2f8fef9d9d44a 📌 Vulnerable Contract (Hub Proxy): 0x73043143e0a6418cc45d82d4505b096b802fd365 📌 Attack Contract: 0x00c64b5a926ba1fcec30efad88c344c619f54f12 Summary: Missing input validation allows a crafted `give()` call to reverse fund flow, draining the reserve. Powered by Tx:
显示更多
🚨SlowMist TI Alert🚨 💸 @Lumi_Finance Loss: ~ $264k 🔍 Root Cause: A vulnerability in Lumi smart accounts allowed token approvals to be performed as a side effect during UserOperation validation. Due to improper validation logic, an attacker-controlled paymaster could trigger approval operations during the validation phase and obtain ERC20 allowances from multiple smart accounts without explicit user intent. 📌 Attacker: 0xce1a3bb0b98d0d90c7dd0620ab86c9a771888d88 📌 Victim: Multiple Lumi smart accounts affected by unintended token approvals during UserOp validation 📌 Malicious contract: 0x56362412ae17cac443aafbab4289946ad958e8a1 The attacker abused a flaw in Lumi smart account UserOperation validation logic to obtain token allowances from multiple wallets through validation-time side effects. The attacker then used the malicious sweeping contract to batch drain approved ERC20 tokens, swapped the stolen assets into ETH, and transferred the proceeds to the attacker-controlled address. Powered by #SlowMist#.AI Tx:
显示更多