Anu

Security Researcher @QuillAudits_AI | Ambassador

[Anu @cryptanu]

I witnessed firsthand how a protocol could live with a live bug (and possibly never catch it) because there's no way to responsibly disclose these issues.

In a review with @QuillAudits_AI , an RWA project <redacted> had forked a portion of @DinariGlobal's code but requested we treat it as a black box.

(Un)fortunately, I tend to digress when not working with code I'm familiar with -- and stumbled on a sizeable vulnerability in their codebase

Thankfully it wasn't exploited before it was patched, but they had ~$3m at risk (which grew to $60m in less than 4 months), big liquidity injection in RWA's this year (and likely for the next few years)💰

While this isn't Yearn-scale, many small drops fill a barrel.

Josselin has been talk about the need to beef up internal security -- this awareness is something I expect to grow as well, and this exploit is another example why
(ty for your talk with Rajeev and Alex at DSS).

[pranav @prd_008]

I think about these two tweets all the time

[Anu @cryptanu]

LFG!

[Devcon 9 | Lisbon @EFDevcon]

Devcon 9 is coming to Lisbon! 🇵🇹

October 11–13, 2027

Building on Mumbai, we're bringing Ethereum's builders together with more friends and allies working toward a freer, more open internet.

[Anu @cryptanu]

@QuillAudits_AI @EFDevcon Come one, come all.

[QuillAudits @QuillAudits_AI]

We are hiring at @EFDevcon.
Booth is set up at the Career Fair today,

Roles in security, BD and marketing. Interns, juniors and mid level folks all welcome.

Building something onchain?
Come by and grab QuillShield access for your team too.

[Anu @cryptanu]

27 years ahead of their time.

Epic flashback from the past.

[Anu @cryptanu]

@KalyfaMuhd @ZenithBank nicely done ser

[Anu @cryptanu]

@lifeofdanel @ournuvion what sort of stealth is this?

[Anu @cryptanu]

niceee bro! 😎

[Phoenix @phoenix244001]

Had a blast while speaking on Quantum Computing and their risk layers.

Thanks to @summit_defi for putting this together !

[Anu @cryptanu]

@bigrkg @summit_defi @QuillAudits_AI Everyone's looking DSS-et

[QuillAudits @QuillAudits_AI]

In Mumbai this week? So are we 👋

Catch QuillAudits across @IBWofficial, @summit_defi, @SolanaSummitOrg, Security Hub and Ready for the Run.

We’re also hosting The Institutional Table on 5th Nov.

Come say hello. Full schedule:
https://t.co/G7tsi1xmPa

[Defi Security Summit @summit_defi]

The DSS 2026 timetable is live.

Nov 1–2 · Mumbai · Amber + Pearl

Pick your talks, save a shortlist and share it with @summit_defi.

Agenda: https://t.co/KX8nDwM0JN
Tickets: https://t.co/RTbPxGH7zF

[Anu @cryptanu]

Nice comparison @Harvesto12 , thanks for sharing your detailed review.

[QuillAudits @QuillAudits_AI]

QuillShield, our multi-agent AI auditor, independently discovered and wrote a working exploit for a bug in a live lending contract, after a 12-agent AI pass had found the bug and a human auditor had stopped at the safeguard.

The auditor later rebuilt the exploit on a mainnet fork and proved it works.

The auditor is @Harvesto12, a security researcher.

His 12-agent pass had already flagged the bug. He tested one attack path, a compensating safeguard elsewhere in the system blocked it, so he filed the bug as refuted and moved on.

QuillShield found the same bug on its own, but it came at it from a different path, one the safeguard did not cover, and then wrote its own exploit test for it.

Then he took that exploit test and rebuilt it himself on a Foundry mainnet fork, with a fresh account and no injected state, so nothing was staged. It went through.

The rest of the run, in his numbers

• 8 findings, 4 of them his pass had not caught
• 3 of the 8 exploit tests it wrote and ran passed
• severity on the bug went Medium from QuillShield, Critical from him

4 reviewers, and not one of them disputed that the bug is real.

