A healthy aquarium ecosystem requires very specific conditions, with factors like the salinity and temperature having to be just right to keep said ecosystem happy. As some species are adapted to fairly cold water, this requires the use a water chiller. Recently [The Blunt Oracle] modified one of these aquarium-focused chillers with a much better controller to make it both more accurate and potentially more efficient as well.

The target for the surgery was a generic Shanhuchong Y-160 chiller that after a brief teardown turned out to use an STC-1000 style controller. The biggest disadvantage with this unit is probably that it just has one temperature probe, which monitored the temperature of the heat exchanger rather than that of the chilled water tank.

This controller was replaced with a Wi-Fi-equipped Elitech ECS-974T sourced for $50 off AliExpress that uses the same 71 x 29 mm form factor. Following that it was just a matter of some creative rewiring – as shown in the top image – and installing the twin temperature probes of the new controller.

Being able to monitor also the temperature of the chilled water adds a layer of redundancy that’s very welcome after splurging thousands of clams on a fancy aquarium and its inhabitants. As a bonus the Wi-Fi interface allows for it to be monitored and controlled remotely, with [The Blunt Oracle] pushing the Home Assistant configuration in a PR as well that recently got merged. They’d also like to extend their thanks to Elitech for having pretty good documentation that really helped with creating the HA configuration file, which is a rarity with many of such controllers.

If you just want to play with a Rubik’s Cube, you can simply buy one from a local toy store. If you want to build one, you could 3D print something and put it together yourself. But what if you want to make lots of Rubik’s Cubes? Then, you might go down the road that [EngBroken] just walked.

What started as a fun reverse-engineering project would lead to an 8-month journey to reproduce Rubik’s Cubes from scratch using injection molding. [EngBroken] started by identifying the basic pieces that make up the cheap cube they bought, including the center core, the edge pieces, and the corner pieces. Parts were then recreated in CAD, and [EngBroken] then set about designing and milling injection molds out of 6061 aluminium to make the parts.

Amusingly, to get the correct colors for the separate parts of the cube, [EngBroken] made the curious decision to mix cut-up pieces of 3D printer filament with clear ABS pellets to tint it as needed. Parts were then assembled with UV-curing glue, and [EngBroken] had a Rubik’s cube built from scratch. Well he actually had several, since he had a stack of parts since injection molding is great at producing things in quantity.

This isn’t a great way to go if you want a Rubik’s cube on the cheap. [EngBroken] estimates the labor put in to this exercise came out to $56,000 alone, to say nothing of what it took to produce all those aluminium molds and source all that plastic. Still, a great deal was learned in the process. We’ve looked at the challenges of injection molding before, too.

[Thanks to Sailor Looking Meme for the tip!]

With Elliot back from Hackaday Europe, he and Al Williams had a lot to talk about with two weeks of Hackaday posts to catch up on. Not to mention the mailbag was overflowing.

This week, the guys look at girlie cyberdecks, a 3D printed circuit board, and talk electric motorcycles. Is 3D printing safe? Want an accurate moon on your desk? How about modern punch cards? All of that and much more were on the menu this week.

For the can’t miss articles, Zoe Skyforest weighs in on file sharing via LAN while Al Williams talks about the surprising state-of-the-art in vacuum tube tech right before their end.

What do you think? Leave us a comment or record something and send it to our mailbag.

Download a copy of the podcast with an MP3 this week in glorious pink and purple.

News:

• Another Gift To The World From CERN: Their Entire Set Of KiCad Libraries

Mailbag

• BirdNET-PI :: BirdWeather
• Environmental Monitoring On The Cheap
• A Merciless Environmental Monitoring System
• A Web Connected Seismometer
• Building The DIY HP41C: A Field Report
• Got something to share for the Mailbag? Drop us a line. Already sent something in? Maybe send it again as we were… ahem… experiencing technical difficulties.

What’s that Sound?

• No one guessed the sound, so by random draw, [Jeeef] wins the T-shirt. Tune in next week for your chance to guess What’s That Sound?

Interesting Hacks of the Week:

