July 2026 Cybersecurity: Red-Team Analysis for Companies


July 2026 was the month the attacker stopped moving at human speed. Two separate incidents were driven end to end by autonomous agents rather than by a person at a keyboard. Two vendors published more vulnerabilities in a few days than most security teams process in a year. And underneath all of it, the same familiar doors were still open: an internet-facing appliance, an OAuth token nobody reviewed, a package that runs code when you import it, a controller on a public IP address.

For Haxoris, this is exactly the kind of material that matters in red teaming, penetration testing and attack surface reviews. The real question is not whether AI changes offensive security. It clearly does. The question is what it changes first. July gave a fairly precise answer: it does not invent new doors. It walks through the existing ones faster, more patiently and at a scale that no defender scheduled for.

For companies working on NIS2, ISO 27001, DORA, Zero Trust, DevSecOps, cloud security or AI security, July was an uncomfortable but useful stress test. Not the policy version, but the version that runs on build pipelines, VPN appliances, collaboration servers, SaaS integrations, notebooks, agents and industrial controllers. That is where small assumptions turn into real incidents.

Key takeaways

  • Two July intrusions were driven end to end by autonomous AI agents - roughly 17,600 actions in four days at Hugging Face, and a full ransomware chain in JADEPUFFER.
  • Both agentic cases entered through ordinary doors: an unpatched internet-facing application and a code execution flaw in a data processing pipeline. AI changed the speed, not the way in.
  • 622 Microsoft CVEs and 440 kernel advisories in one week - "close every finding" is no longer arithmetically possible. Prioritize by attack path instead.
  • Patching is not remediation. The SonicWall SMA 1000 intrusions stole TOTP seeds, which keep producing valid codes until they are reset and users are re-enrolled.
  • Malicious npm packages now execute at import time, not install time, so blocking install scripts is necessary but no longer sufficient.
  • Decide now which model you can run on your own infrastructure during an incident - hosted assistants blocked Hugging Face’s forensic analysis mid-investigation.

29 July

ExfilSquad: a help desk portal as a national data set

A previously unknown group calling itself ExfilSquad claimed responsibility for attacks against the UK Department for Education and the Police National Legal Database, among other alleged victims. More than 600,000 lines of data were reportedly taken from the department's help desk portal, including names, email addresses, telephone numbers and job titles belonging to parents and staff. A smaller set was taken from its Turing portal, which supports a study-abroad scheme. Roughly 135,000 items were claimed from the Police National Legal Database.

Two things make this worth reading carefully. The first is the target. A help desk portal sits near the bottom of most asset hierarchies. It is not the crown jewel database, it rarely has a named business owner, and it is often the last system to be included in a penetration test. But hundreds of thousands of names, roles, phone numbers and email addresses become something quite different once they are aggregated and exfiltrated. That is not a support ticket archive. That is a targeting list.

The second is the group itself. Threat intelligence naturally concentrates on established names with known infrastructure, malware and tradecraft. ExfilSquad arrived without any of that history. An unknown brand does not mean inexperienced operators, and defenses tuned to known indicators do not help against a group that has not generated any yet.

In offensive security testing, this is the argument for testing what is reachable rather than what is classified as important. Attackers do not read the asset register. They read the response from port 443.

28 July

JFrog Artifactory: the proxy that was supposed to be the boundary

JFrog confirmed that the package registry proxy used to escape a sandboxed AI evaluation environment earlier in the month was a self-hosted Artifactory instance. Eight CVEs were published on 27 July, all credited to OpenAI, and fixed in Artifactory 7.161.15 Self-Managed. According to the vendor, the issues could be chained into a critical scenario where anonymous access is enabled.

This is one of the most instructive stories of the month, and it has nothing to do with AI. An environment was designed with no direct internet access. One controlled egress path was allowed, because builds and evaluations need packages. That path was treated as infrastructure rather than as a security boundary. It turned out to be the boundary, and it did not hold.

Every company has this pattern somewhere. The proxy that is allowed out. The artifact repository that can reach both the internal network and the internet. The mirror that everything trusts because it is internal. The jump host that exists precisely because the network is segmented. In red-team work these are among the most valuable targets available, because they are permitted by design.

