The Kernel-based Virtual Machine (KVM) allows Linux systems to function as hypervisors without needing any extra software, but VMs created with it don’t behave exactly like real hardware does. Sometimes that’s important, though, so [sandwich] built a tool called vfio-native that obscures the fact that software might be running in a virtual machine.

There are plenty of the ways that virtual hardware differs from bare metal. The VM may behave slightly differently for obscure instructions in ways that are measurable, it may take slightly longer to perform some tasks, or the hypervisor may simply announce itself directly. vfio-native includes some kernel patches that solve some bugs which address the different behaviors, changes the way that the kernel identifies itself, and attempts to force the CPUs to behave in ways that real hardware would behave. With all of this applied to the virtual machine, it scores a 1/85 against a VM detection tool, with a standard KVM virtual machine scoring 10/85.

For anyone looking to test this out, it’s available in the AUR for Arch Linux. Also, it’s probably worth mentioning that there are more reasons to use this than cheating at Counter-Strike. For example, security researchers testing malware need to know how that software behaves when it thinks its on real hardware, and some may behave in benign ways when confined to virtual machines. Some licensed software also may disable itself when it detects its running in a VM, which can be a nuisance for things like software controlling industrial tools which only run on operating systems that are no longer maintained or hardware that can’t be found anymore. Some other tools we’ve seen before perform similar tasks as well.

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.

The CA private key is… 4

Originally I was calling this the “big one” for the week, but this week that just keeps on giving. The private keys for eight eMudhra intermediate certificates have been compromised, and the way they were compromised is going to be a security talk punchline for years.  Remember the Debian SSL and SSH key debacle?  Of that scale.

Some background first. When your browser connects to a website over HTTPS, the site presents a certificate saying “I am example.com”, signed by a Certificate Authority (CA). Your browser and OS ship with a list of trusted root CAs, but roots are too valuable to use day to day, so they sign intermediate certificates, and the intermediates sign the actual website certificates. Whoever holds an intermediate’s private key can mint a certificate for any website, and every client that trusts the root will believe it. The whole system depends on those keys staying secret, and on them being generated properly in the first place.

eMudhra, an Indian CA which sells certificates under the emSign brand, had six TLS intermediates and two code-signing intermediates chaining to the emSign ECC Root CA – G3, which is trusted by Chrome and Apple, and Mozilla. A researcher identified only as Wayne proved the keys were compromised by signing the message “We have a problem here – Wayne” with each of them and sending it to the root programs.

How did Wayne get the keys? Flüpke posted one on Mastodon, and the secret value for the “EM OV TLS CA – G3C” key is… 4. Not four followed by 380 bits of randomness: the integer four. A reply quickly brute-forced the rest, and they’re all equally tiny: 56, 230, 237, 115, 155, 156, and 66. The keys were “incorrectly generated by the CA”, and anyone could recover them from the public certificates, which has been true since they were created in April 2025.

The browsers moved fast. According to The Hacker News, Chrome pushed a block within two hours of the report, and Mozilla blocked the certificates in under three, pulled the root from NSS, and shipped Firefox updates (CVE-2026-113470) for anyone with automatic updates disabled. There are no Certificate Transparency logs of rogue certificates, so modern browsers were never at risk. Everything that isn’t a browser is going to be the real problem and the extremely long tail of this fault: plenty of software never checks for revoked certificates and keeps trusting these keys until its bundled root list is updated.

Go hard-coded the eight bad keys into its standard library (CVE-2026-111943), but as Penligent points out, that only protects Go programs once they’re rebuilt with the new release. Python, Rust, Java, Node.js, curl, and most Linux distributions have updated root bundles, and the we-have-a-problem.com site has a full list, a checker, and manual workarounds for macOS, whose built-in curl and git don’t check revocation. There are also fixes for Linux, Windows, and the BSDs. Update everything, then go rebuild everything you compiled yourself. And then wonder how you’re going to update appliances, IoT devices, cameras, and everything else that fetches code over HTTPS or SSL.

php2shell: PHP gets owned by running out of memory

PHP, the language behind a significant percentage of the web had a rough week. WordPress, Drupal, Magento, phpMyAdmin, and just about every hosting control panel, major ecommerce sites, home project blogs, and even Hackaday itself was potentially impacted. Details of two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, leaked onto Hacker News a day ahead of the embargo, and Huntress covers the scramble that followed as PHP rushed its release out early. Now that patches are available, Ryan Austin of Calif has published the full writeup, demonstrating pre-authentication remote code execution against important apps on default configurations, in PHP versions back to 5.4.0. That’s over a decade of PHP.

