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.

The recorded messages from the pilots mention that the legitimate WiFi network was “jammed”, though this is unlikely technically correct. While any radio communications can be jammed by transmitting interference, most WiFi networks are susceptible to several basic denial of service attacks due to oversights in the WiFi standards design; by injecting WiFi management packets that tell the clients that a connection to the access point is no longer valid, and the device will attempt to reconnect.

By spamming the these disconnect packets continually, the network becomes essentially unusable, but unlike jamming, the interference is caused entirely by legitimate packets causing expected behavior. More recent extensions to the WiFi standards mitigate some of the most trivial attacks by adding additional validation that the packets were actually sent by the access point, but very few networks and clients use the newer options.

By rendering the legitimate network useless, the attackers hoped that users would select their fake network instead. None of the reports have included detailed information, but the fake network would likely have prompted the user to enter credentials for another site, such as Google or Facebook. The commercial hotspot model is particularly vulnerable to these sorts of attacks: many hotels, airlines, and businesses run an open, unauthenticated access point, and count on a web page the user must click through to gain access. Users are accustomed to clicking through web pages and providing room or booking numbers, names, or other credentials. Since there is no way to authenticate an open WiFi network, creating a look-alike network can be easy.

In lieu of additional official news, Youtuber [ThioJoe] tracked down some information, or the lack thereof, looking for further clarification; it appears that, contrary to some of the more excited online reports, law enforcement was not present when the plane landed, and it’s unclear if there was even an attempt to kick users from the legitimate WiFi network or a sustained “jamming” or denial-of-service. In an official statement from Delta, they say that no in-flight systems were at risk, which is as it should be: customer-facing WiFi is unlikely to be interfaced with airplane flight systems, and even a true jamming attack generating radio interference would be in the WiFi spectrum where radio noise is already expected.

But we repeat: an airplane is an exquisitely bad location for illegal shenanigans.

Steam Hardware Orders Leaked

The European handler of Steam hardware orders, CEVA, was breached in July, exposing customer order information such as phone numbers, and email addresses.

Steam account details were not compromised, but the order information is plenty to arm scammers with enough information to make a convincing phishing attempt. Valve is already explicitly warning impacted customers to expect fake messages pertaining to their orders.

No additional information has been available on how the attack compromised CEVA. It appears this only impacts Steam hardware preorders in Europe.

Zoom Exploit

Zoom, the meeting software, has patched three serious vulnerabilities that would allow members of a call to execute arbitrary code on other members of the call.

CVE-2026-53413 looks to be a typical buffer overflow, where the length of incoming data is not checked properly and overruns the memory space available for it, crashing the Zoom client or potentially allowing code to be executed. CVE-2026-53414 is a closely related buffer size bug, where the buffer allocated is too small for the read operation, crashing the Zoom client. Finally, CVE-2026-53415 is a use-after-free bug, where memory is referenced after it has been released, allowing code execution. The researchers have branded the three vulnerabilities as “Zoomsday”.

The bad news is that Zoom is a high-profile target for business compromise. All platforms are affected, so if you’re on Zoom, time to update before the next call!

AI Agent Hacks a Reservation System

The Australian Broadcasting Corporation reports on an OpenClaw agent finding flaws in the booking system of a gym when asked to make a reservation. Details are relatively thin, with no complete transcript of the interaction with the OpenClaw agent, but supposedly the agent found that the easiest way to make a booking in the full class was to explore the API of the booking site, discovering that the reservation API was protected, but the cancellation API was not.

Within minutes the Claude-backed agent had booked a gym appointment and pushed the user to the top of the list by cancelling other customers. When asked to undo its work, the agent contritely stated that the insertion API was protected and it was impossible, and that it should have performed a test run first before removing users from a live web service.

With so few details available it’s difficult to ascertain how accurate the report is. Claude has certainly been caught overstepping bounds recently, and the AI frontier companies seem happy for the press of declaring they accidentally hacked other companies, so it all seems plausible. This does nothing but increase the confusion about legal liability.

Under almost any jurisdiction, deliberately hacking the reservation system of a company to jump the line would be considered illegal, but when an agent does it, nobody seems concerned, including the user who launched the request: per the ABC article, “It’s not the end of the world, so I didn’t beat myself up about it, but it certainly was a warning signal to use it responsibly.”

United States to Authorize Private Companies for Cyber Operations