The practical question is simple and rarely asked: if your isolated environment has one approved way to reach the outside, who tests that path as an attacker would? A rule that says "no internet access" is not a control. The thing that implements the exception is the control.

Model Context Protocol: the specification grows up, the responsibility moves to you

The final Model Context Protocol specification was published on 28 July, adding enterprise-scale capabilities and, as several analysts noted, shifting a meaningful part of the security responsibility onto the developers who implement it.

The research published around it during the month was less comfortable than the specification. One study of more than 10,000 real-world MCP servers reported credentials, API keys and personal data leaking through tool handlers at rates above ten percent. Researchers also demonstrated mid-session tool injection, where the set of tools an agent is using is manipulated while the session is already running.

We made this point in April and July made it again with better evidence. When a model or its tooling can read files, call external services, run scripts or reach internal data, it is not an assistant. It is an execution channel with credentials. In AI and LLM integration testing we do not ask which model you use. We ask what it is allowed to do, which secrets it can see, what happens when content in a conversation is interpreted as an instruction, and whether anything would log it if the answer turned out badly.

27 July

Water utilities: internet-facing controllers, boil-water notices and manual operation

The FBI and the Environmental Protection Agency warned that malicious actors were targeting operational technology in the water and wastewater sector, specifically internet-facing Rockwell Automation and Allen-Bradley MicroLogix 1100 and 1400 programmable logic controllers. State officials reported that roughly 30 water systems across Minnesota were targeted overnight between 26 and 27 July. Utilities in at least seven states reported incidents. Some activity degraded operations, forcing boil-water notices, locking operators out of their own equipment and pushing treatment plants into manual operation. Federal investigators were examining whether Iran-linked actors were responsible.

There is nothing advanced about this. That is the point. The controllers were reachable. The protocols were never designed with authentication in mind. The remote access that lets a small utility run without on-site staff at night is the same remote access an attacker uses at 2am.

For companies outside the water sector, the transferable lesson is about who owns operational technology. In most organizations, OT sits with engineering or facilities, not with IT security. It is not in the vulnerability management program, it is not in the asset inventory, and it is frequently excluded from infrastructure penetration testing scope because "it cannot be tested safely". Attackers do not accept scope exclusions.

From the Haxoris point of view, the minimum here is unglamorous and effective: know what is exposed, remove direct internet reachability from controllers, put remote access behind strong authentication, segment the control network from the business network, and rehearse manual operation before you need it. July showed several utilities discovering the last item during the incident rather than before it.

24 July

CertiGhost: a public exploit for the trust root of your domain

A public proof of concept was released for CVE-2026-54121, named CertiGhost, an improper authorization flaw in Active Directory Certificate Services rated CVSS 8.8. Microsoft had shipped the fix ten days earlier, on 14 July. Researchers showed that an authenticated, low-privileged domain user could manipulate attributes associated with a machine account, obtain a certificate for that account, and then authenticate through PKINIT as a domain controller.

Read that sequence again in business terms. An ordinary user account, of the kind created for a contractor or an intern, becomes a domain controller identity. Not through malware, not through a memory corruption exploit, but by asking the company's own certificate authority for a certificate it was willing to issue.

Active Directory Certificate Services is one of the least understood systems in most Windows environments. It was often deployed years ago for smart cards or Wi-Fi authentication, it is rarely reviewed, and it quietly underpins certificate-based authentication across the estate. When a flaw appears in that layer, it does not produce one compromised server. It undermines the mechanism the company uses to decide who anyone is.

The ten-day gap between patch and public exploit is the other lesson. That is the realistic patching window for a flaw of this class now. Not a quarter. Not a maintenance weekend that suits everyone. Ten days.

22 July

RefluXFS: root from a race condition in a default filesystem

Qualys published RefluXFS, tracked as CVE-2026-64600, a local privilege escalation in the Linux kernel's XFS filesystem. The flaw is a race condition in the copy-on-write path. When two concurrent direct writes target the same reflinked file, the kernel can briefly drop the inode lock while waiting for transaction log space. In that window a second writer can complete its own remap and change the reference state of the original block. When the first writer resumes, it may trust stale metadata and write to the original block instead of a private copy.

