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

Podcast Logo
Funny User-Agents; FortMail 0-Day; GitLab Patch; macOS Full Disk Access
00:00

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

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.