This Week In Security: What’s In A Name, The AI Bugpocalypse Hits Everyone, OpenWRT Flaws, And Duress Passwords

The great thing about standards is there’s so many to pick from, right?. (Insert obligatory XKCD #927 here.) Several companies have developed naming schemes to refer to groups of attacks, and now Google has too.

Sometimes, malware, ransomware, or exploit groups name themselves: “Shinyhunters”, “LapSus$”, “Cl0p”, “Lockbit”, and so on. For the groups that don’t advertise their presence, identification and naming can be more difficult. Mostly state-run affairs that didn’t want to draw attention to themselves, these Advanced Persistent Threats (APT) groups were originally simply given numbers. APT28 refers to the Russian GRU Intelligence Directorate suspected of hacking the Democratic Party email servers, APT38 is a North Korean governmental agency involved in financial and crypto currency theft.

Multiple companies and agencies have developed naming schemes to make referring to threat groups easier, typically including a regional identifier as well. CrowdStrike naming uses name groups like “Bear” group for suspected Russian actors, “Panda” for China, “Spider” for unattributed crime groups, while Microsoft uses “Blizzard”, “Typhoon”, and “Tempest”.

Google, deciding there weren’t enough classifications already, now introduces “RELIC”, “CASTLE”, and “COMET”. Of course, each naming organization has dozens of other classification groups as well, but now the next time you hear about an attack being attributed to “Scattered Spider” you know it’s the CrowdStrike name for a crime group.

Critical OpenWRT DHCP Flaw Fixed

The Hacker News reports on a major release of OpenWRT which includes fixes to the odhcpd server, the embedded DHCPv4 and DHCPv6 server written by OpenWRT.

The bug is a straight-forward stack style attack where a buffer is allocated, but not length-checked against the data required to reply to a malformed request. OpenWRT runs on a wide range of devices, but one of the most popular legacy platforms still in use, the MIPS processor architecture, lacks most modern security protections against stack-based attacks, making this attack sting more than it might on other architectures.

The latest OpenWRT releases also fix issues in the uhttpd embedded web server, multiple issues in the LUCI web configuration interface that allowed attackers to inject cross-site scripting content and Linux kernel security fixes. If you run a direct OpenWRT build on your equipment, update! These bugs will have an extremely long tail however, with tens of thousands, or likely more, OpenWRT-based devices that will never see updates.

The company behind several of the findings, Hacker House, say they used multiple AI tools and both open and frontier models to discover the bugs, then manual review and testing to confirm before reporting.

Cisco to Stop Assigning (some) CVEs

Cisco has announced it is moving to a twice-monthly patch cycle. Additionally, Cisco will no longer assign CVEs to each bug in the release.

Cisco says this is in reaction to the rapid increase in bugs found by AI tools, and that “Assessing security risk CVE-by-CVE and applying point mitigations is no longer fit for purpose.” Cisco will still assign a CVE to a bug that “requires compensating controls” or is known to be exploited.

It seems like it will be business as usual for the most severe bugs, but it will be interesting to see what happens when exploits are found for bugs which did not get a CVE in a prior release.

Microsoft Suggests Three-Day Patch Race

Microsoft is now recommending a 3 day patch window for new patches. This is, to say the least, an “aggressive” schedule for applying new patches, given the recent track record of issues introduced by patches.

A update that crashes is inconvenient on a home computer — even more so if it’s your parent’s computer — but could be catastrophic when it brings down an entire corporate fleet. Most large organizations have their own internal patch schedules and internal testing requirements before patches are deployed, delaying the patch process further.

Systems like the CISA KEV database, a list of vulnerabilities known to be actively exploited, are in place to help identify the most important issues. With repeated record-breaking numbers of vulnerabilities pushed in Patch Tuesday and the decreasing support of the KEV and related vulnerability indexing systems, the load on IT departments and administrators is becoming impossible.

The AI “bugpocalypse” is finding record numbers of vulnerabilities, while also closing the timeline between bug to exploit to hours in some cases. The time between bug and exploit then drives the patch cycle, which means less testing. With less testing, the patches are less stable, leading to less trust in rapidly installing them.

Oracle Patches Almost 1500 CVEs

Moving directly from the impacts of the flood of Microsoft security issues, the July 2026 patch set from Oracle included fixes for 1499 security issues and 1434 CVEs over 334 Oracle products.

Oracle is also pressuring administrators to move to a monthly patch cycle, but acknowledges “transitioning to a monthly security patching cadence may require updates to existing operational processes”. Not to worry – there is a Oracle consulting service you can hire to help you patch your Oracle problems.

Linux Patches 323 CVEs in Two Days

After announcing over 400 CVEs in the Linux kernel last week, Linux mainters have announced an additional 323 in the last three days alone. The vulnerabilities cover Bluetooth, Ethernet, USB gadget mode, WiFi drivers, virtualization systems, SMB file sharing, and of course more.

One benefit to the architecture of the Linux kernel is that typically all the fixes will arrive in a single kernel update, but when almost every week brings critical updates and a new kernel, patch fatigue is a real thing. Either users stop applying every update, or the uptime and testing requirements of a company prohibits constantly updating and changing servers.

Duress Passwords Aren’t Necessarily a Good Thing

The security-hardened Android variant Graphene, is in the news this week for the use of duress passwords.

A duress password is a mechanism where a second PIN or password can be used to initiate a device wipe. The hope is that in a situation where you are compelled to unlock a device, providing a password which then wipes the device is a preferable option.

The legality of a duress password depends on the environment it is used in. The United States Customs and Border Patrol claims that by wiping a device during an inspection at the US border, Samuel Tunick destroyed evidence and property in violation of federal laws. The issue is compounded because the stop happened at a border, where many US laws against search, seizure, and the availability of a lawyer are suspended, even for US citizens.

The inclusion of duress passwords, and their cousin hidden encrypted volumes, can sound like a good idea, but can place users in serious danger when in situations with less strict rules of law. Having the ability to wipe data sounds great in isolation, but protestors, human rights workers, and other targeted groups have faced direct and physical threats under some regimes. Facing retaliation for wiping a device, or facing physical violence before providing an unlock code out of fear that it might wipe a device, can be a real risk for some.

FreeBSD Fixes a WireGuard Bug

FreeBSD has issued a security update pertaining to the WireGuard VPN implementation.

WireGuard is a modern VPN with excellent performance even on low-end systems, and which has implementations on basically every platform. The FreeBSD implementation, however, didn’t fully validate VPN packets, accepting packets without checking one of the cryptographic validation measures.

Attackers are able to inject data to a FreeBSD WireGuard implementation if they are able to guess some attributes of the connection, and able to fully modify the data in the VPN if they are able to intercept the packets.

The bug impacts any FreeBSD user of WireGuard. FreeBSD has released updated kernels.

This Week In Security: AI Is A Mess, Hacking Car Chargers, An OpenSSL DoS, And Factories Under Attack

[Ayush Paul] posts about extracting data from Claude agents while it accesses web data to fulfill user requests.

But it wasn’t that easy. [Ayush] discovered that Anthropic anticipated many of the attacks, and set up guardrails in an attempt to keep the agent from accessing arbitrary web sites. For Claude to access a website, the user has to specify it, it must be the results of a web search, or it must be referenced by a website previously specified by the user or returned in a search.

To convince the Claude agent to navigate a malicious site designed to extract data, Ayush formed a false warning that Cloudflare was blocking the agent for authentication purposes, and asked it to spell out the name of the agents owner by clicking a list of alphabetical links. Of course Claude trusts Cloudflare and wants to be helpful, so it cheerfully completed the task.

Once the agent is trapped in the false authentication loop, it can be interrogated for all sorts of information it knows about the owner: Ayush was able to convince it to disclose employer, and even data about the user that could be linked to security questions, like their home town.

Since Claude can be detected by the user agent (the field attached to web requests that tells the web server what sort of browser is requesting the page) custom information can be fed to the bot while users see a normal website; clicking a link looks completely normal, but asking an agent to summarize the site triggers fooling the bot into spilling the beans.

After reporting the issue, Ayush was told that Anthropic had already identified the issue internally, and eventually prevented the attack for now by preventing the agent from following links on external pages.

Grok sends entire codebases

Cereblab discovered that the Grok coding agent uploaded the entire content of the codebase it’s working with – and all Git history – to xAI servers, almost immediately. Even when told to never upload a file, the agent would reply “OK”, and then begin uploading the code bundle anyway.

If uploading your code to a remote server isn’t bad enough, and this could be extremely bad in some situations involving sensitive company code, including the entire Git history means that previously deleted files, like accidentally committed secrets or authentication credentials and tokens, were also leaked. Attempting to opt out by disabling options to improve the model by uploading code had no effect.

After gaining attention, Grok has added a privacy option to opt out of data retention. xAI has committed to deleting the retained uploaded code, but it is unclear if users will be told when their data has been removed. To actually prevent the agent from uploading local files to the xAI servers, even temporarily, a global flag “disable_codebase_upload” is required. Watch out, the privacy retention flags are only per-session!

Continue reading “This Week In Security: AI Is A Mess, Hacking Car Chargers, An OpenSSL DoS, And Factories Under Attack”

This Week In Security: The Supply Chain Has Problems

The biggest story of the week is a new massive supply chain breach, which appears to be unrelated to the previous massive supply chain breaches, this time of the Axios HTTP project.

Axios was created as a more developer-friendly Javascript HTTP interface for node.js, giving a promise-based API instead of the basic callback API. (Promise-based programming allows for simpler coding workflows, where a program can wait for a promise to be fulfilled, instead of the developer having to manage the state of every request manually.) Javascript has since provided a modern Fetch API that provides similar functionality, but Axios remains one of the most popular packages on the node.js NPM repository, with 100 million weekly downloads.

The lead developer of Axios believes he was compromised by a collaboration request – a common tactic for phishing specific targets: a project for an IDE like VS Code can include code that executes on the developers system when the project is run. Even outside a traditional IDE, common development tools like configure scripts and makefiles can easily run commands.

Socket.dev breaks down the attack in detail. Once the attackers had credentials to publish to the Axios NPM, they inserted malware as a new dependency to Axios, instead of modifying Axios itself. This likely helped the attack bypass other security checkers. The dependency – plain-crypto-js – is itself simply a copy of a popular encryption utility library, but one which executes additional code during the post-installation process available to all NPM packages. Continue reading “This Week In Security: The Supply Chain Has Problems”

This Week In Security: Cisco, Mitel, And AI False Flags

There’s a trend recently, of big-name security appliances getting used in state-sponsored attacks. It looks like Cisco is the latest victim, based on a report by their own Talos Intelligence.

This particular attack has a couple of components, and abuses a couple of vulnerabilities, though the odd thing about this one is that the initial access is still unknown. The first part of the infection is Line Dancer, a memory-only element that disables the system log, leaks the system config, captures packets and more. A couple of the more devious steps are taken, like replacing the crash dump process with a reboot, to keep the in-memory malware secret. And finally, the resident installs a backdoor in the VPN service.

There is a second element, Line Runner, that uses a vulnerability to arbitrary code from disk on startup, and then installs itself onto the device. That one is a long term command and control element, and seems to only get installed on targeted devices. The Talos blog makes a rather vague mention of a 32-byte token that gets pattern-matched, to determine an extra infection step. It may be that Line Runner only gets permanently installed on certain units, or some other particularly fun action is taken.

Fixes for the vulnerabilities that allowed for persistence are available, but again, the initial vector is still unknown. There’s a vulnerability that just got fixed, that could have been such a vulnerability. CVE-2024-20295 allows an authenticated user with read-only privileges perform a command injection as root. Proof of Concept code is out in the wild for this one, but so far there’s no evidence it was used in any attacks, including the one above. Continue reading “This Week In Security: Cisco, Mitel, And AI False Flags”

This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!

Google Chrome has done a lot of work on JavaScript performance, pushing the V8 engine to more and more impressive feats. Recently, that optimization has one more piece, the Maglev compiler, which sits between Sparkplug and TurboFan, as a mid-tier optimization step. With a Just In Time (JIT) system, the time saving of code optimization steps has to be carefully weighed against the time costs, and Maglev is another tool in that endless hunt for speed. And with anything this complicated, there’s the occasional flaw found in the system. And of course, because we’re talking about it here, it’s a security vulnerability that results in Remote Code Execution (RCE).

The trick is to use Maglev’s optimization against it. Set up a pair of classes, such that B extends A. Calling new B() results in an attempt to use the constructor from A. Which works, because the compiler checks to make sure that the constructors match before doing so. There’s another way to call a constructor in JS, something like Reflect.construct(B, [], Array);. This calls the B constructor, but indicates that the constructor should return an Array object. You may notice, there’s no array in the A class below. Tricking the compiler into using the parent class constructor in this fashion results in the array being uninitialized, and whatever happens to be in memory will set the length of the array. Continue reading “This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!”

A modchip described in the article - a small PCB with an epoxy blob on it, soldered to the Cisco switch PCB using four thin wires

Counterfeit Cisco Hardware Bypasses Security Checks With Modchips

Some pictures recently surfaced on social media, showing a small PCB tapped into four points on Cisco-branded boards. What is this about? A NSA backdoor so data can be exfiltrated to some third party? Well, that’s theoretically possible, but it’s actually used for bypassing hardware authenticity checks in Cisco hardware being cloned — a sizable industry. Of course, “can’t believe it’s not Cisco” hardware is only valuable insofar that it’s able to run the Cisco software, and that’s where the bodge boards play a major role.

An unidentified IC on the a different counterfeit Cisco board, with markings soldered offA 2020 report by F-Secure details an investigation, comparing three switches marked as Cisco 2960X – one known genuine and two known counterfeits. The counterfeits had the aforementioned implants either soldered to the bottom of the PCB or added to the board as a separate component, and the paper goes into why they’re important for successful counterfeiting.

Apparently, these chips emulate or bypass an I2C EEPROM containing part of the code executed during the boot sequence, and Cisco depends on this EEPROM’s contents for authenticity verification. Cisco software reads the EEPROM twice — once for verification, and once again for actually running it. The microcontroller included on the mod board can return a genuine binary with a valid signature on the first read, and a binary with hardware checks patched out for subsequent reads.

The paper will tell you about way more than this — it’s thorough yet captivating. As you’d expect, it devotes quite a bit of time to comparing genuine and counterfeit boards, showing that the cloning process is pretty to-the-T, save for some part substitutions. For instance, check out the PDF page 12 to see how via locations are exactly copied between PCBs in a bizarre way, or the Cisco file format and authenticity check analysis closer to the end of the report. All in all, the 38 pages of the document make for a fun foray into what makes Cisco authentication mechanisms tick, and what helps clone hardware makers bypass them.

Are such chips ever used for adding backdoors and data exfiltration? There’s no evidence of that, as much as that’s not to be excluded — bypassing anti-cloning protections would make other hijinks more viable no doubt, that said, only hardware authentication bypass measures were found so far. This mechanism also breaks during software updates, and absolutely, leaves some to be desired when it comes to its stated functionality. That said, such fun insights can help us, say, enforce right-to-repair, enable hardware reuse, and thwart many predatory business practices in areas where laws fail us.

The Meraki AP PCB on a desk, case-less, with three USB-UARTs connected to its pins - one for interacting with the device, and two for monitoring both of the UART data lines.

Flashing Booby-Trapped Cisco AP With OpenWrt, The Hard Way

Certain manufacturers seriously dislike open-source firmware for their devices, and this particular hack deals with quite extreme anti-hobbyist measures. The Meraki MR33, made by Cisco, is a nice access point hardware-wise, and running OpenWrt on it is wonderful – if not for the Cisco’s malicious decision to permanently brick the CPU as soon as you enter Uboot through the serial port. This AP seems to be part of a “hardware as a service” offering, and the booby-trapped Uboot was rolled out by an OTA update some time after the OpenWrt port got published.

There’s an older Uboot version available out there, but you can’t quite roll back to it and up to a certain point, there was only a JTAG downgrade path noted on the wiki – with its full description consisting of a “FIXME: describe the process” tag. Our hacker, an anonymous user from the [SagaciousSuricata] blog, decided to go a different way — lifting, dumping and modifying the onboard flash in order to downgrade the bootloader, and guides us through the entire process. There’s quite a few notable things about this hack, like use of Nix package manager to get Python 2.7 on an OS which long abandoned it, and a tip about a workable lightweight TFTP server for such work, but the flash chip part caught our eye.

The flash chip is in TSOP48 package and uses a parallel interface, and an iMX6.LL devboard was used to read, modify and flash back the image — hotswapping the chip, much like we used to do with old parallel-interface BIOS chips. We especially liked the use of FFC cables and connectors for connecting the flash chip to the devboard in a way that allows hotswapping – now that we can see it, the TSOP 0.5 mm pitch and 0.5 mm FFC hardware are a match made in heaven. This hack, of course, will fit many TSOP48-equipped devices, and it’s nice to have a toolkit for it in case you don’t have a programmer handy.

In the end, the AP got a new lease of life, now governed by its owner as opposed to Cisco’s whims. This is a handy tutorial for anyone facing a parallel-flash-equipped device where the only way appears to be the hard way, and we’re glad to see hackers getting comfortable facing such challenges, whether it’s parallel flash, JTAG or power glitching. After all, it’s great when your devices can run an OS entirely under your control – it’s historically been that you get way more features that way, but it’s also that the manufacturer can’t pull the rug from under your feet like Amazon did with its Fire TV boxes.

We thank [WifiCable] for sharing this with us!

(Ed Note: Changed instances of “OpenWRT” to “OpenWrt”.)