• Mermaid Clutch-Purse Cyberdeck Is Unapologetically Girly
• VTech Toy Becomes PinkPad, The DIY Linux Laptop
• Using 3D Printers To Make Circuit Boards
  • Prototyping Circuits: Easy Cheap Fast Reliable Techniques
  • http://wd5gnr.com/shoexmit.jpg
  • Retro Gadgets: The 1974 Breadboard Project
• Honda Wants To Complicate Your E-Motorcycle
• Digital Organizer Given Modern Upgrade
• Investigating The Health Impacts Of UFPs And VOCs From FDM Printers
• Electroplating 3D Prints Without Requiring A Big Vat

Quick Hacks:

• Elliot’s Picks:
  • Remembering The Tech We Lost With A Virtual Graveyard
  • Put The Moon On Your Desk
  • A DIY 3D Printing Filament Dryer
  • Extract 3D Video Game Content By Firing Up Photo Mode
  • PreFlight Slicer Brings Added Part Strength Feature, And Many More
• Al’s Picks:
  • Turning A Junk Laptop Screen Into A Portable Monitor
  • 21st Century Punch Cards Are 3D Printed And Read By OpenCV
  • Prolog Via Pokémon

Can’t-Miss Articles:

• Between-Device Sharing Still Sucks
  • KDE Connect | KDE Connect: A project that enables all your devices to communicate with each other.
  • Snapdrop???? : r/software
• The Vacuum Tube’s Last Stand(s)

As fun as ARM and RISC-V single-board computers (SBCs) are, all too often getting the most out of the hardware requires the use of an unofficial firmware image. So too with the Banana Pi BPI-R4 Pro router SBC that has been out for a while, as OpenWRT support for it still very much unofficial. This is where [Interfacing Linux] goes on a bit of a rant while assembling one of these puppies into a sleek metal enclosure.

The first rule of OpenWRT Club is of course that you never run an unofficial image on any hardware that’s part of any network you care about. This is somewhat upsetting, as the testing shown in the video below reveals that performance is great when running it.

Currently OpenWRT support is painfully working its way through development, per the OpenWRT PR thread, so there’s hope that official support will appear at some point. As with all of such SBCs the question is always whether official support appears before the hardware has been rendered firmly obsolete. Until then the community Debian 13 image might actually be safer.

Google’s Project Zero demonstrates a new zero-click exploit for the Pixel 10 phones, showing a full escalation from remote to kernel without user interaction. During the investigation Project Zero found unprotected memory access from userspace in the Tensor G5 video processing chip driver, which allows direct write access to kernel memory.

Using previously discovered flaws in media decoding components — in this case CVE-2025-54957 in the Dolby digital audio decoder — Project Zero modified a Pixel 9 attack to work on the Pixel 10, despite newer protections built into the hardware to harden the system against memory corruption.

The author’s takeaway is mixed. Once the bug on Pixel 9 was reported, one could hope that the Android team would look into similar bugs in their newer systems. On the positive side, though, Project Zero reported the vulnerabilities to the Android team in November 2025 and they were patched in February of 2026, 71 days later. That’s 19 days short of the 90-day timeline.

Linus on AI and Security

Linus Torvalds clarified opinions on AI detected security vulnerabilities in the Linux kernel in a recent mailing list post about the Linux 7.1 kernel development cycle.

In typically succinct phrasing, Torvalds supports the use of AI tools in general, but considers any AI reported bug to be, by definition, public. Linus also requests that submitters of AI generated reports verify the report is accurate and engage with fixing the issue instead of doing an unverified drive-by report.  It’s difficult to summarize his comments without being longer than his initial post, so for more full information, head over to the Linux kernel mailing list!

GitHub on AI and Bug Bounties

Similar to comments from Linus above, GitHub is detailing how AI generated reports will be handled in an attempt to generate higher-quality bug reports in the bug bounty program.

While slightly ironic that a platform which has gone deep down the AI rabbit hole is now facing issues of scope when AI-generated reports flood its own security program, the problem is certainly real. GitHub lays out what seems to be a fair list of requirements for a good bug report. One must provide a working example of the vulnerability in action, adhere to the scope of the bounty, and of course, the report must be valid.

