Beyond the Patch Cycle: How Third-Party Exposure and AI Are Reshaping Ransomware in Europe

Although some recent headlines suggest that European ransomware is becoming predominantly AI-driven, the available evidence does not support such a broad conclusion. The more relevant development is that attackers are expanding the channels through which they reach their targets.

Suppliers, software repositories, cloud identities, and legitimate digital services are increasingly part of the attack path. At the same time, an early documented case shows that a large language model (LLM) can automate substantial parts of a ransomware operation.

The shift is therefore not from conventional ransomware to AI-driven ransomware. It is from relatively direct attacks to a broader mix of supplier access, identity abuse, trusted-service exploitation, and selective automation.

Patching remains essential, but an effective ransomware strategy can no longer rely solely on patch management and endpoint protection.

European ransomware activity is accelerating, but the data needs context

A recent analysis of publicly disclosed ransomware incidents identified 2,066 affected organizations across 31 European countries from January 2025 to April 2026. The 684 incidents recorded in the first four months of 2026 were 55% higher than in the corresponding period of 2025.

These figures indicate rising ransomware pressure, but they are not a complete census. The analysis is based on disclosed incidents, open-source information, dark-web intelligence, and technical telemetry. Undisclosed or unattributed attacks are necessarily omitted.

The same analysis identified 64 European organizations affected via suppliers rather than by direct compromise. This does not show that suppliers account for most ransomware intrusions. It does show that a single supplier compromise can have disproportionate consequences across many customer organizations.

The compromise of Swedish HR software provider Miljödata illustrates this effect. The incident reportedly affected numerous municipalities, universities, and private organizations, exposing personal data for more than one million people.

Supplier risk is therefore not primarily about the number of attacks. It is about the potential scale and concentration of their impact.

ENISA’s latest European threat landscape assessment similarly identifies ransomware as a high-impact threat and highlights the growing abuse of vulnerabilities, digital dependencies, and trusted services.

The attack surface increasingly encompasses business relationships

Third-party cyber risk is often treated as a governance issue involving questionnaires, certifications, and contractual clauses. Ransomware turns it into an operational dependency.

Suppliers may hold privileged credentials, provide remote support, operate applications, manage backups, or connect directly to production environments. IT service providers may also have access to repositories, deployment processes, and cloud administration tools.

A compromised provider can therefore serve as a trusted entry point into several customer environments.

Critical services also depend on subcontractors, cloud platforms, and software components that may not be visible in the primary customer contract. Traditional supplier assessments focus primarily on the direct provider, while the actual attack path may involve a fourth party (a supplier used by a direct supplier) or a shared technology platform.

European regulation increasingly reflects this dependency. NIS2 includes supply-chain security as one of the required cybersecurity measures. DORA requires financial organizations to incorporate ICT third-party risk and provider concentration into their operational-resilience programs.

Compliance does not eliminate the risk. However, it makes it harder to treat a supplier breach as an entirely external event.

This wider perspective is examined in PAC’s Expert View on linking cyber resilience with enterprise resilience, which connects third-party dependencies with critical services, incident response, and business continuity.

Beyond the headlines: AI is an emerging attack enabler, not yet the primary driver

The JADEPUFFER campaign offers the clearest recent example of AI-assisted ransomware automation. A technical investigation identified it as the first known end-to-end agentic ransomware operation, meaning an attack in which an AI system independently selected and executed several steps.

The attacker compromised an internet-facing Langflow system via CVE-2025-3248, a vulnerability that allows command execution without authentication. The AI agent then conducted reconnaissance, searched for credentials, adapted failed commands, and moved toward a production database.

The case matters because the agent did not invent a new attack method. Instead, it combined established techniques into an adaptive workflow.

This could reduce the level of continuous human involvement required during an intrusion. It may also allow attackers to execute multi-stage operations more quickly or with fewer specialized skills.

Despite broader claims in some media coverage, JADEPUFFER does not demonstrate that ransomware has become AI-driven in general. It remains a single documented operation based on one technical investigation.

It is an important proof point for the feasibility of agentic attack automation, but not evidence of widespread adoption.

The initial Langflow vulnerability had also been disclosed and patched more than a year earlier. The incident, therefore, demonstrates both the emerging potential of AI automation and the ongoing importance of basic vulnerability remediation.

Trusted services can hide malicious activity

Attackers increasingly use legitimate cloud and collaboration infrastructure to make malicious communications appear normal.

In one documented ransomware intrusion, attackers routed command-and-control traffic through Microsoft Teams relay infrastructure. This technique made the traffic appear to be directed toward a legitimate Microsoft service.

This was not a vulnerability in Microsoft Teams and did not provide initial access. The infrastructure was used after the attackers had already entered the environment.

The case illustrates a broader detection challenge. Traffic to a trusted service cannot be assumed benign. Reputation-based monitoring alone may fail when attackers use legitimate platforms, credentials, and communication channels.

Defenders, therefore, need to assess what a process, account, or connection is doing, not only which destination it is contacting.

Why patching remains essential yet insufficient

Recent incidents illustrate two distinct vulnerability-management problems.

1. The exploitation of vulnerabilities for which patches already exist. These incidents typically result from unknown assets, delayed remediation, internet-facing exposure, or operational difficulties in applying updates.
2. Zero-day exploitation. In these cases, attackers exploit a vulnerability before the vendor releases a patch. The Oracle PeopleSoft vulnerability CVE-2026-35273 was exploited before Oracle published its security update in June 2026.

