The majority of widely used AI clients like:

• Claude Code
• Claude Desktop
• Cursor
• LibreChat
• Amazon Q CLI

have not implemented the critical refresh-token flow of the OAuth standard.

This is forcing developers to issue long lived tokens creating a serious security regression in an already solved problem.

This write up includes a matrix table of 14 major clients with notes linking to feature requests, pull requests, and multiple forum discussions.

It is not all gloom and doom though!

There is a work-around solution that security conscious users are using as a stop-gap also discussed, along with a best practices guide for developers implementing their own MCP OAuth Solution.

The plan is to update this reference on a monthly basis to track if there is any movement on this open requests.

Topic of this article: Burp AI.

Quick note from a scanning project I've been running. We hit 6,000 web apps with a payment-bypass probe last week, sending a minimal fake `checkout.session.completed` event to common webhook paths (`/api/webhook/stripe`, `/api/payments/webhook`, etc.) without a `Stripe-Signature` header.

1,542 returned 200.

That means anyone with curl can fire a forged Stripe event at those endpoints and the server processes it as legitimate. Depending on what the handler does with it, the consequences range from "logs a fake event" to "marks attacker's account as paid" to "creates a confirmed order with no payment".

The split was roughly:

• Custom domains (real production SaaS): ~720
• Render: 198
• Vercel: 142
• Replit: 121
• Railway, Fly, Heroku, others: ~360

Why so many?

The Stripe library makes signature verification a one-liner. Every framework has the canonical example. But the dev journey usually goes: build the route locally with a stub handler that just `console.log`s the event body, get the upgrade-the-user logic working, leave signature verification on the TODO, ship. Six months later nobody remembers it was ever a TODO.

The fix in Express:

\``js app.post('/api/webhook/stripe', express.raw({type: 'application/json'}), (req, res) => { const sig = req.headers['stripe-signature']; let event; try { event = stripe.webhooks.constructEvent( req.body, sig, process.env.STRIPE_WEBHOOK_SECRET); } catch (err) { return res.status(400).send(`Webhook Error: ${err.message}`); } // proceed with event res.json({received: true}); }); ````

The trap: `express.json()` globally parses the body before your handler sees it, leaving Stripe's library to compute the signature against parsed-then-stringified JSON, which never matches. Use `express.raw()` specifically on the webhook route, before any global JSON parser.

FastAPI / Python: read `await request.body()` directly, not `request.json()`. Same idea.

Caveats: a 200 response doesn't prove the app actually grants the attacker something. Some endpoints log every webhook for analytics and return 200 regardless. The 1,542 number is "endpoints accepting unsigned events", not "definitely exploitable". But the misconfiguration is real on its own.

Full writeup with the methodology and platform-by-platform breakdown: https://securityscanner.dev/blog/stripe-webhook-signature-bypass-1500-apps

Curious if anyone here has shipped a Stripe webhook recently and can double-check theirs.

Around 85% success rate of keystroke recovery with our script :)

TL;DR: If a large model finds a 0-day with 90% probability, and a small model with 50% probability, but the small model costs 10x less, it is better to use the small model.

We compared the cost and recall of various models in finding real, recent zero-days and found that for most applications, smaller models run repeatedly can significantly outperform larger frontier models on cost-to-recall.

Disclaimer: I'm involved with Hacktron, the company that produced this research. This is a factual presentation of our benchmarks, which we hope the community can use to make informed decisions about models like Mythos.

Questions regarding netsec and discussion related directly to netsec are welcome here, as is sharing tool links.

Rules & Guidelines

• Always maintain civil discourse. Be awesome to one another - moderator intervention will occur if necessary.
• Avoid NSFW content unless absolutely necessary. If used, mark it as being NSFW. If left unmarked, the comment will be removed entirely.
• If linking to classified content, mark it as such. If left unmarked, the comment will be removed entirely.
• Avoid use of memes. If you have something to say, say it with real words.
• All discussions and questions should directly relate to netsec.
• No tech support is to be requested or provided on r/netsec.

As always, the content & discussion guidelines should also be observed on r/netsec.

Feedback

Feedback and suggestions are welcome, but don't post it here. Please send it to the moderator inbox.

This new report is kind of a wake-up call. KnowBe4 says 86 percent of phishing attacks are now AI-driven, and it shows. It is not just email anymore either. Attackers are hitting Teams, calendar invites, and basically any tool people trust at work. The scary part is how convincing this stuff is getting, especially with internal impersonation and multi-channel setups. At some point, it feels like companies may need AI defending them just to keep up, because humans alone are going to have a harder time spotting this.

This new Linux kernel bug called Copy Fail (CVE-2026-31431) is kinda terrifying because it’s not complicated at all. A normal user can run a tiny 732-byte script and get root, no race conditions or luck required, and it works across major distros like Ubuntu, RHEL, and SUSE. The exploit quietly modifies the page cache instead of the file on disk, so integrity checks don’t catch it, but the kernel still executes the tampered version in memory.

Even worse, since the page cache is shared, it can potentially cross container boundaries too. Patch ASAP if your distro hasn’t already, because this one feels way too reliable…