The trick is an old one, first found by Stefan Esser back in 2004. PHP enforces a memory limit for each request, and when a request exceeds it, PHP stops immediately with a fatal error. If that happens in the middle of native code updating some internal structure, the structure is left half-built, and the cleanup code that runs afterward trusts it anyhow. That’s a classic “use-after-free” style bug, where the program uses memory that’s already been released or was never properly set up, and those are frequently exploitable. Calif found ways to reliably push a request over the memory limit at exactly the right moment (deeply nested empty file uploads turn out to balloon into hundreds of megabytes of internal tables, while staying under PHP’s upload size limits), and three different places where the interruption leaves a dangerous mess. Austin found the first bug with a generally available LLM, but only because he knew PHP’s twenty-year history of memory-limit bugs well enough to point it in the right direction.

Amazon reports that its honeypots caught a php2shell exploitation attempt on October 17th, four days before the embargo lifted, and that it’s now being broadly exploited. Their advice is worth repeating: for critical bugs on internet-facing systems, measure your patch window in hours, not weeks, and start investigating from the earliest exploitation date, not the disclosure date. If you can’t patch right now, Calif suggests disabling session.upload_progress and removing the memory limit, which comes with its own obvious problems.

One word of caution: alongside the legitimate writeups, there are many self-published “corrected findings” and “proof-of-concept” posts that can’t seem to decide whether their own exploit works, while offering a downloadable “weaponized” bundle. A leaked-bug panic is the perfect time to hand anxious admins a zip file. Read the real advisories, and don’t run random proof-of-concept bundles.

A Sixteen-year-old forever-day in Broadcom WiFi

Quentin Kaiser has the long-form writeup of his Hexacon talk on a bug in Broadcom’s WiFi stack, present since at least 2010, which gives an attacker a root shell on a router from across the street.  So called “parking lot” attacks that can happen from someone not even on your property have long been the boogeymen of WiFi security, and it’s been a little bit since we’ve gotten a new one.

The bug lives in WPS, WiFi Protected Setup: the “push the button on your router and then on your printer” pairing system that was supposed to save people from typing long WiFi passwords. WPS has a long and spotty security history, and this bug can be triggered over the air without knowing the network password, and without completing a WPS pairing. Kaiser’s demos show him pulling the WiFi password straight out of a router’s settings and sending it back over WiFi, and getting a fully interactive remote shell carried entirely over WiFi frames. No Internet connection required.

The really grim part is the patch history. Broadcom quietly released an incomplete fix in 2018, then suggested vendors switch to the open-source hostapd instead. For the older eCos-based chipsets that’s effectively never going to happen, which makes it a permanent “forever-day”. Broadcom refused to assign a CVE, and because Broadcom is its own CVE authority, CERT/CC closed Kaiser’s case the same day it was opened.

As of disclosure, the cable and DSL gateways he tested from three of Belgium’s four major ISPs were still vulnerable, and his napkin math puts it at over a million and a half devices in Belgium alone. Broadcom chips are, of course, sold everywhere. If you’re running ISP-provided hardware, there isn’t much you can do about the firmware. Turning off WPS can’t hurt if your router allows it, although Kaiser doesn’t say whether that blocks the attack. Disabling the gateway’s own WiFi and running your own access point that you can actually update is the safer bet.

GitLab regex bug reaches back twelve years

GitLab has released fixes for CVE-2026-110264, a maximum-severity CVSS 10.0 bug allowing unauthenticated attackers to run code on self-hosted GitLab servers. The flaw is an integer overflow when compiling a specially crafted regular expression in Onigmo, the Ruby regex engine which GitLab bundles into its own packages, so it affects every version back to GitLab 7.0 in 2014.

This is the fourth regex engine code execution bug from the same researcher in about a month (after CVE-2026-97229, CVE-2026-93577, and CVE-2026-89078), and comes with a nasty gotcha: the new fixed versions are one release past the October 12th fix, so if you diligently patched nine days ago, you’re vulnerable again. GitLab hasn’t said what’s needed to trigger the bug, so there’s no configuration workaround. If you’re running GitLab at home or in the shop, patch, and budget for some downtime while the database migrations run.

Node.js Brotli bug

Node.js shipped security updates for the 22, 24, and 26 branches, headlined by CVE-2026-111497, an out-of-bounds write in the bundled Brotli decompression library. Vercel’s advisory notes that researchers have demonstrated both memory leaks and command execution.