All three of the requests directly target things AI has been historically terrible at, especially at scale when deployed by users with limited security background and experience. AI models have often been guilty of completely fabricating code, fixes, and data. Completely false security reports waste time.

GitHub further clarifies their position that malicious repositories are not, themselves, in scope for the bug bounty program, stating that users are responsible for what repositories they clone, fork, or otherwise interact with. This makes sense in the scope of a bug bounty program where a submitter can create an arbitrarily malicious repository and file a bug on it, but seems short-sighted given recent rampant exploitation of the GitHub actions build process. Expecting every user to understand the implications of the GitHub actions workflow before forking a public repository seems unlikely to work in the long term.

GitHub Internal Breach

Speaking of which, GitHub has posted to their security blog about a breach of internal repositories.

There are not a lot of details about the breach, but GitHub says a compromised VSCode extension on a developers system was used to gain the credentials for internal systems. If that sounds familiar, it should – many of the current worms targeting NPM and PyPi include code to infect VSCode extensions as well.

GitHub says that only internal company repositories were impacted, and that if any customer repositories are found to be affected the users will be notified.

If you find it amusing that a developer at GitHub, owned by Microsoft, was compromised by a Microsoft VSCode extension, hosted on the Microsoft’s extension repository, I’d say you’re right.

Zero-Copy Removed from AF_ALG

The Linux kernel is removing the zero-copy code from AF_ALG. The AF_ALG code is part of of the kernel-level encryption libraries, and has been used in the CopyFail exploits.

The patch notes that the zero-copy functionality was originally intended to accelerate performance with hardware encryption accelerators, but is rarely used for that purpose and has almost no dependencies in userspace tools. By removing the seldom used, but very complex, zero-copy API, the kernel developers hope to eliminate future bugs in the CopyFail class which manipulate the page table cache.

CISA Self-Doxes

A contractor for the US government cybersecurity watchdog agency CISA  left a public GitHub repo – hilariously named “Private-CISA” – available, with credentials for CISA cloud services, authentication tokens, plaintext passwords, and internal credentials.

Brian Krebs reports on the full details. Credentials included access to the CISA AWS GovCloud systems, the internal CISA build system for tools, and plain-text logins to the repository of internal libraries. GitHub itself has protections to prevent accidentally publishing authentication tokens and credentials in repositories, but they were explicitly disabled.

The GitHub repository had been active since November of 2025, and even after being taken down, leaked credentials to access AWS GovCloud remained active for an additional 48 hours.

NGINX 0-Day

The NGINX web server is used on millions of systemsm approximately 30% to 40% of web servers, as both a traditional web server and as a proxy system for internal web services.

Last month the “nginx-rift” vulnerability allowed for arbitrary code execution via the NGINX rewrite engine. Now, the “nginx-poolslip” vulnerability has been found causing denial of service and in some cases remote code execution even on the latest NGINX versions.

Currently there are no official patches for the NGINX service, though there likely will be shortly. In the mean time, the primary suggestion for mitigating the bug is to ensure no “rewrite”, “if”, or “set” rules in the NGINX config use unnamed PCRE capture groups.

Pid-fd Linux Bug Gets Official

The “pid-fd” bug mentioned last week now has an official patch and CVE.

Not to be confused with CopyFail or DirtyFrag bugs which allow root access via corrupting the page cache of file data in RAM, this bug, also called “ssh-keysign-pwn”, enables reading any file regardless of file permissions, exposing important files like the system password file in /etc/shadow or the SSH private keys of the server or users, and executing commands as root via other common utilities including ssh-keysign, pkexec, and accounts-daemon.

RDS-Pintheft Linux bug

Seemingly not getting too much attention the V12 group released proof-of-concept code for another Linux kernel bug, naming it “RDS-pintheft”.

The bug lies in the Linux RDS network code, an alternate communications method for high-speed communications within clusters. It functions similarly to CopyFail and DirtyFrag: mis-handling memory buffers allows reliable overwriting of the page cache and replacing the perceived contents of a suid-root binary, granting instant root.