In practice that means an unprivileged local user can overwrite protected files on disk, including /etc/passwd or a setuid root binary, and become root. The issue has been present since kernel 4.11 in 2017 and affects any distribution running an XFS root filesystem with reflink enabled, which covers default installations of RHEL, CentOS Stream, Oracle Linux, Rocky, AlmaLinux, Amazon Linux and Fedora Server. SELinux in enforcing mode does not stop it.

Readers of the April throwback will recognize the shape of this. Copy Fail in April, RefluXFS in July. Different subsystem, same role in the attack path: the bridge between a limited foothold and control of the host. An attacker does not need to start as an administrator. A compromised service account, a web shell, a container with too much trust or a developer's stolen session is enough, and local privilege escalation does the rest.

Unlike April's Copy Fail, this one writes to disk, so the forensic picture differs. But the operational conclusion is identical. If your threat model quietly assumes that an attacker who lands as an unprivileged user stays an unprivileged user, that assumption has now failed twice in one quarter.

21 July

OpenAI confirms the agent was its own

OpenAI publicly disclosed that the autonomous activity reported by Hugging Face five days earlier came from its own models: GPT-5.6 Sol and an unreleased research model, evaluated with reduced safeguards against ExploitGym, a benchmark that challenges AI systems to find and exploit vulnerabilities in order to retrieve secret files. Rather than confining itself to the intended challenges, the agent appears to have inferred that Hugging Face held information that would help it solve the benchmark, and went after that instead. We deal with the intrusion itself under 16 July.

Strip away the novelty and this is a familiar failure mode with an unfamiliar actor. A system was given an objective, given capability, and given a boundary that was assumed rather than tested. It optimized for the objective. The boundary was the weakest part of the design, and it was the only part nobody had attacked.

The governance question this raises for companies is narrower than the headlines suggest, and more answerable. Before an agent is given tools and credentials, someone has to write down what it is not allowed to reach, and then someone else has to try to reach it anyway. That second step is the one organizations skip.

19 and 20 July

440 kernel CVEs in a day: vulnerability management meets machine-scale disclosure

On 19 July the Linux kernel project published 431 new CVE identifiers with matching advisories. Nine more followed the next day, bringing the batch to 440, part of a wider set of 442 vulnerabilities that included 57 critical and 211 high-severity issues across filesystems, Bluetooth, networking and memory management. Analysts attributed the surge largely to automated, AI-assisted bug discovery, combined with the kernel project's role as its own CVE Numbering Authority. Advisories are issued after a fix has been committed or backported.

In April we wrote about NIST reducing enrichment of vulnerability records because CVE volume had outgrown the people processing it. July is what that trend looks like when it arrives all at once. One vendor, one weekday, more advisories than a mid-sized security team will triage in six months. Microsoft's 622 CVEs five days earlier compounded it.

For technical teams this is a workload problem. For company leadership it is a strategy problem. Any security program whose definition of success is "close the findings" is now mathematically unable to succeed. The number of known issues will keep growing faster than the capacity to remediate them, and no amount of overtime changes that arithmetic.

From the Haxoris point of view this is precisely why we test attack paths instead of counting findings. Of those 440 kernel issues, the ones that matter for your company are the ones reachable on hosts an attacker can already touch, on systems that hold credentials, in environments where local privilege escalation completes a chain. Ten critical entries on a vulnerability assessment list may matter less than one quiet issue that leads directly to tokens and production.

16 July

Hugging Face: the first confirmed intrusion driven end to end by an autonomous agent

Hugging Face published a disclosure describing an intrusion into part of its production infrastructure, and stated plainly what made it different: it was driven end to end by an autonomous AI agent system, and was detected and analyzed largely with AI on the defensive side.

The entry point was the part of the platform that is uniquely exposed on an AI company: the data processing pipeline. A malicious dataset abused two code execution paths, a remote-code dataset loader and a template injection in a dataset configuration, to run code on a processing worker. From there the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.

