This Week In Security: Record Patch Tuesday, PHP’s Bad Time, The Oldest Vuln, AI Armies, And More

It’s no longer a proper month without Microsoft breaking its own record for security fixes, and October’s Patch Tuesday was no exception. Brian Krebs brings the roundup: more than 1,400 vulnerabilities fixed in a single batch, dwarfing September’s record of nearly 1,000, which itself was about ten times the normal monthly load. According to Tenable, Microsoft has now passed 4,000 CVEs for the year with two months still to go.

Only one of the fixes is for a vulnerability already being exploited in the wild: CVE-2026-96951, a security feature bypass in the Windows Shell affecting Windows 10, 11, and some Server versions. A .NET Framework bypass, CVE-2026-108398, was publicly disclosed before the patch, giving attackers a head start, and with modern AI tooling, it seems like not much of a head start is needed. At least 78 of the bugs are rated critical, and most of those allow remote code execution with little or no user interaction. Windows 10 holdouts can relax a little: Microsoft quietly extended free updates through October 2027.  Given the pace of exploitation, this is probably the only way to prevent an Internet-scale meltdown.

Microsoft credits LLM-driven bug hunting for the volume, which leaves the poor admins who have to test and deploy all of this in an unenviable spot. Fortra’s analysis shows that only 26 Microsoft vulnerabilities have landed in the CISA KEV catalog of actively exploited bugs so far this year, so start there. For the rest, the SANS Internet Storm Center and Cisco Talos have the usual breakdowns by severity. Or, you know, just patch everything and hope for the best, which is roughly what everyone does anyhow.

Continue reading “This Week In Security: Record Patch Tuesday, PHP’s Bad Time, The Oldest Vuln, AI Armies, And More” →

This Week In Security: Critical DNS Keys Rotated, Hacking Freezers Isn’t Cool, OpenAI Spies On Itself, And Advanced Hardware Wallet Hacks

Critical Internet keys changed this week. Did you notice?  The keys behind DNSSEC, the system for cryptographically validating DNS responses, rolled over on October 11 2026. This is the second time the DNSSEC keys have rotated since the system was implemented, and the first time in 2018 didn’t exactly go entirely smoothly.

DNS is what resolves a host name and turns it into an IP address. It underpins web browsing, email, and just about every other connection. It’s also a very early Internet protocol, written in both a simpler, less paranoid era, and an era where encryption was computationally expensive and legally problematic. DNS offers little protection against malicious actors spoofing responses, and the impacts range from phishing to redirecting email to just about any other manipulation of connections you can image.

DNSSEC addresses this by creating a chain of trust between DNS resolvers — the servers that forward the DNS query into the DNS infrastructure and return the results — and the global DNS servers. Part of this chain of trust is the root key that each resolver must have and trust, and this key is what changed this week.  DNSSEC resolvers automatically watch for a new root of trust key, but the key must be signed by the previous root of trust, and is checked for at least 30 days before it is trusted.  If someone were able to issue a bogus certificate, they would have to maintain control of the infrastructure for over a month before DNS resolvers would trust it.

The process of distributing the new key actually began more than a year ago, on January 11, 2025, to give DNSSEC resolvers time to get the new key. DNSSEC services should have had plenty of time to obtain and trust the new key, and unless DNS stopped working for you this week, they did their job.

The next major change for DNSSEC will require more profound changes to deploy a new signing algorithm that will be post-quantum secure.

Continue reading “This Week In Security: Critical DNS Keys Rotated, Hacking Freezers Isn’t Cool, OpenAI Spies On Itself, And Advanced Hardware Wallet Hacks” →

ESP32 Plugs In To Real-Time Crypto Prices

In today’s high-speed information overload environment, we often find ourselves with too much data to take in at once, causing us to occasionally miss out on opportunities otherwise drowned out in noise. None of this is more evident in the realm of high-speed trading, whether it’s for stocks, commodities, or even crypto. Most of us won’t be able to build dedicated high speed connections directly to stock exchanges for that extra bit of edge over the other traders, but what we can do is build a system that keys us in to our cryptocurrency price of choice so we know exactly when to pull the trigger on a purchase or sale.

[rishab]’s project for doing this is based on an ESP32 paired with a 10″ touchscreen display. It gathers live data from Binance, a large cryptocurrency exchange that maintains various pieces of information about many digital currencies. [rishab]’s tool offers a quick, in-depth look at a custom array of coins, with data such as percentage change over a certain time and high and low values for that coin as well. The chart updates in real time, and [rishab] also built a feature in which scales coins up if they have been seeing large movements in price over short timeframes.

