Summary4 min read

SANS Stormcast Episode Summary

Podcast: SANS Internet Stormcenter Daily Cyber Security Podcast (Stormcast)
Host: Johannes B. Ullrich
Episode Date: February 25, 2026
Episode Theme: Key Daily Cybersecurity Updates — Open Redirect Attacks, New SetHTML API in Firefox, and Latest Telnetd Vulnerability

Overview

This episode covers major security developments including a surge in open redirect scans, an important update on web application security standards from Mozilla Firefox, and a new privilege escalation issue in Telnet daemons (telnetd). Johannes B. Ullrich provides technical context, risk analysis, and practical mitigations for these late-breaking vulnerabilities in his characteristically clear, practical tone.

Key Discussion Points

1. Surge in Open Redirect Exploits

Timestamp: 00:15–02:20

Recent Trends: SANS Internet Stormcenter honeypots report a significant increase in scans targeting open redirects.
- Attackers are actively probing, especially login and clickthrough pages, for redirect flaws.
What is an Open Redirect?
- A flaw where a web app redirects users without validating the destination, making it susceptible to phishing and other abuse.
- “Open redirects is basically a redirect where you’re not really filtering what page you’re redirecting the user to.” — Johannes B. Ullrich [00:40]
Exploitation Workflow:
- Often abused in phishing, and now increasingly in OAuth2 flows, where an attacker can hijack the credential authorization process if they can control the redirect URI.
- “If an attacker is able to swap that redirect URI for a URI that is vulnerable for an open redirect, the attacker may obtain credentials...” — Johannes B. Ullrich [01:45]
Community Guidance:
- While not an OWASP Top 10 issue, there’s an OWASP Open Redirect Cheat Sheet recommended to help prevent and mitigate open redirects.
Source of Recent Scans: Most originate from a single IP (associated with “IP Volume,” a known “bulletproof hoster”).
- “IP Volume is often referred to as a bulletproof hoster... not really all that eager to follow up on abuse requests.” — Johannes B. Ullrich [02:06]
- Review whether blocking this AS is appropriate for your organization.

2. Mozilla Firefox Adds setHTML: A New Weapon Against XSS

Timestamp: 02:21–03:41

What’s New?
- Mozilla’s Firefox team introduces setHTML—part of the Sanitizer API—aimed squarely at combating cross-site scripting (XSS), especially DOM-based.
Technical Details:
- Prior approaches:
  - innerHTML: Dangerous, as it can easily introduce XSS if input is not sanitized.
  - innerText: Completely safe, but no markup allowed.
- setHTML offers a balance—allows HTML markup, but blocks unsafe content (notably, anything JavaScript-related).
- Comes with robust defaults but is configurable (developers can define which tags/attributes are permitted).
- Also supports the Trusted Types standard for further security.
- “Pretty easy standard to implement in my opinion... You still are able to use markup, just no JavaScript.” — Johannes B. Ullrich [03:10]
Browser Support: Currently implemented only in Firefox and Chrome; Safari implementation is pending.
- “Once I think Safari does, then this becomes a real usable standard...” — Johannes B. Ullrich [03:32]
Impact: Offers easier mitigation of XSS, especially useful for modern JavaScript-heavy applications.

3. Another Telnetd Environment Variable Vulnerability

Timestamp: 03:42–05:01

Background:
- Telnetd has a history of vulnerabilities—episode recalls a recent “dash” flaw in command-line parsing.
New Issue:
- Recent bug allows attackers to exploit telnetd by setting specific environment variables, notably CREDENTIALS_DIRECTORY.
  - If an attacker can create a file anywhere on the system, they might escalate to any user, including root.
  - “If an attacker is able to create a file essentially anywhere on the system, they're then able to log in as any user, including root.” — Johannes B. Ullrich [04:32]
Mitigation Advice:
- Best practice: allow only a strict list of environment variables (like “locale,” “language,” encoding) to be set via telnetd.
- Some vendors have implemented allowlists; others use blocklists (far less reliable, easier to evade).
- “The solution is to just limit it to these specific environment variables.” — Johannes B. Ullrich [04:45]
Scope:
- “Interesting vulnerability. It's really more a privilege escalation vulnerability.” — Johannes B. Ullrich [04:20]

Notable Quotes and Memorable Moments

“Open redirects is basically a redirect where you’re not really filtering what page you’re redirecting the user to.” — Johannes B. Ullrich [00:40]
“If an attacker is able to swap that redirect URI for a URI that is vulnerable for an open redirect, the attacker may obtain credentials...” — Johannes B. Ullrich [01:45]
“IP Volume is often referred to as a bulletproof hoster... not really all that eager to follow up on abuse requests.” — Johannes B. Ullrich [02:06]
“Pretty easy standard to implement in my opinion... You still are able to use markup, just no JavaScript.” — Johannes B. Ullrich [03:10]
“If an attacker is able to create a file essentially anywhere on the system, they're then able to log in as any user, including root.” — Johannes B. Ullrich [04:32]
“The solution is to just limit it to these specific environment variables.” — Johannes B. Ullrich [04:45]

Timestamps of Important Segments