Node doesn’t decompress Brotli data on its own, but plenty of applications and libraries do, whether on incoming requests or on responses fetched from other servers. Vercel deployed firewall rules for traffic coming into its own platform, but no firewall can protect your code from a malicious response it goes and fetches itself. Node 20 is end-of-life and won’t be fixed. As a bonus, the same releases carry the eMudhra certificate distrust, so that’s two reasons to go update.

Header accordions and HTTP/3

HTTP/3 is the newest version of the protocol behind the web, running over QUIC (a UDP-based transport) instead of TCP. To save bandwidth, it compresses request headers using a scheme called QPACK: common headers can be sent as a one-byte reference into a table instead of the full text. Compression is great for bandwidth, but any time a small input can turn into a big output, there’s a risk of a “decompression bomb”.  Similar tricks resulted in “zip bombs” in the 2000s, and what’s old is new again.

FoxIO found exactly that in seven of the ten HTTP/3 implementations they tested. One approach packs about 160,000 unique short headers into a single 1MB request; another stores one 4KB header and then references it thousands of times, a 4000-to-1 amplification. The HTTP/3 spec already says how to limit the decoded size, but implementations got it wrong in every possible way: checking only the compressed size, decompressing everything before checking, ignoring the per-header overhead, or reading the limit setting and then never enforcing it.

Fixed so far are quic-go (CVE-2025-64702), which is used by Caddy, Traefik, and Cloudflare’s tunnels; Cloudflare’s quiche (CVE-2026-12523); lsquic 4.9.0; and even Wireshark (CVE-2025-13945), whose QPACK decoder crashed during testing. Bun, the hyperium h3 Rust crate, and aioquic/mitmproxy remain unpatched. Bun gets special mention for an integer overflow that turns a single 516KB request into a permanent 100% CPU infinite loop. The lesson applies to any compression format: limit the decompressed size as you go, not just the bytes on the wire.

Metamorphic macOS ransomware

Patrick Wardle of Objective-See digs into Heartbreaker, macOS ransomware written in Rust that has sat on VirusTotal since May 2025, undetected by every antivirus engine.

Most antivirus detection relies on signatures: a hash or byte pattern identifying a known-bad file. Metamorphic malware tries to dodge signatures by rewriting itself so every copy looks different while behaving the same. Heartbreaker takes a delightfully brute-force approach: it carries its own Rust source code inside the binary, and after running, it shuffles variable names, adds junk functions, installs a Rust compiler if one isn’t present, recompiles itself, and replaces itself with the new build. It is about as subtle as a brick through a window.

As ransomware it’s not very scary. It only encrypts the Downloads folder, and uses the same hard-coded key for every victim, so Wardle simply wrote a decryptor. The rebuilding also depends on a GitHub library which has since disappeared, so it mostly fails anyhow. Wardle uses it to demonstrate his free RansomWhere? tool, which ignores signatures completely and instead watches for an untrusted process rapidly writing files that look encrypted (using a bit of entropy math). The malware can change its hash all day long, but to ransom anything it still has to encrypt the files, and that’s much harder to disguise.

UpdraftPlus vendor breached

TeamUpdraft, the company behind the very popular UpdraftPlus WordPress backup plugin, disclosed a breach of their customer database over the weekend. Names, emails, addresses, hashed passwords, and two-factor authentication settings were taken, and more worryingly, the connection keys for UpdraftCentral, their cloud dashboard for managing many WordPress sites at once. UpdraftPlus previously made an appearance back in June, when a vulnerability in the plugin was used in the Awesome Motive supply chain attack.

Those UpdraftCentral keys can send commands to every connected site, which turns one vendor breach into a remote control for potentially thousands of customer websites. TeamUpdraft has released UpdraftPlus 1.26.12 and 2.26.12, which automatically disconnect the old keys. If you or anyone you know manages WordPress sites through UpdraftCentral, log in to each site directly, update the plugin, and check for unexpected admin accounts and plugins (including the easy-to-miss “Must-Use” plugins tab).

Spyware delivered by ad network

Citizen Lab has published research showing that the Israeli ad-tech company Discover-Tech helped deliver spyware through ordinary online ads, targeting at least 45 devices at the news outlet Al Jazeera in 2024 and 2025. Citizen Lab attributes the spyware to Candiru, a commercial spyware vendor.

