Unfixed Claude Security Issues; Chainalysis Data Compromised; DigiCert Data Exposed for 16 Months

What jumps out at me across these three findings is how seemingly innocent convenience features can introduce unexpected security weaknesses. A browser session that can instruct a desktop agent, a "don't ask again" setting that saves commands containing secrets, and helper scripts that trust predictable file paths all create opportunities for attackers. Now consider how these weaknesses might be chained together with others. As we build increasingly complex systems, the spiderweb of potential attack paths grows enormously, with vulnerabilities and trust relationships connecting in ways their developers never anticipated. AI is becoming particularly adept at exploring these combinations and discovering paths through them. That's a powerful capability for defenders, but also a concerning opportunity for attackers. We need to evaluate AI agents and their surrounding infrastructure as complete systems, tracing the paths from untrusted inputs through permissions, tools, and privileged actions. The security of the individual components is only part of the picture.

I can see multiple reactions to this one — from "physician, heal thyself," thinking of how we're using AI to find and resolve vulnerabilities, to a question (given how much we've embedded/incorporated AI) of how we keep responding and securing it when issues are found. We all should have an inventory of our agents, tracking which accounts they use and what they can access. Then restrict the access to only that which is necessary. Sure, things work better with full admin and access, but we've all seen that movie before. Give some thought to how these are authorized, and perhaps to automation in general. Make sure you're monitoring agent behavior to ensure they are doing what is intended. Once you have all this in place, you're going to have to set up a review cycle. Scope creep happens; rather than labelling that good or bad, just stay on top of it, and use as an indication that something changed and something cool is afoot.

I am a bit saddened to see this. Frankly, I believe, as do some others, that frontier AI labs like Anthropic, Google, and OpenAI are closest to being able to essentially "fixing all security bugs" in their code. This situation casts serious doubt on that for me. Still, I remain optimistic that in the longer run, AI will produce code largely free of traditional software vulnerabilities. Yes, this is a contentious take, and these specific vulnerabilities make it very hard to believe this or, at least, make me redefine what "in the long run" actually means.

This shows that AI tools are being released with significant gaps in security controls and obviously insufficient testing before release. This gets exponentially more dangerous when insecure AI tools are used to create more AI tools.

Anthropic's point holds some weight. The attack vector relies on a malicious browser extension, which is a risk well documented in OWASP's browser extension security vulnerabilities cheat sheet. However, granting an AI agent local command execution requires rigorous defensive controls. By failing to insulate the system against browser-level threats, Anthropic ultimately misses the mark on secure-by-design principles.

It should be clear to all by now, these products are not "secure by design" nor "safe out of the box." Even their authors do not know how to use them safely. The lesson for the rest of us is that they should be used sparingly and cautiously.

Another nail in the reusable credentials coffin. AI is helping attackers in many ways, the net effect of which is reusable credentials being successfully harvested. Traditionally the push-back on MFA was one of inconvenience; I'm not so sure that dog will hunt anymore. Cleanup, rotating credentials, and other recovery activities are far more intrusive than modern phishing resistant MFA. Carefully challenge pushback on MFA, and make sure that current reality — versus hearsay or past history — is considered. Never assume the C-Suite is in opposition; I'm finding they are more often ready to lead the charge as they have considerable skin in the game when it comes to the company and its stability/viability.

This is a good reminder about the importance of API security, both in internal apps and as part of supply chain security.

We often focus on data being leaked or destroyed. A more dangerous and subtle effect of a compromise is the manipulation of data. Chainalysis offers cryptocurrency intelligence, which is particularly susceptible to these types of attacks.

This is another fascinating example of how multiple security weaknesses can combine to create a serious vulnerability. An internal system was moved from a VPN-restricted environment to an externally accessible one. That exposed a self-registration feature inherited from software used elsewhere, and a separate authorization flaw allowed newly created accounts to access archived customer information. Each weakness contributed to the problem, but chaining them together created the path to sensitive data. We've seen attackers combine vulnerabilities for decades, but the growing complexity of our systems creates an enormous number of potential combinations. And AI can help identify these chains far more systematically than traditional manual analysis. For defenders, this means evaluating security across the entire environment, particularly when migrating systems or changing their configurations. Test whether combinations of weaknesses allow access that no individual control was intended to permit. Importantly, DigiCert reports that the system was exposed for approximately 16 months, but confirmed unauthorized data access occurred during a much shorter period, from June 27 through July 2, 2026.

As you move access controls, perhaps you've decided to implement Zero Trust, or otherwise retire your VPN — it's imperative to test the access is still restricted. Zero Trust isn't just about ‘no more VPN,’ it's about device and user authentication/validation, where the device security/configuration is also a part of successful access. No handwaving; really make sure they’ve got this. See if your red team is up for some AI assisted testing, where you’re going to leverage as many scenarios as possible to make sure that you’re dialed in.