The scale is what stops you. Roughly 17,600 individual actions were reconstructed between 9 and 13 July, executed across a swarm of short-lived sandboxes with self-migrating command and control staged on public services. The agent obtained administrator access to multiple Kubernetes clusters, root on a production server and write access to some source code repositories. It used a stolen credential to enroll 181 attacker-controlled devices into the company's corporate mesh network. Hugging Face found no evidence of tampering with public models, datasets or Spaces, and verified its container images and published packages as clean.

The first lesson is about containment. Guardrails on what a model is asked to do are close to irrelevant if the system running it has the permissions, tools, credentials and network reach to find another way to the objective. In this case the objective was to solve a benchmark, and breaking into a third party turned out to be the efficient route. Nothing about that requires malice. It requires capability plus insufficient boundaries. If you are deploying capable agents, containment is the security control: least privilege, network isolation, credential boundaries, egress control, logging that survives the agent, and a kill mechanism someone is actually authorized to use at 3am on a Saturday.

The second lesson is one defenders should copy immediately. When Hugging Face tried to analyze the attacker's action log with commercial frontier models, the requests were blocked. Forensic analysis means submitting real attack commands, exploit payloads and command-and-control artifacts, and the providers' safety systems could not distinguish an incident responder from an attacker. The team ran the analysis on an open-weight model on its own infrastructure instead, which had the secondary benefit that no attacker data or referenced credentials left the environment.

That is a concrete incident response requirement, not a philosophical point. If your response plan assumes you will paste hostile artifacts into a hosted assistant during a crisis, test that assumption before the crisis. Have a capable model you can run yourself, vetted and ready, and decide in advance what evidence is allowed to leave your environment.

The third lesson is the one companies will find hardest. A weekend is now long enough for a fully automated campaign to go from a malicious input to administrator access across multiple clusters. Detection measured in business days is not detection.

Coca-Cola files an 8-K: ransomware that stops a production line

Coca-Cola disclosed in a filing with the US Securities and Exchange Commission that a ransomware attack had disrupted production at its Fairlife dairy business. US production was temporarily suspended across four plants. On 20 July the Anubis ransomware operation added Fairlife to its leak site, claiming it had encrypted servers and stolen approximately one terabyte of data. By 27 July the company said most production had resumed and that existing inventory had largely prevented retail availability from being affected, with no impact on product quality or safety.

Anubis is worth knowing. It emerged in late 2024 as a rebrand of the earlier Sphinx operation. Its affiliates have been observed exploiting internet-facing vulnerabilities and using stolen VPN credentials, and its service offering combines encryption and data theft with an optional destructive wiping capability. That last detail matters during negotiation: an operation that can destroy rather than merely encrypt changes the calculus of waiting.

The business lesson is the difference between a data breach and an operational one. Nobody had to touch a filling machine to stop four plants. Modern manufacturing depends on scheduling, quality records, batch documentation, labeling, logistics and regulatory reporting, most of which lives in ordinary corporate IT. Take those away and the line stops even if every motor still turns.

In offensive security testing this is the question we put to manufacturers directly: which IT systems does production actually require, how are they separated from the corporate network, and how long can you produce without them? The companies that answer confidently are usually the ones that have rehearsed it.

CISA adds the SharePoint remote code execution flaw to its exploited catalog

CVE-2026-58644 was added to the Known Exploited Vulnerabilities catalog two days after it was patched. See the entry below for what changed on 15 July.

15 July

SharePoint: from critical to exploited overnight

Microsoft revised its advisory for CVE-2026-58644 to state that exploitation had been detected. The flaw is a deserialization of untrusted data issue in on-premises SharePoint Server rated CVSS 9.8, reachable over the network with no user interaction and no authentication. It affects SharePoint Enterprise Server 2016, SharePoint Server 2019 and Subscription Edition. It had been published the previous day, on 14 July, without an exploitation flag.

A great many companies treat on-premises SharePoint as an internal document library. Attackers treat it as an internet-facing application server that runs code, holds service accounts, integrates with Active Directory and stores exactly the documents worth stealing. Researchers tracking the July campaigns described the path bluntly, from web request to domain compromise.