When you load a web page with ads, the ad slot is typically auctioned off in real time to the highest bidder, based on a profile of who you seem to be. This “programmatic advertising” system is, by design, a mechanism for running third-party content on a very specific person’s device. It’s easy to see why that’s attractive to a spyware vendor. According to Citizen Lab, Discover-Tech’s platform could profile users and infect a device just by displaying an ad, no click required. CPJ reports that the company’s ads reached nearly 200,000 websites and apps, and researchers at Confiant found them on government networks including the US Department of Defense, NATO, and the UN.

Malicious ads are nothing new, but this is the first public evidence of an ad platform being used for targeted, zero-click spyware delivery. “Don’t click on ads” has always been good advice. An ad blocker isn’t just a quality-of-life improvement; it’s attack surface reduction.

Ransomware negotiators on the wrong side

Last week we covered a ransomware “recovery” CEO charged with secretly paying ransoms while billing customers for decryption. This week, Brian Krebs reports that investigators chasing ShinyHunters (the group behind the FBI hack) have identified executives at two ransomware negotiation firms with unusually friendly relationships with the gang. Chats seized when Dutch police arrested a suspected ShinyHunters member reportedly show negotiators who knew about new victims before the victims themselves did. One Canadian executive has already been arrested, and investigators believe an executive at an unnamed, prestigious US consulting firm helped run the gang’s extortion website.

It’s not the first time: the DOJ sentenced Florida negotiator Angelo Martino to 70 months in July for feeding his own clients’ negotiating positions to the BlackCat ransomware gang, and for helping deploy ransomware against even more victims. The government seized $10 million in assets from him, including a luxury fishing boat and, for reasons unknown, a food truck.

Part of the problem is structural. Some negotiation firms charge a percentage of the ransom paid, which gives the “negotiator” every incentive to pay, and pay big. Firms which refuse to facilitate payments often just get swapped out by the insurance company for ones that will. Meanwhile, ShinyHunters is reportedly furious with Coveware, an incident response firm, for telling victims not to pay, which is probably the best endorsement Coveware could ask for.

An army of AI agents

The Verge reports that security firm Norforge found an attacker using a swarm of mostly autonomous AI agents to break into more than 100 websites, including sites belonging to John Deere, SharkNinja, and Cummins. The agents ran on Cairn, an open-source “general-purpose problem-solving engine”: you give it a starting point and a goal, and the agents work toward it while documenting their progress. That documentation is how they were caught: the attacker’s Cairn instance was exposed to the Internet, along with about 20 others that appear malicious.

According to Reuters, the attacker described their preferred intrusion tactics in fewer than 100 Chinese characters, and each successful breach took about 23 hours. The victims say the impacted sites were standalone support pages, and Cairn’s author insists it was “never a ‘hacking tool'”. Many tools can be double-edged, but the effort balance here is hard to ignore: a short prompt and a day of waiting on one side, and defenders who have to close every hole on the other.

Staples hacked to fund a gift cards

404 Media pieced together, from an unsealed search warrant, that a Chinese organized crime ring hacked Staples in 2023 and issued more than 15,000 gift cards worth over $5 million. Staples’ internal customer support system was supposed to be reachable only from inside the company, but wasn’t. The attackers requested “heap dumps”, a debugging feature which captures everything an application has in memory, and pulled out the active login sessions of customer service reps. With those, they simply logged in as the reps and issued gift cards.  A similar trick was used in a hack of payment data from Target years ago, where attackers leveraged access through the air conditioner control network into the cash register network, and then dumped credit cards directly from RAM as they were processed.

If you’ve ever wondered why debugging endpoints left exposed in production show up in every penetration test report, this is why. The gift cards were then laundered the old-fashioned way: crews of shoppers hitting Target stores with phones full of gift cards, buying Apple and Bose gear by the cartload (about $141,000 across 85 Target stores in 18 states in two days), with the goods shipped back to China. The larger ring this fed into reportedly moved over $100 million in gift cards.

PingCAP breach claims

An extortion group calling itself FulcrumSec has posted a leak site claiming a massive breach of PingCAP, makers of the TiDB Cloud managed database service. The group claims it found cloud credentials committed to PingCAP’s own source code repositories, and used them to set up a replication feed of PingCAP’s production control database that re-exported everything to the attackers every six hours for 22 days, without being noticed.

The claims haven’t been independently verified, but they’re very specific: 10.6TB of data, 115,000 customer API keys stored in plaintext, 20 million customer SQL queries, four years of connection logs with customer IP addresses, and 413 private source repositories. The attackers quote a 2022 internal security ticket noting that any member of a customer organization, even a billing-only account, could reset the root password on every database in that organization. Perhaps most damaging, support engineers allegedly pasted live customer credentials into support tickets, including cloud keys with admin access to other companies’ storage. If you’re a TiDB Cloud customer, assume your API keys, connection strings, and anything ever pasted into a support ticket are burned, and rotate accordingly.