This exploit does require the RDS and RDS TCP kernel modules to be loaded, which may not be present on all distributions. If the module is already loaded or the attacker can cause it to be automatically loaded, and has the ability to execute code locally, it appears to be game over.

Patches are available and will likely be integrated into distribution kernel patches soon.

Google Self-Doxes Chromium

Bleeping Computer reports that Google has accidentally exposed the details of an un-patched Chromium exploit that enables JavaScript based botnets in all Chromium based browsers. Chromium is the open source browser engine which lies underneath Google Chrome, but also Microsoft Edge, Vivaldi, Opera, Arc, and Brave.

The JavaScript bug allows service workers to remain running in the background, even when the original page has been closed, or even when the browser itself has been closed. This would allow malicious websites, or ads carrying JavaScript injected into benign websites, to continue issuing requests without the user knowing, fueling a botnet for click fraud or denial of service attacks.

The bug was first reported in 2022, but ignored until 2024 when it was flagged as requiring attention. In February of 2026, the bug was marked as fixed, though no patches had been shipped yet. On May 20, details of the bug were automatically released because the bug had been closed for more than 14 weeks and marked as fixed.

But in fact the bug was not fixed, and the researcher noted that previous alerts that may have given the user a hint that something was occurring are now gone, making the attack even simpler.

Additional fixes will likely arrive shortly, given the publicity and severity of the bug.

We talk about all kinds of autonomous vehicles here at Hackaday, from aerial drones to rugged rovers. A little less common are the submarine builds, likely due to their technical complexity. That said, though they perhaps benefit most from autonomy given they’re so hard to talk to while underwater. In any case, [Ayman] has built an impressive sub that uses some rudimentary techniques to navigate around while under the surface. 

The build uses typical construction techniques for DIY subs of this size, with a clear acrylic tube serving as the body of the craft. It’s carefully sealed to ensure water ingress doesn’t send it to the bottom, using nifty tricks like a magnetic coupling for the prop. Inside, there’s a Raspberry Pi 4, kitted out with an Arducam IMX708 camera with a wide angle lens. It’s joined by a BNO085 inertial measurement unit, along with two BMP280 pressure sensors for keeping track of motion and the sub’s vital signs, while a DRV8833 motor controller runs the main drive motor.

There’s also an ESP32 which helps out with motor and servo control for steering, and ballast control. Sinking and floating the sub is handled with a pair of two ballast tanks constructed out of 5 mL syringes that are driven in and out with high-torque output gear motors. The build uses an antenna buoy so that communication can be maintained with the sub when it’s within a certain range of the surface.

A neat addition to the sub is its autonomous navigation code. [Ayman] whipped up some simple object avoidance routines, which rely on the Raspberry Pi’s camera. The code uses HSV values to track specific colored objects and avoid them, which proves more reliable than RGB as it allows tracking color in a largely brightness-independent manner.

Although we’ve featured other builds that use similar construction techniques, seeing a transparent submarine gliding through the water will always make us think of the incredible Open Source Underwater Glider that won the 2017 Hackaday Prize.

If you’ve played Cyberpunk 2077, you might have seen the rad jacket that has a screen in the collar. Once upon a time, such a thing would be solely the preserve of science fiction—you certainly wouldn’t be achieving that look with cathode ray tubes, that much is for sure. However, technology has advanced to the point where [Zibartas] was able to produce just such a jacket in real life.

The key to the build is the advent of the flexible OLED screen. [Zibartas] was able to source four such panels in a smartphone-like aspect ratio, which came in at the hefty price of $300 each. Two Raspberry Pi 4s were enlisted to drive two screens each. The older model Pi was chosen as it was capable of achieving a neat hack to better play smooth video across two displays. A rudimentary sync system was whipped up using GPIO pins to keep video from both Pis playing together. From there, it was simply a matter of figuring out how to create a structure to hold the screens within the large collar of the scratch built cyberpunk-styled jacket. As it turns out they don’t actually flex much in the final install, as they’re held in a 3D printed structure to keep them safe from damage.

The final result is quite something, very accurately recreating the jacket from the game itself. While technically a simple build, actually pulling it off required some delicate work and smart design decisions to make it practical to wear. We’ve featured some other fun jackets over the years, too.