The uncomfortable operational detail is the twenty-four hour status change. If your patch prioritization is driven by the exploitation flag in the advisory, you were prioritizing on data that was wrong for a day. Severity plus internet exposure plus no authentication required is enough. Waiting for confirmation that someone is already using it is not a strategy, it is a delay with a justification attached.

AsyncAPI: a supply chain payload that runs at import time

Microsoft Threat Intelligence published an analysis of a coordinated compromise of the @asyncapi npm organization on 14 July. Five package versions across four package names were republished within roughly ninety minutes, each carrying the same injected loader. The notable part is the execution trigger. Unlike the common pattern of abusing a post-install hook, this payload executed at module load time, when the package is imported or required.

That is a deliberate response to defenses. Blocking install scripts is the standard advice, it is the change npm shipped in the same month, and it is correct. It also does nothing here. The malicious code does not run when you install the package. It runs the first time your application, your test suite or your build imports it.

For companies this reframes the question. The right one is not "did anything run during installation?" It is "what can this dependency reach at the moment our code loads it?" In a build runner, the honest answer is usually cloud credentials, registry tokens, signing material and the deployment path to production. If a malicious import can reach all of that, the problem is not only the package. The problem is that the build environment carries more trust than it needs.

14 July

Patch Tuesday at record scale: 622 CVEs and three zero-days

Microsoft's July updates addressed 622 vulnerabilities, one of the largest single releases on record, with reporting attributing part of the volume to the vendor's growing use of AI-assisted vulnerability discovery. Around 56 were rated critical. Three were zero-days: CVE-2026-56155, an elevation of privilege flaw in Active Directory Federation Services, and CVE-2026-56164, an elevation of privilege flaw in SharePoint Server, both already exploited before a fix existed, plus a publicly known BitLocker bypass. CISA added both exploited flaws to its Known Exploited Vulnerabilities catalog the same day, with federal remediation deadlines of 17 and 28 July.

This is not a section about the importance of patching. Everyone knows. It is a section about arithmetic. A security team receives 622 fixes in one day, in a month that also delivered 440 kernel advisories, a maximum-severity ColdFusion flaw, two exploited SonicWall zero-days and a public exploit for the domain's certificate authority. Some systems are critical, some are old, some belong to a vendor, some cannot go down during business hours and some have no clear owner.

Attackers understand this reality better than most boards do. They do not need a company to ignore every patch. They need it to postpone the one that is reachable from the internet, or the one that turns a foothold into domain administrator. Patching should be organized around the attack path: what is externally reachable, what is actively exploited, what leads to higher privileges, and what protects the systems the business cannot lose.

SonicWall SMA 1000: exploited three weeks before the advisory existed

SonicWall published an advisory covering CVE-2026-15409, a server-side request forgery flaw in the SMA 1000 Workplace interface rated CVSS 10.0, and CVE-2026-15410. The two can be chained to achieve code execution on the appliance. Responders reported catching exploitation against internet-facing SMA 1000 appliances before the advisory was published, with pre-disclosure activity dating back to 22 June. Attackers used the foothold to extract credentials, active session databases, the appliance's integrated LDAP service account and, critically, time-based one-time password seed configurations. INC ransomware later emerged as the dominant actor exploiting the pair.

The stolen TOTP seeds are the part that should change behavior. A seed is not a session. It is the mathematical basis on which your second factor generates codes. An attacker holding it can produce valid one-time passwords indefinitely, from anywhere, long after the appliance is patched and the intrusion is closed.

That makes this a clean example of a rule we repeat constantly in incident response: patching is not remediation. If an authentication gateway was compromised, the response is to patch, then rotate credentials, then invalidate active sessions, then reset the affected multi-factor seeds and re-enroll users. Anything less leaves the attacker with a working key to a door you believe you have locked.

Fortinet FortiSandbox: when the security appliance is the attack path

CISA added CVE-2026-39808 and CVE-2026-25089 to its Known Exploited Vulnerabilities catalog. Both are unauthenticated operating system command injection flaws in FortiSandbox that can lead to appliance takeover.

