This Week in Security: IngressNightmare, NextJS, and Leaking DNA

This week, researchers from Wiz Research released a series of vulnerabilities in the Kubernetes Ingress NGINX Controller that, when chained together, allow an unauthorized attacker to completely take over the …read more

Mar 28, 2025 - 16:40

This Week in Security: IngressNightmare, NextJS, and Leaking DNA

This week, researchers from Wiz Research released a series of vulnerabilities in the Kubernetes Ingress NGINX Controller that, when chained together, allow an unauthorized attacker to completely take over the cluster. This attack chain is known as IngressNightmare, and it affected over 6500+ Kubernetes installs on the public Internet.

The background here is that web applications running on Kubernetes need some way for outside traffic to actually get routed into the cluster. One of the popular solutions for this is the Ingress NGINX Controller. When running properly, it takes incoming web requests and routes them to the correct place in the Kubernetes pod.

When a new configuration is requested by the Kubernetes API server, the Ingress Controller takes the Kubernetes Ingress objects, which is a standard way to define Kubernetes endpoints, and converts it to an NGINX config. Part of this process is the admission controller, which runs nginx -t on that NGINX config, to test it before actually deploying.

As you might have gathered, there are problems. The first is that the admission controller is just a web endpoint without authentication. It’s usually available from anywhere inside the Kubernetes cluster, and in the worst case scenario, is accessible directly from the open Internet. That’s already not great, but the Ingress Controller also had multiple vulnerabilities allowing raw NGINX config statements to be passed through into the config to be tested.

And then there’s nginx -t itself. The man page states, “Nginx checks the configuration for correct syntax, and then tries to open files referred in the configuration.” It’s the opening of files that gets us, as those files can include shared libraries. The ssl_engine fits the bill, as this config line can specify the library to use.

That’s not terribly useful in itself. However, NGINX saves memory by buffering large requests into temporary files. Through some trickery, including using the /proc/ ProcFS pseudo file system to actually access that temporary file, arbitrary files can be smuggled into the system using HTTP requests, and then loaded as shared libraries. Put malicious code in the _init() function, and it gets executed at library load time: easy remote code execution.

This issue was privately disclosed to Kubernetes, and fixed in Ingress NGINX Controller version 1.12.1 and 1.11.5, released in February. It’s not good in any Kubernetes install that uses the Ingress NGINX Controller, and disastrously bad if the admission controller is exposed to the public Internet.

Next.js

Another project, Next.js, has a middleware component that serves a similar function as an ingress controller. The Nixt.js middleware can do path rewriting, redirects, and authentication. It has an interesting behavior, in that it adds the x-middleware-subrequest HTTP header to recursive requests, to track when it’s talking to itself. And the thing about those headers is that they’re just some extra text in the request. And that’s the vulnerability: spoof a valid x-middleware-subrequest and the Next.js middleware layer just passes the request without any processing.

The only hard part is to figure out what a valid header is. And that’s changed throughout the last few versions of Next.js. The latest iteration of this technique is to use x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware or a minor variant, to trigger the middleware’s infinite recursion detection, and pass right through. In some use cases that’s no problem, but if the middleware is also doing user authentication, that’s a big problem. The issue can be mitigated by blocking x-middleware-subrequest requests from outside sources, and the 14.x and 15.x releases have been updated with fixes.

Linux’ No-op Security Function

The linux kernel uses various hardening techniques to make exploitation of bugs difficult. One technique is CONFIG_RANDOM_KMALLOC_CACHES, which makes multiple copies of memory allocation caches, and then randomizes which copy is actually used, to make memory corruption exploitation harder. Google researchers found a flaw in nftables, and wrote up the exploit, which includes the observation that this mitigation is completely non-functional when used from kvmalloc_node.

This happens as a result of how that randomization process is done. The function that calculates which of the copies to actually call actually uses its own return address as the seed value for the random value. That makes sense in some cases, but the calling function is an “exported symbol”, which among other things, means the return value is always the same, rendering the hardening attempt completely ineffective. Whoops. This was fixed in the Linux 6.15 merge window, and will be backported to the stable kernels series.

Your DNA In Bankruptcy

I’ve always had conflicting feelings about the 23andMe service. On one hand, there is some appeal to those of us that may not have much insight to our own genetic heritage, to finally get some insight into that aspect of our own history. On the other hand, that means willingly giving DNA to a for-profit company, and just trusting them to act responsibly with it. That concern has been brought into sharp focus this week, as 23andMe has filed for Chapter 11 bankruptcy. This raises a thorny question, of what happens to that DNA data as the company is sold?

The answer seems to be that the data will be sold as well, leading to calls for 23andMe customers to log in and request their data be deleted. Chapter 11 bankruptcy does not prevent them from engaging in business activities, and laws like the GDPR continue to apply, so those requests should be honored. Regardless, it’s a stark reminder to be careful what data you’re willing to entrust to what business, especially something as personal as DNA. It’s unclear what the final fallout is going to be from the company going bankrupt, but it’s sure to be interesting.

Appsmith and a Series of Footguns

Rhino Security did a review of the Appsmith platform, and found a series of CVEs. On the less severe side, that includes a error handling problem that allows an unauthorized user to restart the system, and an easily brute-forced unique ID that allows read-only users to send arbitrary SQL queries to databases in their workspace. The more serious problem is a pseudo-unauthenticated RCE that is in some ways more of a default-enabled footgun than a vulnerability.

On a default Appsmith install, the default postgres database allows local connections to any user, on any database. Appsmith applications use that local socket connection. Also in the default configuration, Appsmith will allow new users to sign up and create new applications without needing permission. And because that new user created their own application on the server, the user has permissions to set up database access. And from there postgres will happily let the user run a FROM PROGRAM query that runs arbitrary bash code.

Bits and Bytes

There’s been a rumor for about a week that Oracle Cloud suffered a data breach, that Oracle has so far denied. It’s beginning to look like the breach is a real one, with Bleeping Computer confirming that the data samples are legitimate.

Google’s Project Zero has a blast from the past, with a full analysis of the BLASTPASS exploit. This was a 2003 NSO Group exploit used against iMessage on iOS devices, and allowed for zero-click exploitation. It’s a Huffman tree decompression vulnerability, where attempting to decompress the tree overwrites memory and triggers code execution. Complicated, but impressive work.

Resecurity researchers cracked the infrastructure of the BlackLock ransomware group via a vulnerability in the group’s Data Leak Site. Among the treasures from this action, we have the server’s history logs, email addresses, some passwords, and IP address records. While no arrests have been reported in connection with this action, it’s an impressive hack. Here’s hoping it leads to some justice for ransomware crooks.

And finally, Troy Hunt, master of pwned passwords, has finally been stung by a phishing attack. And had a bit of a meta-moment when receiving an automated notice from his own haveibeenpwned.com service. All that was lost was the contents of Troy’s Mailchimp mailing list, so if your email address was on that list, it’s available in one more breach on the Internet. It could have been worse, but it’s a reminder that it can happen to even the best of us. Be kind.

This is too many levels of meta for my head to grasp Read More