Normal view
Critical Apache HTTP/2 Flaw (CVE-2026-23918) Enables DoS and Potential RCE
DAEMON Tools Supply Chain Attack Compromises Official Installers with Malware
-
/r/netsec - Information Security News & Discussion
- Major AI Clients Shipping With Broken OAuth Implementations
Major AI Clients Shipping With Broken OAuth Implementations
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.
[link] [comments]
China-Linked UAT-8302 Targets Governments Using Shared APT Malware Across Regions
-
/r/netsec - Information Security News & Discussion
- Popular DAEMON Tools software infected β supply chain attack ongoing since April 8, 2026
-
/r/netsec - Information Security News & Discussion
- HN Security - Extending Burp Suite for fun and profit β The Montoya way β Part 10
-
The Hacker News
- The Back Door Attackers Know About β and Most Security Teams Still Havenβt Closed
The Back Door Attackers Know About β and Most Security Teams Still Havenβt Closed
MetInfo CMS CVE-2026-29014 Exploited for Remote Code Execution Attacks
-
/r/netsec - Information Security News & Discussion
- Ghosts of Encryption Past β How we Read All Your Emails in Salesforce Marketing Cloud
The Danger of Multi-SSO AWS Cognito User Pools
We Scanned 1 Million Exposed AI Services. Here's How Bad the Security Actually Is
ScarCruft Hacks Gaming Platform to Deploy BirdCall Malware on Android and Windows
-
/r/netsec - Information Security News & Discussion
- Proton Pass: Second-Password Bypass Through Emergency Access
Proton Pass: Second-Password Bypass Through Emergency Access
Weaver E-cology RCE Flaw CVE-2026-22679 Actively Exploited via Debug API
Microsoft Details Phishing Campaign Targeting 35,000 Users Across 26 Countries
-
/r/netsec - Information Security News & Discussion
- We probed 6,000 web apps for Stripe webhook signature checks. 1,542 don't bother
We probed 6,000 web apps for Stripe webhook signature checks. 1,542 don't bother
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.
[link] [comments]
Phishing Campaign Hits 80+ Orgs Using SimpleHelp and ScreenConnect RMM Tools
-
ZDNet | security RSS
- This 4TB WD Black SSD is nearly $1,200 off at Best Buy - and you can still qualify for it
This 4TB WD Black SSD is nearly $1,200 off at Best Buy - and you can still qualify for it
Progress Patches Critical MOVEit Automation Bug Enabling Authentication Bypass