Open Redirects Discovered by Honeypots: 00:15–01:45
Open Redirects in OAuth2 Flows: 01:20–02:10
Bulletproof Hosting and Abuse: 02:00–02:20
Firefox setHTML & Sanitizer API: 02:21–03:41
New Telnetd Environment Vulnerability: 03:42–05:01

Conclusion

This episode arms defenders with actionable intelligence around emergent threats and mitigation techniques—from simple web app fixes to re-evaluating network blocklists and adopting new browser security APIs. Johannes succinctly connects threat activity seen in the wild to practical, up-to-date defense strategies, especially around web application security (both in code and in incident response).

For further links and cheat sheets mentioned, visit isc.sans.edu.

Loading summary

Transcript1 lines

[00:05]
A
Hello and welcome to the Wednesday, February 25, 2026 edition of the sans United Storm Center's Stormcast. My name is Johannes Ulrich, recording today from Jacksonville, Florida and this episode is brought to you by the Sans Edu Graduate Certificate Program in Cloud Security. One thing I noticed today was that our honeypots have been seeing recently a big increase in the number of SC looking for open Redirects an open redirect is a feature in a web application where the web application redirects you to another site without any regard as to where the user is really being redirected to. And it often happens as part login pages where you would like to, for example direct a user to the page they originally attempted to visit and well, all sorts of click through counters and similar features that often use redirects and with that are susceptible to creating open redirects. There are a couple of problems with open redirects. So open redirects is basically a redirect where you're not really filtering what page you're redirecting the user to. The receiving page may then for example receive URL parameters, but could also be used for phishing. One spot where this has been particular sort of a little bit of problem lately is with OAuth2 where during the initial credential flow where you are authorizing a site to use a particular service, well, the sites are being redirected back to the client that's attempting to use these credentials. But if nethacker is able to swap that redirect URI for a URI that is vulnerable for an open redirect, the attacker may obtain credentials and that sort of bypasses some of the protections that sites have put in place to prevent these changes of the redirect uri. So it's certainly an important vulnerability. It's not currently sort of part of the OWASP top 10, but OWASP has a great sort of cheat sheet about open redirects and how to prevent them and why they are a problem. Also interesting here, pretty much all of the requests that sort of responsible for that peak over the last few days, they came from one IP address associated with IP volume. IP volume is often referred to as a bulletproof hoster, meaning that they're not really all that eager to follow up on abuse requests and are often providing shelter to some illegal activity. So you may want to take a look at whether or not it's appropriate for you to block their as. And talking a little bit about web application security, we do have an interesting new development here From Mozilla, from the Firefox team and that support for Set HTML Set HTML is part of the Sanitizer API and that's a standard that's supposed to make it easier to prevent some cross site scripting attacks. In particular some of these DOM based cross site scripting attacks that have been particular domain difficult to sort of prevent in some modern applications. The problem here is that we often use JavaScript in order to insert unsanitized text into an HTML page. And then of course you are opening yourself up for cross site scripting. What the Sanitizer API in Set HTML does is that it basically doesn't allow you to insert unsafe HTML and that's in particular anything that's related to JavaScript. It comes with the default configuration that's pretty good, but you can basically define also your own configuration and which particular HTML tags and attributes you are allowing. Pretty easy standard to implement in my opinion. And it sort of tries to basically balance the two ends we had so far. We had inner HTML which of course was horribly unsafe and that led to a lot of these problems. And we had inner text which didn't allow any HTML at all. So with Set HTML you still are able to use markup, just no JavaScript. There's also the idea of trusted types that's also supported Set HTML at this point in the Sennheiser API appears to be only supported in Firefox and Chrome. So Safari is still holding out here. Haven't really found anything quickly sort of when Safari, if Safari is going to implement this once I think Safari does, then this becomes a real usable standard to actually integrate in your web applications. You know how it sometimes goes if there's a vulnerability in a particular piece of software, we then have people look closer and find additional vulnerabilities. There's a second pretty bad and interesting Telnet the vulnerability. Remember we had like a couple months ago, the one with the dash? They're basically command line parameters for easily passed to the login shell and then you could essentially bypass authentication. This second one isn't quite as bad. It's really more a privilege escalation vulnerability. But the root cause here is that Telnet also is able to set environment variables and some environment variables can be used for authentication. In particular, one pointed out here in the bug report by Ron Ben Itzhak is Credentials Directory Credentials Directory is basically where you find credentials. And if an attacker is able to create a file essentially anywhere on the system, they're then able to log in as any user, including root so that's the problem here. Pretty interesting vulnerability. As I said, the workaround apparently some versions of Telnet have implemented this, but the workaround here is that you only allow very specific environment variables to be set. There are couples that are useful like null language and things like that and encoding parameters and such that are useful and that Telnet does routinely set. And the solution is to just limit it to these specific environment variable. Apparently others have just basically set up block lists of environment variables they don't allow. Then, of course, people just come up with a different way to set the same environment variable or another environment variable that they may have missed. That's not systems are using well. And that's it for today. Thanks for listening, thanks for liking, thanks for subscribing, and special thanks to anybody leaving a good comment with your favorite podcast platform. And talk to you again tomorrow. Bye.