blchead | Felipe

Pushed a few commits to @blchead's auditor-skill and released v7.0 with: - even more checks & attack vectors - @0xcastle_chain & @trailofbits skills integration - full audit firm lifecycle / methodology - rust pre-scanner + cross-audit memory - auto exploit poc/patch generator Can easily say this is the most comprehensive and capable security skill for Solana builders. If you're shipping, install it now at: github.com/solanabr/audit… @superteam is a cheatcode and @SuperteamBR keeps delivering, LFB 🦾

I recently submitted a CVSS 7.7 (High) authorization vulnerability affecting @MeteoraAG Before sharing fully transparent (BUT removing critical info) I spoke with team and as I don't agree with that, I want to know CT opinion. The issue allows a configured shareholder to divert one side of dual-token fee claims, resulting in DIRECT THEFT of protocol/partner fee revenue. - A shareholder with even a 1-unit share can steal 100% of one token side. - The attack is repeatable on every fee accrual. - The theft is silent (the diverted fees never appear in the vault or events). It undermines the fundamental guarantee that fees are distributed according to shareholder allocations. The report was classified as DUPLICATE. After I followed up with additional evidence, including: - an end-to-end PoC reproduced on a local fork, transaction hashes, - proof that the issue remained exploitable on deployed binaries, - blast-radius analysis covering thousands of affected vaults, Meteora responded that: - the issue is still exploitable on the deployed DFS integration; - the duplicate status is only about bounty eligibility, not the validity of the finding; - that my PoC and exposure analysis are useful for prioritization. This raises a question I'd like to discuss with the bug bounty community. If the issue was already known, why does it remain exploitable on production? And more broadly: How is a researcher supposed to know whether a live vulnerability is already known internally? From the outside, there is no distinction between: - a brand-new vulnerability, - one that has already been privately reported, - one that is internally tracked, - one awaiting a future fix. Every one of those requires the same audit effort, reverse engineering, code review, exploit development, and responsible disclosure. I'm not questioning the duplicate policy itself bc most bug bounty programs have one. I'm questioning the lack of transparency around known-but-unpatched vulnerabilities. Should protocols provide more visibility when a CVSS 7.7 (High) issue capable of silently diverting protocol fees remains live? Or is it simply accepted that researchers may spend days producing original analysis and PoCs for vulnerabilities that have zero possibility of a reward because that information is impossible to know beforehand? I'd be interested in hearing how both protocol security teams and other researchers think this should be handled.