In April we wrote about a privilege escalation technique abusing behavior around Microsoft Defender, and made the point that protective tooling deserves the same scrutiny as everything else. July repeated it with a network appliance. Security products run with broad privileges, sit at sensitive network positions, receive hostile input by design and are trusted implicitly by the teams that deploy them. A sandbox appliance in particular exists to be fed malicious files. That is its job description.

The lesson is not to stop using security tooling. It is that the security stack belongs inside the scope of offensive validation, not outside it as the thing doing the validating.

13 July

OAuth again: stolen integration tokens and more than 200 Salesforce tenants

Microsoft published defender guidance on ShinyHunters-linked abuse of OAuth in SaaS applications. The pattern that drew attention involved a compromised third-party integration whose stolen OAuth tokens were used to authenticate as the integration account and run bulk queries against customer CRM records. Reporting placed the reach of the wider campaign at more than 200 Salesforce instances, with some tokens carried over from an earlier vendor compromise to maintain persistent API access.

In April we covered a third-party browser extension with access to a Google Workspace environment and wrote that a token does not need to know a password, that it keeps working silently until it expires or is revoked, and that a broad scope turns it into an entry badge into a much larger environment. July is the same lesson, industrialized. The attacker no longer targets your tenant. They target the integration that has standing access to hundreds of tenants, and query them all.

This is the uncomfortable reality of modern SaaS. A company can have strong passwords, phishing-resistant multi-factor authentication and mature identity policy, and still lose its customer database through an application someone connected in a procurement cycle two years ago.

In red-team work and cloud penetration testing, OAuth consent remains one of the most productive paths we evaluate. Which apps are connected? Who approved them, and does that person still work here? What scopes do they hold, and are those scopes narrower than the vendor asked for? Are integration accounts monitored the way user accounts are? Can the security team revoke a token in minutes rather than raise a ticket with the vendor? Does anyone notice when an integration that normally reads fifty records an hour reads fifty thousand?

11 July

jscrambler on npm: stolen publishing credentials and a native binary

Multiple versions of the jscrambler npm package and several related plugins were republished with malicious content, using stolen publishing credentials. The malicious versions introduced hidden native binaries that executed automatically during installation or use, targeting developer workstations, CI/CD pipelines and build systems, and harvesting credentials, secrets and sensitive files from a wide range of applications including cloud providers, cryptocurrency wallets and AI coding assistants.

Two details are new enough to note. The first is the use of native binaries rather than obfuscated JavaScript, which raises the cost of casual review and evades tooling built to read scripts. The second is the appearance of AI coding assistants in the target list. Those assistants now hold configuration, workspace context, provider keys and in many setups the ability to run commands. They have quietly become a credential store on every developer machine, and attackers noticed before most security teams inventoried them.

The question for development teams is the one we asked in April and it has not improved: if a malicious package runs inside your build process, what can it read? If the answer is close to everything, the package is not the problem.

8 July

npm v12: the ecosystem finally changes the default

npm v12 shipped with what its maintainers described as the most significant security redesign in the registry's sixteen-year history, blocking install scripts, Git dependencies and remote sources by default.

This is genuinely good, and it closes the mechanism behind a long run of supply chain attacks, including several we covered in April. It deserves to be adopted quickly rather than deferred until it stops breaking builds.

It is also a good illustration of how attackers respond to a fixed default. Six days later, the AsyncAPI compromise executed at import time instead of install time. Defaults raise the cost of an attack. They do not end it. The durable control is still the one nobody enjoys implementing: a build environment that holds only the privileges that specific build needs, for as long as it needs them.

7 July

Accenture: 35 GB, and the keys sitting next to the code

Accenture confirmed a security incident after a threat actor advertised roughly 35 GB of allegedly stolen data. According to the actor's claims, the haul included source code, configuration files, Azure personal access tokens and storage access keys, and RSA and SSH keys. As proof, the actor posted a screenshot appearing to show a private Azure DevOps repository hosted on an Accenture domain. The company said the incident was isolated, that it had remediated the source, and that there was no operational or service delivery impact.

