Shut Down KiteWorks Servers on September 26; Coding Agents Vulnerable to Plugin Supply Chain Attack; Ubuntu Kernel Releases Will be More Frequent

Kudos to KiteWorks for sharing the threat information, and this guidance from them is a bit of a gamble. Because they don't know what the attempted exploit will be, they are advising the shutdown regardless of version, network architecture, or security measures. Color me skeptical, but given the scope of the warning, there is nothing stopping the attackers from expediting (or delaying) and attacking outside the identified window. For now, make sure that you're on the current KiteWorks, and you've got your MFA/DDoS/WAF protections and monitoring dialed in and active regardless of your decision to shut down as advised. Fingers crossed that this is a non-event.

Oh my. You don’t see this every day. When a vendor receives credible law-enforcement intelligence indicating an attack may be imminent and tells every customer worldwide to shut down its systems for six hours, including systems that aren't Internet-facing, this is not the weekend to debate whether your particular deployment is "probably safe." Follow the vendor guidance. I echo Lee Neely in hoping this turns out to be a non-event, but we shall see. More broadly, this is a powerful reminder that resilience sometimes means being able to intentionally take a service offline. If six hours of planned downtime is unacceptable to your organization, imagine an attacker choosing the downtime for you. This is what threat intelligence is supposed to do: change defensive behavior before an attack happens.

The last time I remember seeing something like this was Drupalgeddon. If the company has forward awareness of a forthcoming attack because of a vulnerability, it must be very trivial to exploit. My question is why there’s a time window of exposure and not a “shutdown by” timeline. This one has me scratching my head; what does this company know that we are missing? If you are a customer of this product, and I would imagine that, given its age, it's probably going to be a fair number of large customers, this one is one that I would imagine I would be alerting folks on.

The only mitigation for this is to update your agents — the fix has to be in the agent. Make sure that your team has updated their Claude Code or Codex to the current version and migrated to Antigravity where used. With the newness of our AI agents, updating to current versions and technology is something we all need to get our arms around. Make sure you're properly considering the risks of AI tools in use and govern them accordingly.

Most of us now run coding agents with plugins and skills, some of which we even forget we've enabled unless we're doing periodic hygiene. I try to follow my own advice here and periodically have Claude audit its own configuration. This raises the issue that AI plugins and skills are now a patch & hygiene management surface similar to browser extensions, IDE extensions, etc. You've heard me discuss placing the onus of responsibility on developers and software vendors to provide safe auto-updates, but “safe” is the key word. In this scenario, auto-update enabled the zero-click RCE. The agent asks Git for a specific commit; Git hands back an attacker's branch that shares the same name. Before the fixes, none of the four agents checked what actually got installed. If you pull plugins from a self-hosted git or Bitbucket instance, that could expose you. These same researchers previously got a harmless test plugin onto more than 26,000 agents through normal adoption, so I wouldn't file this under “purely theoretical.” What can you do? Do the same things as always: update where you can, evaluate auto-update settings for untrusted sources, and actually inventory the agents, plugins, and skills present in your environment. Inventorying these assets is difficult. Tooling is emerging to help, but I've seen very few organizations mature enough to manage this today, and none who truly have a complete handle on it. Last month I said browser extension inventory has been a necessary asset category for years, and agent plugins belong right next to it.

Pinning a plugin to a hash is supposed to mean, "Run exactly this reviewed code." If the agent records the hash but never verifies that the code it fetched actually matches it, the integrity control isn’t doing its job. A hash that isn't verified is merely decoration. We actually see this in our penetration testing projects rather often, where systems dutifully pass hashes or digital signatures around, but the receiving system fails to check them. Such an oversight is worse than worthless due to the false sense of security it provides. Coding agents make this especially dangerous because their plugins may inherit access to source code, credentials, build tools, and the ability to execute code. Treat the plugin resolution and update path as part of your software supply chain.

A good reminder that any use of AI by enterprises has to plan for continual patching as just one element making AI safe to use.

Consider this an impact of the increased number of vulnerabilities discovered and addressed. The trick will be finding a cadence for your Ubuntu users that isn't overly disruptive. Canonical is committing to those frequently updated kernels tested and certified, for the YOLO user hanging on the leading edge of releases. Even so, they are offering an option for users to do their own kernel acceptance testing, if you really need assurances or have need for expedited updates. This may be a time to consider using the LTS Ubuntu versions for increased stability.

Expect more vendors to adopt hyper-fast release cycles, as browsers have for years. I think it'll be this way for some time to balance security with stability.