After brain-draining existing government cyber agencies like CISA, this week the US Government issued a memo authorizing the National Coordination Center, part of the Department of Homeland Security to use private companies to perform cyber security responses on behalf of the United States.

The memo requires companies to obey the US Constitution and federal law, and requires a one million dollar bond for each company, but still represents a massive change in the posture of the US government with regards to cyber security. Previously, cyber incidents and responses would often by handled by CISA, the US Army Cyber Command, or the NSA. Allowing private companies to respond on behalf of the country feels almost like a return to letters of marque authorizing piracy and freebooting in the 1800s.

LiteLLM Supply Chain

Some weeks ago we mentioned the compromise of the open source supply chain vulnerability scanner, Trivy. Infected with a supply chain worm which steals credentials and infects every package and build it can now access, the worm has continued to spread, now compromising LiteLLM which is an AI proxy and gateway package used by thousands of enterprises.

LiteLLM was infected because they utilized Trivy as part of the automated build workflow, and the compromise was not detected. Once the worm had access to the LiteLLM publishing credentials, it pushed new versions of the LiteLLM packages, of course infected with the same credential, authentication token, and cryptocurrency stealing code. Like the NPM node.js based worms, this code triggered using the Python startup hooks, causing it to execute as soon as Python indexed available libraries, even if the infected libraries themselves were never used.

The firm Hudson Rock was able to obtain the archive of dumped credentials and data, saying it was 153 GB of compressed content. Trivy, in turn, was compromised in March of 2026 after a misconfigured GitHub workflow allowed a pull request to extract authentication keys. The keys were not fully disabled, and the attacker returned weeks later to infect over 50 Trivy packages and workflows.

Analyzing the contents of the stolen data, the list of credentials stolen is staggering, including GitHub and GitLab credentials for Boeing, Orange Telecom, Roku, and multiple government agencies and labs, as well as Slack credentials, SSH keys, and cloud computing access. Hudson Rock has created a site to look up domain to see if your company has been impacted.

Supply chain compromises continue to spread and impact thousands of packages, but the final goal clearly isn’t to simply spread between packages. When high profile heavily used packages are compromised, the stolen tokens will be used to breach the affected companies sooner or later. The various package ecosystems are still struggling to find solutions to poisoned packages that don’t break existing automation processes, and until those are solved, we can expect continual hacks like these to succeed.

Hacking Solar Inverters, Part 2

Recently, unauthenticated flaws over radio were discovered in solar inverter systems popular as “patio solar” installs in Europe. this week, SaiFlow details vulnerabilities in the REST API of FIMER inverters.

Inverters convert between DC and AC current, and optionally between DC and DC for hybrid systems. They are a core part of energy systems that interface solar, battery, and power grids. SaiFlow targeted FIMER inverters because, in their own words, “batteries catch fire” if the system goes wrong badly enough. They found that the inverters are made of several interconnected components, but at the heart is an embedded Linux system built with buildroot, a system framework similar to traditional distributions or a framework like OpenWRT. Due to a misconfiguration in the nginx webserver, API requests can be sent with no authentication at all, and one of the endpoints allows direct injection of commands over a proprietary protocol.

The proprietary protocol, Aurora, predates internet connectivity on the devices, and lacks any modern protection or authentication. SaiFlow discovered that Aurora uses a six-digit PIN, which would be simple to brute force if the function to read the PIN from flash weren’t also available, with no authentication. And the PIN is disabled by default.

Since Aurora was designed as an internal low-level protocol for controlling the hardware, it has access to critical safety features and the ability to override them. The most significant finding was the ability to enable feeding power to the grid, even if the grid is detected as being disabled. This could damage the inverter itself as it tries to power the whole neighborhood, but worse, like a generator plugged in incorrectly, it could electrocute repair workers handling the power lines. SaiFlow points out this could be enabled fully remotely through the unauthenticated web interface. Other exposed commands allow writing arbitrary data to flash, corrupting the unit, changing the country standards, generating incorrect power exported to the grid, and control over charge and discharge rates and battery charge control.

Vulnerabilities in infrastructure components can be difficult to fix, and SaiFlow reports they have received no meaningful response from FIMER months after reporting them. Hopefully effective patches can be developed soon.

