Usually in Tech In Plain Sight, we talk about technology you probably see every day, even if you don’t notice it. But we hope you don’t get to see one of the latest crop of medical robots, such as the LUCAS chest compression system. If you watch the popular TV series “The Pitt”, though, you may have caught a glimpse of one of these medical marvels. They aren’t fiction. They are very real devices.

Calling them robots might be stretching the definition a little. They don’t roam the halls looking for patients. But once attached to someone in cardiac arrest, they can take over one of the most important — and physically demanding — parts of CPR: chest compressions.

Keep The Blood Moving

When someone’s heart stops pumping blood, time is critical. CPR doesn’t normally restart the heart on its own. Instead, chest compressions produce enough blood flow to keep oxygen reaching the brain and heart while rescuers work on the underlying problem and, when appropriate, use a defibrillator.

Doing that well is harder than it looks on television. Current American Heart Association guidelines call for adult chest compressions 100 to 120 times per minute, at least 5 cm deep but generally no deeper than 6 cm, while allowing the chest to recoil fully between compressions. Interruptions should be kept to a minimum.

That’s hard physical work. In fact, studies show compression depth begins to fall after only about 90 to 120 seconds, which is one reason CPR teams normally swap compressors every two minutes. But a robot doesn’t get tired.

Meet LUCAS

LUCAS stands for Lund University Cardiopulmonary Assist System, reflecting the device’s origins in Lund, Sweden. Early versions entered clinical use around 2002-2003 and were pneumatically powered. Later versions replaced the compressed-gas system with an electric motor and battery.

The current LUCAS 3 looks something like a small drill press straddling the patient as you can see in the video below. A backplate goes beneath the torso, and a frame locks onto it. An electrically driven piston presses a suction-cup-like pad against the sternum. Internally, the motor drives a belt and ball screw that moves the piston up and down.

Factory settings are around 102 compressions per minute and roughly 53 mm compression depth for a typical adult, although parameters can be configured.

Beyond tirelessness, another obvious advantage is that LUCAS doesn’t need hands. Medics can deal with ventilation, drugs, defibrillation, IV access, and the dozens of other things occurring during a cardiac arrest. More importantly, the device can keep compressing while a patient is being carried, wheeled through corridors, or transported in an ambulance — situations where doing good manual CPR is awkward and sometimes dangerous to the practitioner.

So Does It Save More People?

You might reasonably expect perfectly regular machine CPR to beat a tired human. Large randomized trials haven’t demonstrated that, however. The 4,471-patient PARAMEDIC trial found 30-day survival of 6.3% with LUCAS versus 6.8% with manual CPR, not a statistically significant difference. The 2,589-patient LINC trial similarly found essentially identical four-hour survival — 23.6% versus 23.7% — and no significant improvement in longer-term neurological outcomes.

That doesn’t make the machines useless. It says something slightly different: high-quality mechanical CPR hasn’t proven superior to high-quality manual CPR as a routine replacement. The International Liaison Committee on Resuscitation currently recommends against routine mechanical CPR, while specifically noting that it can be a reasonable alternative when sustained manual compressions are impractical or would endanger the practitioner.

One issue is setup. Installing the machine adds a time penalty: compressions must stop briefly while the backplate and mechanism are positioned. Good training is essential to keep that interruption short. Another problem is that some studies show potential links to higher rates of internal chest injuries, such as bleeding around the lungs. There have also been rare device malfunctions or power failures that can compromise care.

Not The Only Game In Town

LUCAS isn’t alone. ZOLL’s AutoPulse takes a very different mechanical approach. Instead of a piston pushing on one spot, a motor tightens a broad load-distributing band around the patient’s chest.

There’s also the German corpuls cpr, which returns to the piston idea but uses a cantilevered single-arm mechanism. That leaves much of the chest unobstructed and makes the system useful during procedures such as cardiac catheterization.

So perhaps these aren’t quite the autonomous robot doctors science fiction promised us. But when your heart has stopped, and a machine is tirelessly pumping your chest a hundred times a minute while the medical team works around it, you probably won’t complain. We hope you don’t have to find out.

We’ve seen DIY devices, though certifying medical devices for actual use isn’t for the faint of heart. Robots can also help train humans to do better CPR.

Featured image is a still from the instructional video “Physio-Control LUCAS 3 Chest Compression System – Hospital Use” by MFI Medical.

The AI platform ServiceNow which offers both hosted and on-premises versions just patched a trifecta of CVSS-10 vulnerabilities.

