Hello and welcome to the Thursday, December 11th, 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 Master's Degree Program in Information
Security Engineering. Well, in diaries today we do have a
detect that I associate with a Kubernetes vulnerability that
was patched last year, an OS command injection
vulnerability. This vulnerability was a fairly
straightforward OS command injection in the node log
query feature. Wasn't widely exploited in part because at
least at a time this feature was still in beta and wasn't
enabled by default. Also, the user in order to attack this
feature must have the privileges to actually query
logs. Now, the way the exploit works was you just sent
essentially data to the logs endpoint and the pattern
parameter was injectable. Now, the OS command injection,
there are a couple different ways how to often do that with
like backtakes or pipes or ampersand. In this case, the
attack worked by enclosing the operating system commands in
parentheses leading with a dollar symbol. So that very
common shell extrapolation that is often used for these
types of attacks. Well, today I was actually looking for
some React exploits and while sort of going to my logs, I
found this other request that reminded me a little bit of
this particular Kubernetes vulnerability. So I wonder if
it's related. So I wonder if it's related. However, in this
case, the OS command injection is not a command line
parameter. Instead, it's part of the URL, but it still uses
that same dollar parentheses pattern. Also, still at the
end of the URL, we have a static string /logs/
just like for the Kubernetes vulnerability. So if anybody
has any ideas of what this could be about, let me know.
But maybe sort of a slightly different variant of the
exploit to hit the same vulnerability or maybe
something new and different. And then talking about React
to Shell, Wiz has a real nice blog summarizing some of the
attacks that are currently going around pretty much
matches what we are seeing as well. And also a couple of
additional details about this particular vulnerability. One
point I think that's important to make here is that currently
we do see pretty much all the exploits. So specifically
targeting next.js and that's sort of what's also visible
then in respective headers and such. So some people may use
that to filter requests, which is probably a good idea if
you're not using React or next .js. But the problem is that,
well, it's not really a next .js vulnerability. The
vulnerability is in the React server components and next.js
is just the more popular way how these RSCs are exposed. So
other components may also expose them. And the exploit
may work with some modifications, as Wiz points
out, without next.js. But if you're using instead some
other additions that are taking advantage of React.
Server components. So keep that in mind when you're
setting up your filters. Again, these web application
firewall filters that are commonly being proposed here,
they aren't perfect. They are meant to buy you time. They're
not supposed to, well, substitute patching. And then
we got a new update for Notepad++. Now, typically I
don't talk about Notepad++ updates, but this one fixes an
interesting and already exploited security issue.
Apparently Notepad++ didn't verify signatures when it
downloaded updates. And yes, you know, often you can get
away with this. But in this case, it has already been
exploited by entities hijacking traffic to Notepad++
servers. So this is the only really significant issue being
fixed. And yes, these attacks do happen. So be careful how
you are updating your software. Make sure you're
verifying any certificates of servers that you may be
connecting to, but also verify the executable you're
downloading itself by checking respective signatures. And
then we have an interesting privilege escalation
vulnerability in Mac OS that currently has not been patched
yet and is relatively straightforward to exploit.
It's actually very similar to an older vulnerability that
was patched last year. And I'll link to the older
vulnerability in the show notes. The newer one, haven't
really seen sort of a decent write-up of it. So sort of
bits and pieces across social media. Maybe I'll find
something and if so, then I'll add it. But the fundamental
problem here is that, of course, when you're running an
installer to install some packages, well, the installer
runs as root. But the problem is that this installer may
then also, well, use resources on the system. And one of
these resources is C shell, the default shell on Mac OS.
And a user may prepare malicious C profile file
that's then being loaded at the beginning of executing C
shell. And of course, the user is able to manipulate that
file that's owned by the user and can execute commands as
root as a result. So interesting little
vulnerability. I was actually sort of hoping that Apple
would release updates today. They're sort of due to release
updates this week. Maybe we'll see them tomorrow. And then
I'll point out in case this vulnerability is being
addressed. Well, and that's it for today. And thanks again
for any likes and recommendations. And this
week, as I mentioned before, would be nice if a couple
people would leave some good comments with Apple podcast.
Let me know if you did so. And that's it for today. Thanks
and talk to you again tomorrow. Bye.