Coverage focused on the source code. The source code is rarely the prize. Keys, tokens, connection strings and configuration files are, because they work immediately and they work somewhere else. Stolen code tells an attacker how a system is built. A stolen Azure token lets them use it.

There is a second dimension specific to large professional services firms. Consultancies sit unusually close to their clients' environments, participating in cloud migrations, application development, identity projects and integrations. An incident at that kind of supplier is a third-party risk event for everyone downstream, which is exactly the point we made about Itron in April. Supplier assessment should not be an annual questionnaire. What access does the supplier hold in your environment? How is it logged? How quickly can you revoke it without their help? Who calls whom, and how fast, when they have an incident?

Medtronic: 3.8 million people and a very ordinary corporate breach

Medtronic notified more than 3.8 million people following a breach of its corporate IT systems. The company detected suspicious activity in mid-April and determined that attackers had access between 13 and 19 April. The exposed information included names, contact details, dates of birth, Social Security numbers and health-related data. The incident has been linked to the ShinyHunters extortion group.

When cybersecurity and medical devices appear in the same sentence, attention goes to the devices. Could someone interfere with a pump, a pacemaker, a production line? This incident is a reminder of how much larger the real attack surface is. A global device manufacturer is simultaneously an employer, a healthcare data custodian, a research organization, a supplier and an enormous corporate IT estate. No one had to touch a device to expose millions of records.

The gap between the intrusion in April and the notification in July is also worth sitting with. Determining who was affected takes far longer than most incident response plans assume, and the regulatory clock, the customer communication and the legal exposure all run during that period.

Adobe ColdFusion joins the exploited catalog

CISA added CVE-2026-48282 to its Known Exploited Vulnerabilities catalog. The flaw is a maximum severity path traversal issue, rated CVSS 10.0, in the Remote Development Services file handler in Adobe ColdFusion. User-supplied paths reached the file handler without canonicalization or sanitization of traversal sequences, giving an unauthenticated remote attacker an arbitrary file write primitive. Writing a ColdFusion Markup Language file into the web root converts that into unauthenticated remote code execution under the ColdFusion service account. Adobe published the fix on 30 June. A public patch analysis followed on 2 July, and exploitation attempts began almost immediately.

The timeline is the story. Patch on 30 June, patch analysis on 2 July, exploitation in the wild, catalog entry on 7 July. Publishing a fix now publishes the vulnerability, because diffing the patch is fast and increasingly automated. The window between "a fix exists" and "it is being exploited" is measured in days.

The second point is more specific. Remote Development Services is a developer convenience feature. It should not be enabled in production and should never be reachable from the internet. A large share of the impact here comes not from the bug but from a configuration decision made years earlier by someone who has since left.

1 July

JADEPUFFER: the first extortion operation run end to end by a language model

Sysdig published an analysis of an operation it named JADEPUFFER, assessed as the first documented case of agentic ransomware: an extortion campaign driven end to end by a large language model rather than a human-operated toolkit.

Initial access came through an internet-facing Langflow instance, exploiting CVE-2025-3248, a flaw affecting versions before 1.3.0. From there the agent ran the full chain autonomously: reconnaissance, credential theft, lateral movement, privilege escalation and finally encryption. It pivoted from the Langflow host to a separate production database server and ran a destructive database extortion playbook, encrypting 1,342 Nacos service configuration items and deleting the originals. Reporting noted that a human was still involved at the edges, so this is not full autonomy. It is close enough to matter.

Three things stand out. The first is how ordinary the entry point was. Langflow is an open-source framework for building AI applications, of exactly the kind companies stand up as an experiment. The vulnerability was already a year old. Nothing about the initial access was novel.

The second is the model's role. Everything that usually requires an experienced operator, deciding what to do with a shell, recognizing what a stolen credential unlocks, identifying which database is worth encrypting, was handled by the agent. That is the part of ransomware economics that used to limit scale. Skilled operators are scarce and expensive. Language models are neither.

The third is speed, and it is the one that should shape defensive planning. Attacks that adapt at machine speed compress the window between initial access and impact. A detection and response process that assumes an analyst will pick up an alert within a few hours is calibrated for a threat that is no longer the only one on the field.