CVSS rankings are determined by the severity of a flaw, the ease of exploiting the bug, if authentication is required for exploitation, if the vulnerability exposes confidential data, and other criteria. A CVSS of 10 is as bad as it gets, and having three of them at once is certainly attention-getting. Of the three vulnerabilities fixed, one allowed unauthenticated modification of data in the hosted instance, a second allowed arbitrary code execution via the GraphQL interface, and the third allowed arbitrary SQL commands that could modify the database.

ServiceNow claims Adobe, Lenovo, Fedex, and Fujitsu among their high-profile customers. With luck, the vulnerabilities were patched before significant public exploitation could happen.

Router Malware

Previously in 2026 the US Government warned against embedded malware found in consumer routers, which may be linked to the FCC enacting bans against certification and import of foreign-made consumer devices. This week, the NVD (National Vulnerability Database) reported specific embedded malware in the Zbtlink and MoreQuick brands of devices.

Multiple versions of the firmware, for multiple lines of products, contain a backdoor service that uses unencrypted UDP to connect to a command and control (C2) service. The service, or anyone able to intercept the network traffic, since it’s unencrypted, can execute commands as root, allowing them to change configurations, open tunnels, or steal ISP credentials.

The malware is baked into the firmware, so removing it is impossible for most users: a factory reset wouldn’t do. In theory if third-party firmware like OpenWRT supports these devices, the hardware could be made safer with a custom install.

Given how commonly the same device is marketed under dozens of names, likely the same devices and firmware have yet to be identified under other brands.

Vulnerability in Qubes

The security-focused distribution Qubes has an important security bulletin for recently discovered issues.

Qubes is built on top of the Xen virtualization system, where each application can be given a dedicated container. The utility to copy files from the primary container into an application container, qvm-copy-to-vm, displays a message if there is an error copying the file. To show the message, the utility launches kdialog with the error as arguments, but fails to ensure that the error doesn’t include shell commands.

The system call used to show the alerts has the dangerous side effect of calling the command as if it was a normal shell. This is extremely powerful, but equally risky: a shell typically allows multiple commands per lines, require quoted strings to protect arguments with spaces or complex text, and can expand variables. Generating an error that escapes out of the message and runs arbitrary commands was all it took.

Qubes already has a fix ready and everyone getting standard updates should have it waiting.

Were US Military Freezers Hacked?

The controls for the freezers used in the commissaries of a growing number of US military bases may have been compromised.

Independent researchers noticed growing reports in Reddit threads that freezer units were out of service, with other service members and families reporting the same. At least fourteen bases throughout the United States appear impacted, and the story has been picked up by the official military newspaper “Stars and Stripes” as well as by mainstream media outlets.

Posts by staff at the bases clarify that it was not a power loss or cooling loss, the fridges and freezers were placed in defrost mode where they self-heated. The commissaries are operated by the Defense Commissary Agency, with central monitoring and control of facilities. Central monitoring makes complete sense when you need to ensure devices are keeping food at a safe temperature, but something definitely seems to have gone wrong.

Diving into it further, M. Elizabeth finds a post from August 9, 2026 describing vulnerabilities in the Danfoss controllers that allow unauthorized access to the refrigeration controller, and a second paper by the same team exposing over 20 vulnerabilities in Copeland refrigeration controllers that included full control of the unit settings. M. Elizabeth is careful to point out that without confirmation from the commissary agency, it’s impossible to know for sure that this was a hack of the control system, but the evidence is mounting.

BGP and SSL Hijack Used to Push Bad Updates

Virtualizor, a web interface for managing virtual machines in an enterprise (bring-your-own AWS), was recently targeted in a global route hijacking scheme.

Border Gateway Protocol (BGP) is a core routing system underlying the Internet at large. Service providers use BGP to announce the ranges of IP addresses they handle and how to reach them. BGP is operated as basically a global gentleman’s agreement: the protocol itself lacks any authentication or encryption. If you think this sounds vulnerable to disruption, you’d be completely right.

Global disruptions have happened accidentally, like when an ISP in Pakistan took down YouTube, deliberately, such as when thieves hijacked the routes to cryptocurrency exchanges, and mysteriously, like when China hijacked parts of the Internet repeatedly with no explanation.

This time, the BGP attack targeted the IP range used by Virtualizor, and was combined with spoofed SSL certificates for the Virtualizor servers to push spoofed updates. The BGP announcement was targeted to a specific class C: a relatively small allocation of 253 addresses, similar to what a home network would use. BGP gives precedence to the smallest announcement for an IP range, so all systems that received the spoofed announcement routed those addresses accordingly. The network advertising the false route was based in Romania, though of course they could also be a victim.

With control over the IP range, the attackers were able to generate a certificate via Lets Encrypt, which was sufficient for browsers and the updater to accept the rerouted addresses. The attackers then published a malicious package that appears to install additional services. The company has not provided details about the trojaned update, so it’s not clear what other risks it poses.