17 thoughts on “This Week In Security: BugTraq, AI Hacks, And Being Dumb On Planes

    1. in most cases its not an issue as the inverters are line followign and not giving aka they need the 50Hz signal and follow it, if its not there nothing happens. dunno how much of that is implemented in hardware and how much in software tho – I hope it cant be overwritten somehow (i would expect different hardware is needed for that but theese days you never know…)

    1. It may well be interfaced and sharing the same “broadband” connection to the internet – but taking it offline is very unlikely to affect any useful systems – as it’d be a nightmare to get the avionics or even catering equipment logged into the captive gateway portal…

      Even if any plane systems are using wifi – which I very much doubt as WiFi on planes is relatively new and planes have a very slow approval process (wasn’t that long ago they were still using floppies – search the HaD archives) – they’ll be using a separate hidden network.

    2. I used to do Aircraft Communications Systems: There’s regulation against even having the processors on the same network. They must be physically separated in order to get it approved.. Unless, it’s the corrupt FAA

      1. All the talk is cute, but I recall an incident where it was actually shown that the flight systems were connected to the passenger internet systems in an incident, and can’t recall the details but it was not a while after that Malaysian plane mysteriously went missing, and at around the time too that they were intercepting diplomatic planes in the EU on the suspicion Snowden was onboard.

        That Malaysian plane btw flew right to where there was nothing but ocean. (well except for the military-only island with the large landing strip that was in the area of course, but yeah nothing but ocean basically.)

        Anyway you would expect only an insane set of engineers would have the two system be interfacing in way where you could influence the plane, unless of course there was some secret reason to want to have a way to have someone not part of the crew to have access of course. but we aren’t living on an insane planet with insane secret insanity are we? Nope.
        I for one am pleased that at least on this planet, with its flaws, rationality is the moto and guiding principle still, as it has always been.

  1. We rapidly need to establish culpability for AIs doing bad things.

    I’m inclined to say whether it’s the user or AI company depends on whether a “reasonable man” would expect malicious behaviour from the prompt.

    If I hire an uber to get me to the hospital ASAP, I’d not be liable for any road laws the driver breaks. Whereas if I ask him to deliver a package (containing drugs), it’s me who’s liable.

      1. Not bad, if the law for pet attacks is that you’re always liable 100% of the time.

        The precedent from the Air Canada case is that if your AI says it, your company said it.

        But that was back in the naive days before we were giving the things car keys. I propose the extension: if it’s running on API keys that you gave it, you did it.

        1. How would that be fair in a case like the gym booking? If they just asked the agent to book a gym slot (without specifying “by any means necessary”) and it decided to do the hacking rather than reporting back that the gym was already fully booked then I’d say culpability falls back on the AI company for an unsafe product. We can’t just let the AI providers wash their hands of any and all responsibility.

          I think Dan’s “reasonable person” test would seem the better choice. That said I remember a case not too long ago where Duracell managed to convince a court that a “reasonable person” wouldn’t expect a battery to not leak before it’s expiry date, so I can’t see the law being any real help even if it looks like the right idea. For now I think the current system of whoever’s poorer is to blame is likely to prevail, and as we all know the AI industry is currently pretty flush with cash. Maybe after the impending financial crash we’ll actually be able to get a decent handle on this culpability problem.

          1. I think it’s multifaceted, and a key point to note is that the gym hacking AI here was owned and instructed by the AI company owner himself. I suspect it could just be a marketing stunt.

            To continue the analogy of dogs, the AI companies almost have the role of breeder and trainer. A dog owner is still responsible if they tell their unleashed dog “fetch” but it ends up with a small child in it’s jaws, even if they paid for professional dog training.

            In the AI case the operator/dog owner was not responsible for the training at all, but maybe there should be an analog to muzzling/leash laws: if you’re responsible for launching an autonomous system with the ability to break laws, then you’re also responsible for risk mitigation and oversight.

            See the restrictions on XL Bullies in the UK, a dog breed where the main selection criteria was aggression, brutish appearance and physical bulk/raw strength, and to make it worse most examples come from an ancestry with multiple inbreeding loops including a specific dog which had a human kill count of 2.
            I guess the AI equivalent would be Mythos with guardrails removed, or for local usage a heretic or abiltterated model.

  2. The Australian Broadcasting Corporation has no credibility at all and has, on more than one occasion, acted criminally by actually fabricating evidence, changing the soundtrack on videos etc. They are bad eggs, never use them as a source.

  3. Call me a filthy casual but denial of service using “legitimate” packets or whatever other means still counts as jamming since the end result is the same.

    Just so long as they didn’t give them the raspberry.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.