Although it’s not a direct fiber link into an exchange, it certainly has its advantages over keeping this information in a browser window on a computer where it could get missed, and since it’s dedicated hardware running custom firmware it can show you exactly what you need to see if you’re day trading crypto. Certainly projects like this are in the DIY spirit that crypto enthusiasts tout as ideals of the currency, and as people move away from mining and more into speculative trading we’d expect to see more projects like this.

Continue reading “ESP32 Plugs In To Real-Time Crypto Prices” →

A Crypto Miner Takes The Straight And Narrow

As it stands, cryptocurrency largely seems to be a fad of the previous decade, at least as far as technology goes. During that time, many PC users couldn’t get reasonably priced graphics cards since most of them were going into these miners. In contrast, nowadays any shortages are because they’re being used to turn the Internet into an AI-fueled wasteland. But nonetheless, there is a lot of leftover mining hardware from the previous decade and unlike the modern AI tools getting crammed into everything we own, this dated hardware is actually still useful. [Zendrael] demonstrates this by turning an old mining rig into a media server.

The mining rig is essentially nothing more than a motherboard with a large number of PCI slots, each designed for a GPU. PCI slots can do many other things, though, so [Zendrael] puts a terabyte solid state drive in each but one of the PCI cards using NVMe to PCI adapters. The final slot still hosts a GPU since the computer is being converted to a media server, and this allows it to do various encodings server-side. Even with only 4 GB of memory, the machine in its new configuration is more than capable of running Debian and spinning up all of the necessary software needed for a modern media server like Jellyfin, Nextcloud, and Transmission.

With many people abandoning miners as the value of them declines over time, it’s possible to find a lot of hardware like this that’s ready to be put to work on something new and useful. Hopefully all of the GPUs and other hardware being put to use today in AI will find a similar useful future, but until then we’ll note that you don’t need super powerful hardware to run some of those models on your own.

Continue reading “A Crypto Miner Takes The Straight And Narrow” →

Hacking An NVIDIA CMP 170HX Crypto GPU For EM Sim Work

A few years back NVIDIA created a dedicated cryptocurrency mining GPU, the CMP 170HX. This was a heavily restricted version of its flagship A100 datacenter accelerator, using the same GA100 chip. It was intended for accelerating Ethash, the Etherium proof-of-work algorithm, and nothing else. [niconiconi] bought one to use for accelerating PCB electromagnetic simulations and put a lot of effort into repairing the card, converting it to water-cooling, and figuring out how best to use this nobbled GPU.

Typically, the GA100 silicon sits in the center of the mighty A100 GPU card and would be found in a server rack, cooled by forced air. This was not an option at home, so an off-the-shelf water-cooling block was wedged in. During this process, [niconconi] found that the board wouldn’t power on, so they went on a deep dive into the power supply tree with the help of a leaked A100 schematic. The repair and modifications can be found in the appendix, right down to the end of the article. It is a long read to get there.

Continue reading “Hacking An NVIDIA CMP 170HX Crypto GPU For EM Sim Work” →

Undo Arduino Encryption With An Oscilloscope

Cryptography ain’t easy. Seemingly small details like how many times a computationally intensive loop runs can give the game away. [Lord Feistel] gives us a demo of how this could work with nothing more than poorly designed code, a resistor, and an oscilloscope.

The hardware side is, as mentioned, really simple. Put a resistor inline with the Arduino and monitor the voltage drop across the resistor with the scope. When the chip is working hard, it consumes more current, and code sections that take longer will show up as longer dips.

On the software end, it’s only a little more complicated.  The RSA encryption scheme involves a lot of exponentiation and modulo-taking. Here, [Lord Feistel] is targeting a naive way of computing the exponents quickly, and demonstrates how you can read the exponent straight out the chip’s power demand.

Implementing this attack against a real-world RSA algorithm, in the context of the Arduino doing other stuff, will be harder. And we don’t know if the algorithm implemented in “standard” Arduino libraries is smarter than this one. (If you know, let us know in the comments.) But still, this is a cool example of just how simple and straightforward it can be to eavesdrop on bad code.

If you only need to bypass encryption instead of breaking it, check out [Lord Feistel]’s other tutorial on power glitching that we featured previously. If you haven’t played around with the hardware side of security, it gets deep pretty quickly, but you can at least dip your toes in the shallow end with what you’ve got in your closet.

This Week In Security: Putty Keys, Libarchive, And Palo Alto

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto” →