Certificate authorities and registrars should be subject to more stringent security requirements. Seeing CAs making basic security mistakes two news cycles in a row is not confidence-inspiring.

Change control processes should require security review for anything being brought into a zone — this is a good example of why.

I’ve worked with Linux for decades, and this one really caught my attention! On affected systems, an account deliberately configured to reject password logins can actually be accessed using an absurdly long password. Yikes! The flaw arises from subtle interactions among OpenSSH, musl libc, and Linux authentication conventions. It’s a fascinating reminder that even well-established, carefully scrutinized software can have surprising weaknesses where components interact. Check your musl-based Linux systems, especially embedded devices, and apply the appropriate OpenSSH updates. Don’t forget to restart sshd! And remember, the specific configuration matters. Not every Linux system is vulnerable.

Things were fine prior to the introduction of the SHA512 support, passwordless accounts (with a ‘*’ in the password field) of /etc/shadow would never match, but the must crypt() SHA256/SHA512 routine returned an “*” on passwords over 256 characters - which matches the stored ‘*’ - and lets users into these accounts. I was watching a thread on this, and was really glad to see the notification that HD was merging the updated code which addressed the flaw. The simple fix is to apply version 10.6p2 of OpenSSH and restart services. If you're using musl Linux without PAM, you need to apply the patch, like yesterday, the mitigation is to disable password authentication or disable SSH, both of which could be problematic. Don’t forget to search for “Accepted password for” entries in your logs, regardless of Linux flavor - you’re looking for logins to your passwordless accounts which shouldn’t be there.

In my testing, I found it exceedingly difficult to configure a Linux system to be vulnerable to SSHOLE. If we see any hacking of this, it will likely be in systems that were preconfigured in a vulnerable state, like Alpine's preconfigured Docker images. Similar to PHP2Shell, this is a vulnerability likely to have two phases: After initial disclosure, exploitation is difficult and vulnerable systems have yet to be identified. The second stage could come weeks later or even years later, after exploits have been improved, or large classes of vulnerable systems have been identified. The biggest challenge for defenders in both of these cases is inventorying all vulnerable systems. Software and hardware asset management is more important than ever, given how often 'drop-everything-and-patch-now' vulnerabilities are being disclosed. Put in the work, so that answering the question, "are we affected?" is just a query away.

Don’t pass go; update Azure Linux. If your team is saying they don't have it, but you have Azure cloud services, you probably do have Azure Linux, aka CBL-Mariner. Given the updates to Azure Linux listed, you may want to see if any of your other distributions have similar updates queued up that you should pull the trigger on. Don't overlook that there are also Docker updates here, which means you need to do some container maintenance too. Make sure you also push out updates to Ruby and libcurl.

The eMudhra certificate issues keep hurting systems. So much of our network trust ultimately depends on certificate trust. eMudhra focused on issuing personal certificates, but because it was part of the trust store, these certificates could still be used for other purposes. Maybe we need more focused trust stores for applications outside of browsers and WebPKI.

Rolling out 470 security fixes in a routine version update speaks volumes. It's a strong indicator that Microsoft is leveraging AI-driven vulnerability research to scrub its codebase. Because several critical flaws hit the 9.8–10.0 range, immediate patching is non-negotiable as adversaries have likely already reverse-engineered the patches and weaponized the exploits.

There is nothing like a crisis to test legislation, in this case Japan's new Proactive Cyber Defense Act. The Japanese are banking on both AI and public-private partnerships to help them implement an active cyber defense. It's going to be interesting to see how that plays out: Will they really be able to disable attackers’ computers, and what will the response be? I am fairly certain attackers will not just walk away. In the meantime, recently attacked entities such as GMO Internet Co. are recovering, apologizing to customers, and promising to make them whole. Keep an eye on what Japan does here; it may be something worth emulating.

It's an ambitious plan by the government; let's hope it scales. Success will hinge on whether it produces practical mechanisms to automate essential cyber hygiene.

It’s pretty significant that five federal agencies joined in warning about the cybersecurity of industrial refrigeration systems. These attacks exposed a common dependency across several critical infrastructure sectors that previously received little cybersecurity attention. We've known for years how to protect industrial controllers from unauthorized remote access, so the challenge now is getting those protections implemented across thousands of facilities operated and maintained by different organizations and service providers. I would like to see the federal government and industry move beyond issuing warnings and develop a coordinated approach to identifying vulnerable systems, helping operators secure them, and verifying that the physical processes they support remain safe.

