From unprivileged user to root. Most dangerous for those renting multi-tenanted GPU from a neocloud.

Fixed versions: NvRoot in 610.57.04 / 595.91.07 / 580.178.04

no sysctl or seccomp workaround.

Disclaimer: I work at Stealthium, alongside the team that found these. Happy to answer questions on exposure

I work at IPinfo and this one started with a simple question: if a registry says an address is African, is it actually in Africa?

This started as work for a paper by our research team (WHEREIS, IMC 2026). We tested it with ping times. Light in fiber only travels so far in a millisecond, so a fast reply puts a hard limit on how far away an address can be.

Most registries pass, but AFRINIC is the exception: 2.4% of the addresses we could measure answer from outside Africa. And about 81% of those are in just four blocks, held by one company.

What surprised me most while writing this is that the registries’ own files still list 98.6% of them as African. So anything that blocks or allows traffic by registry country gets these wrong.

The numbers are a minimum, and anycast is left out.

Stormshield's Cyber Threat Intelligence team has uncovered the Trigram campaign, targeting the AI, blockchain, and logistics sectors across Europe and the United States.

• The Bait: Threat actors impersonate 50 companies using fake job offers, invitations, and package tracking notifications to deliver an infostealer to victims.

• Behind the Scenes: A dedicated platform enables the attackers to track the entire operation end-to-end, from the initial click to credential theft.

By correlating this data with research from Proofpoint, SafeDep and Genians, Stormshield attributes this campaign with high confidence to North Korea, as a continuation of the UNK_DeadDrop cluster and the Kimsuky group (APT-43).

A while back, I had released a blog showing that NTLMv1 downgrade attacks still work on Windows Server 2022! While it isn't a default setting, it's still a misconfiguration to potentially look for.

If a DC’s LmCompatibilityLevel is set to 0-2, you can coerce authentication, strip Extended Session Security (ESS), and obtain an NTLMv1-SSP hash that’s crackable with a rainbow table. :)

Blog: https://hunio.org/security/ntlmv1-ssp-cracking/

Many Electron apps auto-update without verifying signatures. Many also still trust the compromised eMudhra certificates. Together, that lets an attacker on your network install malware on your machine.

I've compiled a list of notable Electron apps, installed them in a lab, and test which still trust the eMudhra certs, compared to whether they verify update signatures.

You can find the full table of apps on my post.

UPDATE: Livingston County, MI, has removed amzonses[.]com from its SPF record. It had been there since at least November 2023, and when we checked, it authorized 32,066 IPs to send email as milivcounty[.]gov Since our research on US government domains went public, several government organizations have made changes to their DNS. The City of Waynesboro, TN has fixed the typo in its MX record, and the private company’s homepage served under woosterar[.]gov has been taken down. The Alabama Legislature looks to have a fix in progress too.

I run a small email security consultancy and this is our research.

A typo of AmazonSES in US government DNS whitelisted 32,066 IPs to pass DMARC p=quarantine as milivcounty[.]gov, with the IP set rotating every 3-8 days.

Attackers are snowshoeing the IPs, and once they get listed by Abusix and Spamhaus, they rotate the SPF include chain.

Other AmazonSES typos in gov SPF are amasonses[.]com under pikevilleky[.]gov and amazones[.]com under townofkirkwood[.]gov.

There are also 40 other US Gov domains with dangling & abused NS (domain takeover), MX (mail interception), and DMARC (telemetry hijack) records.

Our team has registered 17 of these typos and expired domains, including one that had been in use for 20 years and only expired in August.

DNS vulnerabilities have been around for decades, but many US government orgs decided to skip the security guardrails when they had the chance, and now those old gaps are being exploited by the same technologies they missed.

CAs found 17% of their own incidents in 2026 so far, down from 29% last year and 59% in 2022. Researchers, root programs, and other outsiders found the rest.

That's from a dataset we built of every TLS incident in Mozilla's CA program since 2017 (1,581 as of November 7). 2026 is already the busiest year, with 338. Only 11 incidents in the whole set are critical, and eMudhra's computable keys are the only one where a CA lost control of its own keys.

https://www.certkit.io/ca-report

Has anyone heard of this?

https://blog.gitguardian.com/the-agents-have-now-found-your-secrets-on-github-artex-is-abusing-public-secrets-right-now/

When the PHP vulnerabilities were first announced, I spent a HUGE amount of time trying to figure out the logic behind them.

As many others who tried investigating them probably noticed, there was barely any technical information available at the time. We had a few basic hints: something related to PHP_SESSION_UPLOAD_PROGRESS, some kind of Out of Memory condition, and, of course, that video Calif published showing a dancing girl with a shell running the exploit in the background. 😂

I found that pretty funny, especially considering the scale of the vulnerabilities and how many servers around the world could potentially be affected. Anyway, that was pretty much all we had to work with!

Even AI assistants weren't particularly helpful. At the time, they were heavily restricted when it came to this subject. A simple technical question about an internal PHP function could get flagged just because you mentioned PHP and something technical in the same sentence. For those of us without access to a more cybersecurity-focused model, even asking basic questions and using AI to help investigate things was practically impossible.

So I started digging into the PHP codebase myself (I was honestly getting a little mentally insane by that point).

I spent countless hours going through the source code, tracing functions, setting up experiments, debugging, and trying to understand exactly what was happening behind the scenes. There were long days and endless nights spent following one thing after another, trying to connect all the pieces until things finally started making sense (the Steal My Bitcoin challenge helped a lot, thanks to James Pavur, and Jaydip Modhwadia (Killa)).

The more I investigated, the more I realized that I wanted to put everything together somewhere. Not just the final explanation, but the entire process: the PHP internals behind the vulnerabilities, what's happening in memory, why certain things happen the way they do, and how all of this eventually leads to a working exploit.

That's how this research project started.

I structured the write-up to start from the basics and gradually build up to the actual exploitation. Each part builds on what came before, with the explanations becoming progressively more technical until we get to the real thing. I wanted someone with little or no experience in low-level memory exploitation to be able to follow along and understand how all the pieces fit together.

The write-up also goes through the actual exploit code used to solve the "Steal My Bitcoin" challenge, breaking it down step by step rather than simply showing the final result.

Everything is based on my own research, local experiments, and understanding of the PHP engine. I'm not claiming this is an official analysis or that everything is necessarily correct. I'm still learning, and there might be mistakes or things I've misunderstood.

And honestly, I was getting tired of explanations that only scratched the surface without actually showing what was happening internally. I wanted to do something different: a proper, in-depth technical walkthrough covering the entire process, examining the important details and explaining not just WHAT happens, but WHY and HOW it happens.

You can read the full write-up here:

PHP2Shell: From Memory to C Internals to Real Exploit Code

And here's the GitHub repository, which also includes the project files and the backstory behind the research:

GitHub Repository

Many common web frameworks like Spring and Ruby on Rails trust the RFC 7239 Forwarded header by default, even though most proxies don't actually have any support for it. This makes apps vulnerable to request hostname or client IP address spoofing in the default configurations.

I've been researching how the Forwarded header is supported across frameworks and proxies. Rails and Spring recently shipped fixes following my research. There are still other frameworks that need application configuration changes to be secure.