His explanation for why it got through where he hadn't is the part I keep thinking about. He had tested one path and assumed the safeguard handled the rest. QuillShield had no such assumption, so it worked through the other paths until one went past it.

That's the point of building QuillShield: to keep challenging the code when one blocked attack makes it look safe.

[Anu @cryptanu]

@bootnodedev @QuillAudits_AI @summit_defi Great! I'll leave you a DM 😀

[Anu @cryptanu]

@meshaqRapha0761 Ty ser! 😃

[Anu @cryptanu]

🙌

[QuillAudits @QuillAudits_AI]

Our auditor @cryptanu is taking the stage at @summit_defi in Mumbai!

Damn Vulnerable Daml: live CTF-style challenges built from real bugs he found on the Canton network while reviewing Daml code. Inspired by Ethernaut and Damn Vulnerable DeFi.

1st Nov, 02:30PM IST, Amber room

Save it to your agenda: https://t.co/XZr3UMLHHj

See you there. 🛡️

[QuillAudits @QuillAudits_AI]

Our auditor @cryptanu is taking the stage at @summit_defi in Mumbai!

Damn Vulnerable Daml: live CTF-style challenges built from real bugs he found on the Canton network while reviewing Daml code. Inspired by Ethernaut and Damn Vulnerable DeFi.

1st Nov, 02:30PM IST, Amber room

Save it to your agenda: https://t.co/XZr3UMLHHj

See you there. 🛡️

[Anu @cryptanu]

@bigrkg @QuillAudits_AI @summit_defi fingers crossed, it will be!

[Anu @cryptanu]

I had the best experience with the development of this tool when I saw our clients say it's one of the best tools aiding their continuous development.

Win-win.

[QuillAudits @QuillAudits_AI]

Scan your smart contracts before attackers do.

We are opening beta access to QuillShield, our multi-agent auditor for EVM smart contracts, for the first 50 teams.

October has made it clear that waiting is no longer an option. In the last few days alone:

• PHP: pre-auth remote code execution, CVSS 9.2
• GitLab: CVSS 10, self-hosted servers back to 2014
• Node.js: 10 CVEs in one release
• Railway: customer secrets accessed
• LiteLLM: credential stealer shipped on PyPI

AI helped find some of these bugs, and attackers have the same tools.

A bug in a deployed smart contract can drain funds in a single transaction, so we built QuillShield to find them first. Here's what it has done so far:

> 25 Critical or High vulnerabilities caught across 155 projects

> 497 findings, with 85% of auditor-reviewed ones confirmed valid

> 350,000+ lines of Solidity reviewed

> 83.8% on EVMBench, against 45.6% for the best published model

Here's the beta link: https://t.co/yI8s3a4Sv4

[Anu @cryptanu]

This reminds me of Cloudflare just a few months ago.

At this point, APTs could be a well-funded attacker with a crazy amount of credits to spend.

[QuillAudits @QuillAudits_AI]

If your deployer key was sitting in a Railway variable, who owns your contracts right now?

Possibly the attacker.

Railway was breached today. Their disclosure says an unauthorised party may have accessed customer environment variables and decrypted some of them. Railway thinks the target was AI inference keys.

On-chain trackers say a sweeper script went through the same dump and hit 200+ addresses across 19+ EVM chains, around $371k as of Oct 21 evening UTC.

Here is the part the “rotate your keys” advice skips.

An API key has an issuer. You revoke it with OpenAI or Stripe or your database provider and get a new one.

A private key has no issuer, so there is nothing to rotate. Once it has been read, that address is gone, and the balance in it is usually the least of what it controls. The same key is the owner, upgrader or minter on whatever contracts you pointed it at, and that is what the attacker can use next.

So if you ran a bot, relayer, keeper, indexer or backend on Railway with a signing key in its variables, do these 5 things first, from a clean machine with a new key. None of them touch Railway, so you don’t have to wait for deploys to come back.

1. Treat every address whose private key or seed phrase was in a Railway variable as controlled by the attacker.
Move what’s left and retire it. One key is the same address on every EVM chain, so check all of them, not just mainnet. The sweeper already did.