These scenarios require different responses. Known vulnerabilities primarily require better asset visibility, prioritization, and remediation. Zero-days require compensating controls such as isolation, access restrictions, enhanced monitoring, or temporarily disabling exposed functions.

Patching, therefore, remains indispensable, but it protects an organization only when:

• the vulnerable asset is known;
• a patch or mitigation exists;
• the update can be deployed safely;
• remediation happens before exploitation.

It does not directly address compromised suppliers, stolen credentials, trusted-service abuse, or malicious activity that uses legitimate product functions.

A broader PAC analysis of cyber resilience across financial services, manufacturing and utilities shows that ransomware readiness must combine exposure reduction, identity controls, tested recovery, and continuous control validation.

From security products to exposure and resilience services: what providers must change

Security vendors, managed security service providers, and IT service firms need to adapt their offerings to the evolving ransomware attack path.

1. Make third-party exposure part of security operations

Supplier-risk services should move beyond annual assessments and generic security scores. Providers need to link supplier information to technical exposure, including privileged access, vulnerable services, identities, data flows, and operational dependencies.

Customers need to know which suppliers can access critical systems, which providers hold administrative credentials, and which business services depend on the same underlying platform.

Monitoring should focus on changes that create exploitable attack paths rather than on every fluctuation in an external rating.

2. Integrate identity, secrets, and developer environments

Ransomware-readiness services often focus on endpoint detection, vulnerability management, and backups. They should also include repositories, developer systems, API keys, service accounts, and cloud identities.

Providers should support least-privilege access, short-lived credentials, secure password and key storage, and separation of development and production environments.

AI development tools and agent frameworks should be included in application- and cloud-security assessments rather than treated solely as productivity software.

3. Detect the abuse of legitimate services

Monitoring that focuses mainly on malicious domains, IP addresses, or known attacker infrastructure will increasingly miss activity routed through trusted platforms.

Managed detection services need behavioral analytics to identify unusual process execution, credential access, identity behavior, and service-to-service communication.

Detection engineering (the creation of rules and analytics to identify malicious activity) should assume that attackers may communicate through approved cloud or software-as-a-service platforms.

4. Prepare for agentic attacks without overstating the threat

Providers should not label every automated attack as AI-driven. They should focus on the capabilities that agentic systems may realistically change, including attack speed, adaptation, automated reconnaissance, and error correction.

Security testing should assess whether existing controls detect rapidly changing, machine-generated attack sequences.

Incident-response teams should also be prepared to analyze AI-generated code, natural-language instructions, and automated decision traces found during an investigation.

5. Extend resilience across organizational boundaries

A supplier compromise may require coordination among the customer, service providers, subcontractors, cloud platforms, legal teams, and regulators.

Providers should offer joint response procedures, evidence-sharing arrangements, and tested fallback options.

Recovery testing should assess whether customers can continue operating when a critical provider, software platform, or identity service is unavailable or no longer trusted.

6. Demonstrate measurable outcomes

Security providers should show reductions in exposed attack paths, excessive supplier privileges, remediation times, and untested dependencies.

The value of a service should be measured by whether the customer can detect, contain, and recover from an indirect compromise, not by the number of security tools deployed.

From patch compliance to attack-path control: what user organizations must change

User organizations need to maintain strong patching discipline while broadening their ransomware programs beyond internally managed assets.

1. Identify where external trust enters the organization

Supplier registers should be linked to technical access. Organizations need to know which providers have remote access, administrative roles, service accounts, API access, or responsibility for critical systems.

The objective is not to monitor all suppliers equally. It is to identify the relationships through which an attacker could access critical systems or disrupt essential operations.

2. Reduce the potential blast radius

Supplier and service accounts should have narrowly defined permissions, strong authentication, and time-limited access.

Shared administrator accounts and permanent remote-support connections should be removed wherever possible. Development, test, and production environments should also be separated.

Reducing the blast radius means limiting the number of systems and processes affected by a single compromised account or service.

3. Prioritize vulnerabilities by attackability

CVSS, the standard system for rating vulnerability severity, should not be the sole basis for remediation.

Priorities should also consider internet exposure, evidence of active exploitation, asset criticality, available attack code, and the privileges an attacker could obtain.

Organizations also need predefined controls for vulnerabilities that cannot yet be patched. These may include isolation, access restrictions, enhanced monitoring, or temporarily disabling an affected service.

4. Govern AI agents as executable systems

AI assistants that can run commands, access repositories, invoke tools, or use cloud credentials should be treated as privileged software.

Organizations should define which agents and extensions are allowed, which tools they may use, what information they can access, and when human approval is required.

Agent configurations and repository instructions should be treated as executable content rather than harmless metadata.

5. Monitor behavior within trusted platforms

Connections to established cloud and collaboration providers should not be automatically considered benign.

Organizations need telemetry from endpoints, identity platforms, cloud administration systems, proxies, and application logs to determine what a process or account actually did.

Allow-listing a destination may reduce false alarms, but it should not replace behavioral monitoring.

6. Test recovery from supplier-driven incidents

Ransomware exercises should include scenarios in which the initial compromise occurs at a provider rather than within the organization.

Testing should cover supplier communication, credential revocation, alternative operating procedures, regulatory notification, and recovery without reconnecting to a compromised provider.

Conclusion: ransomware resilience now extends across the business ecosystem

European ransomware is evolving through a wider mix of supplier compromise, trusted-service abuse, identity attacks, and selective AI automation. Patching remains essential, but effective resilience also depends on controlling third-party access, monitoring legitimate platforms, and preparing for disruption across the wider business ecosystem.