Spent 2024–2025 filing Apple Security Bounty reports. All 16 are now closed. I've written up every one — including the ones Apple were right to reject, the ones where my own PoC was lying to me, and the few where I couldn't bridge the gap between binary evidence and a working exploit. No hype, no CVE-farming. 

Recently saw a post '20 common AI-coded app vulnerabilities', and thought to myself that 20 is nice but very optimistic, as an avid AI user for years now I personally saw more than 20 on every project that was not ai-written in a targeted manner, but as huge chunks. So, I got my good friends Claude, ChatGPT, Gemini and Grok to help me throw few more into it. Initial thought was to package as a vulnerability scanner, but... would rather not even attempt to earn on vulnerabilities and instead encourage users to run audits for keeping all free, open source and with an ability to contribute. And here it is:

Open source checklist of 258 vulnerabilities common in applications built with AI coding assistants. 17 categories. Detection method ([S] static, [R] runtime, [C] config) and severity rating on every item.

The part that isn't in existing references - Category 6, 33 items specific to LLM integration. Some of the less-obvious ones:

6.26 - MCP tool poisoning: attacker-controlled MCP server injects instructions into tool results the agent reads as trusted input. Detection: static analysis of MCP server config plus runtime inspection of tool result handling before prompt injection.

6.27 - Agent memory poisoning: malicious content written to long-term memory (vector DB, key-value store, file) is retrieved in a future session and executed in context. Detection: audit memory write paths for content validation before storage.

6.30 - Cross-agent prompt injection: orchestrator passes Agent A's output as Agent B's input without sanitization or trust boundary. Detection: static analysis of multi-agent orchestration code.

6.31 - Insecure agent handoff: parent agent passes full API keys/session tokens to sub-agents rather than scoped credentials with minimum required permissions.

Companion prompt.md runs all 258 checks against a codebase using Claude Code or any capable LLM CLI. Returns file paths, line numbers, code snippets, specific remediations.

Apache 2.0. license - so anyone willing to do anything around this are open to do so.

A pre-auth remote code execution vulnerability was found in the CWMP implementation of ipTIME routers, allowing unauthenticated attackers to execute arbitrary code remotely.

I think the bigger point here is that AI has clearly been accelerating attackers, so it makes sense that frontier models are now being packaged more directly for defenders too.

Not sure how to start using it yet or get access

I recently published a security research post on the myAudi connected vehicle platform. I found that anyone with a VIN can access a sensitive informations about car and ownership
I think the topic is useful beyond Audi itself, because many vendors now rely on these “connected vehicle” platforms and mobile apps, often with very similar architectures and assumptions

Across all major ShinyHunters campaigns (AT&T/Snowflake, Salesforce, Canvas/Instructure), only one event has both a publicly stated payment amount and a known approximate settlement date: the May 2024 AT&T payment of ~5.7 BTC (~$370K), confirmed by Wired but never published with a transaction hash. I use that as the analytical anchor for an end-to-end on-chain analysis using only free public data.

Pipeline (5 stages):

1. BigQuery bulk filter on amount and time window → 500 candidates.
2. Recipient profiling via Blockstream Esplora (lifetime tx count, spend shape).
3. Sender-side cluster analysis using common-input ownership; looking for broker-aggregation patterns.
4. Depth-12 concurrent forward trace, top-K=4 fan-out.
5. Terminal attribution via OKLink, BitInfoCharts, WalletExplorer.

Result:

A single highest-fit candidate: 5.71997804 BTC paid 2024-05-17 22:04 UTC to a fresh recipient, spent in 6 min, laundered through a 6-cycle automated peel chain, terminating at an exchange deposit cluster. Funding side shows broker-aggregation fingerprint (4× 1.147 BTC peels in a 90-min window pre-payout). Upstream hub addresses appear reused across multiple victims of the same laundering service, active through 2025. Paper closes with the legal pathway from chain endpoint to indictment and a scoped compliance-request template.

Limitations (explicit in §5):

Ranking under a scoring scheme, not positive ID. No off-chain ground truth. Documented OKLink vs. Arkham label conflict on the dominant terminal, resolved via behavioural audit. No formal null-distribution analysis yet. Score weights are author judgements.

Asking for:

1. Technical feedback / methodology critique.

2. arXiv cs.CR endorsement — endorsement code: ZQXBSQ

   github.com/tr4m0ryp/shinyhunters-gotta-catch-em-all/blob/main/Gotta_Catch_Em_All_ShinyHunters.pdf

Tooling and dataset released for reuse