This Week In Security: FBI Gets Hacked, Muse Vulnerable To ClickFix, Popular Rust Developers At Risk, And New Attacks Against RSA

The prolific ShinyHunters group has announced it used a zero-day vulnerability in Oracle PeopleSoft to exploit the FBI jobs website and gain access to the AWS GovCloud instances and dump 2 TB of employee data. GovCloud being a special, locked-down version of the Amazon Web Services cloud for US government users.

ShinyHunters has previously been involved in dozens of high-profile hacks and ransomware incidents.  Some of the highest-profile incidents include Jaguar-Land Rover, causing a measurable impact on the UK GDP, Grubhub, Carnival Cruise Lines, Rockstar Games, and multiple universities and educational institutions, casinos, and other government agencies.  ShinyHunters has also been credited with the hack of the Canvas educational program in the spring of 2026 where data including test results and chat logs of hundreds of millions of students, teachers, and staff was stolen.  ShinyHunters has generally been identified as an international group of criminals, often teenagers, who will demand a BitCoin ransom of several million US dollars, with the threat of the stolen data being leaked if the victims do not pay.

On May 15, 2026 the FBI released a bulletin on the activities of ShinyHunters, focusing on the Canvas educational hack.  In the report, the FBI said that the group uses “harassment strategies, sending threatening text messages and phone calls to victims and their family members”.  ShinyHunters says that this is not accurate, and that they will release the FBI employee data, including information of employees and their family members, if the agency does not retract the statements, telling The Register “I have been doing my very best to combat these allegations, and this is the best way to do it”.

Continue reading “This Week In Security: FBI Gets Hacked, Muse Vulnerable To ClickFix, Popular Rust Developers At Risk, And New Attacks Against RSA” →

yserver screenshot demonstrating compiz comptibility

Why Not Yserver? It’s Xserver, But Rust-y.

If you’re not into Wayland as a display manager, it seems like your options are slowly dwindling. Xorg isn’t exactly a hotbed of activity, and the one fork everyone knows about is best known as a political lightning rod. Luckily, Rust developers can apparently never see a tool without pulling it into their heavily oxidized bucket of crabs, so we now have another option: the creatively named yserver, released under the MIT license by [joske].

The name, yserver, for the record, is just a placeholder name, but we rather like the simple logic of “Y comes after X” — sure, you could call it X12, but that could imply continuity, and this is a clean break. It’s also not a full reimplementation of the huge, sprawling mess that Xorg has become over the decades. It can’t launch multiple screens and thus lacks full multi-monitor support. So, for now, it may be too bare-bones for some people’s use cases.

As it uses Vulkan, it is limited to relatively modern hardware, but has been tested on Intel, AMD, Nvidia, and Apple chips. The target kernel is good old Linux, but the docs do cover compiling for FreeBSD; just be aware that that’s very much a secondary target. FreeBSD users are probably used to that, though.

On Linux, a standalone DRM/KMS yserver can successfully run not just window managers but full desktops — specifically MATE, Cinnamon, and XFCE, as they’re not on the Wayland bandwagon. It even supports Compiz, in case you missed the cube and wiggly window animations. You can also use yserver via Xwayland or even Xorg. Speaking of Xorg, [joske] has run the X.Org X Test Suite (xts5) against this proposed successor, and it currently scores 66.2%, which seems pretty good considering the project explicitly does not plan to copy all of Xorg’s functionality.

Aside from multiple screens, one thing that would have been neat to see is support for the Asterinas rust-based Linux-compatible kernel — though if that project achieves full Linux compatibility, that may be a non-issue. Even if you aren’t an oxidization enthusiast, you might find reasons to be happy to see more competition in the display-manager market — after all, Wayland Will Never Be Ready For Every X11 User. If Xorg really is destined to the slow death critics predict, perhaps yserver could cover the holdouts.

Rust-y Firmware For Waveshare Smartwatch

Waveshare makes a nifty little ESP32-S3 based smartwatch product, but its firmware is apparently not to everyone’s liking. Specifically, it’s not to [infiniton] a.k.a [Bright_Warning_8406]’s liking, as they rewrote the entire code base in Rust. No_std Rust, to be specific, but perhaps that doesn’t need to be specified when dealing with ESP32.