Fake WhatsApp on the Play Store

Android Authority found a fake WhatsApp app on Google Play with over half a million downloads, a week after a fake Chrome app racked up over 100,000. The fake copied the real listing’s screenshots and description word for word, and in some cases appeared as a sponsored result when searching for the real app.

The trick that let it linger is Google Play’s “Early Access” program, which disables public reviews. Normally a fake app gets buried in one-star “THIS IS A SCAM” reviews; in Early Access, nobody can see them. As of publication it was still available. “Only install from the official store” is still good advice for family members, but it’s a little less reassuring when the official store is selling ad placement to the fake.

Meta Muse leaks via DNS

Back in September, we covered a serious vulnerability in Muse, Meta’s extremely privileged AI agent. This week, Meta suspended Muse’s chat sharing feature after researchers at Claroc found they could find and read thousands of shared conversations.

Each shared chat got its own web address, with the conversation title as part of the hostname. Hostnames get looked up in DNS, and many DNS lookups are recorded by “passive DNS” services, essentially a giant searchable history of which names have been resolved. One search returned a ready-made table of contents of shared chats. Claroc found 6,800 of them, including a small business loan application, a bank fraud alert with partial account details, and internal company documents. “Secret URL” sharing only works if the URL stays secret, and putting the secret in a DNS hostname is roughly the opposite of that.

Password1 strikes again

The UK Information Commissioner’s Office reprimanded IT provider Ogi Networks and the Welsh public sector data organization Data Cymru over a 2024 ransomware attack which exposed data on 3,300 people, most of them children. The way in? A test account named “Test2”, created in 2012, never reviewed, and protected with the password “Password1”. The local administrator accounts on three systems also shared a single password for the same twelve years.

There’s nothing exotic here, sadly. Old accounts nobody remembers, passwords that would fall to the first guess of any automated tool, and an outsourcing arrangement where each side assumed the other was handling security. None of it makes for exciting headlines, but these are the things that keep causing very real breaches.

Trezor wallets also implanted

As a follow-up to last week’s coverage of hardware implants in Ledger crypto wallets, Kim Zetter reports that Trezor’s claim of “not a single piece of evidence” that its devices were compromised doesn’t quite line up with reality. Joe Grand found implants in two Trezor wallets, bought through Facebook Marketplace and a TikTok shop, and reported them to Trezor in August.

The Trezor attack is different from the Ledger implant. Instead of adding a radio to spy on the screen, the attackers replaced the main microcontroller with one running modified (open source) firmware. The firmware “randomly” generates one of a dozen recovery phrases the attackers already know. To pass Trezor’s integrity checks, it presents a copy of the legitimate firmware for verification before switching to the malicious code. The takeaway hasn’t changed from last week: buy only directly from the vendor, and if you’re holding enough crypto to make this worth someone’s while, consider whether you can really trust any single device.

NGINX gets more critical bugs

F5 has released out-of-band (meaning outside their normal patch schedule) updates for three critical vulnerabilities in NGINX, the web server and reverse proxy that sits in front of a huge chunk of the Internet, and quite possibly in front of the services on your home lab. The Cyber Security Agency of Singapore has a summary: all three are rated CVSS 9.2, can be triggered remotely without authentication, and can crash worker processes or, under the right conditions, allow remote code execution.

The bugs are CVE-2026-15176, a heap overflow in the “alias” and “rewrite” directives; CVE-2026-97205, a use-after-free in asynchronous file I/O combined with Server Side Includes; and CVE-2026-93479, a heap overflow in the “map” directive. Code execution requires the vulnerable configuration to be in use, and requires bypassing ASLR (the randomization of memory layout which makes exploits harder to aim). Affected versions include NGINX Open Source 1.30.5 and below and 1.31.6 and below, NGINX Plus R33 through R37, and a long list of F5’s NGINX-based products, including the Kubernetes Ingress Controller.

Back in May we covered “nginx-poolslip”, where the suggested mitigation was to avoid unnamed regex capture groups in rewrite rules. The mitigation for the “map” bug this time? Use named captures instead of unnamed captures. If you’ve been putting off cleaning up those “$1” references in your config, now’s the time. For the other two, avoid “alias” inside “location” blocks (and the “$request_filename” variable), or disable AIO or SSI, until you can update.

