SANS Stormcast Wednesday, January 28th, 2026: Romance Scams; DoS Vuln in React Server Components; OpenSSL Patch; Kubernetes Priv Confusion

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9784.mp3

previous

Romance Scams; DoS Vuln in React Server Components; OpenSSL Patch; Kubernetes Priv Confusion

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Wednesday, January 28, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Master's Degree Program in Information
 Security Engineering. Well, today's diary comes from one
 of our undercredit interns, Fares Azhari, wrote about the
 initial stages of romance scams. You probably received
 some of these text messages yourself that look like they
 were just misrouted. Someone typing the wrong phone number
 and looking for an old friend. Well, this is just the start
 of it. The goal here is to retain the interest of the
 victim. That's the recipient of this text message. Get them
 involved in a more elaborate conversation. And of course,
 in the end, getting money out of them. Now, what Fares found
 here is that there were likely multiple scammers involved
 here impersonating the same individual. Also, the money in
 the end, well, was apparently being extracted via crypto
 coin scams. Fares, of course, didn't follow up on the actual
 crypto coin scam, but let it be at that stage. The scammer
 was, of course, no quiet insistence after investing
 some time into the conversation to actually get
 Fares then to take the next step, which didn't happen
 here. A couple sort of comments on this. So first of
 all, these scams are very common. Most people don't fall
 for them. But sadly, ever so often, someone does fall for
 these scams. And from what I have heard from people who try
 to help victims is that it can sometimes be very difficult to
 convince the victim that this is actually a scam. So that's
 an added problem here. And I think it's probably also
 related with the victim not really wanting to admit that
 they fell for something that in hindsight was a very
 obvious scam. The other thing that sort of made the news
 ever so often is that the scammers here, which well are
 essentially sort of call centers, aren't always
 scamming voluntarily, but that there are also victims of some
 sorts of human trafficking and such that are basically being
 forced to conduct these scams. So a very complex case and
 scam overall. And best thing, of course, is don't respond to
 these scams. Well, maybe have some fun with them if you want
 to do it and waste some time off yourself and the scammer.
 But your time is probably more valuable than the time of the
 scammer. Then we do have a patch for the patch for the
 patch that was originally triggered by React to Shell.
 Remember back in December, we were all worried about React
 to Shell, the remote code execution vulnerability in
 React server components. Well, that was patched relatively
 quickly, but then there was a denial of service
 vulnerability that wasn't completely patched. So that
 was patched also, I think, around New Year. And now we
 have another denial of service vulnerability that had to be
 patched. So that's another sort of leftover of that React
 to Shell. Again, it's only denial of service. So it's not
 another React to Shell, but something you probably want
 to, well, patch as you get around it. And OpenSSL
 released updates at this time fixing one vulnerability in
 more recent OpenSSL version. That's three and later that
 may lead to code execution. Now I say here may and should
 probably say it's probably not going to lead to code
 execution. It's probably more going to be a denial of
 service. But what's happening here is that we do have a
 classic stack-based buffer overflow. This one is in the
 CMS auth envelope data parsing. And this is something
 that happens before sort of any signatures and so are
 verified. So it's pre-auth occasion and could potentially
 be exploited via SMIME messages. The actual
 vulnerabilities of your classic buffer overflow, you
 have these IV parameters, for example, that should have
 fixed length. So that's the length of the buffer being
 assigned. But then due to the fairly tricky sometimes ASN.1
 encoding in these certificates, the key
 material, well, you can actually specify a larger
 length than the standard allows, which then leads to
 that buffer overflow. So get it updated. But I don't think
 too many systems are using OpenSSL version 3 yet. It's
 still sort of a little bit newer. So if you don't use
 that, you don't have a problem here. And like I said, the
 exploitation is tricky because usually these stack-based
 buffer overflows are reasonably well mitigated with
 various compiler options and such. And then we got an
 interesting Kubernetes issue. I call it, I don't call it a
 vulnerability because Kubernetes calls this expected
 behavior. What's happening here is if you're connecting
 to the API and you have get permissions to connect to the
 API and you set up a WebSocket. The problem is that
 your permissions are only verified as you're starting
 the WebSocket. Because with WebSockets, it's not like
 normal HTTP. You no longer have individual requests. You
 now have a connection. So with normal HTTP, you have to
 authenticate and access control every single request.
 With WebSocket, you really, if you do it right, only have to
 basically authenticate and access control the user at the
 beginning of the connection. However, the problem here is
 that then later the user may send create or permissions
 requiring create permissions, like for example, to the slash
 exec endpoint, which does give the user access to execute
 arbitrary commands on the kubelet. So that's the basic
 risk here that if you are giving user limited permission
 to the nodes proxy, then they can escalate their permission.
 Really sort of more awareness item that you're aware of
 this, that you know that what you're doing here by giving
 these permissions as the advisory here notes. Well,
 it's sadly sometimes needed for monitoring and such that
 you do assign those permissions. So it may not be
 that easy to further and accurately restrict those
 permissions. Well, and this is it for today. So thanks for
 listening. Thanks for liking. Thanks for subscribing to this
 podcast and talk to you again tomorrow. Bye.
 Bye.