SANS Stormcast Tuesday, August 05, 2025: Daily Trends Report; NVidia Triton RCE; Cursor AI Misconfiguration

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/9556.mp3

previous

next

Daily Trends Report; NVidia Triton RCE; Cursor AI Misconfiguration

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

New Discussions closed for all Podcasts older than two(2) weeks
Please send your comments to our Contact Form

Podcast Transcript

 Hello and welcome to the Tuesday, August 5th, 2025
 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 Undergraduate Certificate Program in Applied
 Cybersecurity. Today I added a new daily notification report
 that you may subscribe to via email or, well, just download
 the raw JSON from the website if you want to sort of build
 your own little report like this. This is really something
 that I found useful. I originally built it for myself
 and figured, well, you know, why not share it with others?
 So you may also see some interesting new things in our
 data. It does summarize some of the highlights of the data
 for each day. Starts out with our suspicious domains for the
 particular day that we sort of identified. Then any new URLs
 from our web honeypots. So here looks like, for example,
 some of these Odin calls were new. And then, yeah, yet
 another variation of SharePoint, of course. This is
 actually an older vulnerability here. Just a
 slightly different sort of way of using it. This uedit part
 here, I think, is usually ueditor. So attackers trying
 something a little bit different. Top SH data. Here
 we are looking at the new usernames that we have seen.
 Sysadm3. That could potentially be interesting.
 Haven't really looked at the details here yet for this
 particular one. There are some odd ones like this user agent.
 That just happens if an attacker is sending an HTTP
 request to a telnet server. Well, this is being logged as
 a username in this case. Finally, we also have top
 ports. That's actually, in my opinion, a little bit the
 least interesting report at this point. All of this is
 still being worked on and refined on an ongoing basis.
 If you have any ideas, any additional data or such that
 you would like to see included, please let me know.
 And as I mentioned, you can also just get the data
 directly here. A little JSON snippets. Sometimes, of
 course, we had issues with reports like this where they
 got blocked by various email gateways. So, if you have any
 feedback here, please let me know. And NVIDIA patched
 critical vulnerability in its Triton servers. These are
 servers that are used for AI training. And the
 vulnerability was identified by researchers from WIS. And I
 kind of like this vulnerability. Not just
 because, well, it affects these very important and
 critical systems. But also how it really leads from a simple
 information leakage vulnerability to a complete
 system compromise. As I often say when I talk about
 information leakage vulnerabilities, they're all
 about essentially the creativity of the attacker.
 And what WIS found here is an error message. If you
 essentially run out of memory on the system, you get this
 relatively harmless-looking error message that the system
 failed to increase the shared memory pool size. And then it
 gives you the name of that memory area. This is a file
 actually in DEFSHM, the shared memory file system, that's
 very commonly used on Linux. The problem is that the
 attacker may also use that same shared memory device and
 establish regions with arbitrary names. So once the
 attacker knows this file name, an attacker is then able to
 create a memory region that overlaps with it, which has
 the same file name. And if you look at the file name, it's,
 well, a UUID. It's a long random string. Without that
 leak in the error message, an attacker would pretty much
 have no chance of ever guessing that value. Once the
 memory is compromised, the attacker is now able to
 essentially execute arbitrary code. And that, of course,
 could lead to the leak of any models you have running there
 to compromise the data. And in general, well, whatever an
 attacker would do with a nice, valuable resource like this.
 Patches have been made available. So if you're using
 these systems, make sure you apply them. And just to stick
 with AI for a second story, we do have this blog post by AIM
 Security about, well, I'm not really sure it's a
 vulnerability. It's really more a feature in the popular
 AI editor Cursor. The problem here is something that they
 call MCP Auto Start. So MCP often used for agentic AI,
 where you are passing data from various systems directly
 to, in this case, a Cursor. And the Cursor offers a very
 easy way to configure this. In Cursor, you may have a file in
 your home directory called .Cursor.mcp.json. And this
 file basically describes various connectors that it
 would like a Cursor to listen on. Well, in this case, Slack.
 And, well, I don't think that's really a surprise. And
 I would hardly call it a vulnerability. But if you are
 connecting Cursor, the code editor that also executes
 code, codes to a Slack channel where anybody can post
 messages, well, then anybody who has access to Slack
 channel is able to execute code on your system. I still
 mention it here because apparently, for some
 developers, this is big news. The entire idea of
 unvalidated, untrusted user input. Remember, the basic
 rule of application security still applies. Users are
 always evil. Validate your input. Provide strong
 authentication and access control before you execute any
 significant code. Well, and that's it for today. So,
 thanks again for listening, and talk to you again
 tomorrow. Bye.