If you have modern refrigeration systems, use this guidance to ensure they are secure. We can debate whether the attacks leveraged default credentials, leveraged a flaw, or simply caused an Internet exposed PLC to fail, but the reality is that there are a number of things you want to do for defense in depth. This three-page alert pulls it all together: the risks, mitigations, and references. Use it to build your plan and make sure that you’ve got this, soup to nuts. I am pretty sure I heard someone say we don't have any modern refrigeration systems; OK, how about any other OT systems? This guidance works for them as well.

Refrigeration is the tip of the tip of the iceberg here, and this kind of reactive approach to securing these systems is proven time and time again to be ineffective. Everyone's knee-jerk reaction is to ask, "Do these things really need to be on the Internet?" There's absolutely no reason why industrial refrigeration units can't be both secure and remotely monitored. The problems are twofold: 1) Economic incentives don't exist — buyers purchase these units regardless of how secure they are and buyers are unqualified to judge how secure these systems are, both before purchase and after installing them. 2) Most industrial manufacturers specialize in building reliable, large scale equipment — they are not traditionally software security experts. However, I'd argue that three decades into stuffing computers into industrial equipment, security basics should have made it into this equipment by now, no matter how long its lifespan in the field might be.

Nothing in this fact sheet is new, and these are all things you should already be doing. But having this official fact sheet may help justify the resources required to implement these measures.

News of the first industrial refrigeration cyberattack broke around October 12, 2026, quickly making headlines across the world. With today’s release of this USG fact sheet, the threat intelligence loop is finally closed. Hopefully CISOs in affected sectors started mitigating that risk 25 days ago.

There’s something genuinely encouraging about all 66 branches of the Queens Public Library remaining open despite a serious ransomware incident. Public libraries provide so much more than books. They're places where people learn, access technology, connect with their communities, and sometimes simply find a welcoming place to spend time. Although important digital services have been disrupted, library personnel have kept many essential services running while their technical colleagues work through recovery. That's worth recognizing! For security and operational leaders, this is a reminder to build continuity plans around the services people actually depend upon, not merely the computer systems that deliver them. Kudos to the Queens Public Library team for keeping their community mission front and center during a difficult incident. I hope their recovery goes smoothly!

Back in the days when our data center had no power backup, we had a walkthrough after the first outage to make sure we had workarounds and manual processes defined to minimize the impact. Use this one as a reminder to make sure you have some plans if the internet "juice" goes out or has to be turned off.

The third anniversary of the British Library's ransomware incident was a few weeks ago and it still hasn't fully recovered. The British Library self-published a report on its incident so other organizations could learn from its mistakes. Other libraries would do well to read this report and learn from it.

QPL is one of the biggest public libraries in the country. We’re talking 66 branches, 2.3 million customers, 5 million books in 50 languages. Interestingly although renewals were impacted, they eliminated late fees in 2021, so there is no financial impact for late returns. Currently nobody is taking credit for the attack yet, but even so, the library is keeping both their status page and social media updated, as well as staffing an information line you can call

The lesson for the rest of us is that we should have a plan in place for business continuity in the event of a breach.

The ransomware gang BYOD seems to be popping up in the context of university breaches of late. Regardless, if you're a university student, be prepared to switch to non-university networks when needed — like, say, a cellular hotspot — and be religious about implementing the MFA option where available. That is one of those things where if you can postpone it, it's really tempting to do so, particularly in the heat of enrollment/registration or the press of completing assignments at the end of the term. If you're providing account enrollment services, look closely at requiring MFA at account creation rather than allowing it to be delayed.

Schools are hard to secure. In the late 90s, Richard Clarke asserted that three fourths of the attack traffic was proxied by higher ed. At that time, there was almost exclusive reliance on passwords. That said, in the 1990s schools made huge strides. The examples set by USC, Georgia Tech, and the University of Georgia were widely adopted. EDUCOM provided leadership. However, there are approximately 4,000 colleges and universities in the US alone; there will be outliers at both ends of the distribution.

This is just the latest in a series of third-party software incidents affecting software used by schools. PowerSchool and Instructure's incidents were considerably worse, but schools need to start holding third parties entrusted with student data to higher standards.

While I make a big deal about MFA, you need to be prepared to respond when a service which still uses a reusable credential alerts you to change your password. Make sure that you not only verify that request — login portal impersonation is still a thing — but also generate a suitable passphrase and update your password manager readily. It's really easy to set something like this aside until you have everything "organized," and that day can be a long time in coming. Make sure that your other family members are prepared as well, and help them to get there and understand why this matters.

An e-commerce site should not store passwords in the clear, should not rely on passwords, and should not store all this PII in the clear.