I recently re-tested an old Binance API finding I had reported through Bugcrowd.
The original issue was about Binance API IP whitelisting and derived listenKey stream credentials.
At the time, a listenKey could be created from a whitelisted IP and then used from a non-whitelisted IP to consume private user data streams.
That did not allow trading, withdrawals, or account takeover.
But it did allow real-time access to sensitive private stream data such as balances, orders, executions, positions, timing, and strategy behavior.
The core security argument was:
A derived credential should not be more portable than the credential that created it.
The report was rejected as “Social Engineering” / “Not Applicable”.
I disagreed, because the relevant threat model was not “convince the user to send a token”.
The realistic threat model was supply-chain compromise: malicious code running inside a trusted bot server, CI job, dependency, IDE workspace, or trading environment where API keys already exist.
I re-tested the behavior on May 5, 2026.
Result:
The old behavior appears to be gone.
Spot and Margin no longer use the old listenKey model. Futures still uses listenKey, but now appears to enforce the API key IP whitelist correctly. From a whitelisted IP the calls worked; from non-whitelisted Mullvad exits they failed with the expected IP restriction error.
That is good for users.
But it raises an uncomfortable disclosure-process question:
If a finding is “not applicable” enough to reject, not acknowledge, and not reward — but technical enough to later fix — what should a healthy disclosure process do?
Full technical write-up, timeline, re-test setup, and raw outputs:
I am mainly interested in the process question here:
When a rejected report later disappears from production, should the program re-open it, acknowledge it, partially reward it, or leave it closed unless the researcher can prove direct causality?
It's not just you. Scammers, hackers, and other cybercriminals are complaining about “AI shit” flooding platforms where they discuss cyberattacks and other illegal activity.
It's a fascinating display of leverage: the ShinyHunters folks, with very limited resources and experience (their demographic will be teenagers to their early 20s), consistently gaining access to the data of massive brands. Not through technical ingenuity alone (although I'm sure there's a portion of that), but primarily through good ol' social engineering. That's coming through in the disclosure notices from the impacted companies, and Mandiant has a good write-up of it too:
These operations primarily leverage sophisticated voice phishing (vishing) and victim-branded credential harvesting sites to gain initial access to corporate environments by obtaining single sign-on (SSO) credentials and multi-factor authentication (MFA) codes
Question now is how long their run will go for. There's a very predictable ending if things keep going in this direction but right now, they show little sign of abating.
In this blog post I introduced several novel techniques:
1.How to get all routes - no need to authenticate.
How to get methods to fuzz from pages and not just the bootstrap JS files - the vast majority of methods are in those pages and not the JS files that existing tools and guides point to.
How to parse "LWC" components and not just legacy components.
Graduating should feel like a fresh start, a time when the whole world is at your fingertips.
Unfortunately, scammers often see graduates and think “student loans.” Or more specifically “student loan scams.”
As student loan payments resume or repayment plans shift, scammers move in fast; posing as loan servicers, promising forgiveness, or offering to “simplify” your loans for a fee.
The tricky part? These messages often look real.
That’s where tools like McAfee’s Scam Detector come in. It flags suspicious emails, texts, links, and even deepfake-style messages, helping you spot what’s real before you click, respond, or pay.
Here’s how to spot these scams and stay safe with McAfee:
What Is a Student Loan Consolidation Scam?
Student loan consolidation itself is a legitimate option. It allows you to combine multiple federal loans into one, often to simplify payments.
Scammers exploit that confusion.
Instead of helping, they pose as government partners or “relief experts” and charge you for services you can do yourself…for free.
According to Federal Student Aid, you never have to pay for help managing or consolidating your federal student loans.
That’s the baseline truth most scams try to blur.
How These Scams Actually Work
Step
What Happens
Red Flags
What Scammers Want
1. The Outreach
You get an email, text, or call about “loan consolidation” or “forgiveness”
Urgent tone, unfamiliar sender, “final notice” language
Your attention and quick reaction
2. The Hook
They claim you qualify for a special program or limited-time offer
“Act now,” “guaranteed forgiveness,” or “new law” claims
Your trust
3. The Ask
They request payment or personal info
Upfront fees, requests for FSA ID or bank info
Money + account access
4. The Control
They may ask for authorization to manage your loans
Power of attorney forms, account takeover steps
Full control of your loan account
Luckily, for McAfee+ Advanced users, they have access to Scam Detector which alerts users to suspicious emails, messages, links, and deepfakes that are often employed by scammers in these student loan fraud scenarios.
The Most Common Lies to Watch For
Scammers tend to recycle the same scripts. Federal Student Aid warns about messages like:
“Act immediately to qualify for student loan forgiveness before the program is discontinued.”
“You’re eligible for total loan discharge. Call now.”
“Your loans are flagged for forgiveness pending verification.”
These messages are designed to create urgency, not clarity.
And importantly, they are notcoming from the U.S. Department of Education or its partners.
Image Courtesy of STUDENTAID.GOV.
Where McAfee’s Scam Detector Comes In
This is exactly the kind of gray-area messaging that trips people up.
Federal Student Aid also recommends reviewing your account activity and confirming no unauthorized changes were made.
The Bottom Line
Student loan consolidation scams don’t look like scams anymore.
They look like helpful emails. Official notices. Last chances.
That’s why protection today isn’t just about knowing the rules, it’s about having backup when something feels off.
With McAfee, you’re not left guessing. You can spot suspicious messages, understand the risks, and move forward with confidence, without handing your time, money, or identity to someone who doesn’t deserve it.
Because starting your post-grad life shouldn’t come with a scam attached.
ESET researchers have investigated an ongoing attack by the ScarCruft APT group that targets the Yanbian region via backdoor-laced Windows and Android games
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.
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 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.
Using a 1930s trade law, Homeland Security targeted the man—who hasn’t entered the US in more than a decade—following posts on X condemning the killings of Renee Good and Alex Pretti.
Login
