This Week In Security: ShinyHunters Won’t Dox The FBI, Pentagon Data Stolen, And OBS Vulnerable

404 Media reports that the ShinyHunters group who stole multiple terabytes of FBI employee data say they do not plan to release the data.

Known for ransomware and extortion of innumerable companies and government agencies, ShinyHunters used a zero-day vulnerability in Oracle PeopleSoft to compromise the employment site of the FBI and pivot into scraping the content of FBI AWS instances, claiming to have the full employment and health data of all FBI agents, employees, and spouses.

The hacker group took exception to an FBI press release that claimed that the group over-stated stolen data and that they directly harass victims and victim’s families.  The group publicized the FBI data breach, demanding a retraction of the statements, and it was generally assumed that the group would follow their typical methods of releasing the data publicly if the demands were not met.

The group has told 404 media that they had always agreed internally to not release the stolen data, saying “This was all a marketing campaign to protect our business and actively combat disinformation”.  Meanwhile the FBI continues the investigation, and Shiny Hunters may be hoping to defer some of the ire.

Continue reading “This Week In Security: ShinyHunters Won’t Dox The FBI, Pentagon Data Stolen, And OBS Vulnerable” →

The Least Annoying Of All Evils

If you missed the hubbub this week, it was discovered that the Raspberry Pi Foundation added code in the firmware that locks the boot process up if non-original RAM chips are detected onboard. Hot-rodding your Pi is a time-honored tradition in these parts. We do wonder just how many folks are taking the risk of hot-airing the memory off the board, versus paying the extra cash to get one with more RAM. But according to Raspberry Pi, enough boards are showing up that have the RAM surreptitiously replaced, and often defective, that they took the step to lock the machine down.

Should users be alerted to potentially unscrupulous behavior by the companies selling them single-board computers? I think we’d all say “sure”. But should that entirely brick the device? And prevent people from upgrading their own? The hacker in me says “no”. Is there any way to reconcile these two? Our own [Arya Voronova] suggests that it’s no big deal to flash an older version of the initial firmware, and we concur, although it does leave behind all the improvements since 2023, and it will only get less fresh as time goes by.

How to announce that the board has non-factory memory without breaking it? [Jeff Geerling] suggested a non-matching-memory bit that users could check, but then they could also neglect to check. My cellphone has a screen that appears every bootup, and requires me to press the power button to continue, because I rooted the phone and installed an open-source OS. It’s a hassle for sure, but it’s a lot better than bricking the phone or disallowing user firmware entirely.

Doing the same thing for the Raspberry Pi isn’t as easy. You never know what, if any, peripherals are connected, so you can’t guarantee that there’s a screen to alert you or even necessarily a keyboard on which you could acknowledge. We’re reminded of a similar situation with FTDI USB-to-serial converter chips ages ago. Their driver software simply refused to work with counterfeit versions of their chips. Hackers were up in arms, largely because we couldn’t know if the parts were genuine at purchase time, and the counterfeits were widely distributed even by reliable resellers.

So what about it? Can you think up a tamper-evident signal that could run on boot on a Raspberry Pi, maybe a headless system installed in some difficult-to-reach place? Maybe ideally the equivalent of the cell phone’s scare message? It would have to be hard to overlook, but keep the machine running, notifying the user that things aren’t kosher, but not preventing them from getting to work. Sounds like a tall order to us.

This Week In Security: Baked-in Malware, Freezers Not Freezing, Zoom Snoops Clipboards, And AI Makes Things Worse, Faster

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. Continue reading “This Week In Security: Baked-in Malware, Freezers Not Freezing, Zoom Snoops Clipboards, And AI Makes Things Worse, Faster” →

This Week In Security: Android Malware, VOIP Hijack, Signal Contact Discovery, And TeamPCP Arrests

On GitHub, [AyaanB] details buying a cheap Android TV streaming device, looking for, and finding, baked-in malware.

Multiple warnings have been issued by the FBI and CISA regarding malware on media box Android devices. Many devices have been caught participating in botnets providing residential proxies, ad-click fraud, and DDOS services. [AyaanB] sets out to discover if a $30 set-top streaming box is pre-infected with malware, and extracting it – without ever letting the device talk to the Internet or access other devices on the local network.

Picking a device named in the advisories, [AyaanB] discovered that it was, indeed, preloaded with multiple app stores and applications that wouldn’t typically make sense on a set-top TV box. After identifying the serial port test pads and obtaining a low-voltage serial adapter, they were able to gain access to the bootloader and from there dump the contents of the MMC over TFTP.

With the entire filesystem accessible out-of-body, proving it was infected with malware at the factory becomes simple: the malware is signed as a system application, baked onto the system partition of the MMC, granted SELinux exceptions to mark it as a system binary with shell privileges, and has multiple launch scripts to make sure it is executed even if partially removed. With the malware identified, [AyaanB] continues to dig through to uncover the capabilities.