Linux kernel bugs posted to the wrong list

Normally, security bugs in the Linux kernel are reported privately to the kernel security team, which coordinates a fix before details go public. This is “coordinated disclosure”: the bug and fix are published together, ideally giving admins a chance to patch before attackers can start writing exploits. The Linux Kernel Mailing List (LKML), on the other hand, is about as public as it gets.

Phoronix reports that Trend Micro’s Zero Day Initiative, seemingly by accident, sent a batch of unpatched vulnerability reports straight to LKML. Greg Kroah-Hartman replied to each report asking about the choice of mailing list, which I can only imagine was done with remarkable restraint. The most serious two are both CVSS 9.0 remote code execution bugs in ksmbd, the kernel’s built-in SMB (Windows file sharing) server: an integer underflow in SMB Direct, and a race condition. The rest include local privilege escalation bugs in the networking code, the VMware graphics driver (an out-of-bounds write), and a stack overflow in search-domain TCP query handling, plus an information leak in the NVMe-over-fabrics target code.

Some of the bugs already have patches being tested or queued for future kernel releases, and those will presumably be expedited now. Most systems don’t run ksmbd (the userspace Samba server is far more common), but if you’ve enabled it on a NAS or a home server, it’s worth disabling until patched kernels land. As Phoronix puts it: “the bug and security reports keep on coming in the AI fueled world.”

The Nokia E6 is a smartphone from back in the old days when Symbian was a thing. [fluffleswaffled] has been doing the work to get the ancient handset running Linux instead, because that’s ultimately cooler than what the phone shipped with out of the box.

There isn’t an unlocked bootloader on the E6, so instead, [fluffleswaffled] used an altogether different route to boot Linux. A Symbian app is used to load the kernel and device tree into RAM, at which point the MMU and caches are turned off and the device jumps into Linux. It’s a one-way trip, from which there is no way back to Symbian without a power cycle. The setup nets a terminal on the phone’s own screen, and the hardware keyboard and touchscreen are functional. The display is controlled by a Broadcom VideoCore III, with [fluffleswaffled] capturing messages from Nokia’s original display driver to create a custom kernel driver that replays them.

There’s an issue, though. The phone doesn’t stay in Linux land for long — it always resets within a couple minutes of booting into the alternative OS. [fluffleswaffled] believes this is because the phone’s baseband chip is supervising the application processor, and killing things once it’s detected that the Symbian mobile stack has stopped running. They’re hoping that someone with experience with Nokia basebands or the relevant hardware can point them in the right direction to get this hack running for more than 3.5 minutes at a time.

There probably isn’t a great deal of utility in getting Linux running on a 2011 smartphone, but we love the hustle nonetheless. We’ve seen this done before, though, and it’s always interesting to learn what it takes to get the OS booting on a new platform. If you’re whipping up similar hacks in your home lab, don’t hesitate to let us know on the tipsline.

It’s plenty easy to do lots of vision tasks with a single camera, but using two cameras gives you lots of magical abilities, like depth perception! If you’d like to experiment with stereo vision, you might enjoy this board that [machinehum] built specifically for hackers.

The project came about because [machinehum] was particularly excited about the Rockchip RV1103, a 1.1 GHz single-core ARM chip. It comes with 64 MB of DDR2 RAM and a has a MIPI CSI-2 bus on board, which comes in handy for interfacing cameras. Thus, it was the perfect part to whip up a stereo vision board with on-board compute capability and Linux support right out of the box. The processor is paired with two OV9281 global-shutter cameras, as well as a LI2HH12 3-axis accelerometer to provide motion sensing. There’s also 4 MB of flash memory thrown on board, as well as a 10/100 Mbit Ethernet interface for good measure. [machinehum]’s write-up also lays out the software stack and how everything works in concert with Video4Linux2.

If you’re new to experimenting with stereo vision, you might find this to be a useful platform for getting started. Design files are on GitHub for the curious. We’ve seen similar projects built using the Raspberry Pi before, too, which itself is essentially just a fast ARM powered computer with useful camera interfaces built-in. Funny that.

Meshtastic has gained a lot of popularity over the last few years thanks to its low barrier of entry. No licenses are needed and the hardware is dirt cheap, at least when compared to a lot of ham radio gear. But while that physical barrier is low, there is a bit of a learning curve. Part of that comes from the fact that there are a lot of channels and modes that people could be communicating on, and unless the user knows that information up front it can be hard to find where the conversations are happening. [cemaxecuter] noticed this problem and built a Meshtastic sniffer into his radio-forward Linux distribution, DragonOS.

