The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has ordered federal agencies to secure their systems by Saturday against ongoing attacks exploiting a critical vulnerability in the Oracle E-Business Suite (EBS) financial application. The directive to repeat states that as mandated by Binding Operational Directive (BOD) 26-04, this needs to be patched by tomorrow. AKA Saturday.
Ted Miracco, Approov (https://www.linkedin.com/in/tedmiracco)
“Organizations continue to struggle to patch critical vulnerabilities quickly because enterprise resource planning (ERP) platforms like Oracle and SAP are highly customized and deeply interwoven with other business applications. Patching them isn’t like updating a web browser; a single database update can break custom API integrations, halting payroll, shipping, or manufacturing.
“The window for ‘safe testing’ no longer exists for edge-facing systems. In the past, organizations had 30 to 90 days to test and deploy patches before exploits were widely weaponized. Today, threat actors reverse-engineer patches and deploy exploits within days or even hours.
“To better prioritize and respond to these types of threats, security teams must implement strict Web Application Firewall (WAF) rules, sever internet exposure, or place vulnerable assets behind a Zero Trust Network Access (ZTNA) gateway until patches can be safely tested. When patches can be deployed to a staging environment, tested automatically, and instantly rolled back if they fail, emergency deployments become a low-risk routine rather than a weekend crisis.”
Damon Small, Board Member, Xcape, Inc. (https://www.linkedin.com/in/damon-small-7400501)
“Deploying a patch on a single computer may seem like a trivial task, but doing it across an enterprise that may have hundreds, or even thousands, of servers is daunting. That said, we have seen incidents where a patched vulnerability is exploited months after it was resolved. As an industry, we must strike a balance between operational readiness and patching fatigue.
The first open source vulnerability scanner was released in 1995. Since then, vulnerability management has remained the least sexy, yet the most important, directive in cyber security. Frankly, as an industry, we struggle to update software quickly, and this fact will become more problematic as the time between vulnerabilities being discovered and them being actively exploited continues to shrink.
Security leaders should first and foremost ensure that their organizations have accurate software and hardware inventories. You cannot defend what you can’t see. Additionally, as ‘silent’ or no-reboot patching becomes an industry standard, automatic updates may follow.”
Donald McFarlane, Advisory Board Member, Xcape, Inc. (https://www.linkedin.com/in/dmcfarlane)
“Organizations rarely fail to patch because they lack another alert: they struggle when they lack reliable asset inventories, clear ownership, tested maintenance paths, or the authority to interrupt business-critical systems and processes. In today’s machine-scale, machine-speed adversarial environment, IT organizations must deploy critical security patches far more quickly. When immediate patching is not possible, leaders must prioritize vulnerabilities based on active exploitation, internet exposure, mission impact and potential blast radius, not severity scores alone. They should know in advance who owns each critical system, how it can be isolated, and how emergency changes can be made safely.
“Patching is not the finish line: organizations must determine whether an adversary arrived before the fix was applied. Find material exposure before an adversary does, fix it, and prove the risk actually went down.”
Kevin Surace, CEO, Token (https://www.linkedin.com/in/ksurace)
“Patching is rarely as simple as installing an update. Critical enterprise applications are often deeply connected to financial systems, databases, customized workflows, and third-party software, so teams fear that an untested patch could interrupt essential operations.
“The deeper problem is that many organizations do not have an accurate, continuously updated inventory of their systems. They may not know which servers are exposed to the internet, which versions are running, who owns them, or whether a patch was successfully applied.
“In this case, Oracle released the patch in May, exploitation was observed by late June, and more than 1,000 Oracle E Business Suite systems were still exposed to the internet in July. That is not primarily a technology failure. It is a failure of ownership, visibility, testing capacity, and executive accountability.
“Urgent federal patching orders and extremely short remediation deadlines are becoming more visible, but this particular action was not technically a standalone Emergency Directive. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog under Binding Operational Directive 26 04 and required remediation within three days.
“The significance is the deadline. CISA is effectively telling agencies that once exploitation is confirmed, the traditional patching cycle is no longer acceptable. Attackers are weaponizing vulnerabilities faster, while many organizations are still operating through monthly maintenance windows, lengthy approval processes, and manual asset reviews.
“These directives also reveal an uncomfortable truth: too many organizations still need an external government deadline to force action on vulnerabilities that vendors have already patched.
“Security leaders should prioritize vulnerabilities based on actual exploitation, internet exposure, business importance, and the potential impact of compromise, not simply on the severity score. A vulnerability that is being actively exploited against an exposed financial system should move immediately ahead of a higher scoring flaw on an isolated test machine.
“Every critical system needs a named business owner, a technical owner, a tested emergency patching procedure, and a clearly defined authority capable of accepting the operational risk of patching or the security risk of delaying it. When exploitation is confirmed, teams should be able to patch, isolate, restrict network access, or temporarily remove a system from service without waiting through days of meetings.
“Organizations should also assume that patching may come too late. Organizations must review logs for evidence of earlier exploitation, rotate potentially exposed credentials, inspect connected systems, and protect privileged access with hardware based biometric assured identity.
“Biometric assured identity would not prevent an unauthenticated Oracle software exploit such as this one. It can, however, stop attackers from turning stolen administrator credentials into broader access after the initial compromise. Patching closes the software vulnerability. Biometric assured identity helps contain what attackers can do next.”
Steven Swift, Managing Director, Suzu Labs (https://www.linkedin.com/in/steven-swift-5238956a)
“Patching is a big thankless task, and it rarely gets the resourcing it would require to actually patch all the things quickly. In order to have any chance at keeping up with patching, organizations need to implement solutions to automate both patching and vulnerability scanning.
“A lot of organizations are hesitant to patch immediately, because there have been enough issues with bad patches being released over the years, that the risk of patching slowly is preferred over the risk of patching fast and breaking things.
“Patching automation is great for those systems which are consistently deployed across the organization. However, the applications that are only on a few systems are those least likely to have automated patching. This would be fine, except for that there tends to be a lot of applications that fall into this category. Practically, that means staff can patch the vast majority of things consistently and in a timely manner, and still always have a long tail of vulnerabilities that are more challenging to fix.
“This is compounded when ownership is split between different teams. Especially so when organizational priorities are split. If teams are under pressure to hit tight deadlines, the last thing they want to do is spend time fixing/patching things that don’t directly assist in that goal. This results in a lot of vulnerability management teams spending much of their time providing reports on what needs patching, to teams that will get to it when they get to it.
“As for what leadership can do to better prioritize and respond to new vulnerabilities? A big part of is keeping metrics so that the work being done isn’t invisible anymore. If the team is consistently patching 90% of all published CVEs in a timely manner, and yet all that leadership sees are reports showing the remaining 10%, it can look like the team just isn’t doing much patching when the opposite is true.
“Track stale vulnerabilities in the organization, and prioritize those. Stale can be older than 30, 90, or 365 days for example. Depending on how mature existing processes are. Once all of the stale vulnerabilities are remediated, build automation to handle as much repeatable work as is possible. Provide developers with vulnerability feedback as early in the process as you can, as it costs much less time and money to fix code early on, than it does after release.”
While it is beyond time to patch all the things, organizations need rethink how they go about keeping their environments safe. Because patching is clearly not enough.
Hugging Face Breached by Autonomous AI Agent
Posted in Commentary with tags Hugging Face on July 20, 2026 by itnerdOpen-source AI and machine learning platform Hugging Face said it detected and responded to an intrusion into part of its production infrastructure. They said it was different from anything they had previously handled in that it was driven end to end, by an autonomous AI agent system that accessed to a limited set of internal datasets and to several credentials used by their services,
Hugging Face has posted details here: https://huggingface.co/blog/security-incident-july-2026
Rohit Valia, CEO of cybersecurity company Tumeryk, provided the following comments:
“Open source model repositories like Hugging Face now represent a meaningful supply chain risk. As adversaries increasingly target training and fine-tuning data rather than source code, organizations need to test open source models for behavioral drift, not just code-level vulnerabilities. An AI trust score gives enterprises a way to verify a model hasn’t been altered and is safe to use, while aligning to frameworks like the Cloud Security Alliances RiskRubric v2 which provide the structured testing methodology.”
If you use Hugging Face, you might want to see if you are at risk. And you might want to do it sooner rather than later.
UPDATE: Two more comments came in staring with Gidi Cohen, CEO & Co-Founder, Bonfy.AI:
“This incident should be a wake-up call, not because AI was involved, but because it shows how fast AI-native attacks are outpacing security programs.
An autonomous agent didn’t use fancy tricks, it just exploited familiar gaps in the system like code execution paths, credentials, and lateral movement. The difference is speed. Thousands of coordinated actions across short-lived environments shrank the response window from days to hours.
The bigger issue is defense. Hugging Face found its own response constrained by model guardrails. This s a new imbalance we see everywhere: the attacker operates without limits, while defenders (security personnel or security platforms) rely on tools that can refuse to help. If your company’s response tech stack isn’t fully under your control, your security posture isn’t either.
From this case, we have three takeaways for leaders: 1) “Data as code” is now a real attack surface. 2) Speed is the new risk multiplier. 3) You need internal, controllable AI for incident response, not just external APIs.
Security is shifting from hardening systems to operating at the speed of agents with tools you own. Organizations that plan for both sides of AI (attacker and defender) will set a new baseline for resilience.”
Toghrul Tahirov, Head of AI Governance, Polygraf AI
“What stands out to me in this Hugging Face incident is that the attack reportedly began with something organizations routinely trust: data entering an AI processing pipeline. Once AI agents can execute code and access infrastructure, a malicious dataset is no longer just bad content. It can become an entry point for credential theft and lateral movement. This is a reminder that AI systems must be treated as privileged software, not as just a smarter generation of the chatbots we’re used to.
My professional opinion is that secure AI adoption requires controls around the entire interaction: inspect untrusted data, isolate execution, minimize permissions, use short-lived credentials, restrict network access, and maintain clear audit trails. Organizations also need incident-response tools they can operate privately without exposing sensitive evidence. The answer is not to avoid AI agents, but to ensure governance and security ar
UPDATE #2: More commentary starting with John Strand, Owner, Black Hills Information Security, Inc.:
“There are plenty of jokes to be made about autonomous AI agents attacking a website that hosts autonomous AI agents, but that’s not the part that concerns me. What caught my attention was the claim that everything had been verified as clean despite hosting more than 45,000 models. At that scale, what does ‘verified clean’ really mean? Validating tens of thousands of models is an enormous challenge. That’s the reality we’re going to keep running into with software supply chain attacks. Whether it’s Hugging Face or any other platform hosting code that developers depend on, proving that everything is truly clean is only going to get harder as these ecosystems continue to grow.”
Donald McFarlane, Advisory Board Member, Xcape, Inc.
“This incident underscores how AI is changing the economics of cyber offense. AI-enabled tools allow attackers to automate reconnaissance, accelerate exploitation, and operate at machine speed. Just as leaders who eschewed advances such as longbows, RADAR, or drones have repeatedly found themselves facing defeat, defenders cannot afford to ignore AI. We must leverage AI to modernize cyber defense so as to increase attackers’ costs while reducing defenders’ workload. Meanwhile, organizations continue to need strong identity controls, segmentation, containment and resilience.
“Although Hugging Face reports no evidence that public models or the software supply chain were modified, incidents like this highlight the importance of protecting not only infrastructure, but also the credentials, private repositories, datasets, and deployment pipelines that support modern AI development.”
Jacob Krell, Senior Director: Secure AI Solutions & Cybersecurity, Suzu Labs:
“Dataset processing pipelines get the same level of security scrutiny that CI/CD hooks and build functions get, which is almost none. Teams pour AppSec effort into the application layer and treat the infrastructure that ingests and transforms data as plumbing. The attacker exploited a remote code loader and a template injection in that plumbing, then let an autonomous agent framework chain them across 17,000 actions in a weekend.
“A human attacker running that campaign needs a team and weeks. The agent framework did it with short-lived sandboxes and command-and-control staged on public services. Keeping pace requires AI-assisted incident response, and Hugging Face found out what happens when you reach for it mid-breach.
“Hugging Face’s team fed attack logs to commercial frontier models, and safety filters blocked the analysis because the logs contained real exploit payloads. They ran GLM 5.2, an open-weight model, on their own infrastructure instead. I’ve hit the same wall. I still run Opus 4.6 for security work and haven’t upgraded because newer models’ guardrails increasingly block legitimate analysis of exploit code and attack artifacts.
“Machine-speed exploitation requires machine-speed response, and that response can’t run on models that refuse to examine the evidence.”
Waseem Ahmed, Head of Engineering, Secure.com:
“For years we talked about the agentic attacker as a someday problem. Hugging Face just made it today’s problem. One agent, no human at the keyboard, credentials stolen and infrastructure crossed in a single weekend.
“The response is as telling as the attack. Hugging Face used AI to reconstruct the full attacker timeline in hours rather than days — processing thousands of events that would have taken a human team far longer to sequence. AI ran the attack. AI ran the investigation. That is the new baseline.
“The part that should concern every security team: you cannot out-click an attacker operating at machine speed across 45,000 models and 50,000 customer environments. The only viable answer is defence that runs at the same speed and never clocks out — AI that watches, triages, and acts alongside your team every hour of every day.
“Fight autonomous attacks with autonomous defence, or you will always be a step behind.”
Leave a comment »