I'll admit I got a little excited about this one. I've been saying for most of 2026 that vendors need to architect for seamless upgrades and micro patches, and that the mega patch dumps we're seeing were a sign that vendors were using AI-assisted testing for good. This feels like the next step: once the backlog is out the door, fixes should arrive in a steady stream instead of a periodic flood. To be fair, Canonical hasn't said each weekly kernel will be smaller, only that releases will come faster. But if the volume of fixes holds steady and you ship weekly instead of every two to four weeks, each release carries less — more “micro patches” — and each one still goes through the full two weeks of certification and regression testing. Smaller changes should be easier to test, easier to trust, and easier to back out when something breaks. Here's my worry, though. None of that helps if your change management process still runs monthly. Canonical is offering early access to release candidates for teams that want to move faster, plus workarounds within 24 to 48 hours of disclosure, but somebody on your side has to actually pick those up, and kernel updates still mean reboots unless you're live patching. So here’s a question for anyone running big Linux fleets: If a kernel fix shipped this Friday, when would it actually be running in production? If the honest answer is “sometime in the next 90 days when we have a reboot window,” then the advances of AI-enabled development and testing and the faster cadence isn't buying defenders and vuln management teams much yet. What would it take for your organization to deploy smaller changes faster, with confidence?

AI is enabling bad guys and good guys to find vulnerabilities faster — we need to see similar advances in IT ops ability to test and deploy patches faster.

While this is a security win driven by frontier model code analysis tools, it raises a major operational concern: Can organizations keep up with a higher volume of kernel releases? Given historical struggles with monthly patching, traditional methods fall short. The entire patch management framework needs a paradigm shift toward continuous automation, akin to how browsers update.

All Linux distributions are not equal.

As noted previously, three-day KEV deadlines are becoming really common. Consider this a reflection of the current threat environment rather than anything negative or sinister. You should already be tracking these, as most have updates that you're already working on. Consider subscribing to CISA's KEV notices so you get the alerts sooner than later.

Is it just me, or is this turning into a record year for KEV catalog additions? Either way, it's a loud wake-up call for information security teams to double down on patch management and automate as much of the process as possible. Between the sheer volume of entries and those shrinking mitigation windows, CISA is clearly sending a strong signal.

Pshew… there's a whole lotta high CVSS scores here. A couple of weeks ago in NewsBites, I wrote that "Unknown" in KEV's ransomware-use field means exactly that: _Unknown_, not _No_. Here's a nice illustration. TeamCity CVE-2026-63077 was added to KEV on August 5 because exploitation was already confirmed. Only now has the ransomware-use field been updated to Known. The lesson isn't that KEV somehow predicted ransomware. It's that confirmed exploitation was already enough reason to act. Don't wait for the retrospective label, especially if mission-critical systems are involved.

The three-day mitigation window is becoming the default. This would be consistent with the observation that CISA wants to focus its intelligence on things that really require timely action.

The whitepaper is four pages and really lays out the issues, challenges and opportunities. The next steps lie in CISA's coordination with the CVE working groups. While I'd like a more specific plan, given the time of year, it's unlikely they have their budget settled for FY27 and are hedging their bets accordingly. You can get information or join a working group by visiting the "Contacting the CVE Program" web page.

While CISA's white paper is a solid first step, the focus must shift to implementing its four quality dimensions. This requires reconciling CISA's proposed FY2027 budget cuts with upcoming congressional appropriations. Frameworks are helpful, but funding is what turns policy into action.

The CVE system is a bit broken right now, and fixing it will require more industry scrutiny. I am not sure how we get to a point where CVE is more useful, but right now we are seeing a breakdown in the overall program. A single Microsoft Patch Tuesday in 2026 would account for a large percentage of the bugs found in 2024.

Moses is right that the CVE ecosystem is under real strain. The identifier itself is only the beginning; CVE records have become foundational input to vulnerability management tools and processes throughout the industry, including the nascent VulnOps capabilities organizations are starting to develop. If those records are incomplete, inconsistent, or late, every downstream system inherits that uncertainty. CISA's quality dimensions make sense to me. The real test will be whether they measurably improve enrichment speed and record quality at scale.

The rapid increase in reported vulnerabilities increases the need to focus on those that are known to be actively exploited.

The extortion demand here speaks to how cybercrime continues to resemble legitimate business, right down to brand management: ShinyHunters isn't asking for money (at least not publicly). They're asking the FBI to take down a PSA they don't like and makes them look bad (laughable — they're _criminals_, of course they look bad). Back in August I wrote about LockBit's “pirate's code,” and this is in the same theme. The PSA in question is about attacks on learning management systems, and describes the group harassing victims and their family members with threatening calls, texts, and in some cases swatting. That said, threatening to publish FBI agents' home addresses and their spouses' information is a strange way to argue you've been mischaracterized as a villain. The long tail here is the risk of the data being sold to people with far more patience and nefarious interests than ShinyHunters themselves. That said, groups like this often overblow their claims; the PSA in question even warns that this group uses "real or exaggerated claims of access" to pressure victims, so take the scale claims with a grain of salt until they are confirmed. If you run HR or recruiting platforms, where are they in your tabletops (you ARE running regular tabletops, right)? What could an adversary do to your business, reputation, or employee and customer trust with that data? Employee and applicant home addresses are the kind of data that turns a breach into a physical safety problem for people and their families, especially in sensitive industries aligned against these groups (security, law enforcement, research, victim advocacy). Who can pull that data in bulk today, and would you know if they did?