By installing hooks into the low-level Android process spawning system, the malware installs hooks into every application as it is launched: even if an application isn’t trojaned already, by the time it finishes executing, it’s definitely been subverted. The functions patched and the methods used match the Vo1d botnet, which is used for account takeovers, residential proxies, free “VPN” services, and other unfriendly behavior.

Further digging into the system showed hooks for ad-click fraud, where hidden browser windows are allowed to run unthrottled and display overlays are configured to obscure ads below where the user may click. Other included tools bid in real-time ad auctions, claiming to directly publish ads to the user which may or may not be visible. To cap it all off, a root level backdoor allows botnet operators to access the systems directly and install additional tools.

Be sure to check out [AyaanB]’s writeup for more details on exfiltration methods and other malware found on the devices. Continue reading “This Week In Security: Android Malware, VOIP Hijack, Signal Contact Discovery, And TeamPCP Arrests” →

This Week In Security: Apple Warns Users, Stripe Merchants Leak Keys, Copilot Helps Hack Itself, And Comcast Senses Movement

Apple has started sending some users push notifications warning that they have been targeted with specific malware. No specific information about the threat Apple detected is available. While multiple iOS attacks were released in spring of 2026, they all target much older versions of iOS and older hardware versions.

Users in 110 countries have received notifications recently, warning them they may have been targeted or already impacted by malware such. Apple typically uses the crash reporting mechanism for system apps to track new attack trends. The majority of users will likely never see an alert from Apple because malware with state-level capabilities like the Pegasus family is extremely expensive to develop. However, commercial availability means that some governments have deployed them against political opponents, protesters, human rights lawyers, and journalists.

If Apple pushes a security alert, it will show up as an email and a standard system notification, but also as a notification inside the Settings application. While email and notifications can be spoofed as part of phishing attempts, to date there is nothing which can generate false alerts inside Settings.

Almost universally in these cases, Apple recommends enabling “Lockdown Mode“, which adds extra protection to devices at the cost of decreased battery life and slower performance. Lockdown mode disables custom fonts on web pages, accelerated JavaScript, restricts message attachments over SMS and iMessage, and disables other common paths used by malware to steal data. Android devices offer a similar feature since Android 15 that is less comprehensive but can still provide additional safeguards for users directly at risk.

Attacking Airplane Networks

With research that will surely result in some breathless reports, researchers presented at Usenix 2026 an attack against the communications bus of a Boeing 737.

The ARINC 429 bus is a communications architecture for planes, similar to the CAN bus used in cars. Once you are connected to that bus, it can be vulnerable in the same ways cars can be vulnerable to data manipulation. In the Usenix paper, researchers discovered that one access port to the airplane communications system is easily reached from the outside of the plane, though “easily” in this context means “by airplane maintenance technicians”. The paper represents over a decade of work by the team in obtaining and building a test lab of avionics equipment to represent an actual airplane, culminating in an embedded device described as “the size of a quarter” that plugs into the communications port and provides remote access over WiFi.

It needs to be emphasized, given other recent news, that this is a piece of hardware being added to the plane which communicates over WiFi, and not a way to attack an unmodified plane via passenger WiFi!

Once part of the ARINC bus, it seems access is basically unfettered: the team describes being able to reprogram the autopilot, feed the pilot displays false data, and being able to modify the temperature and weight data shown, which could lead to miscalculations in take-off speeds with obviously catastrophic results. Fortunately, the researchers have also been working with Boeing since 2020 to address the issues being found, and the practicality of the attack in the wild remains largely theoretical. The research team has recommended removing the external ports in future aircraft, and blocking access to them physically, like with epoxy, in the current designs.

If reading security research papers is your kind of fun, be sure to check out the rest of the papers that were part of Usenix 2026.

Continue reading “This Week In Security: Apple Warns Users, Stripe Merchants Leak Keys, Copilot Helps Hack Itself, And Comcast Senses Movement” →

This Week In Security: BugTraq, AI Hacks, And Being Dumb On Planes

After a multi-year hiatus, the venerable BugTraq mailing list is back!

For decades, BugTraq was the place where vulnerabilities were disclosed, from the early days when nearly all vendors viewed all security research as a hostile force, through to the modern era of working with vendors to coordinate disclosing bugs. With the rise of bug bounty programs and other social changes, the mailing list slowly died: what started in 1993 ended in 2021 is returning. The new maintainer, Jonathan Brossard, says in his announcement “The mission is unchanged: full disclosure, researcher-first, no corporate filter.”

Don’t Be Dumb on Planes

In the unlikely event anyone here needs to be told: Don’t do dumb things on planes.