Virtualizor does not have a public list of customers, but one has to assume it includes high-profile companies to make such an attack viable. Hijacking BGP is extremely obvious, and isn’t frequently used for such obvious spoofing attacks.

Linux Zoom Steals Clipboard Contents

Simon Tatham, the author of the extremely popular PuTTY SSH client among other projects, posted on Mastodon an interesting observation about the clipboard behavior of recent Zoom clients on Linux.

Relatively recently, some operating systems have added the ability to alert the user when an application access the clipboard. Unfortunately, Linux is not yet one of them, but thanks to other clipboard management tools, Simon noticed that the recent update to Zoom 7.1.5 copies the contents of the clipboard as soon as they change. What happens to the clipboard contents once copied is currently a mystery.

Considering that the clipboard can often contain passwords, authentication tokens, or simply data you might not want to share with Zoom, automatically scraping the contents isn’t what you’d hope for.

Plex Vulnerabilities

The Plex media streaming software sent out an advisory this week warning about security updates for the server and desktop application.

Details are currently thin, with the promise of future details once CVEs have been assigned. For now, make sure you’re on version 1.43.4 or newer. The Plex post has additional directions for updating on platforms that may not have pushed new packages yet.

AI Accelerates Exploit Development

Security company CrowdStrike has released their 2026 report on threats, focusing on the proliferation of AI tools in exploit writing.

CrowdStrike observed that 88% of exploits happened with 48 hours of the proof of concept code being released, crediting AI tools for shortening the adaptation. Typically proof of concept code is designed to demonstrate the vulnerability without providing an immediate mechanism for malicious use, and the window from exploit announcement to wide-spread risk was on the order of weeks. The report notes some vulnerabilities being widely exploited in 20 hours after public disclosure.

The tightening window makes patching even more important, but rapid patching caries the risk of instability when the patches themselves haven’t had extensive testing. Unfortunately there’s no simple solution; faster exploitation via AI tools drives faster patching, often also with AI tools that can introduce more bugs as well.

If you want improve a model rocket’s performance, all the common options come with serious trade-offs: you could increase the motor’s size, which raises safety issues, or you could cut down on weight, which limits the possible payload. [Con Hathy] was therefore intrigued by the design of the Arcas sounding rockets, which with the aid of a gas-fed launch tube could reach an altitude of 100 km. Even in models without a gas generator, a launch tube apparently boosted performance, an effect which [Con] was able to replicate in a much smaller model rocket.

In theory, as the rocket engine fires, it should pressurize the tube behind the rocket, providing an extra boost out of the tube. To test this, [Con] 3D printed a test rocket, launched it both from a standard rail and from a tube, and compared the results. During tube launches, a printed sabot fit around the rocket and formed a seal with the launch tube. The results were surprising: the tube-launched rocket actually performed substantially worse than a rail launch. After building a simulation, [Con] found that, as the rocket moves down the tube, the volume of tube it needs to back-fill with gas increases faster than the engine puts out exhaust; it was pulling a slight vacuum behind it, slowing itself down.

To solve this, [Con] decreased the diameter of the launch tube. To let the rocket fit into the tube, he also modified it to use pop-out stabilizer fins which wrap around the rocket while in the tube. The sabot was also shrunk, and had foam added to improve the seal between it and the rocket. For this second test, [Con] also connected a pressure sensor to the base of the launch tube. The results on the second launch were much better: according to an altimeter, it managed to fly 72% higher. Based on the pressure sensor’s data, a longer tube could have squeezed out still more performance, but this still demonstrated the principle quite well.

We’ve seen a tube-launched rocket before, though not with such a performance focus.

The big news today is, of course, the successful launch and deployment of NASA’s Nancy Grace Roman Space Telescope earlier this morning. The space agency’s latest observatory lifted off at 7:26 AM Eastern from Launch Complex 39A at Kennedy Space Center aboard a SpaceX Falcon Heavy, and by 8:00 AM it was separated from the rocket’s upper stage and flying on its own.

While the sound and fury of launch is exciting, it’s just the beginning of the journey for Roman. It will take several months for the spacecraft to complete its roughly 1.5 million-kilometer trek out to Earth’s second Lagrange point (L2), where it will set up shop near — in cosmic terms, anyway — the James Webb Space Telescope (JWST). Along the way, it will switch on and test various systems and components, with its primary 300 megapixel infrared camera scheduled to power up in three weeks or so.

There’s a lot to cover about the Roman Space Telescope. Built from spy satellite spare parts donated by the National Reconnaissance Office and featuring a field of view 100 times greater than that of Hubble, its launch is widely considered to be one of the most important scientific milestones of the decade. We’ll be bringing you more about the past, present, and future of this flagship mission as it progresses.