On the Reddit thread about the project, he lists some of the advantages. For one thing, the size of the binary has dropped from 1.2 MB to 579 kB while maintaining the same functionality. More interesting is that he’s been able to eliminate polling entirely: the firmware is purely event-driven. The CPU is not just idle but parked until a timer or GPIO event wakes it up. For this form factor, that’s a big deal — you can’t fit a very large battery in a watch, after all.

Getting drivers for the AMOLED display, touch sensor, audio, and RTC modules written from scratch is an impressive accomplishment. Apparently the screen driver in particular was “a nightmare” and we believe it. There’s a reason most people go for existing libraries for this stuff. [Bright_Warning] did not post screenshots or video, but claims his version of the watch watch can make HTTP calls to Smart Home, play MP3s, play the old phone games– Snake, 2048, Tetris, Flappy Bird, Maze– and even comes with a T9 keyboard for text input.

If you’re looking to get closer to bare metal, and don’t mind it being Rust-y, take a look at the code on GitHub in the first link above. This author isn’t enough of a rustacean to say if the code is as good as it sounds at a glance, but nothing egregious jumps out. The documentation describing exactly what’s going on under the hood isn’t half-bad, either. If you aren’t into Waveshare products, you could easily adapt this code into a more DIY ESP32 watch, too.

If you’re not into Rust, uh… washing soda and electric current can get it off of steel, and probably microcontrollers too. We can’t say that the chip will work after that, but hey — no rust.

Detail of Horus's face, from a statue of Horus and Set placing the crown of Upper Egypt on the head of Ramesses III. Twentieth Dynasty, early 12th century BC.

HORUS Framework: A Rust Robotics Library

[neos-builder] wrote in to let us know about their innovation: the HORUS Framework — Hybrid Optimized Robotics Unified System — a production-grade robotics framework built in Rust for real-time performance and memory safety.

This is a batteries included system which aims to have everything you might need available out of the box. [neos-builder] said their vision is to create a robotics framework that is “thick” as a whole (we can’t avoid this as the tools, drivers, etc. make it impossible to be slim and fit everyone’s needs), but modular by choice.

[neos-builder] goes on to say that HORUS aims to provide developers an interface where they can focus on writing algorithms and logic, not on setting up their environments and solving configuration issues and resolving DLL hell. With HORUS instead of writing one monolithic program, you build independent nodes, connected by topics, which are run by a scheduler. If you’d like to know more the documentation is extensive.

The list of features is far too long for us to repeat here, but one cool feature in addition to the real-time performance and modular design that jumped out at us was this system’s ability to process six million messages per second, sustained. That’s a lot of messages! Another neat feature is the system’s ability to “freeze” the environment, thereby assuring everyone on the team is using the same version of included components, no more “but it works on my machine!” And we should probably let you know that Python integration is a feature, connected by shared-memory inter-process communication (IPC).

If you’re interested in robotics and/or real-time systems you should definitely be aware of HORUS. Thanks to [neos-builder] for writing in about it. If you’re interested in real-time systems you might like to read Real-Time BART In A Box Smaller Than Your Coffee Mug and Real-Time Beamforming With Software-Defined Radio.

This Week In Security: Cloudflare Wasn’t DNS, BADAUDIO, And Not A Vuln

You may have noticed that large pieces of the Internet were down on Tuesday. It was a problem at Cloudflare, and for once, it wasn’t DNS. This time it was database management, combined with a safety limit that failed unsafe when exceeded.

Cloudflare’s blog post on the matter has the gritty details. It started with an update to how Cloudflare’s ClickHouse distributed database was responding to queries. A query of system columns was previously only returning data from the default database. As a part of related work, that system was changed so that this query now returned all the databases the given user had access to. In retrospect it seems obvious that this could cause problems, but it wasn’t predicted to cause problems. The result was that a database query to look up bot-management features returned the same features multiple times.

That featurelist is used to feed the Cloudflare bot classification system. That system uses some AI smarts, and runs in the core proxy system. There are actually two versions of the core proxy, and they behaved a bit differently when the featurelist exceeded the 200 item limit. When the older version failed, it classified all traffic as a bot. The real trouble was the newer Rust code. That version of the core proxy threw an error in response, leading to 5XX HTTP errors, and the Internet-wide fallout. Continue reading “This Week In Security: Cloudflare Wasn’t DNS, BADAUDIO, And Not A Vuln” →