Hexens

Audit Completed: Thesauros We're glad to have supported Thesauros with a security review of their optimized Rebalancer contracts. It's an ERC4626 vault that reallocates deposits across lending providers to keep yield up. Our audit covered the withdrawal and allocation flow, the Aave V3, Morpho, Dolomite and Revert provider adapters, provider registration, and position valuation. Wishing the Thesauros team the best as they continue building Full report: https://lnkd.in/dK9dGJjg

Your own contract can pass every check and still sit in a risky neighborhood. Nothing on-chain runs in isolation. You depend on other contracts, and others depend on yours. A risk anywhere in that web doesn't stay contained. Most monitoring stops at the single contract you point it at. Glider Monitor maps the whole thing. The deeper dependency graph, every connected contract, and its live monitor status, so you can see risk building up around the code you rely on and the code that relies on you. Clean code isn't the same as a clean perimeter.

A critical vulnerability is never in just one contract. The same bug is usually sitting in dozens more, still live. When a hack hits, Glider Monitor reviews it and pulls out what actually made it work: the vulnerability itself. That becomes a Glider query, automatically. Then that query runs across the whole chain, millions of contracts scanned per case, surfacing every one carrying the same bug. If one of them is a contract you monitor, it fires the response mechanisms you set up. Plenty of feeds tell you a hack happened. Glider covers this PLUS more. Checking whether the same bug is in your own code is a continuous problem requiring a team covering threat intelligence, with Glider you can do it with zero-click 24/7, and it's one of many things that Glider (and only Glider) can do.

In web3, the exploit IS the disclosure. No patch window. The moment a hack lands on-chain, it's a free, working PoC. And the race is to copy it, not to fix it. So we flipped it. Glider Monitor watches live exploits and turns each one into a detection query, automatically. 2 weeks. 12 live incidents in → 198 confirmed-vulnerable contracts out, still running on Ethereum & BSC. 80 codebases, 9 bug classes. From exploit tx to a full sweep of ~2M contracts: about 30 minutes. Full Article: https://lnkd.in/dVQAxtnQ

Standard monitoring isn't enough anymore. So we built on top of it. Today we're launching Glider Monitor, built for everyone in Web3 deploying Contracts or Capital. At its core is Glider - which recognizes any on-chain pattern and tracks it across your contracts continuously, protecting you on multiple fronts. • Exposure replay: when an exploit hits another protocol, or a novel attack vector surfaces in public research, we replay it against your contracts and tell you if you share the vulnerability - before it reaches you. • Dependency risk & invariants: your contracts trust oracles, vaults, and third-party code. Glider Monitor maps your full dependency graph automatically and monitors invariants for known risk classes - stale oracles, vault health, stablecoin depegs - plus custom invariants built for your specific risk profile. • Real-time attack monitoring: continuous observation of your contracts, alerting you the moment you're targeted. Threats in web3 are continuous. Now your security matches the pace. Start with our free tier, <10 contracts, 60 seconds onboarding. Link below  ↓

We found a critical vulnerability in the Aptos Move VM: a type confusion at the execution layer that placed up to $70B of on-chain value within reach of a single attack path. The flaw sits in the VM itself, not in any individual contract. On Aptos, every application inherits the runtime's guarantees: Move's security model depends on the runtime enforcing type and resource safety. When that assumption breaks at the base layer, even a correct, fully audited contract can have its state manipulated from beneath it, meaning application-level diligence can't fully bound the exposure. To measure real-world exploitability rather than assume it, we built the attack on a 30+ validator cluster for ~$3,000 in infrastructure and ran it hundreds of times. The result was a ~90% success rate with no chain halts. Our PoC reached bridge capabilities, signer capabilities, master-minter roles and protocol accounting state. We walked a legitimate administration path to a master-minter-style role and deliberately stopped before minting. We handled this through responsible disclosure from start to finish: emergency channels, a SEAL 911 warroom opened the same day, and runnable PoCs shared with downstream partners. No funds were lost, and no user was ever at risk during the process. We're publishing the full research and the PoC because severity should be judged on evidence. The writeup includes the mechanism, the setup, the measured success rate and the calibration method behind it. We'd rather you read it and reach your own conclusion than take ours. Research by kemmio. X post - https://lnkd.in/dF_UFjiD Full breakdown https://lnkd.in/d8rYWF7r

Not every ERC-20 transfer is just a token move. Some tokens override the native ERC-20 transfer logic and add external logic on top: harvest calls, reward minting, fee distribution, and so on. What most people don't realize is that this hook can run regardless of the transfer amount including zero. OpenZeppelin's ERC-20 skips the allowance check when amount == 0, which means a zero-value transfer still fires that hook. In pools, a zero-value transferFrom(userA, userB, 0) with a modified hook can: -Trigger a harvest function inside _update() -Mint new tokens directly into a liquidity pool -Inflate the pool's token balance without updating its internal reserves -Leave the AMM mispriced until someone calls swap() to extract the difference The assumption that zero-value transfers have no side effects is wrong when the token carries hooks. To find which ERC-20 tokens make external calls inside their transferFrom hooks, check out the query:https://lnkd.in/dAghGBya

The dangerous part of an oracle manipulation is not the oracle. It is where the returned price flows, and which critical operations depend on it. Any protocol that reads a price and routes it into decisions is exposed. Lending protocols make this clearest. The lending pool uses the price to determine how much a user can borrow, loan health, liquidation costs, and more. An attacker does not need to break the lending logic. They just need to control the price. The protocol does the rest. Tracing this manually means following the oracle to its callers, then their callers, then theirs. Glider maps every function a price can reach before an attacker does. Run the query below and see where oracle prices actually go: https://lnkd.in/dfQBbnWu

Not every contract that looks like a Uniswap V2 pool is one. Uniswap V2 launched in 2020. Six years later it remains one of the most forked and imitated codebases in DeFi. Some of those imitations ship custom logic underneath a standard-looking interface. The ABI matches. Function signatures are identical. Standard tooling treats it as vanilla Uniswap. The custom code can modify swap behavior, manipulate price calculations, or introduce logic that downstream integrations inherit without knowing. Here is a Glider query to surface every UniswapV2Pair contract on mainnet containing custom code: https://lnkd.in/djqmNUNM