Handler on Duty: Bojan Zdrnja
Threat Level: green
Podcast Detail
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
My Next Class
Application Security: Securing Web Apps, APIs, and Microservices | Las Vegas | Sep 22nd - Sep 27th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Denver | Oct 4th - Oct 9th 2025 |
Daily Trends Report
A new trends report will bring you daily data highlights via e-mail.
https://isc.sans.edu/diary/New%20Feature%3A%20Daily%20Trends%20Report/32170
NVidia Triton RCE
Wiz found an interesting information leakage vulnerability in NVidia’s Triton servers that can be leveraged to remote code execution.
https://www.wiz.io/blog/nvidia-triton-cve-2025-23319-vuln-chain-to-ai-server
Cursor AI MCP Vulnerability
An attacker could abuse negligent Cursor MCP configurations to implement backdoors into developer machines.
https://www.aim.security/lp/aim-labs-curxecute-blogpost
Application Security: Securing Web Apps, APIs, and Microservices | Las Vegas | Sep 22nd - Sep 27th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Denver | Oct 4th - Oct 9th 2025 |
Application Security: Securing Web Apps, APIs, and Microservices | Dallas | Dec 1st - Dec 6th 2025 |
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.