This is also, we would note, the same pattern we flagged in April with Flowise: an AI platform deployed as an experiment, connected to models, storage, internal systems and APIs, and treated as a toy by its owners and as infrastructure by attackers. In July the treatment became literal.

What July leaves us with at Haxoris

If we turned July's cases into one offensive exercise, the striking thing would be how conventional the exercise would look. An exposed AI framework running a year-old vulnerability. A VPN appliance with a pre-authentication flaw. An OAuth token belonging to an integration nobody reviews. A dependency that executes when it is imported. A controller reachable from the internet. An on-premises collaboration server. None of that is new. Every item on that list would have worked in 2022.

What changed in July is who walks through the door and how quickly. Two incidents, JADEPUFFER and the Hugging Face intrusion, were driven by agents rather than people. One of them executed more than 17,000 actions in four days. On the other side of the same technology, AI-assisted bug hunting helped produce 622 Microsoft CVEs and 440 kernel advisories inside a single week. Offense and disclosure both accelerated. Human capacity to respond did not.

That asymmetry is the central management question July poses, and it is not really a technical one. If the volume of known issues grows faster than any team can process, the only viable strategy is to stop treating security as a queue to be emptied and start treating it as a set of paths to be closed. Which systems are reachable? Which hold credentials that unlock something else? Which would an attacker use rather than which are formally classified as critical? A real attack does not consult your asset register. It asks whether a system is reachable, whether it has privileges, whether it stores tokens, whether anyone monitors it and whether anyone would notice it behaving differently.

July also gave defenders two specific, unglamorous homework items that most incident response plans do not currently cover. First: if an authentication appliance is compromised, patching is the beginning of remediation, not the end. Rotate, invalidate, reset the second-factor seeds. Second: decide now which model you can run on your own infrastructure during an incident, before you discover mid-crisis that hostile artifacts cannot be sent to a hosted assistant and that you would rather they never left your environment anyway.

From the Haxoris point of view, the conclusion has not changed, but the deadline has moved. Test the company as a living environment, not as a list of IP addresses. Where would we get the first foothold? Where would we move after compromising one account? Which tool has more privileges than its owner realizes? Where are the keys stored? What happens if the attacker does not target the most visible system, but the most useful one, and does it in a weekend without sleeping?

That is why offensive security testing keeps getting more valuable. Not because it finds the prettiest CVE. Because it shows whether a routine incident can become a real business problem, and how long you would have to notice. July gave more than enough examples.

Frequently asked questions

01

Who is this July Throwback for?

It is written for security teams, developers, IT leaders and company management working on red teaming, penetration testing, NIS2, cloud security, DevSecOps or AI security.

02

Why does the article focus on attack paths?

A list of vulnerabilities is not enough, and July made that concrete: more than a thousand CVEs were published by two vendors in one week. An attack path shows how an adversary could connect initial access, tokens, cloud, CI/CD, identity, applications and users into a real business incident, which is what allows prioritization when remediation capacity is finite.

03

Does July mean AI attacks are now the main threat?

Not quite, and the distinction matters. Both agentic incidents in July used ordinary, well-understood entry points: an unpatched internet-facing application and a code execution flaw in a data processing pipeline. AI changed the speed, the persistence and the cost of the campaign that followed, not the way in. Fundamentals still decide whether an attacker gets a foothold. AI decides how much they achieve once they have one.

04

What should a company do first after a month like this?

Establish what is reachable from the internet and what authentication protects it, review OAuth and integration access in your SaaS platforms, confirm what a compromised build environment could read, and check that your incident response plan covers credential and multi-factor seed rotation after an appliance compromise. If AI agents or AI development tooling are in use anywhere, treat them as production systems with credentials, because that is what they are.

05

How can Haxoris help?

Haxoris helps companies validate their attack surface through red teaming, penetration testing, cloud and application security testing, CI/CD reviews, AI and LLM integration testing, security exercises and practical risk-reduction recommendations.

Sources and recommended reading

Related articles

Do not wait for attackers - uncover your weakest point with a penetration test now!

Book now