This feels like ShinyHunters got upset and found a weakness in the FBI's jobs site. Take this as a reminder to have consistent security across your sites, especially those with sensitive information. Even more so where you've outsourced a service or function. The onboarding process needs to include a validation of security settings, to include sign-off and regular verification the configuration hasn't drifted.

While it is a poor look for an organization known for cyber best practices, this incident highlights the need to audit third-party vendors. Since external support providers are effectively part of your cybersecurity ecosystem, they must be held to the same internal control standards.

Astrana is a healthcare management company that provides back-office services, including claims and billing. This is another social engineering attack, this time using fake Caller-ID to fool people into thinking the call was from the company itself. Two thoughts here: First, remind people to not assume the calls are coming from the identified number, and when in doubt call the known number (not one provided by the caller); and secondly, move away from reusable credentials. For extra credit, make sure you're actively monitoring and retiring user accounts, both for remote and system/application access.

This TTP isn't new and has become a go-to entry point over the last two years. Think about how much implicit trust we place in an internal number showing up on caller ID. I've said before that changes like MFA resets need an out-of-band callback, but those callbacks must go to a number _you_ already know, because an inbound call that appears to be from your own company proves nothing. STIR/SHAKEN (https://www.fcc.gov/call-authentication) was supposed to help, but the attestation rarely reaches the person answering the phone, and I'd like to see the FCC push further. The response actions also include “restricting remote access tools,” which I'd read as a hint that someone may have been talked into letting “IT” connect to their machine. If you don't already allowlist remote access tools with JIT access and auditing, and alert on new ones appearing, add this to your list. Some caveats: no ransomware has been confirmed, no group has claimed this, and restoring from clean backups is standard practice after any compromise, so don't read too much into that line yet. It is still undetermined what data was taken. This is also the fourth healthcare story I've commented on in about a month, after CareCloud, SickKids, and Boston Scientific. So here's my question for healthcare security teams: I know you're dealing with challenging environments where patient safety is paramount and tech modernization is often underfunded, but how are we doing on security awareness and security culture? How many of your employees would challenge a call that appears to come from your organization's main phone number? If we can't entirely block the access (RMM tools and spoofed phone numbers), what are we doing to build awareness and focus additional logging and hardening from a threat-informed-defense perspective?

The filing confirms it was a phishing attack, but we still don't know which controls failed to stop it. Astrana handled the incident about as well as expected. Since AI is making phishing more believable every day, someone getting tricked is practically bound to happen. Instead of trying to prevent every human error, the focus needs to be on solid cybersecurity basics, especially patch and configuration management.

It's pretty brazen for the attackers to use social engineering the way they did, but as I am thinking about it, with the way that AI is going, I suspect that we will see a dramatic increase in this, much more so than is expected.

I'm seeing an uptick in voice-based phishing attacks with the organizations and people I work with. Several reasons for this: First, after years of training, people are getting better at spotting and reporting phishing email attacks, so attackers have shifted to a modality that people may not be as trained on. Second, when you get someone on the phone, most security teams do not have visibility or control of those devices, so people are more vulnerable. Third, it's much easier to channel emotion in a phone call versus an email, making calls more effective. Finally, AI introduces a whole new attack method with Voice Cloning, now easy to do and very effective. These voice-based attacks will only increase in frequency and sophistication for the simple reason that they work.

All processes, digital and human, that face the public networks, Internet, POTS and even the postal system, are part of the attack surface and must be managed accordingly. Greed, lust, sloth, curiosity, urgency, and even good intentions are fundamental, persistent, and pervasive vulnerabilities.

Given the scope of the incident, this doesn't come as much of a surprise. Here’s the thing: It's likely IDScan is still heads-down in their own investigation and recovery. Consider how you would handle supporting the outside investigation without derailing your existing effort if you were in their shoes. Decide how much you want to disclose before your actions are finalized. Enlist legal counsel in this plan, as this isn't the sort of outside investigation you can dismiss.

It would have been reasonable for IDScan to use the credentials that it verified to refine its algorithm. To retain them, not so much. Reckless. The lesson for the rest of us is that if one does not retain it, one cannot leak it.