2. Find every contract where that address holds a role.
Owner, admin, proxy upgrader, minter, pauser, oracle updater, guardian, relayer allowlist. Transfer each to a new address. Start with the deployer key, because in most codebases the account that deploys a contract becomes its default owner and nobody ever changes it.

3. If the key is a signer on a Safe or another multisig, replace it.
Then check the threshold still makes sense without it.

4. Revoke token approvals.
The ones that address granted, and the ones other addresses granted to it.

5. Set monitoring on the old addresses and on the attacker address in the first reply.
A role the attacker hasn’t used yet can still be used.

Then rotate the normal secrets. RPC keys, database passwords, registry credentials, AI API keys. Do it with the provider that issued them, because changing the value inside Railway does nothing to the old one.

And go through services you stopped months ago. One engineering lead on X traced a stolen AWS key to a Railway service that had been idle since July. A stopped service keeps its variables.

None of this is unusual practice, which is the uncomfortable part. At least one template on Railway’s own deploy page asks you to paste a 0x-prefixed wallet private key straight into a variable.

Longer term, three things.

A hot key on someone else’s platform holds a few hours of float and no admin roles at all.

Admin roles sit behind a multisig with a timelock.

If you can, sign through a KMS or HSM so the raw key is never in an env var in the first place.

It is also worth running a key leak drill once, because the thing most teams discover mid-incident is that nobody can list which contracts a given key still controls.

[QuillAudits @QuillAudits_AI]

If your deployer key was sitting in a Railway variable, who owns your contracts right now?

Possibly the attacker.

Railway was breached today. Their disclosure says an unauthorised party may have accessed customer environment variables and decrypted some of them. Railway thinks the target was AI inference keys.

On-chain trackers say a sweeper script went through the same dump and hit 200+ addresses across 19+ EVM chains, around $371k as of Oct 21 evening UTC.

Here is the part the “rotate your keys” advice skips.

An API key has an issuer. You revoke it with OpenAI or Stripe or your database provider and get a new one.

A private key has no issuer, so there is nothing to rotate. Once it has been read, that address is gone, and the balance in it is usually the least of what it controls. The same key is the owner, upgrader or minter on whatever contracts you pointed it at, and that is what the attacker can use next.

So if you ran a bot, relayer, keeper, indexer or backend on Railway with a signing key in its variables, do these 5 things first, from a clean machine with a new key. None of them touch Railway, so you don’t have to wait for deploys to come back.

1. Treat every address whose private key or seed phrase was in a Railway variable as controlled by the attacker.
Move what’s left and retire it. One key is the same address on every EVM chain, so check all of them, not just mainnet. The sweeper already did.

2. Find every contract where that address holds a role.
Owner, admin, proxy upgrader, minter, pauser, oracle updater, guardian, relayer allowlist. Transfer each to a new address. Start with the deployer key, because in most codebases the account that deploys a contract becomes its default owner and nobody ever changes it.

3. If the key is a signer on a Safe or another multisig, replace it.
Then check the threshold still makes sense without it.

4. Revoke token approvals.
The ones that address granted, and the ones other addresses granted to it.

5. Set monitoring on the old addresses and on the attacker address in the first reply.
A role the attacker hasn’t used yet can still be used.

Then rotate the normal secrets. RPC keys, database passwords, registry credentials, AI API keys. Do it with the provider that issued them, because changing the value inside Railway does nothing to the old one.

And go through services you stopped months ago. One engineering lead on X traced a stolen AWS key to a Railway service that had been idle since July. A stopped service keeps its variables.

None of this is unusual practice, which is the uncomfortable part. At least one template on Railway’s own deploy page asks you to paste a 0x-prefixed wallet private key straight into a variable.

Longer term, three things.

A hot key on someone else’s platform holds a few hours of float and no admin roles at all.

Admin roles sit behind a multisig with a timelock.

If you can, sign through a KMS or HSM so the raw key is never in an env var in the first place.

It is also worth running a key leak drill once, because the thing most teams discover mid-incident is that nobody can list which contracts a given key still controls.