The sniffing software is built in C and comes as a complete standalone binary and does not rely on GNU Radio. With DragonOS up and running and the software loaded, it can look at the entire bandwidth that Meshtastic operates on and detect any traffic and decode it (as long as the key is known). [cemaxecuter] is using a HackRF as a software-defined radio for this project, which he notes doesn’t quite have enough bandwidth to cover every Meshtastic operating frequency, but it can get most of them. After firing up his own node, the software quickly detects it and shows its details in the terminal.

Software like this opens up a lot of opportunities for things that would be tedious, difficult, or impossible to do with with a standard Meshtastic node. Besides finding places where conversations are happening more easily, [cemaxecuter] also suggests that it could be used for wardriving and for locating or finding other networks much more easily. For those who still haven’t tried it out, take a look at this 2023 treatise on the protocol and hardware and then dive right in.

Just-in-time, or JIT, compilation could be considered a fundamental backbone of modern computing.  JIT compilation turns scripting languages like JavaScript or intermediary binary forms like Web Assembly into native code on the fly, giving web apps, and things that are web apps under the covers like Electron-based tools, near native speed.  A new paper explores leveraging JIT systems to revive Spectre-v2 attacks against processors.

Most modern processors gain performance by using a trick called “speculative execution”.  The processor guesses the likely result of a compare, and begins executing some of the next instructions before the results are actually known.  If the processor guessed right, things continue and there is a speed gain because it can jump ahead, but if the processor guessed wrong, any instructions that were run and any side effects of running them are discarded and execution resumes on the actual path.  In theory, anyhow.

In practice, the Spectre class of attacks targets branch prediction. It was discovered that when the wrong branch was chosen, not all of the results were truly hidden; Patterns of failures in guessing branches can be used to leak behavior processing encryption keys and other activities. The attacks evolved with the research dubbed Spectre-V2, which showed that non-privileged contexts, like non-root users and virtual machines, could poison the instruction prediction and use it to read arbitrary memory.  Fixes to the Linux kernel and other platforms were required to mitigate the worst of the effects.

The paper shows that by using self-modifying code in the JIT, the processor can be tricked into loading cached versions of the instructions.  The fixes to the kernel to prevent Spectre attacks include identifying malicious code patterns that attack the branch prediction, and stopping or changing them:  By causing the CPU to execute the cached copy of instructions instead of the live copy, the attack ignores the fixed instructions entirely and can attack the branch prediction algorithm.

To prove the attack is feasible in the real world, the researchers targeted several JIT compilers, including the SpiderMonkey JavaScript engine used by Firefox, the eBPF JIT found in the Linux kernel, and GraalVM, the JIT used in Python.  They found success with each, demonstrating that the attack is at least plausible.

Research like this is unlikely to be an instant world-melter, and will help find possible mitigations in the future to prevent these sorts of attacks.  Operating systems that support a high-security “lock-down” mode, like macOS and iOS, often disable JIT entirely, out of concern about these sorts of attacks.  There’s probably no need to start disabling JIT on every system, but attacks like these have a tendency to evolve.

Enormous List of Vulnerabilities Patched in Linux

Updated Linux kernels are available for most distributions, with a truly intimidating list of patched security issues.  As this Debian post states, “Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks.”  Several, in this case, is a load-bearing word, and you should go check out the CVE list.  I’ll wait.

This, apparently, is what the AI Vulnpocalypse looks like today. After Windows patched over a thousand vulnerabilities in a single Patch Tuesday, we probably had a pretty good idea what would be coming. With over 1,200 vulnerability report IDs listed in the patch, manually understanding the security impact is extremely daunting if not entirely impossible. A random sampling shows vulnerabilities in compression handling, denial of service attacks from local users, and memory corruption that may or may not be exploitable, but with a list this huge that’s hardly exhaustive.

For normal admins and users, there isn’t much else to do besides apply the patches and hope they don’t cause new problems.  Linux overall has a better track record with patches not breaking they entire system, but it’s not unheard of, and with this much churn, the chances of something going wrong of course increases.  Patching is almost always a better option than not patching and hoping you don’t get owned, though!

Google Stops Bug Bounty Program Because of AI

“Stop hitting yourself” comes to mind. Google has stopped the Google Open Source Vulnerability Rewards Program, the bounty program offering rewards for finding bugs in the companies open source releases.

