Handler on Duty: Guy Bruneau
Threat Level: green
Podcast Detail
SANS Stormcast Monday, October 5th, 2026: Funny User-Agents; FortMail 0-Day; GitLab Patch; macOS Full Disk Access
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/10122.mp3
My Next Class
Click HERE to learn more about classes Johannes is teaching for SANS
User Agent Strings Curiosities
https://isc.sans.edu/diary/User%20Agent%20Strings%20Curiosities/33394
FortiMail Improper limitation of a pathname to a restricted directory CVE-2026-104286
https://fortiguard.fortinet.com/psirt/FG-IR-26-175
Critical GitLab Vulnerability CVE-2026-90970
https://docs.gitlab.com/releases/patches/other-patches/patch-release-gitlab-ai-gateway-19-4-1-released/
Updates to Full Disk Access in macOS
https://developer.apple.com/news/?id=p6zjojqw
My Upcoming Classes
https://www.sans.org/profiles/dr-johannes-ullrich
| Network Monitoring and Threat Detection In-Depth | Amsterdam | Oct 12th - Oct 17th 2026 |
| Application Security: Securing Web Applications, APIs, and Microservices | Washington | Dec 14th - Dec 18th 2026 |
| Application Security: Securing Web Applications, APIs, and Microservices | Online | US Eastern | Feb 8th - Feb 12th 2027 |
| Application Security: Securing Web Applications, APIs, and Microservices | Online | India Standard Time | Mar 15th - Mar 19th 2027 |
| Application Security: Securing Web Applications, APIs, and Microservices | Orlando | Apr 12th - Apr 16th 2027 |
| Application Security: Securing Web Applications, APIs, and Microservices | Online | US Mountain | Apr 21st - Apr 25th 2027 |
| Application Security: Securing Web Applications, APIs, and Microservices | Baltimore | May 17th - May 21st 2027 |
Podcast Transcript
Hello and welcome to the Monday, October 5th, 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 Graduate Certificate Program in Cyber Defense Operations. In Diaries this weekend, Didier talked about, well, funny user agent strings. Didier's Honeypot, as all of our Honeypots are of course collecting lots and lots of HTTP requests and some of them come with a little bit odd or interesting user agent strings. We already had the one that the hacker basically claims in user agent string that they're in Belarus and he helped me escape from Belarus. User agent string, of course, has made the rounds for quite a while. There are also, of course, some user agent strings that are from companies that are scanning the internet for their own commercial or research purposes. Quite a few variations, for example, of Claudebot, for example. We also have famously Palo Alto. They're pretty aggressively scanning web applications as well. They have their own user agent string. Now, whenever you do scans like this, it's of course always good to identify who originated the scans. So these kind of strings are certainly useful. A URL where you can learn more about the scan, where you can opt out or an email address that you can contact in case the scan causes problems. Treat them, of course, also with a grain of salt. They are not always correct. They are sometimes spoofed. Famously, years ago, we had some bot that used as a user agent like the SANS ISC scanner. No, we are not affiliated with this. And another thing to consider before you sort of start your own scanning of the internet project, we're currently tracking 40, 50 different organizations already doing that. So take a look if some of the researchers are willing to share their data or something's just easier to buy a data set like this than running your own scanner and scanning the internet yet again. There's a very large percentage these days of scans that our honeypots are detecting that are affiliated with these internet-wide research scans. So, well, just don't add to the noise. From a defensive point of view, definitely makes sense to block some of these user agents. Yes, real attackers will not use these user agents, but it does substantially cut down on the noise and can also help with some load issues on your web applications. And on Friday, I told you that I'll give you a break with a zero-day attacks for the weekend. Well, so we have to catch up today. Thursday, Fortinet did release an update for 40 mail. This fixes a vulnerability that was already exploited at the time. It's a path traversal vulnerability. We had quite a few of them, but this one isn't quite as stupid as some of the others. It's not a Yarl encoding. It's the null byte or the null character cause issues. Typically, when attackers sort of are tall enough to get beyond Yarl encoding, that's not the next thing they're looking at. And in this case, it does allow an unauthenticated hacker to write arbitrary files on the underlying system. And with that, they achieve remote code execution. This vulnerability is linked to the identity -based encryption or IBE feature in Fortinet Mail. So one option is instead of patching, you may want to turn it off. If you don't use it, maybe turn it off anyway. The identity-based encryption Fortinet Mail is a feature where you can add certain keywords to the subject line, like Fortinet Mail Confidential and such. And then Fortinet Mail will automatically encrypt the email before it's being sent out to the recipient. So if you're not using this feature, may as well turn it off. Who knows what other little Easter eggs are hidden in that feature that attackers may take advantage of. Fortinet also provides some of the indicators of compromise that you may be seeing in your logs if you are attacked by the attackers that they have spotted taking advantage of this vulnerability prior to the patch being released. And if you're running GitLab on -premise, there's a critical update for you for the AI gateway. This does allow an attacker to manipulate some of the workflows that you have configured, which then of course can lead to code execution and a compromise of the AI gateway. Again, only an issue if you run it locally. The cloud stuff has been taken care of by GitLab already. Nothing you have to do in this particular case. And for a while now, Apple has restricted access of applications to the file system and they kind of encourage developers to sort of take a sandbox approach here for files needed by the application. But occasionally, of course, applications need access, for example, your home directory, download directory, or other locations on the file system. And well, there is this permission system where you can assign these permissions to particular applications. Usually you see like the famous pop-up messages asking for permission. Now, one easy shortcut around all of this for developers is to just ask for full disk access. Apple has put developers now at notice stating that they're reviewing how this full disk access is granted, whether or not applications really need it. One interesting point they're making is that this not only puts the user's data at risk, but in particular, if data from communication applications, messengers and such is exposed, it also puts data at risk that belongs actually more to people communicating with the user. So we'll see what this will exactly involve. There is not a lot of detail here yet, just that Apple in future versions of macOS macOS is likely going to a more fine-grained access system or where full disk access isn't really full disk, but full disk minus some critical locations. Well, and that's it for today. So thanks for listening. Thanks for liking, subscribing, and thanks for leaving good comments on your favorite podcast platform. And talk to you again tomorrow. Bye.