It seems that someone coming home from from the DEF CON hacker conference in Las Vegas decided to mess with the in-plane WiFi, and is likely now in the “find out” phase of doing something dumb. There hasn’t been any public followup beyond the original reports: a passenger on a Delta flight leaving Las Vegas brought up a fake WiFi hotspot named “Delta WiFi FAST” to trick other passengers into connecting, and attempted to disable the in-flight WiFi using a denial of service attack.

Continue reading “This Week In Security: BugTraq, AI Hacks, And Being Dumb On Planes” →

This Week In Security: Claude Gets Hacking, Hotel WiFi, And NPM Compromised Again

kMaybe feeling left out from the questionable hype train of “Our AI models can’t be trusted”, Anthropic has released reports that their Claude model has “reached the Internet” and accessed the systems of other companies on at least three occasions during testing.

It appears that the model was restricted from accessing the Internet because (and wait for it) the prompt told it that it didn’t have Internet access, and was inside a simulation. It seems like Anthropic counted on the same trick that users try to convince a model that Grandma really wanted to pass on her life-long love of hacking services, it’s all pretend. Like the OpenAI incident, the models were tasked with completing a capture-the-flag style challenge, a common hacker challenge format where vulnerable systems are provided and contestants try to hack them the fastest. Anthropic says that a misconfiguration of the test environment left the models with Internet access, so the model succeeded in accessing the Internet at large once it ignored the prompt.

In some instances, Anthropic says the model proceeded under the “misconception” that it was still in a simulation, listening selectively to some of the prompt, while in others it continued regardless. In once incident, the test model generated malicious PyPI packages, which were uploaded to the public PyPI repository and downloaded 15 times. Further clouding the issue, one of the downloads of the malicious PyPI module was by a security auditing company that was then infected by the package during analysis, allowing the Claude agent to access credentials of the security company via a poorly designed malware analysis pipeline. The company essentially deliberately infected itself with a malicious package, while lacking protections against malicious packages!

Anthropic promises tighter controls in the future, but stops short of ensuring that models under test will be prevented from accessing the Internet, and categorizes it as a test gone wrong. “These facts give us cautious optimism that with tighter monitoring and controls around evaluation infrastructure, as well as continued investment in alignment, this type of risk can be overcome.”

It remains to be seen why allowing automatic code to hack the production environments of other companies is considered acceptable. If any of us had done the same we’d be facing serious legal questions.

Hotel WiFi Pushes Malware

A threat group associated with the Russian Foreign Intelligence Service (APT29, Cozy Bear, Storm-2945, and/or Midnight Blizzard) has been identified behind an attack to push fake updates over hotel WiFi networks.

It appears that the attackers compromised the captive portal and gateway systems of the impacted hotels. The captive portal system is the typical gatekeeping system that requires you to pay for Internet access, or at least input your hotel room and name. By hijacking the DNS, users were redirected to additional fake “verification” pages that served a menu of malware using a variety of techniques.

Like previously reported activity attempting to capture Microsoft365 logins via spoofed pages, most these attacks seem very loud and obvious, counting on the end user to ignore warnings about invalid SSL certificates or run commands in the shell. Using a variant of the “click-to-fix” attacks, the user is presented with a fake request for additional verification by copying and pasting a string of text into a command shell, which then decodes to a standard malware installation script. More subtle attacks attempt to trick the user into adding a new device to their Microsoft accounts. The user is redirected to a page claiming to require a Microsoft login to access the Internet, often hosted on a copycat domain similar to a legitimate Microsoft resource. The fake login then prompts the victim to copy and paste an authentication URL, adding a new logged-in device to the Microsoft account.

Obviously, running arbitrary shell commands, accepting invalid SSL certificates, or pasting arbitrary URLs after signing in are all something nobody should be doing, and it’s unclear how many users were actually impacted by the campaign. For corporate users, the answers are relatively simple: user training, and an always-on corporate VPN that routes all traffic and DNS through the company servers.

For home users, the solution may be more nuanced. Every third video on YouTube tells you that you need to install a commercial VPN, but in many ways this simply shifts the problem. A commercial (or even worse, a free public VPN) service can also intercept DNS requests and traffic, by design. While some services are legitimately privacy protecting and respecting, many hide the true owners of the service. A better tool is Tailscale, designed for implementing personal VPN services, where your traffic stays on your own devices.

Tailscale, OpenAI, and Hugging Face

Speaking of the Tailscale VPN, we jump to their role (or non-role) in the recent Open AI “incident” with Hugging Face.

Tailscale is a zero-trust framework for connecting systems using the WireGuard VPN protocol. For end users, this is an excellent way to set up a VPN where your traffic never leaves your own systems unencrypted. For enterprises, it is often used to connect services Internet-wide, which is how it was used in the Hugging Face infrastructure. Once the Open AI agent had selected Hugging Face as a target, it found a vulnerability in a package manager, accessed a worker machine at Hugging Face, escalated to root on the Kubernetes cluster, and extracted the production key and authentication storage. This allowed the Open AI model to authenticate against the Tailscale system and directly connect to the network.