From real space missions to virtual ones, this week the developers of EVE Online announced that 2.4 million lines of code that keep the massively multiplayer online role-playing game running would finally be making the switch to Python 3. Given the immense complexity of the codebase, it’s been stuck at Python 2.7 since their last overhaul back in 2010, a situation which has become increasingly difficult to manage as time goes on.

The announcement goes into a surprising amount of depth about the state of Python in EVE. We imagine most players couldn’t care less, but naturally the developers have strong feelings about the situation and perhaps thought it would benefit others in a similar situation to get their thoughts out there.

While there’s certainly an argument to be made that the only justification they really need for making the migration is that 2.7 hit end-of-life back in 2020, the developers explain that the more immediate problem for them was that various tools and libraries they wanted to use were no longer compatible with the Python 2.x series. They also point out hopes that speed improvements made in the latest version of Python will eventually translate into better game performance down the road.

In more terrestrial news, this week the necessary regulatory amendments were passed to make plug-in solar systems legal in the United Kingdom. Assuming the wiring meets the necessary requirements, consumers can pick up the hardware and install it themselves without involving an electrician, although they may still need to contend with landlords and local ordinances that may limit their ability to physically mount the panels. The rules as they stand now allow each residence to have four panels with a total combined output rating of no more than 2,000 watts, although critically, the system is only allowed to generate a maximum of 800 watts at the inverter. As the government and consumers get more comfortable with plug-in solar systems, these numbers will likely increase over time.

Solar isn’t the only area where DIY approaches are moving into the mainstream. This week, Citrix pitched a “different approach to endpoint resiliency”: an isolated Linux-based operating system called UniconOS that users can boot into should the computer’s primary Windows installation become compromised or otherwise inoperable. The idea is that an independent, read-only backup OS kept on its own partition will reduce downtime, since the computer can still be used while IT figures out what the hell happened.

This solution will sound suspiciously familiar to anyone who’s booted a live Linux system from CD/DVD/USB in the last few decades. Try not to keep yourself up all night wondering why you never pitched the idea to some hungry venture capitalists in exchange for a yacht in the Bahamas.

Finally, on the theme of new technology embracing the old ways, we bring you Defrag98, a web reincarnation of Microsoft’s dial-up era Disk Defragmenter tool. While it won’t actually improve the performance of your modern solid-state drive, you may find your own mood boosted by the wave of nostalgia when you see — and hear — the classic tool go to work.

That’s right, not only do the blocks dutifully flip from red to blue just like you remember, but all the while you’ll be treated to the unmistakable whirs and clicks of a spinning hard drive circa the turn of the millennium. Never forget what they took from us.

See something interesting that you think would be a good fit for our weekly Links column? Drop us a line; we’d love to hear about it.

Humanoid robots, even scaled-down ones, tend to be expensive. The Berkeley Humanoid Lite offers a more accessible and economical option by centering the design around 3D printed actuators that make up the bulk of the robot’s frame.

The actuators are made by combining motors with printed cycloidal gearboxes and an embedded magnetic encoder. They’re modular, so even if one has no desire to recreate the whole robot it might be worth checking out the actuator design details to see if they might be useful in some other way.

The Berkeley Humanoid Lite isn’t a finished product so much as an open-source, easily customized reference design. The GitHub repository contains everything one might need, and you can watch some basic demonstrations, including VR-driven teleoperation, in the video embedded below.

At a total hardware cost of under $5,000 USD it’s still expensive, but much more economical than other humanoid robots, open-source or not. As mentioned, even if one doesn’t plan to build one, the modular actuator design is worth keeping in mind for other purposes.

Many of us have noted a tremendous price increase in many computer components for some mysterious reason. Whatever this cause is will be debated among the various modern philosophers and Diogeneses, but regardless of cause we all still have to live in this world and make do. That turns us towards getting maximum value from the things we already have rather than trying to go out and buy more computer components right now, like [svofski] using his vast swath of existing microSD cards to build an SD card library.

The library is based around a tiny robotic arm that can physically grip the cards and move them in and out of a reader. The first iteration of the arm involved rotating the two pincers, but this turned out to be overly complicated and [svofski] eventually settled on a design resembling a rack and pinion that slides the two pincers together instead. With the gripper sorted out, it’s placed in system called T-bot arrangement, similar to coreXY kinematics, that lets it pick and place among 12 microSD card slots.

Many of the parts in this build were directly from or inspired by 3D printers, making it relatively simple with so many parts available. [svofski] didn’t build it for a specific use case, though; mostly it was constructed out of fascination for robotic tape changers which perform a similar function. But for anyone who actually needs to duplicate a large number of SD cards, or other types of removable media, this could prove to be a fairly handy robot.