Everyone claims they're elite. We back it up Get secured https://teapaw.org/t.co/XjjwUNFl5s Contact https://teapaw.org/t.co/ZayFNyJUud for more
Joined April 2024
- Tweets320
- Following3
- Followers1.1K
- Likes786
Pinned Tweet
Everyone claims they're elite. We back it up.
> $18B in TVL secured by our researchers
> 81 audits on record
> 244 vulnerabilities found
Bugs ruin you, we catch them.
egissec.net
If your backend or relayer acts on an emitted event, it can be lied to.
The EVM never checks that a log matches the state it claims. A contract can emit a transfer that moved nothing.
EventSpec reproduced it on bridge relayers.
arxiv.org/abs/2609.07865
A log is a claim, not a receipt.
Does your protocol give out anything per address?
High severity issue we found while auditing a raffle project. An address with one Wei staked had the same odds of winning as the largest staker.
1️⃣ Project summary
Lotus is a staking protocol. You lock LOTUS, your position earns shares, and five percent of every reward distribution funds a separate raffle pool. Every two weeks that pool pays its whole jackpot, in TITANX, to one staker, drawn with Chainlink VRF.
2️⃣ The bug
The pool holds its participants as a set of addresses, and the draw is one line, index into that set with the random word. One address, one ticket. Stake size doesn't appear in that line.
Entering the set was a side effect of staking, with no threshold of its own. One share put an address in, and one share was one wei of LOTUS. The randomness was never the problem. What the random number indexed into was.
3️⃣ The attack path
1. Stake a wei of LOTUS from an address. That address is now a ticket.
2. Repeat from a substantial number of addresses.
3. Every honest staker's odds drop, whatever they locked.
The protocol priced a raffle ticket in gas and priced everything else in stake.
4️⃣ Fix
The client shipped a minimum stake to enter the draw.
Run the split test on anything you weight. If splitting one position across ten addresses beats holding one, you don't have a weighting, you have a headcount.
If you have the same pattern in your codebase, contact us so you don't repeat the same mistake.
egissec.net
Egis Security retweeted
This is still happening btw
If you want to succeed
Learn how to sell yourself
Over the past week I've gotten at least 10 messages of auditors offering to work with me and I notice people don't know how to sell themselves
> Show your experience in the first few lines of the DM
> No links, unless someone asks for them
> Be short and to the point
Don't do this
Egis Security retweeted
If every user of your protocol delegatecalls into one shared helper contract, this affects you too.
On 1st of September, four forgotten Reflexer vaults were drained for 5.9436 ETH by two rules that are both correct.
1️⃣ Summary
Reflexer's GEB is the engine behind RAI, a stablecoin you mint by locking ETH in your own vault.
Nobody calls the vault manager directly. You delegatecall a shared helper from your own proxy, so address(this) is your proxy, recorded as the owner.
2️⃣ The bug
Rule one, record address(this) as the owner. Correct under delegatecall.
Rule two, let only the recorded owner move a vault's balance. Correct on its own.
In 2020 someone reached the helper as a plain call instead of through a proxy. address(this) was then the helper itself, so vaults 3, 5, 8 and 18 ended up owned by a shared contract whose migration function, quitSystem, is public and unchecked.
The manager compares the caller to the recorded owner, sees the helper on both sides, and says yes. Nothing was bypassed.
3️⃣ Attack path
1. Reflexer has been in permanent settlement since January 2021, so anyone may cancel a vault's debt. Do that for all four, leaving debt free ETH in each.
2. Call that migration function directly, once per vault, moving every balance to a handler you control, then exit through the ETH adapter.
Four vaults, one transaction, five years after that owner field was written.
Delete either rule and the ETH is still there. An access check is only as trustworthy as whatever filled in its owner field.
If you have the same pattern in your codebase, contact us so you don't repeat the same mistake.
egissec.net
Egis Security retweeted
Do you review your own contracts before an audit?
@AwareXone has skills that cover 10 different bug classes using a knowledge base consisting of target scoring, bug patterns, grep arsenal, PoC templates and real case studies.
Check them out below ⬇️
Do you review your own contracts before an audit?
@AwareXone has skills that cover 10 different bug classes using a knowledge base consisting of target scoring, bug patterns, grep arsenal, PoC templates and real case studies.
Check them out below ⬇️
Source:
github.com/Awarexone/web3-bu…
If every user of your protocol delegatecalls into one shared helper contract, this affects you too.
On 1st of September, four forgotten Reflexer vaults were drained for 5.9436 ETH by two rules that are both correct.
1️⃣ Summary
Reflexer's GEB is the engine behind RAI, a stablecoin you mint by locking ETH in your own vault.
Nobody calls the vault manager directly. You delegatecall a shared helper from your own proxy, so address(this) is your proxy, recorded as the owner.
2️⃣ The bug
Rule one, record address(this) as the owner. Correct under delegatecall.
Rule two, let only the recorded owner move a vault's balance. Correct on its own.
In 2020 someone reached the helper as a plain call instead of through a proxy. address(this) was then the helper itself, so vaults 3, 5, 8 and 18 ended up owned by a shared contract whose migration function, quitSystem, is public and unchecked.
The manager compares the caller to the recorded owner, sees the helper on both sides, and says yes. Nothing was bypassed.
3️⃣ Attack path
1. Reflexer has been in permanent settlement since January 2021, so anyone may cancel a vault's debt. Do that for all four, leaving debt free ETH in each.
2. Call that migration function directly, once per vault, moving every balance to a handler you control, then exit through the ETH adapter.
Four vaults, one transaction, five years after that owner field was written.
Delete either rule and the ETH is still there. An access check is only as trustworthy as whatever filled in its owner field.
If you have the same pattern in your codebase, contact us so you don't repeat the same mistake.
egissec.net
Are you building a UniswapV4 hook?
We recently finished one hook audit and we are currently conducting a second one.
That's 5 consecutive weeks of securing hooks.
If you need your hook secured, you know how to reach us.
egissec.net
Egis Security retweeted
Recently I had a conversation with a potential lead looking for an audit
They were looking at several teams and wanted me to give them a quote
I sent the quote and they reply with
"We don't have the budget for you, so we chose XYZ"
I didn't back down or get defensive, I asked one question
"I understand, XYZ is a great choice, our price reflects our experience and expertise so we can't go any lower. Who would you have picked if the price was the same?"
"You, we just don't have the budget right now"
They admitted @EgisSec was the better choice, I didn't even have to convince them
A few weeks later I ask how the audit went, they say that they went back to building and the audit is on hold, I asked about a timeline on the new audit, you can see their response in the image
Don't back down on your price, push the client to understand why that's the price
To all protocols that plan for a security review.
The singles most important thing you can do, is give a correct scope for the audit.
A new ack3 preprint mapped 135 DeFi incidents from H1 2026. Of the 68 with a prior audits, 46 were exploited in code the audit never covered.
A malformed scope can lead to disastrous consequences.
@EgisSec doesn't look blindly into your scope, if something marked out of scope is necessary to be reviewed, we'll tell you.
Do you fuzz your contracts?
You should.
Ultrafuzz is Monad's open source agentic fuzzing orchestrator.
github.com/monad-developers/…
If your token runs custom logic inside it's transfer, a fee or a router check, this affects you too.
On June 16, the DIP token on BNB Chain was drained for 111,097 USDC.
Here is how
1️⃣ Summary
DIP is a fee on transfer ERC20 paired with AIC on PancakeSwap. Its `_transfer` override sorts each transfer into three cases, a zero amount, one touching the router or a sell into the pair.
2️⃣ The bug
The zero amount case ends in a `return`. The router case doesn't. It moves the full amount, falls out of the branch, and lands on the function's last line, another unconditional `super._transfer`. Same sender, same receiver, same amount, moved twice.
3️⃣ The attack path
1. Flash swap 19,000,000 AIC, route it through the router for 17,564,897 DIP.
2. Send 9,896,547 DIP into the AIC-DIP pair. After the 6 percent fee, 9,302,754 DIP sits above the pair's recorded reserve.
3. Call `skim`, public on every pair, with the router as the payout. The pair asks for that surplus once, the token sends it twice, and the DIP reserve drops to 1045 wei.
4. Swap 7,208,249 DIP against that dust for 29,037,659 AIC, the AIC side down to 4221 wei.
5. Sell the rest for 111,097 USDC.
A branch that already moved the money has to end the path, or the code after it moves it again.
If you have the same pattern in your codebase, contact us so you don't repeat the same mistake.
egissec.net
Egis Security retweeted
If you want to succeed
Learn how to sell yourself
Over the past week I've gotten at least 10 messages of auditors offering to work with me and I notice people don't know how to sell themselves
> Show your experience in the first few lines of the DM
> No links, unless someone asks for them
> Be short and to the point
Don't do this
Egis Security retweeted
Does your contract gate anything on a token balance?
Critical @EgisSec found on a previous review.
1️⃣ Summary
TrotelCoin pays users in TROTEL for finishing quizzes. Users can mint different tiers of NFTs based on their current TROTEL balance and can only claim each tier once. The highest tier is "Expert" and requires 50,000 TROTEL.
2️⃣ Bug
`mint` is public. It asks whether the recipient holds 50,000 right now, gets true, and mints. Nothing is transferred, locked or burned. The requirement is read, never spent.
The guard is meant to stop users from double-claiming. It stops one address claiming twice, it doesn't stop the same tokens being used to claim again.
3️⃣ Attack path
1. Alice holds 50,000 TROTEL.
2. Alice mints her "Expert" NFT.
3. Alice sends all her TROTEL to Bob.
4. Bob calls `mint` and mints another "Expert" NFT.
The same balance was used by different addresses to pass a check.
Classic double-spend issue.
4️⃣ Fix
When a user mints a NFT, consume the required amount of TROTEL, this way double-spending is impossible.
If you have the same pattern in your codebase, contact us so you don't repeat the same mistake.
egissec.net