This, rightly, is not Tailscale’s problem. Once the authentication keys are available, it’s working as designed to allow new devices to register on the network. This is a pervasive problem with stored authentication tokens, and is one of the root goals, and causes, of the supply chain attacks suffered by NPM, PyPI, GitHub, VSCode plugin repositories, and more. Once an attacker is able to extract the authentication tokens, they are able to impersonate that account or system with equal privileges for as long as that authentication remains valid. Typically these tokens are not time limited, and the window of opportunity lasts until the owners of the account become aware of the compromise and are able to reset all of the impacted authentications!

Solutions to the permanent authentication token already exist, but are not widely used. Many package repositories already support restricted and dynamic authentication via OpenID Connect, where a token grants specific resources, not system-wide access. On some platforms, keys can be protected in a hardware-backed key store like a TPM or the Apple Secure Enclave chip, though this doesn’t solve the problem for most servers.

Tailscale, obviously, is looking to lean on the publicity generated from the Open AI incident, but the message is a good one: Anything that can be done to automatically and painlessly reduce the risks associated with long-lived authentication tokens will benefit everyone on the Internet. Even if you don’t run an integration pipeline, you most definitely run software built by one.

Another Set of NPM Package Compromises

The NPM package repository has suffered yet another incident where a large number of packages have been compromised.

Investigators have tracked over 400 packages infected with another variant of the same “Mini Shai-Halud” worm that ran rampant through package repositories in the Spring of 2026. While efforts have been made to reduce the attack surface of packages, few have implemented them, partly because they are not mandatory, and partly because they can greatly impact, or completely break, the build process. The packages this time include high-profile, commonly used tools, with several billion (yes, with a “b”) monthly installs during builds of other software.

Like the worms impacting the package repositories previously, packages are infected by added scripts to the pre-install commands which are executed automatically before the package is installed. The latest infection appears to have spread from a single developer of two widely used packages, keyv and cacheable. Once triggered, the worm will infect and upload new versions of all packages it can access, using stolen NPM authentication tokens. Like other variants of the “Mini Shai-Halud” family, the worm steals authentication tokens for NPM, PyPI, AWS, Kubernetes, and GitHub, the contents of env files which typically contain additional authentication keys, SSH keys, VPN configurations, and over 200 other types of credentials. These newer variants of the worms have increased the list of stolen credentials, begun modifying the instructions for AI coding assistants, added cryptocurrency theft, and added poisoned configurations for VSCode and AI tools to infect projects once the initial infection has been resolved.

Given the scope of the latest outbreak, the number of impacted packages will only increase: no effective countermeasures exist in the NPM community to prevent another wide supply chain event.

Mythos Knocks Out Post-Quantum Candidate

The Anthropic Mythos model found flaws in a candidate post-quantum encryption algorithm, HAWK. Multiple encryption algorithms have been under testing for years as part of the standardization process at NIST, with selected algorithms becoming part of the Federal Information Processing Standard requirements for systems handling secure data for government systems. Cryptographers fear that future advancements in quantum computing could break current encryption and signature methods, driving the search for new standards that will survive.

Anthropic reports that after 60 hours and approximately $100,000 in compute resources, the Mythos model was able to discover a flaw in the HAWK post-quantum signature algorithm. HAWK had previously survived multiple rounds of validation testing, but following the attacks generated by Mythos, the developer has withdrawn it from consideration. Mythos was not able to completely break HAWK, but combined multiple methods to reduce the key space by half.

Ultimately this is a case of the system working fully as designed. The proper time to find flaws in new algorithms is before they’re selected as standards!

Backdooring an Entire Linux Distribution

In 1984, Ken Thompson, one of the creators of Unix, gave the lecture “Reflections on Trusting Trust” in which he outlines the difficulties of establishing trust in tools. Thompson proposed the issue of a compiler modified to insert an invisible back door in any binary it compiled, including future versions of itself, ultimately showing the near impossibility of establishing a guaranteed clean tool chain, ultimately existing in all compiled tools and compilers without any evidence of the original code or modifications. Even if you inspect the source code, a compromised compiler could still be your undoing.

This week, a coalition of researchers published a paper demonstrating the “trusting trust” attack against a modern Linux distribution. Starting with a modified copy of the strip tool that removes debugging and other extraneous information to generate a smaller binary, the researchers demonstrated that the entire build of a NixOS Linux distribution could have a modification injected in every binary, including future builds of strip itself. While the attack starts with a source code modification of strip, after the first generation the modification exists in binary form only, built into each generation of the tool. This demonstrates that the “trusting trust” attack extends to any tool involved in the build process, not only the compiler, since the strip binary never reads source code, only the compiled results.