Surprising nobody, the bounty program has been flooded with “low effort” and “low quality” AI generated reports. Google says maintainers were overwhelmed with false reports containing AI hallucinations, and that the program would be re-evaluated in 2027. While AI-assisted, or even directed, security research is our new normal, if the results aren’t checked by someone able to confirm they’re legitimate, submitting them helps nobody.

Can’t help but feel some schadenfreude that a company shoving AI into every aspect of our lives is then impacted by AI being shoved everywhere, but in the end swamping developers with bogus reports keeps them from fixing the real bugs and benefits nobody, so it’s hard to find a positive takeaway on this one.

Retailer Asos Hacked, Ransomed

Customers of the Asos online clothing store who installed the Asos app got first-hand evidence that the platform was hacked by a ransomware crew.  The attackers used the Asos app push notifications to send an alert to all customers: “Dear Asos DPO and IT, we have fully compromised the Snowflake instance.  Engage with us, or we will leak it.”

Snowflake is a cloud-scale database company, and has been implicated in several other attacks over the past few years, including a large hack in 2024 by the ShinyHunters group that led to compromises of Ticketmaster, AT&T, Lending Tree, and others. It’s unclear how the Asos Snowflake instance was compromised.

Direct-to-consumer ransomware demands aren’t new, and apply pressure to the impacted company. The message itself is a well-phrased piece of propaganda, casting the hacked company as the villain who isn’t protecting the customers by engaging in the extortion demands. Asos so far indicates that “basic customer information” like name and contact information, but possibly not payment details.

Accenture Contractor Implicated in FBI Hack

The FBI has removed a contractor from the multinational tech company Accenture, after determining that the breach of the Oracle PeopleSoft instance that then led to the breach of the information of the entire FBI agent and employee system, was avoidable.

Details remain scarce, but this would imply that the vulnerability used by ShinyHunters wasn’t a zero-day after all. One of the most dangerous phases of the vulnerability lifecycle is when both the bug and patch are known, because researchers can often quickly deduce the vulnerability from the patch and write an exploit. This seems to be what happened here.

Rarely are specific individuals held directly responsible for patch cycles. Patching production services of large organizations is usually determined at an institutional level.  Reading between the lines, the individual may have been directly tasked with doing the work of installing the patches and didn’t.

Last week, the ShinyHunters group made public statements that it did not plan to leak the stolen information, and was simply using it as a means to get press coverage of their grievances against the FBI.  The promise not to leak the addresses of the families of agents is probably appreciated by the agents themselves, but unlikely to do much to slow the pursuit.

Domain Registrars Hacked to get TLS

Ars Technica reports that three domain registrars were hacked and the access used to obtain certificates for Google domains.

By hacking the registrars and changing the assignment of country-level Google domains for the “gh” (Ghana), “sl” (Sierra Leone), and “as” (American Samoa) top-level domains, the attackers were able to pass automated domain ownership checks required for obtaining SSL certificates.

To be usable, an attacker would have to be able to intercept and redirect the traffic between a user and the compromised domain, and the user would have to be attempting to connect to the Google domains in that country TLD in the first place. The attack may have been targeted against those specific countries, or may have simply been an opportunistic attempt to harvest credentials. Conceivably, the certificates could be used on malicious WiFi networks to try to capture user sessions from other Google domains and services.

Google has already implemented filtering for the specific certificates in Chrome, but these fixes do not help other browsers or services, and Google says it may not have identified all the compromised domains. Google also cautions that the domains of other companies were also compromised, and that those companies must take independent action to protect their users, but the impacted companies were not provided.

Hacking Lawnmowers

Researchers found a series of vulnerabilities in the Mammotion robot lawnmower platform. After spending “a few days on Mammotion’s cloud”, they demonstrated an admin account takeover and a full dump of all 337,000 customers, and for the cherry on top, unauthenticated access to first-person mode on mower. In case you wanted to help tidy up someones lawn or just go for a drive around the neighborhood.

After finding previous security issues in Mammotion products which were not, to put it delicately, fixed according the current norms of security patching in the industry, the company was on the radar.  In addition to discovering that there was no rate limiting on brute-forcing account recovery and changing any users password, the team also found that factory systems lacked any authentication at all, hard-coded authentication tokens were baked into the firmware, and it may be possible to add any customer’s mower to any account.

After repeated attempts by the team to get the company to set up security contacts and respond to the vulnerability reports, it appears that the issues whith are remotely testable have been resolved, but for a fun read be sure to check the article and the email threads as an example of how, probably, you shouldn’t handle security reports as a company.