The vulnerability landscape shifted significantly in Q2 2026. First, the number of registered CVEs reached an unprecedented level. This is driven primarily by the widespread adoption of AI, both for application development and search for security flaws. This resulted in entire new classes of vulnerabilities emerging, particularly in the Linux networking subsystem.

Second, security researchers have been publishing exploits for unpatched vulnerabilities more frequently. Publications like these can generate significant fallout, since they potentially open the door for attackers to target unprotected systems.

Statistics on registered vulnerabilities

This section provides statistical data on registered vulnerabilities. The data comes from Kaspersky’s vulnerability knowledge base, which draws on the CVE database as well as the Russian BDU database and GitHub Advisory (GHSA). As a result, the figures for previous reporting periods may differ from those published in earlier reports.

We examine the number of registered vulnerabilities for each month over the last five years. As the chart below shows, this number continues to surge, a trend reflected across all the databases we track. It’s driven primarily by the widespread adoption of AI tools: as we predicted in our previous report, these tools have played a major role in the discovery of vulnerabilities in third-party software. Meanwhile, these tools often contain security issues of their own. For example, OpenClaw, a popular AI project, ranked 12th among those with the highest number of vulnerabilities discovered and published in Q2, with over 200 CVEs registered during the reporting period. Finally, AI development tools are also contributing to the vulnerability landscape, since the quality of the code they produce can vary widely. Therefore, the rate at which new vulnerabilities are discovered will inevitably keep growing.

Total published vulnerabilities per month from 2022 through 2026 (download)

Next, we analyze the number of new critical vulnerabilities (CVSS > 9.0) over the same period.

Total critical vulnerabilities published per month from 2022 through 2026 (download)

As the chart shows, the number of published critical vulnerabilities jumped sharply in Q2. This is because using AI for vulnerability research makes it possible to analyze massive amounts of previously unexamined code, uncover new attack surfaces, and identify entire classes of vulnerabilities that have gone unnoticed for decades. In particular, AI was used to find a series of Dirty Frag vulnerabilities in the Linux kernel.

Exploitation statistics

This section presents statistics on vulnerability exploitation for Q2 2026. The data draws on open sources and our telemetry.

Windows and Linux vulnerability exploitation

Q2 2026 saw a new precedent in the publication of vulnerabilities in Windows components and exploits for these: researchers no longer waiting for CVE registration, let alone patches. A case in point: a researcher who goes by Nightmare Eclipse (also known as Chaotic Eclipse) published a list of new “named” vulnerabilities across various Windows subsystems. At the time the technical details were published, none of the vulnerabilities had been assigned a CVE identifier:

• BlueHammer: a local privilege escalation vulnerability in Windows Defender. During signature database updates, a time-of-check to time-of-use (TOCTOU) race condition occurs, allowing an attacker to substitute the directory where temporary update files are written. The researcher published a fully functional exploit for the vulnerability.
• RedSun: another logical vulnerability in Windows Defender with a working exploit. Suspicious and malicious files marked as “cloud” can be overwritten or restored to their original directory with elevated privileges. The exploit incorporates fragments of algorithms that make it possible to leverage various logical vulnerabilities in Windows, effectively combining a large number of popular exploitation techniques.
• YellowKey: a vulnerability that lets the user bypass BitLocker full-disk encryption and access system data through the Windows Recovery Environment (WinRE). A fully functional exploit was also published.
• GreenPlasma: a vulnerability that enables system object injection via the CTF loader for the Collaborative Translation Framework (CTFMON) service in Windows. The original publication included an exploit with limited functionality.
• RoguePlanet: yet another Windows Defender vulnerability that, like BlueHammer, stems from a TOCTOU issue, this time in the engine responsible for real-time system scanning. The published exploit uses the vulnerability to overwrite the system file wermgr.exe with a malicious one.
• UnDefend: another vulnerability in the Windows Defender service. This time, the exploit causes a denial of service and blocks updates.

Even though such cases remain isolated for now, we believe they’ll grow into a full-fledged trend. Early publication of exploits gives attackers an advantage over software developers, who are left with no time to fix the issues.

Veteran vulnerabilities in Windows software also remain relevant. These are the ones our solutions most frequently detect exploits for:

• CVE-2018-0802: a remote code execution (RCE) vulnerability in the Equation Editor component
• CVE-2017-11882: another RCE vulnerability also affecting Equation Editor
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to gain control over the system
• CVE-2023-38831: a vulnerability in WinRAR that involves improper handling of objects within an archive
• CVE-2025-6218 (formerly ZDI-CAN-27198): another WinRAR vulnerability allowing the specification of relative paths to extract files into arbitrary directories, potentially leading to malicious command execution
• CVE-2025-8088: a vulnerability similar in exploitation method to CVE-2025-6218. The attackers used NTFS Streams to circumvent controls on the directory into which files are being unpacked

The vulnerabilities listed here can be leveraged to gain initial access to a vulnerable system and for privilege escalation. This underscores the critical importance of timely software updates.

That said, the number of Windows users who encountered exploits declined slightly in Q2, hitting an 18-month low.

Dynamics of the number of Windows users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

Linux also hit a rough patch in Q2 2026. Specifically, the period saw the disclosure of the Dirty Frag family of vulnerabilities, which lets an attacker reliably escalate privileges within the operating system.

All the vulnerabilities published in Q2 2026 were, in one way or another, related to the Linux caching subsystem. Here are the ones being most actively exploited:

• CVE-2026-31431 (Copy Fail): a local privilege escalation vulnerability in the Linux kernel that lets an unprivileged user modify the page cache and gain root privileges. Especially dangerous for cloud and containerized environments
• CVE-2026-43284, CVE-2026-43500 (Dirty Frag): a family of vulnerabilities in the Linux networking subsystem (IPsec ESP and RxRPC) that lets a local user overwrite the page cache and escalate privileges to root
• CVE-2026-46300 (Fragnesia): a local privilege escalation vulnerability in the Linux kernel related to packet fragment handling and the page cache mechanism. It lets an unprivileged user gain root privileges and is also classified as part of the Dirty Frag family
• CVE-2026-31635 (DirtyDecrypt): a Linux kernel vulnerability that lets a local attacker escalate privileges due to improper handling of decryption operations and page cache data modification
• CVE-2026-43494 (PinTheft): a Linux kernel vulnerability that lets a local user gain elevated privileges due to errors in the memory page pinning mechanism
• CVE-2026-46331 (pedit COW): a vulnerability in the Linux kernel’s traffic control subsystem (tc-pedit) that exploits a flaw in copy-on-write to modify the page cache and subsequently escalate privileges to root

The vulnerabilities described above were quickly embraced by attackers. At the same time, our solutions continue to detect exploitation attempts targeting older vulnerabilities as well:

• CVE-2022-0847: a vulnerability known as Dirty Pipe, which enables privilege escalation and the hijacking of running applications
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation
• CVE-2021-22555: a heap out-of-bounds write vulnerability in the Netfilter kernel subsystem
• CVE-2023-32233: another Netfilter subsystem vulnerability that allows for Use-After-Free conditions and privilege escalation through improper processing of network requests

Dynamics of the number of Linux users encountering exploits, Q1 2025 – Q2 2026. The number of users who encountered exploits in Q1 2025 is taken as 100% (download)

In Q2 2026, the number of Linux users who encountered exploits declined slightly compared to Q1. Given that a significant share of new vulnerabilities are tied to the operating system’s caching subsystem, we recommend installing patches as quickly as possible, or disabling vulnerable kernel modules if patching isn’t an option.

Most common published exploits

The distribution of published exploits by software type in Q2 2026 includes categories that haven’t appeared in the sample for a long time. For instance, we’re once again seeing exploits targeting SharePoint. It’s worth noting that while several vulnerability write-ups for Exchange and SharePoint were published during the quarter, most turned out to be fake, AI-generated research. While the articles and exploit source code themselves look fairly polished, they describe nonexistent problems in the software or its components — often close to genuinely vulnerable mechanisms — in order to mislead researchers. This type of attack is aimed at increasing the time it takes to detect real vulnerabilities. In some cases, the description of a nonexistent vulnerability came bundled with completely unrelated malware.

Distribution of published exploits by platform, Q1 2026 (download)

Distribution of published exploits by platform, Q2 2026 (download)

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were exploited in APT attacks during Q2 2026. The rankings provided below include data based on our telemetry, research, and open sources.

TOP 10 vulnerabilities exploited in APT attacks, Q2 2026 (download)

In Q2 2026, a trend emerged in APT attacks toward exploiting new vulnerabilities right from the moment they’re published. As before, we’re also seeing a large number of zero-day vulnerabilities. The Langflow vulnerability deserves particular attention: it’s one of the first cases of an APT group exploiting AI technology, which many organizations are only just beginning to integrate. Because most of this tech is proprietary, it has a considerable number of security blind spots. Therefore, given the growing number of AI-based automation tools, we strongly recommend going beyond the usual patching and developing secure procedures for credential use and sensitive data handling in systems that rely on agents and LLMs.

C2 frameworks

In this section, we examine the most popular C2 frameworks used by APT groups and analyze the vulnerabilities targeted by the exploits that interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks during Q2 2026, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems, Q2 2026 (download)

Sliver, Havoc, AdaptixC2, and Metasploit remain the most widely used C2 frameworks. After studying open sources and analyzing samples of malicious C2 agents that contained exploits, we determined that the following vulnerabilities were utilized in APT attacks involving the C2 frameworks mentioned above:

• CVE-2026-35273: a vulnerability in Oracle PeopleSoft PeopleTools that security vendors classify as server-side request forgery (SSRF). The details of the vulnerability have never been disclosed, although some research covers the post-exploitation steps
• CVE-2023-46604: an insecure deserialization vulnerability in Apache ActiveMQ that allows arbitrary code execution in the context of the service process
• CVE-2024-12356 and CVE-2026-1731: command injection vulnerabilities in BeyondTrust software that allow an attacker to send malicious commands even without system authentication
• CVE-2023-36884: a vulnerability in the Windows Search component that allows commands to be run on the system, bypassing the mark-of-the-web (MoTW) mechanism
• CVE-2025-53770: an insecure deserialization vulnerability in Microsoft SharePoint that allows for unauthenticated command execution on the server
• CVE-2025-8088 and CVE-2025-6218: similar directory traversal vulnerabilities in WinRAR that allow files to be extracted from an archive to a predetermined path, potentially without the archiving utility displaying any alerts to the user

These vulnerabilities show that attackers used them for initial access and privilege escalation on vulnerable systems, setting the stage for launching a C2 agent. They include both zero-day vulnerabilities and fairly well-known security issues.

LLM/AI tool vulnerabilities

This section analyzes data published in Kaspersky’s vulnerability knowledge base. We reviewed the Q2 2026 version of the knowledge base.

As mentioned above, AI tools, plugins, and technologies have proven fairly effective at automating the search for problematic code and anomalous behavior. The high speed at which new vulnerabilities are being discovered has naturally created a need to fix them just as quickly. AI is often used for this too, which increases the volume of code being generated. However, neither code written without human involvement nor AI-generated advice is always correct.

The chart below covers registered vulnerabilities in AI tools for 2025–2026.

Number of published vulnerabilities in LLMs, AI tools, and plugins with similar functionality, 2025–2026 (download)

As the charts show, AI tools are racking up a substantial number of registered vulnerabilities, and that number keeps growing quarter over quarter. It’s also worth looking at how AI tool vulnerabilities break down by type, according to the CWE system:

Interestingly, vulnerabilities of an undetermined type have ranked first in every quarter since the start of 2025. Traditionally-made software has the same issue, and it doesn’t look like the growing number of AI tools will fix it. It’s also notable that the list includes classes CWE developers themselves don’t recommend using for vulnerability classification, since they lump together a whole range of more specific types. CWE-284 is an example of this.

Looking at the most common classes, the key issues found in AI-related software can be summed up as follows:

• Inadequate access control over critical system objects
• Improper implementation of authentication and authorization mechanisms
• Injections

It’s worth noting that injection-related vulnerabilities were relatively rare before AI agents took off (previously, they mostly affected web apps). Recently, though, these security issues have become relevant again.

Looking back at a year and a half of the AI boom, one conclusion stands out regarding registered vulnerabilities: AI tool developers are more focused on expanding functionality than on security. This is worth keeping in mind when using these tools. Let’s look at the projects and applications that either integrated AI tools or offered them as the core product. Below is a list of the those with the highest number of registered vulnerabilities for 2025–2026.

TOP AI/LLM-related projects by number of published vulnerabilities, 2025–2026 (download)

Notable vulnerabilities

This section highlights the most significant vulnerabilities published in Q2 2026 that have publicly available descriptions. Since the above already covers several significant vulnerabilities published during the reporting period, this section consists mainly of LLM/AI tool vulnerabilities.

CVE-2026-25253: a gatewayUrl vulnerability in OpenClaw

The issue stems from the fact that the OpenClaw user interface trusts the value of the gatewayUrl parameter passed in the URL and automatically establishes a WebSocket connection to the specified address. During this connection process, it sends an authentication token without any additional user confirmation.

The attack algorithm exploiting this vulnerability works as follows:

1. The application obtains a critical connection address from an external source (the gatewayUrl URL parameter), which is controlled by the attacker.
2. There is no validation before use.
3. The client automatically initiates a connection to the address specified in the parameter, which belongs to the attacker.
4. While connected, the application sends credentials (an access token) to the specified address.

If the attacker obtains a valid token, the consequences depend on that token’s level of access within the system. In general, this could lead to:

• User session compromise
• Execution of operations on the user’s behalf
• Modification of the AI agent configuration
• Unauthorized access to tools and resources connected to the agent
• Under certain OpenClaw configurations, further compromise of the host running the agent

It’s worth noting that the risk of exploitation arises from a combination of several factors: the automatic connection and token transmission, the lack of address trust verification, and the high privileges granted to the local AI agent.

CVE-2026-41948: a path traversal vulnerability in the Dify AI platform

The vulnerability lets an authenticated user craft a request that enables the application to escape its permitted tenant and gain access to internal REST APIs that weren’t meant for that user. The root cause is insufficient normalization and validation of the URL path before it’s passed to the internal service.

Depending on the Dify configuration, the consequences can include:

• Unauthorized access to internal service interfaces
• Breach of isolation between workspaces
• Exposure of internal service information
• Conditions favorable to further attacks when combined with other vulnerabilities

The use of Dify in enterprise AI platforms is particularly risky, since internal services there tend to hold elevated privileges.

CVE-2026-45386: an improper access control vulnerability in Open WebUI

In Open WebUI, pin/unpin operations on messages are write operations, since they modify that message’s metadata (is_pinned, pinned_by, pinned_at). In vulnerable versions, however, before performing these actions, the API only checked for read access to the channel (a chat between a user or group and the AI) containing the message, not permission to modify its content. As a result, a user with a role limited to viewing messages could still change a message’s pinned status.

The vulnerability’s mechanism works as follows:

1. The user initiates an action that changes the state of an object.
2. The application treats this action as a regular read request.
3. Only channel view permission is checked.
4. The application performs a write without verifying the required user authorization.

This violates one of the fundamental principles of access control models — namely, that any operation that changes the state of data must be checked for the appropriate write or moderation permissions, regardless of whether the object itself is readable.

Although the vulnerability doesn’t lead to arbitrary code execution or compromise of sensitive data, it can affect data integrity and collaborative workflows. Potential consequences of exploitation include unauthorized pinning or unpinning of messages, disruption of channel moderators’ and administrators’ activities, changes to the display order of important information, and even the potential spread of false or misleading information by altering the channel containing a pinned message.

Open WebUI is widely used as an interface for interacting with local and enterprise LLMs. In these systems, pinned messages often contain important instructions, announcements, or tips for users. The ability to modify them with minimal privileges can disrupt collaborative workflows, cause confusion, and undermine trust in information published by administrators and moderators.

CVE-2026-45501: a vulnerability in Microsoft Exchange

The vulnerability stems from improper neutralization of user input when generating Exchange web pages. As a result, the browser may interpret specially crafted data as active content instead of plain text.

Although Microsoft categorizes the potential impact of exploiting this vulnerability as spoofing, flaws like this can lead to alteration of displayed content, imitation of trusted interfaces, actions on behalf of the user within an active session, and abuse of user trust.

It’s worth noting that issues like this are still relevant in modern software, given that mechanisms like Content Security Policy and various parsers were specifically created to help developers neutralize dangerous parts of user page content.

Conclusion and advice

Q2 brought the first significant results of AI automation adoption in software development and vulnerability hunting tools. This research shows that beyond traditional patch management, organizations now need real-time monitoring of systems and access controls, since infrastructure and everyday applications now contain far more AI functionality that could lead to compromise.

Accordingly, besides quickly detecting infrastructure vulnerabilities and managing security patches, modern enterprise-grade security solutions need to provide a broad range of preventive measures for tracking the overall health of systems and workstations. Kaspersky Next meets these requirements by combining proactive mechanisms with the ability to respond promptly to emerging threats.

OpenClaw, which was previously known as Clawdbot and Moltbot, is today one of the most successful and fast‑growing ecosystems for AI agents, recognized worldwide. The project quickly became popular with users because of its flexibility and ability to solve fairly complex tasks that previously required a lot of time for automation and execution. A dedicated marketplace appeared quickly after the project started gaining traction, where developers and users began publishing tools that integrate with OpenClaw. Currently, employees all over the world use OpenClaw to automate their tasks, often unaware of risks this practice introduces to them and their employers.

In this article we will examine several security aspects of OpenClaw, look at how attackers can target this system, which vulnerabilities are already known, and how to protect your organization against these issues.

OpenClaw skills

The project’s success was ensured by the fact that the agent accepts natural language instructions, does not require knowledge of programming languages, and allows the use of skills, which expand its capabilities. The overall architecture of OpenClaw can be seen below:

As shown in the diagram, the system is designed to be used with agent skills. These skills can reside locally on the system where the agent is installed or they can be obtained from external sources. At the time of writing this article, a dedicated hub named “ClawHub” is used for sharing skills with other users.

One of the key features of OpenClaw skills is that they are easy to create and do not require coding. A skill is in essence a set of commands written in natural language, although it can contain code. Currently, there is a general description of the skill format: it is usually a text file named SKILL.md, although more complex variants may exist. The primary requirement for these files is that they use a plaintext format. To illustrate what this looks like, here is a fragment of a skill:

The applications for OpenClaw skills are quite broad and can include everyday tasks like checking email, performing routine operations and calculations on a computer, as well as more complex pipelines that handle testing, research, or software development. For most actions, the agent requires access to the operating system’s file system, as well as to the tokens and keys of the systems it will interact with. All necessary data are usually provided by users either through environment variables or in plaintext files located alongside the agent.

Since many skills enable automation of work processes, employees worldwide actively use them. This fact, combined with the widespread adoption of the system and the overall popularity of artificial‑intelligence technologies, has attracted attackers to the project.

OpenClaw vulnerabilities

In less than two years, around 530 vulnerabilities have been discovered both in OpenClaw itself and in the underlying technologies. That said, the publication of OpenClaw vulnerabilities in the CVE database began only in February 2026. Below is a breakdown of these vulnerabilities by severity.

Registered vulnerabilities (download)

As shown in the chart, the number of high-severity vulnerabilities is quite large. Most of these vulnerabilities fundamentally involve issues with storing sensitive data and operating with excessively high privileges. Each of them can be exploited to hijack the agent or inject commands that it will execute.

Malicious skills

Besides exploiting vulnerabilities and deceiving users, there are more specific attack vectors against OpenClaw, namely, skills.

Research logically draws a parallel between supply‑chain attacks and the distribution of malicious skills. However, unlike usual supply-chain attacks, creating malicious skills is trivial because there is no longer a need to develop custom malware. Despite this, until February 7, 2026, no skills had undergone even a basic security check, which allowed malicious skills to appear immediately. Our scan of the skill hub in April identified 24 accounts that were distributing more than 600 malicious skills. Overall, open‑source intelligence indicates that over 1100 malicious accounts have been created since January.

Following the investigations and a lengthy effort to clean the skill repository of malicious entries, it was announced that files would undergo preliminary scanning with VirusTotal (VT) and NVIDIA’s SkillSpector. On the one hand, this is a more responsible approach to publishing skills; on the other, because OpenClaw is primarily an agent that executes a set of instructions, detecting malicious activity moves to a different level. Now it is necessary not only to analyze a file for dangerous commands that should be blocked, but also to examine all possible malicious behaviors that could be triggered by a harmful instruction within a skill. An example of a malicious command in natural language:

An example of a malicious command using a part of a bash command:

The example in the image and similar malicious skills are detected by Kaspersky products as HEUR:Trojan.ANSI.MalClaw.gen.

In addition, Kaspersky products monitor malicious OpenClaw skill activity on the system. Below are detection statistics from our systems that have identified malicious OpenClaw client behavior. The data for June cover the first half of the month.

Statistics on Kaspersky product detections of OpenClaw malware (download)

As shown in the chart, even despite the measures taken to counter the publication of malicious skills, attacks continue. Therefore, it is important to employ layered protection that isolates the OpenClaw agent from critical data and infrastructure systems. We also recommend checking all skills that enter the organization’s perimeter. For this purpose, Kaspersky Scan Engine is suitable. This solution is designed to protect web applications, proxy servers, network attached storage, and mail gateways. It can be integrated into almost any application, and it is easy to deploy and manage.

Additionally, monitor network accesses used by the agent. For this purpose, the project already provides a sandboxing subsystem and various wrappers for working with APIs and services. Last but not least, develop a comprehensive AI policy and make sure your employees never use third-party tools that they are not explicitly allowed to use.

Small and medium-sized businesses (SMBs) remain attractive targets for cybercriminals – in both mass cyberattacks and sophisticated campaigns targeting larger enterprises through trusted relationship attacks. At the same time, smaller businesses may lack the robust cybersecurity policies and necessary resources to protect themselves against an evolving threat landscape.

Kaspersky believes that raising awareness can help small and medium-sized enterprises develop an effective protection strategy. Ahead of International SMB Day on June 27, Kaspersky presents the findings of its 2026 threat analysis for SMBs, which includes real-world examples of attacks.

Key findings

• In the first four months of 2026, Kaspersky solutions detected over 33,300 cyberattacks on SMBs masquerading as popular artificial intelligence (AI) tools – almost five times more than in 2025 and 39% more than the number of attacks disguised as the office and collaboration tools that Kaspersky’s research focuses on.
• Popular messengers and communication services remained the attacker’s most widespread lure, with almost 415,000 attacks involving fake messenger apps and video conferencing software.
• The attackers follow trends: the AI tools Claude and OpenClaw (ex-ClawdBot/MoltBot), which have gained popularity in 2026, were among the common AI lures.
• Fraudsters use fake AI tools to scam businesses out of money, while corporate accounts on social media also remain targets.
• The majority of initial accesses to corporate infrastructures sold on the dark web are allegedly accesses to SMBs. This could be because SMBs tend not to be as well protected as large enterprises and, at the same time, may be trusted contractors for those well-protected enterprises.

Malware and potentially unwanted applications (PUAs) disguised as popular services

Kaspersky researchers used data from Kaspersky Security Network (KSN) to explore how frequently malicious and unwanted files are disguised as legitimate applications that may be used by SMBs. KSN is a system for processing anonymized cyberthreat-related data shared voluntarily by Kaspersky users. For this part of the report, only anonymized data received from users of Kaspersky solutions for SMBs were analyzed.

According to a survey by the Small Business & Entrepreneurship Council (SBE Council), small business owners continue to embrace artificial intelligence and digital transformation as they maintain a generally positive outlook on the economy. Threat actors are also aware of the hype surrounding AI and exploit it for their own benefit. In particular, they actively distribute cyberthreats under the guise of popular AI services.

From January to April 2026, Kaspersky solutions detected 33,352 attacks on SMB users in which malware or potentially unwanted applications for PCs were disguised as five popular AI services. This figure represents an increase of almost five times compared to the previous year. This highlights an evolving trend in which threat actors are weaponizing trust in widely used AI platforms and services, especially popular ones like Claude. Kaspersky experts note that it’s important to download apps from official sources and to verify which apps are available for which platforms.

Share of attacks targeting SMBs in which malware or PUAs mimic the five popular, legitimate AI apps that Kaspersky’s research focuses on, first four months of 2025 and 2026 (download)

In the first four months of 2026, Kaspersky researchers also identified more than 1,100 unique samples of malware and PUAs detected in the SMB sector that masqueraded as five popular AI applications, representing a 21% increase compared to the same period of 2025. The samples were mainly different types of Trojware (Trojans and Trojan-like malware), including those capable of downloading and running other malware on compromised devices. Trojware disguises itself as harmless files to trick users into installing them. Their functionality may vary depending on the particular type of Trojware. This may include stealing, deleting, blocking, modifying or copying users’ data, as well as other malicious actions. Trojware therefore represents a highly dangerous cyberthreat to entrepreneurs and businesses.

Kaspersky experts also note that the threat landscape is constantly evolving with new lures appearing all the time. For example, in the first four months of 2026, Kaspersky solutions blocked hundreds of attacks in which malware or PUAs for PCs were disguised as OpenClaw (previously known as Clawdbot or Moltbot).

Other lures for SMBs: Fake communication apps and office software

Kaspersky analysts also explored how attackers leverage other legitimate applications as lures to target SMBs. For example, from January to April 2026, Kaspersky solutions blocked 414,736 attacks on SMB users in which malicious software or PUAs for PCs were disguised as the popular communication apps that Kaspersky’s report focuses on. The number of attacks changed marginally compared to the previous year’s figure, indicating that the lure of fake communication apps remains a serious cyberthreat.

Share of attacks targeting SMBs in which malware or PUAs mimic the four legitimate communication apps covered by Kaspersky’s research, first four months of 2025 and 2026 (download)

Various fake office applications and collaborative platforms also remain among the lures that attackers may exploit to target SMBs. According to Kaspersky telemetry, more than 24,000 attacks were detected from January to April 2026 in which malware or PUAs for PCs were disguised as specific office applications.

Share of attacks targeting SMBs in which malware or PUAs mimic the six popular office applications and collaboration tools covered by Kaspersky’s research, first four months of 2025 and 2026 (download)

In 2026, AI-related baits have become more widespread among cybercriminals than traditional fake office and collaboration tools. Kaspersky experts note that the more publicity and hype there is around certain tools, the more likely a user is to come across a fake package online.

Scammers and phishers tricking victims into providing credentials and funds

In 2026, Kaspersky researchers observed a wide range of phishing campaigns and scams targeting businesses and entrepreneurs. Fraudsters mimic financial and AI services as well as other platforms in order to steal credentials, personal information and funds.

In the following example, fraudsters disguise themselves as a bank that allegedly offers services for businesses (in other similar schemes they may offer business loans). Entrepreneurs are prompted to visit a scam website and enter their data to open a business account. The requested information varies depending on the scam, but may include name, email address, phone number, social security number, date of birth and address. Scammers may then use this data in their schemes or sell it on the dark web.

Kaspersky experts advise: if you encounter such a website, you should not rush to enter any data. First, examine it. Does the purported financial organization actually exist? How old is the website? Check the WHOIS records and read user reviews before entering any information on the page.

As with many other cyberthreats, AI services are also leveraged as a lure in scams. For example, Kaspersky experts identified a scam website for an AI service “built for contractors”. According to the text on the fraudulent page, the tool can help with “estimates, invoices and schedule”. However, in reality, in such schemes victims usually receive nothing after paying for a subscription, while the scammers get all the money.

Kaspersky experts note that business accounts on social networks and messengers remain attractive targets for cybercriminals in 2026. In one scheme, phishers distributed notifications with fake alerts related to companies’ business pages. The notifications claimed that Facebook’s review system had detected behavior that seriously violated its Community Standards and Advertising Policies. To avoid permanent restriction of their business page on the social network, owners were prompted to fill out an appeal form and provide personal and business email addresses, phone numbers, as well as the name of their business page and the password for their social network account. The attackers’ goal was to obtain credentials. To reduce user vigilance  and appear legitimate, fraudsters also sent victims a fake appeal code.

Email threats: Fake online documents and exploitation of legitimate platforms

Email remains one of the most widely used channels for cyberattacks targeting enterprises, including small and medium-sized businesses. In 2026, attackers have frequently combined email distribution with the exploitation of legitimate third-party platforms. This is how phishers and scammers usually attempt to bypass traditional email filters and exploit user trust in reputable services. Kaspersky researchers have also observed a large number of schemes targeting corporate users in which phishers and scammers use fake online documents or nonexistent meetings as bait.

In one recent scheme detected by Kaspersky, the attackers sent a fake notification disguised as a letter from OneDrive. The victim was prompted to access the document by clicking a button, but in reality, it led to a phishing website where users risked losing their confidential data. To make the email appear legitimate, the attackers added a phrase designed to  lower the victim’s vigilance: “This item is encrypted and hosted within your secure cloud perimeter.” They also parsed the recipient’s email address and used the extracted data in the fake notification text so that the email looked like a standard notification from this type of service: “[email address domain as company name] has successfully uploaded a new file for [the user’s name as stated in their email address].”

Attackers also use other pretexts to trick victims into sharing confidential information, for example fake compliance issues. In the example below, the attackers posed as Apple representatives. The fake notification stated: “Apple has identified a compliance issue related to Google Ads campaigns directing traffic to Apple product detail pages associated with the victim’s seller account.” However, the button in the email led to a phishing website where users are tricked into sharing confidential data.

Kaspersky experts observed another notable two-stage scheme aimed at stealing credentials from corporate emails, which involved distributing an invitation to a nonexistent meeting. The scheme is deployed in two stages. In stage one, a corporate user receives an email about a fictitious meeting. After clicking the “Accept Meeting Invitation” button, the user is redirected to a legitimate Zoom Docs (previous Zoom canvas brand) page. In stage two, the victim is prompted to click a hyperlink that reads “Click Here to Accept Meeting”. However, the URL of a phishing page is hidden behind this hyperlink.

Malware is also actively distributed via email. In 2025, individuals and corporate users encountered over 144 million malicious and potentially unwanted email attachments, representing a 15% increase from the previous year.

Kaspersky experts note that the lures used in subject lines and texts of malicious emails can appear relatively harmless and rather unsophisticated. In the example below, the attackers target businesses with a fake request for “the best quote for the items attached.” However, the attached file actually contains a Trojan.

Corporate infrastructure access for sale: Posts on the dark web

To assess threat actor activity, Kaspersky Digital Footprint Intelligence experts analyzed hundreds of posts offering initial access to corporate infrastructures published on dark web forums from January to April of both 2025 and 2026. Kaspersky experts note that a single post may contain several offers for access to different allegedly compromised companies.

Initial access brokers (IABs) sell initial access to compromised businesses, for example, via RDP or web shells. In their posts, IABs may provide information about the region where the allegedly compromised companies are located, their industry and revenue, as well as the type of access. IABs sell access that the buyers can then use for different purposes, including ransomware attacks, stealing corporate confidential information or other fraudulent activity. The price of initial access on dark web forums may depend on the revenue, industry or location of the allegedly compromised companies, or on the access privileges. For example, accounts with admin rights are usually more expensive because they can provide attackers with a wide range of possibilities.

According to the research, there were more posts offering initial access to companies of different sizes located in the Middle East (up 53% from last year), Africa (up 40%) and Latin America (up 17%). Meanwhile the number of posts related to companies located in Europe decreased by 34%. According to Kaspersky experts, this decline can be partially explained by the closure of a dark web forum containing such posts around the time of the study. The number of publications related to companies located in the APAC region also decreased slightly (down 4%), but remained at a consistently significant level for the second year in a row.
At the same time, the number of posts where the region was not specified decreased by 56% in 2026 compared to the previous year. Kaspersky analysts assume that this may indicate that initial access posts from IABs are becoming more targeted and unique.

Share of posts with initial access offers by business size

For this research, Kaspersky experts defined a small business as having an annual revenue of up to US$50 million, and a medium-sized business as having an annual revenue of between US$50 million and US$1 billion.

According to Kaspersky’s research, at the beginning of 2026 the share of posts on dark web forums with offers of initial access to allegedly compromised small businesses was larger than the shares of posts offering access to medium, large or nonprofit organizations. However, this share decreased in the first four months of 2026 compared to the same period in 2025. The share of posts concerning medium‑sized organizations also remained significant for two consecutive years. Taken together, posts concerning small and medium‑sized organizations account for more than half of all the analyzed posts with initial access offers on dark web forums.

At the same time for a certain number of posts initial access brokers didn’t indicate companies’ revenue, therefore, making it impossible to determine the size of the company.

Share of posts with initial access offers by business size, January–April 2025 (download)

Share of posts with initial access offers by business size, January–April 2026 (download)

Kaspersky experts note that despite the prevalence of posts concerning small businesses, threat actors may target medium‑sized businesses because they generate higher revenues than small businesses and may have weaker security defenses than large businesses.

SMBs can also become targets as a part of trusted relationship attacks, which enable the attackers to reach larger organizations. According to the Global Report by Kaspersky Security Services, the share of trusted relationship attacks among the initial vectors increased from 12.7% in 2024 to 15.5% in 2025. Therefore, the common belief that small and medium‑sized enterprises are of no interest to attackers is a misconception. Companies of all sizes need to understand the cyberthreat landscape, adhere to cybersecurity rules, implement appropriate cybersecurity solutions, and continuously improve employee awareness.

Cybersecurity action plan for SMBs

SMBs can reduce risks and ensure business continuity by investing in comprehensive cybersecurity solutions and increasing employee awareness. To protect themselves from the ever-evolving threat landscape, companies are advised to follow these rules:

1. Define access rules for corporate resources such as internet services, email accounts, shared folders, and online documents. Keep access lists up to date and revoke access promptly when employees leave the company.
2. Regularly back up important data to ensure the preservation of corporate information in case of emergencies.
3. Establish clear guidelines for using external services and resources. Create well-defined procedures for coordinating specific tasks, such as implementing new software, with the IT department and other responsible managers. Develop short, easy-to-understand cybersecurity guidelines for employees, with a special focus on account and password management, email protection, and safe web browsing. A well-rounded training program will equip employees with the necessary knowledge and ability to apply it in practice.
4. Raise employees’ security awareness. Conduct dedicated training to teach staff how to detect and address potential threats, and track their educational progress. Organizations can achieve this with the Kaspersky Automated Security Awareness Platform through interactive online modules and simulated phishing campaigns that build sustainable cyber hygiene habits across all teams.
5. Implement specialized cybersecurity solutions that fit your budget, size, and industry requirements, with an emphasis on scalability and ease of integration.
   1. Kaspersky Small Office Security Premium is an easy-to-use solution that protects against advanced threats and also provides access to security awareness training for employees, making it ideal for micro-businesses.
   2. Small and medium-sized enterprises with more mature IT expertise should consider Kaspersky Next Optimum, which is designed specifically for growing organizations and offers real-time protection, threat visibility, as well as EDR and XDR investigation and response capabilities.
6. Protect your business against email-borne threats. Kaspersky Security for Mail Server, a comprehensive email security platform that offers robust, multi-layered protection at mailbox and gateway levels, can help with this. Powered by machine learning and leading global threat intelligence, it effectively addresses all mail security challenges.
7. Adopt specialized solutions such as Kaspersky Digital Footprint Intelligence to monitor the surface, deep, and dark webs for information about a company’s credentials, leaked data, and lookalike websites. Small and medium-sized companies with limited IT security budgets can partner with a managed security service provider (MSSP) to access this comprehensive digital risk protection service at an affordable, subscription-based price point.

Executive Summary: Bypassing Boundaries in Enterprise AI Infrastructure

The massive global adoption of artificial intelligence (AI) and large language models (LLMs) has fundamentally rewritten the enterprise threat landscape. Modern high-compute bare metal clusters, cloud nodes, and developer workstations now routinely host dense data science stacks running frameworks such as TensorRT LLM, PyTorch, and deep CUDA execution layers. To process complex matrix calculations efficiently, low-privilege user mode tasks require direct pipelines straight to the underlying graphics acceleration hardware.

This week on the Lock and Code podcast…

If you weren’t taking deepfakes seriously before, it’s too late now to ignore them.

According to new research from Malwarebytes, one in three people who use AI every day said it’s okay to generate pornography of people without their consent.

Nearly 10 years ago, “deepfake” technology provided hobbyists and film editors with artificial intelligence (AI) tools to swap the face of one person onto the body of another. In its infancy, this technology brought silly film experiments like swapping Tom Cruise in Mission Impossible with Keanu Reeves. Today, this same technology produces something far more harmful—fake nude images of teenagers.

On the Lock and Code podcast today with host David Ruiz, we are re-visiting an interview from 2024, in which we spoke with a lawyer named David Chiu about his lawsuit against 16 deepfake nude generation websites.

The websites named in that lawsuit often needed just one image of a person to generate fake pornography. And while nearly everyone has at least one image of themselves online, even if they had hundreds, the path towards deletion is somewhat understood—start by deactivating and deleting popular social media accounts. But for teenagers today, raised mostly online, and who share images directly with friends and boyfriends and girlfriends and exes, it’s likely impossible to remove every visual trace of themselves. Also, they shouldn’t have to face this problem alone.

The Lock and Code podcast frequently discusses structural problems that require individual management. You have to skirt corporate data collection. You have to find the automated license plate readers in your hometown. You have to review every single message you get with a certain antagonism, to guard yourself against scams.

So, it’s rare to encounter a solution that benefits more than one person.

Chiu serves as the City Attorney for San Francisco, which means his department can file a lawsuit on behalf of not just the people of San Francisco, but also California, and that’s what his team did in going after the deepfake websites.

Since then, Chiu’s department has shut down 10 deepfake nude websites, and it received a settlement agreement from a company called Briver LLC to no longer operate any website that creates nonconsensual deepfake pornography.

And, as California goes, so goes the nation.

In May of last year, the Take It Down Act became effective as law in the United States, which criminalizes “revenge porn” and AI-generated nonconsensual intimate imagery. The law is not perfect but so far it is being used as intended. Last month, two men in the US were among the first to be charged with violating the Take It Down act for allegedly creating deepfake nudes that, according to the AP, “included both celebrities as well as private women, including recent high school graduates.”

Today, we revisit our conversation with San Francisco City Attorney David Chiu about the important fight against deepfake porn and the clear threat that his department found against the public.

“At least one of these websites specifically promotes the non-consensual nature of this. So, and I’ll just quote, ‘Imagine wasting time taking her out on dates when you can just use website X to get her nudes.'”

Tune in today to listen to the full conversation.

Show notes and credits:

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/
Outro Music: “Good God” by Wowa (unminus.com)

---

Listen up—Malwarebytes doesn’t just talk cybersecurity, we provide it.

Protect yourself from online attacks that threaten your identity, your files, your system, and your financial well-being with our exclusive offer for Malwarebytes Premium Security for Lock and Code listeners.

By Yarden Porat

AI agents need memory. Frameworks like LangGraph provide it through checkpointers – persistence layers that store execution state. But what happens when that persistence layer isn’t locked down?

Key Points

• Check Point Research analyzed LangGraph, an open-source framework for stateful AI agents with over 50 million monthly downloads, and uncovered three vulnerabilities in its persistence layer.
  
• Two of them chain into remote code execution: a SQL injection in the SQLite checkpointer (CVE-2025-67644) and an unsafe msgpack deserialization (CVE-2026-28277).

• A third, parallel issue (CVE-2026-27022) introduces the same injection class into the Redis checkpointer.
  
• Who’s at risk: teams self-hosting LangGraph with the SQLite or Redis checkpointer, where the application exposes get_state_history() with a user-controlled filter. LangChain’s managed cloud service, LangSmith Deployment (formerly LangGraph Platform), runs PostgreSQL and is not vulnerable.

• LangChain patched all three issues. Users should update to langgraph-checkpoint-sqlite 3.0.1+, langgraph 1.0.10+, and langgraph-checkpoint-redis 1.0.2+.

Background

LangGraph is an open-source framework for building stateful, multi-agent AI systems with built-in persistence. It’s an extension of LangChain, with over 50 million monthly downloads according to PyPI stats.

Checkpointers are LangGraph’s persistence layer that stores execution state at each step. LangGraph supports two checkpointer implementations: SQLite and PostgreSQL.

Vulnerability #1: SQL Injection (CVE-2025-67644)

The SQLite Checkpointer Database Schema:
The SQLite checkpointer uses an internal table called checkpoints with the following structure:

CREATE TABLE checkpoints (
    thread_id TEXT NOT NULL,
    checkpoint_ns TEXT NOT NULL DEFAULT '',
    checkpoint_id TEXT NOT NULL,
    parent_checkpoint_id TEXT,
    type TEXT,
    checkpoint BLOB,
    metadata BLOB,
    PRIMARY KEY (thread_id, checkpoint_ns, checkpoint_id)
);

The metadata column stores additional contextual information about each checkpoint in JSON format. For example:

{
  "user_id": "alice",
  "step": 1,
  "source": "input"
}

The list() Function and Filtering:

When calling the list() function on sqliteSaver (the checkpointer), the filter parameter is used to query checkpoints based on their metadata:

def list(
    self,
    config: RunnableConfig | None,
    *,
    filter: dict[str, Any] | None = None,  # Used to filter by metadata
    before: RunnableConfig | None = None,
    limit: int | None = None,
) -> Iterator[CheckpointTuple]:

The filter parameter is passed to an internal function called _metadata_predicate, which constructs the SQL WHERE clause to query checkpoints by their metadata fields.

# process metadata query
    for query_key, query_value in filter.items():
        operator, param_value = _where_value(query_value)
        predicates.append(
            f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"
        )
        param_values.append(param_value)

    return (predicates, param_values)

The Injection

The vulnerability exists in how _metadata_predicate handles the query_key from the filter dictionary.
Notice this critical line:

f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"

An attacker-controlled filter could provide a query_key with a ' character that will escape the JSON path string and inject arbitrary SQL code.

Injection -> Arbitrary Deserialization

To understand how SQL injection leads to arbitrary deserialization, we need to see the complete picture.
Here’s the SQL query that gets executed in list():

query = f"""SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata
FROM checkpoints
{where}
ORDER BY checkpoint_id DESC"""

This query retrieves checkpoint data from the database, including the checkpoint’s BLOB column.
The results are then processed:

async for (
    thread_id,
    checkpoint_ns,
    checkpoint_id,
    parent_checkpoint_id,
    type,
    checkpoint,  # ← This comes directly from the SQL query results
    metadata,
) in cur:  # ← cur contains the query results
    # ... 
    yield CheckpointTuple(
        # ...
        self.serde.loads_typed((type, checkpoint)),  # ← Deserialization
        # ...
    )

The checkpoint contains serialized data, and when fetched gets deserialized.

The Attack

Using SQL injection in the WHERE clause, an attacker can inject a UNION SELECT that adds their own row to the query results:

SELECT thread_id, checkpoint_ns, checkpoint_id, parent_checkpoint_id, type, checkpoint, metadata
FROM checkpoints
WHERE ... (injected: ') UNION SELECT 'thread1', 'ns', 'checkpoint1', NULL, 'msgpack', X'', '{}' -- )
ORDER BY checkpoint_id DESC

The injected UNION SELECT returns a fake checkpoint row where the checkpoint column contains attacker-controlled serialized data. When the code loops through the query results, it deserializes this malicious checkpoint’s BLOB, giving the attacker arbitrary deserialization

Vulnerability #2: MsgPack Unsafe Deserialization (CVE-2026-28277)

Now let’s examine what happens during deserialization. The self.serde.loads_typed() function that deserializes checkpoint data looks like this:

def loads_typed(self, data: tuple[str, bytes]) -> Any:
    type_, data_ = data
    if type_ == "null":
        return None
    elif type_ == "bytes":
        return data_
    elif type_ == "bytearray":
        return bytearray(data_)
    elif type_ == "json":
        return json.loads(data_, object_hook=self._reviver)
    elif type_ == "msgpack":
        return ormsgpack.unpackb(
            data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS
        )
    elif self.pickle_fallback and type_ == "pickle":
        return pickle.loads(data_)
    else:
        raise NotImplementedError(f"Unknown serialization type: {type_}")

Formats

1. Pickle –  is disabled by default
2. JSON –  The json.loads() with object_hook was discussed in our LangGrinch research, but does not lead to code execution
3. Msgpack – This is the one we are interested in

What is msgpack?

MessagePack (msgpack) is a binary serialization format designed to be faster and more compact than JSON. LangGraph uses ormsgpack, a Rust-based implementation with Python bindings.

Msgpack Extensions

MessagePack allows developers to define custom extension types to handle additional data types beyond its built-in primitives. LangGraph implemented its own extension handler to support serialization of custom Python objects.

When the type_ is msgpack, the code calls:

ormsgpack.unpackb(data_, ext_hook=self._unpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS)
```
The `ext_hook` parameter points to LangGraph's custom implementation: `_msgpack_ext_hook`.

```python
def _msgpack_ext_hook(code: int, data: bytes) -> Any:
    if code == EXT_CONSTRUCTOR_SINGLE_ARG:
        try:
            tup = ormsgpack.unpackb(
                data, ext_hook=_msgpack_ext_hook, option=ormsgpack.OPT_NON_STR_KEYS
            )
            # module, name, arg
            return getattr(importlib.import_module(tup[0]), tup[1])(tup[2])
        except Exception:
            return

When an attacker controls the serialized data, they control both the extension code and the data bytes.

The vulnerability

If we pass a msgpack with EXT_CONSTRUCTOR_SINGLE_ARG code, and the tuple:

1. os
2. system
3. Command (“echo PWN > /tmp/pwned.txt” for example)

When this line executes:

return getattr(importlib.import_module(tup[0]), tup[1])(tup[2])

It will:

1. Import the os module

2. Get the system function from it

3. Call os.system("echo PWN > /tmp/pwned.txt")

This gives an attacker arbitrary code execution – by calling os.system() with attacker-controlled commands, they can execute any shell command on the server.

The Attack Chain: Combining Both Vulnerabilities

Now let’s walk through how an attacker chains these two vulnerabilities together to achieve remote code execution.

The Entry Point: When a developer exposes get_state_history(), it internally calls the checkpointer’s list() method to retrieve historical checkpoints:

def get_state_history(
    self,
    config: RunnableConfig,
    *,
    filter: Optional[Dict[str, Any]] = None,
    before: Optional[RunnableConfig] = None,
    limit: Optional[int] = None,
) -> Iterator[StateSnapshot]:
    # ...
    for checkpoint_tuple in self.checkpointer.list(config, filter=filter, before=before, limit=limit):
        # Process and return checkpoint data

If the filter parameter comes from user input without sanitization, an attacker controls the dictionary keys passed to the SQL injection vulnerability.

The Attack Flow

1. Craft Malicious Payload: The attacker prepares a msgpack payload containing instructions to execute arbitrary code (e.g., run a shell command).

2. Exploit SQL Injection: The attacker sends a malicious filter parameter that exploits the SQL injection vulnerability. This injection adds a fake checkpoint row to the database query results, where the checkpoint column contains their malicious msgpack payload.

3. Trigger Deserialization: When the application processes the query results, it encounters the injected fake checkpoint and deserializes the malicious msgpack data.

4. Code Execution: The unsafe deserialization executes the attacker’s payload, giving them remote code execution on the server.

Vulnerability #3: SQL Injection in the Redis Checkpointer (CVE-2026-27022)

The same injection class affects langgraph-checkpoint-redis: user-controlled keys in the filter dictionary are interpolated directly into the query instead of bound as parameters. Preconditions match CVE-2025-67644 (the application exposes get_state_history() with a user-controlled filter and uses the Redis checkpointer). Patched in langgraph-checkpoint-redis 1.0.2.

Additional SQL Injection Findings

Beyond the primary SQL injection in the filter parameter, we identified additional defense-in-depth SQL injection issues in both the SQLite and PostgreSQL checkpointers. These involved direct concatenation of integer values (such as LIMIT and ttl parameters) into SQL queries instead of using parameterized bindings.

Since Python doesn’t enforce type hints at runtime, these parameters could still accept malicious string input. We worked with the LangChain team during disclosure to remediate these issues using parameterized queries.

Disclosure Timeline

2025-11-19: CVE-2025-67644 (SQL injection), CVE-2026-28227 (msgpack deserialization) And CVE-2026-27022 (Redis injection) disclosed to LangChain team

2025-12-10: CVE-2025-67644 fixed and publicly released in langgraph-checkpoint-sqlite 3.0.1

2026-02-20: CVE-2026-27022  fixed and publicly released in langgraph-checkpoint-redis 1.0.2

2026-03-05: CVE-2026-28277  fixed and publicly released in langgraph-checkpoint 4.0.1

Note on Vendor Response

The LangChain team responded quickly to fix the critical SQL injection vulnerability, which effectively breaks the attack chain described in this research. They continue to work methodically on additional remediation efforts, including the msgpack deserialization issue.

Additional Research

There was significant community research into LangGraph security during November and December 2025. Other security researchers independently discovered CVE-2025-67644 and CVE-2026-28277. Full credits can be found in LangChain’s security advisories.

The post From SQLi to RCE – Exploiting LangGraph’s Checkpointer appeared first on Check Point Research.

Introduction

Containerization using Docker has become firmly established in modern development standards, significantly increasing the speed and convenience of deploying various services. Developers often use ready-made Docker images, making only minimal changes. The largest repository of container images is the Docker Hub service.

Container-hosted infrastructure is an attractive target for attackers. At a minimum, a compromised container can be used for DDoS attacks, cryptocurrency mining, or traffic proxying. The list of threats does not end there: once an attacker gains control of a container, they can steal or destroy data directly from it, access neighboring containers, or even attempt to escape the container, compromising the entire enterprise network.

At the same time, the infrastructure inside containers is typically updated less frequently and may contain outdated and vulnerable software versions. When deploying third-party images or modifying them for a specific environment, it is easy to make configuration errors that attackers can later exploit. And due to the architectural characteristics of containers, developers often face constraints when preparing images; to overcome these, they may resort to insecure solutions they find online.

In other words, containerized infrastructure can be both the simplest and the most lucrative target to exploit. Therefore, its security requires heightened attention. To minimize the risk of successful attacks on container infrastructure, it is essential to check the final Docker images, including all underlying layers, for vulnerabilities and misconfigurations. The easiest way to do this is by analyzing the Dockerfile; however, it is not always available for inspection. Moreover, it typically defines how to build layers on top of a base image from an external repository whose reliability cannot be guaranteed.

To help users identify insecure configurations and potential vulnerabilities within them, we have added our AI assistant to Kaspersky Container Security.KIRA (the assistant’s name) uses artificial intelligence to analyze the image and identify potential issues within, along with recommendations on how to fix them.

As part of this study, we asked KIRA to analyze a number of popular community images, and later in this article, we’ll show you the results.

Software vulnerabilities and compromise of update sources

One of the key security issues with using pre-built images is that developers do not update them in a timely manner. A Docker image is, by its very nature, a snapshot of a specific Linux distribution after packages have been installed on it. However, in most cases, it does not receive security updates on its own, unlike traditional Linux servers, where these updates are automatically installed by specialized services, such as unattended-upgrades in Debian-based distributions and dnf-automatic in RedHat-based distributions.

To apply updates to a Docker image, it must be rebuilt and redeployed. Often, this process is not automated, and some updates require additional effort to verify their correct operation, modify configurations when upgrading to new software versions, and so on. As a result, many popular images do not receive timely updates, which significantly increases the risks associated with their use.

An image that was secure at build time accumulates vulnerabilities as they are discovered in the packages installed within it, which over time significantly increases the opportunities for a successful attack on the container.

Vulnerable versions of web applications and network services accessible from the internet immediately become targets of various malicious campaigns. For example, just one day after the discovery of the CVE-2025-55182 vulnerability in React Server Components, our honeypots recorded numerous attack attempts related to this vulnerability. It was adopted by operators of many malicious campaigns, ranging from classic cryptocurrency miners to variants of Mirai and Gafgyt. Attackers are constantly adding new distribution methods and can use dozens of exploits targeting various vulnerabilities and configuration errors in popular services. Often, the same vulnerabilities are used in self-propagation mechanisms from already compromised hosts. For example, in a malicious campaign to spread the Dero miner, attackers use infected containers to automatically search for and infect new targets.

In addition to vulnerabilities that can be exploited remotely, attackers are rapidly adding local vulnerabilities to their arsenal, used to gain root privileges and escape the container: in the Kinsing malware campaign, attackers used CVE-2023-4911 (Looney Tunables) to elevate privileges, and in the perfctl campaign, the CVE-2021-4034 (PwnKit) vulnerability was used for the same purpose. The access gained was used to install a rootkit that hides the presence of perfctl on the system.

To assess the situation with unpatched vulnerabilities in containers, we took a random sample of 100 images, which included various popular solutions with 10,000 to 1 million downloads on DockerHub. In the 64 images we scanned, we found outdated software versions with critical vulnerabilities. For example, some images contained the CVE-2025-49844 vulnerability in the Redis server, leading to RCE by leveraging a vulnerability in the Lua parser; the current CVE-2026-24061 vulnerability in nginx, which in some configurations leads to a server process crash, and with ASLR disabled, again, to RCE; vulnerabilities CVE-2025-32463 in sudo and CVE-2023-4911 in glibc, allowing an attacker to gain root privileges with local access. At the same time, only one in ten Docker images from the analyzed sample is fully up to date.

It is worth noting that, of course, not every discovered vulnerability can be directly exploited by attackers. A practical risk arises when the vulnerable application or library is actually in use, and the conditions necessary for exploitation – which vary significantly from vulnerability to vulnerability – are met. Nevertheless, updates must not be ignored, as the risk of vulnerabilities being exploited – both individually and in various combinations – cannot be predicted in each specific case, and even vulnerabilities that seem harmless at first glance can ultimately pose a serious risk of compromise.

However, frequent updates have a downside. Every rebuild that downloads new packages from source repositories introduces an additional risk of a supply chain attack – a compromised dependency or a modified base image could silently inject malicious code into your environment precisely through an update. During our analysis of images from the sample, we did not find any signs of supply chain attacks. However, in March 2026, a supply chain incident occurred in the Trivy and LiteLLM projects. In the case of Trivy, the infected file was injected directly into the container image in the official repositories.

This leads to a difficult choice: infrequent updates leave known vulnerabilities unpatched within the image, while frequent updates increase the risk of supply chain compromise. Therefore, to protect your infrastructure, you need not only to regularly update base images but also to take a more comprehensive approach, specifically by pinning dependencies to known-good versions and scanning the resulting images for malware upon update.

Configuration vulnerabilities

Even a container with a fully updated image can be compromised if it is configured incorrectly. Embedding keys and secrets in the image, disabling authentication in network services, default passwords, and insecure file access permissions – all of these can be exploited by attackers in one way or another to achieve their goals.

The situation is exacerbated by the fact that errors may be introduced by the authors of the original image, which complicates their detection, as this requires analyzing every layer and the command that generated it. As with vulnerabilities, not every configuration error leads to compromise: it all depends on the container’s role, its network accessibility, and many other factors. But the very use of insecure settings will sooner or later lead to errors appearing in images where their consequences will be significantly more dangerous.

Standard rules are often insufficient for analyzing problematic configurations. To gain a deeper understanding of the context and assess potential risks, AI tools can be used. Later in this section, we will examine examples of typical insecure configurations we discovered while scanning public images from Docker Hub, along with the descriptions of issues and risk mitigation methods provided by the KIRA AI assistant.

Insecure handling of credentials

Use of default passwords

In some cases, containers may use default passwords set via environment variables or directly in Dockerfile. If these passwords are not overridden, attackers will be able to access the application by using the default password.

RUN |1 DEBIAN_FRONTEND=noninteractive /bin/sh -c echo [removed]:[removed] | chpasswd

According to KIRA’s analysis, the user’s password is stored in plain text in the image layer history. Anyone who gains access to the image – whether through a public registry, a compromised build environment, or other means – will be able to extract the password. If SSH or another form of interactive access is enabled in the container, this could lead to its complete compromise and allow attackers to move laterally within the infrastructure.

Passwords may be present in environment variables. Consider the following Dockerfile snippet:

ENV SERVERNAME=localhost WWW_PATH_CONF=/etc/apache2/apache2.conf WWW_PATH_ROOT=/var/www HTTPS=on PKP_CLI_INSTALL=0 PKP_DB_HOST=db PKP_DB_NAME=pkp PKP_DB_USER=pkp PKP_DB_PASSWORD=changeMePlease PKP_WEB_CONF=/etc/apache2/conf-enabled/pkp.conf PKP_CONF=config.inc.php PKP_CMD=/usr/local/bin/pkp-start

In this example, the environment variable PKP_DB_PASSWORD is set to changeMePlease. If the user forgets to override it, the application will use the password that can be obtained from Dockerfile.

Let’s look at another image:

/bin/sh -c #(nop)  ENV MOODLE_URL=<a href="http://0.0.0.0/">http://0.0.0.0</a> MOODLE_ADMIN admin       MOODLE_ADMIN_PASSWORD [removed]      MOODLE_ADMIN_EMAIL admin@example.com MOODLE_DB_HOST     MOODLE_DB_PASSWORD       MOODLE_DB_USER     MOODLE_DB_NAME    MOODLE_DB_PORT 3306

For this image, Dockerfile specifies that the administrator password is hardcoded in the ENV directive and remains in the image metadata (layer history, docker inspect). Anyone who gains access to the image (registry, build cache) will be able to extract this secret and compromise the account.

To eliminate these risks, ensure that no passwords are specified in Dockerfile. If authentication is required, you can use orchestrator mechanisms (secrets) or generate a temporary password when starting the container via the entrypoint script, without saving it in the layers. We also recommend using mechanisms for securely passing secrets at runtime (Docker secrets, Kubernetes Secrets) or, as a last resort, passing them via --secret during the build with BuildKit, but under no circumstances should they be left in the final image.

Passing passwords via command arguments

In some cases, passwords may be exposed when passed via command-line arguments, as these arguments are visible to all users on the system:

/bin/sh -c #(nop)  HEALTHCHECK &{[""CMD-SHELL"" ""mysql --protocol TCP -u\""root\"" -p\""$MYSQL_ROOT_PASSWORD\"" -e \""SELECT 1;\""""] ""15s"" ""30s"" ""0s"" '\x05'}

In the example provided, the MySQL superuser password is passed into the healthcheck command in plaintext, making it visible when viewing the process list (ps aux), in audit logs, and in monitoring systems. If the attacker gains read access to the container’s processes or logs, they can extract the password and gain full control of the database.

To fix this issue, the healthcheck should use a local connection via a Unix socket with default authentication (if the auth_socket plugin is configured for root), or create a dedicated user with minimal privileges (e.g., only USAGE), without a password or with a password passed via a secure file (--defaults-file with restricted permissions). You can also use the MYSQL_PWD environment variable for healthcheck authentication, but it remains visible in /proc.

Privilege escalation in the container

One of the most common vectors for initial compromise of Linux systems is RCE in web applications and network services. Typically, these services have minimal privileges, which complicates attackers’ subsequent actions: dumping credentials, covering their tracks, attempting to escape the container, and much more.

The situation worsens significantly if the attacker gains root privileges, as this allows them to fully control all processes within the container, conceal their activity, and use methods to escape the container. For example, they can compromise the host if the container is privileged, a Docker socket is mounted inside it, or other insecure configurations and vulnerabilities exist that cannot be exploited with standard user privileges.

Similarly, this simplifies network attacks on neighboring containers, the orchestrator, and various internal services, making this configuration error a potential link in the chain for compromising the entire network.

Attacks on sudo

One of the simplest privilege escalation methods is executing arbitrary commands as root using sudo without entering a password. Consider the following example:

/bin/sh -c set -xe;     apt-get update &&       apt-get -y install sudo;       echo ""solr ALL=(ALL) NOPASSWD: ALL"" >/etc/sudoers.d/solr;

Analyzing this configuration using KIRA immediately highlights the main issue: by installing the sudo package and setting NOPASSWD: ALL for the solr, the user severely violates the principle of least privilege. The Solr platform does not require such broad privileges to run within a container; instead, they create an easy path for escalating to root.

echo 'postgres ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers

In another example of an insecure configuration, NOPASSWD:ALL privileges are granted to a PostgreSQL database user, which is a direct and severe weakening of the access control policy. If an attacker gains the ability to execute code on behalf of the postgres user – through a vulnerability in a network service, an SQL injection, or by compromising of one of the processes – they will immediately and unconditionally be able to execute any commands on behalf of the root user. This is equivalent to the entire container running as root.

As a risk mitigation measure, we recommend completely removing this directive. The minimum necessary commands requiring privileges should be delegated on a case-by-case basis via sudoers with explicit specification of allowed executables and parameters, using NOPASSWD only as a last resort and for specific utilities.

Our AI assistant KIRA can identify even more complex insecure configurations, such as allowing passwordless sudo for the entire sudo group — by modifying existing rules.

perl -i -pe 's/\bALL$/NOPASSWD:ALL/g' /etc/sudoers

The risk in this example is that the command replaces standard declarations requiring authentication with passwordless execution of all commands for any user within the sudo group – potentially including postgres, should it be assigned to that group. This expands the attack surface to all group members, turning each of them into a potential point for instant privilege escalation.

To mitigate the risks, we recommend not modifying the global sudoers policy, keeping the standard password requirement, or using a more secure escalation mechanism – such as gosu to run a specific process on behalf of another user without permanent privileges.

Insecure file permissions

Another common vector for privilege escalation is insecurely configured file and directory permissions. Most often, for convenience, container image authors use 777 permissions, which allow anyone – including unprivileged users – to freely create and delete files, as well as modify their contents. This can lead to both privilege escalation and the ability for an unprivileged attacker to delete or modify logs, among other undesirable consequences.

Consider the following command:

chmod 0777 /usr/share/cargo /usr/share/cargo/bin

The risk is that directories containing binary files and scripts will become writable by any container user. This allows a low-privileged attacker to replace utilities included in cargo or add new malicious executables. When these tools are subsequently invoked, especially as the root user or via sudo, the attacker’s code will execute with the inherited privileges of the calling process, leading directly to a local privilege escalation.

To mitigate the risks, you can set the minimum necessary permissions: chmod 0755 for directories and chmod 0755/0644 for the corresponding files. The owner should be root, and only the owner should be allowed to write. Do not use chmod 777 on any system paths.

Lack of integrity checks

Downloading software without verifying its integrity can make the infrastructure vulnerable to software tampering.

For example, this risk may arise when downloading a distribution via HTTP:

RUN /bin/sh -c wget -qO- ""<a href="http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz">http://acestream.org/downloads/linux/acestream_3.1.49_debian_9.9_x86_64.tar.gz</a>"" | tar --extract --gzip -C /opt/acestream

Using HTTP without verifying the archive’s integrity creates conditions for a man-in-the-middle attack during the image build phase. An attacker controlling the communication channel or DNS can replace the archive with malicious content, which will compromise the container and the entire environment in which it runs.

To mitigate the risks, you can configure connections to web resources to use HTTPS only — if the resource supports this protocol. You can also download the archive without extracting it, compare its checksum (SHA256) with the checksum from a trusted source, and only then extract it. It is advisable to store the verified archive in an internal artifact repository to avoid direct downloads from the network.

There will still be a MitM risk even if certificate verification is disabled:

wget --no-check-certificate<a href="https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip"> https://github.com/phpvirtualbox/phpvirtualbox/archive/refs/heads/7.2-dev.zip</a> -O phpvirtualbox.zip

The absence of TLS certificate verification allows an attacker controlling the network segment to replace the downloaded ZIP archive with malicious content. Since the archive contains PHP code that will be executed by the web server, compromise during the build phase will result in the deployment of a backdoor or data leakage.

To mitigate the risks, remove the --no-check-certificate flag; after downloading, calculate the SHA256 hash of the archive and verify it against a known reference value (the release page or a local repository of trusted hashes). Additionally, consider using a fixed release (tag) rather than the floating 7.2-dev branch.

Conclusion

Docker containers have become a very popular means of deploying software, and attackers are by no means oblivious to this trend. They are rapidly adding software vulnerabilities and configuration errors to their arsenal and carrying out attacks on supply chains. They can compromise container infrastructure for a wide variety of purposes, from cryptocurrency mining to encrypting data for ransom or stealing information critical to the company.

Our research found that 64 out of 100 container images for popular applications contain critically vulnerable software, and only 10% are fully up to date. We also identified numerous insecure configurations, including passwords stored in plaintext in Dockerfiles and excessive privileges granted to users and processes.

To detect and prevent these threats, it is essential to strictly adhere to security measures: audit image configurations, securely manage secrets used in images, apply security updates in a timely manner, scan their contents for malware with every update, and follow industry-standard best practices for enhancing security.

This approach requires specialized solutions built to accommodate the unique characteristics of container environments. Kaspersky Container Security ensures the security of containerized applications at every stage of their lifecycle, from development to operation. The product protects an organization’s business processes, helps ensure compliance with industry standards and security regulations, and enables the implementation of secure software development practices.

Artificial intelligence (AI) is changing the shape of the application attack surface. A traditional application assessment usually starts with familiar questions, such as:

In our previous posts, we explored the Identity Paradox and the rising risks at the enterprise edge. Together, these blogs highlighted how attackers gain initial access and leverage unmanaged devices to escalate privileges. The next phase of intrusion – execution – demonstrates how modern adversaries, aided by automation and AI, operate at speeds and a scale that challenge traditional human-centered defenses. Understanding these capabilities is critical for organizations aiming to reduce attacker dwell time and maintain operational resilience.

Automation: The Real Machine Multiplier

The cybersecurity conversation today often centers on AI, with organizations experimenting with generative models, agentic systems, and predictive analytics. While these tools offer unique capabilities, the backbone of modern defense and the source of the real operational advantage is automation.

In today’s landscape where we are seeing a shrinking window for response, adversaries are operating almost entirely at machine speed. In this environment, human operators alone cannot respond fast enough to prevent compromise. Automation enables defenders to reclaim the tempo. By integrating AI insights into hardened automated workflows, security teams can move from reactive triage to proactive intervention, closing gaps before attackers can exploit them. SentinelOne’s® own internal data demonstrates the tangible impact of this shift, showing that proper automation can save analysts approximately 35% manual workload despite 63% growth in total alerts, proving that automation can increase operational speed.

AI as Insight, Not Just Hype

The irony of AI innovation in the last year is that the AI tools we deploy to defend ourselves now need defending. The attack surface didn’t just grow, it folded back on itself. Automation executes tasks at speed, but AI provides context and predictive intelligence that guides those tasks. AI for security encompasses two complementary disciplines:

• Security for AI: Protecting AI tools, models, and agentic systems themselves from misuse or compromise. This includes governing employee access, ensuring secure coding practices, and managing autonomous AI agents.
• AI for Security: Leveraging machine learning and reasoning systems to detect and respond to threats faster than traditional rule-based approaches.

AI excels in identifying subtle behavioral patterns, predicting attacker intent, and supporting agentic workflows that can autonomously investigate alerts, recommend actions, and enforce pre-approved policies. By combining high-quality data, low-latency telemetry, and centralized visibility, AI transforms raw signals from endpoints, cloud environments, and identity systems into actionable insights.

However, AI is not a panacea. Without robust automation to operationalize these insights, organizations risk generating alerts faster than they can respond, replicating the same bottlenecks that have plagued traditional security operations.

Threats Accelerated by Automation and AI

Attackers are leveraging the same principles. Across campaigns observed in 2025 and 2026, adversaries are increasingly automating reconnaissance, exploitation, and lateral movement. Examples include:

• AI-assisted phishing: Rapid generation of highly localized and convincing campaigns in minutes, bypassing traditional content filters.
• Polymorphic malware: AI-generated malware that mutates faster than signature-based defenses can detect.
• Automated pivoting: Integration with compromised edge devices or cloud assets to move laterally and escalate privileges at machine speed.

These behaviors compress the attack lifecycle dramatically. What once required hours or days now occurs in milliseconds, highlighting why both automation and AI must form the core of modern defensive strategies.

Transforming Enterprise Operations with Agentic AI

Defending against machine-speed attacks requires agentic AI – systems that can perform investigative and response tasks autonomously, but under human-defined guardrails. SentinelOne’s Purple AI exemplifies this approach:

• Agentic auto-investigations: From alert assessment to hypothesis validation, Purple AI can perform complete investigations with minimal human intervention, documenting every step for audit and compliance.
• Custom detection creation: Analysts receive agentically recommended detection rules that can be implemented immediately to stop similar attacks before they spread.
• Integrated hyperautomation: Workflows, alerts, and response actions are executed automatically across endpoints, cloud services, and AI systems, enabling coordinated defense at machine speed.

These capabilities bridge the gap between insight and action, ensuring that detection is accurate and response is rapid, precise, and auditable. As organizations adopt AI for business processes, security must evolve to address the expanding attack surface. Key challenges include:

• Shadow AI adoption: Employees and teams using unmonitored AI tools create unseen channels for data exfiltration or misconfiguration.
• Agentic AI risks: Autonomous agents acting without sufficient oversight could unintentionally expose sensitive data or introduce vulnerabilities.
• Data velocity and volume: AI systems rely on vast, real-time data streams. Ensuring integrity, context, and governance of that data is critical to maintain trust in automated defenses.

Solutions must integrate visibility, control, and governance. SentinelOne’s Prompt Security portfolio provides real-time monitoring for employee AI use, AI coding tools, and agentic AI operations. By automatically redacting secrets, blocking vulnerable code, and enforcing policy compliance, organizations can safely harness AI while reducing exposure.

Meanwhile, Observo AI and AI-native SIEM integration enable organizations to ingest, normalize, and analyze petabytes of telemetry in near real time. By pairing this high-fidelity data with Purple AI’s agentic reasoning, defenders can detect threats, trigger pre-approved responses, and maintain operational oversight across both traditional and AI-native environments.

Operational Principles for Machine-Speed Defense

Implementing an effective AI- and automation-driven security strategy requires clear guiding principles:

• Intelligence Over Rules: Move beyond static signatures to behavioral and predictive detection. Threats evolve faster than predefined rules; systems must continuously learn, reason, and adapt.
• Autonomy with Accountability: Automation and agentic AI should operate at machine speed, but within human-defined guardrails, ensuring actions remain traceable, auditable, and aligned with policy.
• Unified Data and Context: Signals from endpoints, identities, cloud, and AI tools must be fused to create a coherent understanding. Insight without context is noise; action without context is risk.

When consistently applied, these principles reduce dwell time, enable faster response, and ensure that human expertise is focused on high-value decision-making rather than repetitive manual tasks.

Conclusion | Automation & AI as Allies

For two decades, security has been a human-speed discipline applied to a machine-speed problem. That model is over. The organizations that will lead from here aren’t the ones with more analysts or better dashboards. They’re the ones where detection, investigation, and response happen autonomously. The future will be defined by organizations where human and AI manage the SOC together: AI reasons, automation acts, and humans govern the process. Not in sequence. In parallel. At machine speed.

Execution is no longer a phase in the kill chain. It’s the entire game. The defenders who win it won’t be the fastest responders. They’ll be the ones who made their response automatic.

The evolution of execution in cybersecurity demonstrates a broader trend: Defenders must match the speed, scale, and sophistication of adversaries. Not just tools, automation and AI are partners in defense and able to extend human capacity while maintaining oversight, context, and control.

Organizations that invest in integrated, agentic AI systems and robust automated workflows can detect and respond to attacks in real time, reduce analyst workload while increasing coverage, and secure AI adoption itself, maintaining trust in both technology and operations. This shift marks a transition from perimeter-based and manual defense to autonomous, adaptive security, where systems and people collaborate to outpace attackers, secure critical assets, and support business innovation.

Execution is the new frontier in the cyber kill chain. By combining automation, AI-driven insight, and human oversight, organizations can operate at machine speed, defend against advanced threats, and confidently embrace AI-powered transformation.

As the cybersecurity landscape evolves, success will no longer depend solely on faster patching, deeper monitoring, or more alerts. It will depend on the intelligent orchestration of people, machines, and AI, enabling defenders to act faster, smarter, and with confidence in a world where adversaries are already moving at machine speed.

 

As organizations rush to adopt AI, they are discovering that traditional, siloed security tools cannot keep pace. The data is too vast, the infrastructure is too interconnected, and runtime environments are too dynamic. Security leaders are confronting a hard reality: AI cannot be secured with point solutions — it is just too broad.

To scale AI with confidence, enterprises must move beyond check-the-box controls and adopt a holistic, machine-speed defense that secures the entire AI lifecycle. This means protecting the data that fuels and is accessed by models, the cloud infrastructure that runs them, and the workloads and AI systems operating at runtime as a single, unified, and immutable system.

As AI capabilities accelerate, a critical question is emerging in the market: Does AI reduce the need for cybersecurity, or fundamentally increase it?

The answer is clear. With current infrastructure architectures, AI is not a replacement for security. It is a multiplier for risk. Models ingest massive volumes of data and agents can sprawl uncontrollably. It depends on complex cloud infrastructure and operates continuously at machine speed. Each stage of the AI lifecycle introduces new attack paths and new failure modes.

Today, SentinelOne is announcing the expansion of its AI Security platform with new Data Security Posture Management (DSPM) capabilities, model red teaming, validation and guardrails (by Prompt Security), MCP Security (by Prompt Security), AI-SPM, AI Workload Protection, and AI end user protection. This milestone advances our broader vision, delivering a unified platform that secures AI end to end, from data accessed, all through runtime execution and model input and output. This is complete security, visibility, and governance over Al usage throughout its entire lifecycle.

The Foundation: Securing AI at the Data Layer

AI security starts with data, not because data is abundant, but because mistakes made at this stage are irreversible. AI models also don’t just process the data they ingest, they memorize it. If sensitive PII, credentials, or proprietary information enter a training pipeline, that data can become baked into a model’s weights, creating a permanent security liability that is nearly impossible to remediate later.

This risk is amplified by scale. Industry projections estimate that the global datasphere, the unstructured data stored in cloud object stores and increasingly fed into AI pipelines, will reach 10.5 zettabytes by 2028. This data is not just storage. It is the fuel that trains, fine-tunes, and powers AI systems. This is why data security is the first mile of AI security.

With the introduction of these new DSPM capabilities, SentinelOne enables organizations to establish a “safe-to-train” gate before data ever reaches an AI pipeline. These capabilities provide deep visibility into cloud-native databases and object stores, allowing teams to discover unmanaged or forgotten data sources, classify sensitive information with policy-driven precision, and prevent high-risk data from being used in training or inference workflows.

Singularity Cloud Security’s integrated DSPM discovers cloud object stores and databases and classifies sensitive data that could find its way into AI training pipelines. 

However, visibility alone is not enough. AI pipelines ingest data at massive scale, making them an attractive vehicle for malware delivery and pipeline poisoning. In addition to identifying and redacting sensitive data, SentinelOne actively scans cloud storage at machine speed to prevent malicious content from ever reaching AI models or applications. By securing data at ingestion all before training begins, organizations eliminate entire classes of AI risk that cannot be fixed downstream. This is the foundation for trusted AI adoption.

The Infrastructure Layer: Securing the Systems That Run AI

Securing AI data is necessary, but it is not sufficient. Data does not exist in isolation. Rather, it lives on cloud infrastructure and in AI environments where infrastructure becomes a critical failure point.

AI workloads introduce a uniquely high-risk combination of high-value data, high-privilege access, and high-performance compute. AI factories, training clusters, managed AI services, and inference endpoints often require broad permissions and continuous access to cloud object stores. Without strong infrastructure controls, attackers can pivot from exposed data into model logic, model weights, or downstream applications. This is where cloud infrastructure security becomes inseparable from AI security.

Traditional Cloud Security Posture Management (CSPM) provides essential hygiene across the cloud estate by identifying misconfigurations, excessive permissions, and policy drift. In AI environments, however, security teams also need visibility and control that is specific to how models are built, deployed, and accessed.

AI-Security Posture Management (AI-SPM) extends infrastructure security directly into the AI layer. By treating AI systems as first-class assets, AI-SPM provides a unified inventory of training jobs, development notebooks, managed AI services, and inference endpoints across the environment.

 

Together, CSPM and AI-SPM allow security teams to understand how data, infrastructure, and AI systems are connected. They can trace attack paths from misconfigured storage to over-privileged training containers, detect unmanaged AI assets, and prevent adversaries from moving laterally from the cloud foundation into model logic. This infrastructure layer is what connects secure data to secure runtime and it is essential for protecting AI at scale.

The Runtime Layer: Protecting AI In Production

AI security cannot stop when a model finishes training. The moment AI systems move into production, they begin interacting with real users, real data, and real business processes, making runtime protection a critical part of the AI security lifecycle.

At runtime, AI workloads operate continuously and at machine speed. Models and agents execute inside cloud workloads that must be protected against exploitation, unauthorized access, and lateral movement. Any compromise at this stage can immediately impact business operations, data integrity, and customer trust.

This is where runtime workload protection becomes essential. Cloud Workload Protection Platforms (CWPP) provide real-time visibility and enforcement across the compute environments running AI models, ensuring that workloads are monitored, hardened, and protected without degrading the performance required for high-velocity inference.

By extending protection into runtime, security teams ensure that AI systems remain secure not only during development and deployment, but throughout their operational life. This completes the AI security lifecycle from data ingestion, through infrastructure, to production execution.

Prompt Security and AI Red-Teaming: Continuously Validating Trust

Securing AI at runtime goes beyond protecting the workloads that execute models. It also requires validating how models behave when they are used (and misused) in the real world.

Prompts are the primary interface to AI systems and they represent a powerful new attack surface. Malicious or malformed prompts can be used to bypass controls, extract sensitive information, manipulate model behavior, or trigger unintended actions in downstream systems. These risks cannot be addressed solely through static controls or one-time reviews. This is where prompt security and AI red-teaming become essential.

By continuously testing AI systems with adversarial prompts and simulated attacks, organizations can identify behavioral weaknesses before they are exploited in production. AI red-teaming helps validate that models behave as intended under real-world conditions, exposing prompt-level vulnerabilities, unsafe outputs, and policy bypasses that would otherwise go undetected.

When combined with runtime protection, this approach ensures that AI systems are not only secure in how they are built and deployed, but also resilient in how they respond — even as models evolve, prompts change, and new attack techniques emerge.

This continuous validation loop is critical for maintaining trust in production AI systems and closing the final gap in the AI security lifecycle.

A Unified Fabric for AI Security

The transition to AI is ultimately a trust shift. Organizations will only move AI from experimentation to production if they can trust the data that trains models, the infrastructure that runs them, and the systems that govern how AI operates at runtime. Securing AI therefore cannot be fragmented. It requires a unified platform that treats data, infrastructure, and runtime as a single, connected system with shared context and continuous visibility across the entire AI lifecycle.

By integrating data security, cloud infrastructure posture management, AI-specific posture management, and runtime workload protection, SentinelOne delivers end-to-end AI security from data ingestion through runtime execution. This approach does more than reduce risk. It enables velocity. When security is built into the foundation, organizations can deploy AI faster, meet evolving regulatory requirements more easily, and innovate with confidence.

Secure the data.

Secure the infrastructure.

Secure the runtime.

This is how AI moves from risk to real-world impact. Contact us or book a demo to see how SentinelOne secures AI end to end — from data ingestion to runtime execution.

AI coding assistants are no longer just autocompleting lines of code, they are quietly making decisions for you. Tools like Claude Code are able to read projects, plan multi-step changes, install dependencies, and modify files with minimal human oversight. To make this possible, these assistants rely on plugin marketplaces, where third-party developers can enable ‘skills’ that teach the agent how to manage infrastructure, testing, and dependencies. Though powerful, the model requires a high degree of trust, thus bringing with it a new set of risks.

At a first glance, third-party marketplace plugins are harmless productivity boosters. Connect a marketplace and enable a plugin so your coding assistant becomes smarter about your stack. However, beneath the convenience is a security blind spot: These same skills often run with extremely high privilege and very little transparency on how they make decisions or where the code and dependencies are coming from. The code issue isn’t prompt manipulation or social engineering – it’s compromised automation.

A full technical blog post by SentinelOne’s own Prompt Security team breaks down how a single benign-looking plugin from an unofficial marketplace exposes a dependency management skill. When the developer asks the agent to install a common Python library, that skill quietly redirects the install to an attacker-controlled source, ensuring a trojanized version of the library is pulled into the project. While nothing looks wrong – the library imports cleanly, the example code runs without error – malicious code is now embedded into the environment, capable of exfiltrating secrets, monitoring traffic, or lying dormant until it is triggered at a later time.

What makes this especially concerning is persistence. Marketplace plugins are not one-off interactions. Once enabled, their skills remain available across sessions and will continue to shape how the agent behaves in the future. Rather than a ‘bad prompt’, this effect is more like compromising your package manager itself.

As AI-driven development workflows accelerate, plugin marketplaces and third-party skills are now part of the software supply chain whether teams realize it or not. If your coding assistant can fetch and execute code on your behalf, every plugin installed joins your trust boundary.

Read the full blog post here for a detailed walkthrough of the attack mechanics and learn why dependency skills are such a powerful, but under-modeled, risk.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

As we close out 2025 and look ahead to 2026, nothing is as we might have expected even a year ago. AI has disrupted, and will continue to disrupt, every corner of modern life. In threat intelligence, SentinelLABS has not only recognized this shift but actively pivoted to meet it. At the same time, geopolitical alignments have grown increasingly unstable, with long-standing relationships now less certain than ever.

How will these new realities shape enterprises’ ability to anticipate and counter the cyber threats forming on the horizon? Predictions always carry the caveat that the future remains intractably unknowable, but even the unexpected emerges from trajectories already in motion.

In this post, SentinelLABS researchers and leaders share their perspectives on how the cyber threat landscape is evolving and what may lie ahead. Read on to explore how developments in global strategy, organized cybercrime, and of course, AI could impact us all in the coming year.

The Forgiving Internet is Over

The cybersecurity industry has been living on borrowed time, and AI is about to call in the debt.

The effects of cyberattacks are not always immediately visible: sometimes they go by entirely unnoticed. That encourages a fundamental cybernetics problem, as there isn’t an obvious causal link between the levers available to defenders and the constraining effects imposed on attackers.

That broken loop can create a corrosive perception that what we do doesn’t have meaningful effects, which has allowed our industry to backslide into lowest-investment, compliance-checkbox territory.

Meanwhile, the feedback delay entails that just as exploitation can go unnoticed for years, technical debt sits dormant, unnoticed for prolonged stretches.

We are moving to a future where being vulnerable and being hacked are not two separate steps. Today, organizations run edge appliances riddled with a bottomless supply of weaponizable vulnerabilities and n-days, and yet they often come away uncompromised simply because no one has gotten around to them yet.

Consider Cl0p’s MOVEit campaign: nearly 2,800 organizations compromised, 96 million individuals’ data exposed and the group was still processing victims more than a year after the initial breach. Cl0p explicitly stated they leaked names slowly to avoid overwhelming their own negotiation capacity. The attack itself was automated, executed over a holiday weekend, largely complete before the patch dropped, but extortion is human work. That capacity bottleneck —the gap between what automation can compromise and what humans can monetize— is about to disappear.

The internet’s forgiveness is a function of attacker capacity, and AI is a capacity multiplier. When autonomous agents can probe, validate, and exploit at machine speed, the gap between vulnerable and compromised collapses. Without a countervailing investment in AI-native defense, that asymmetry becomes the defining feature of the landscape.

Attackers will harness AI as a force multiplier long before defenders do. Scrappy resourcefulness, clear financial incentives, and freedom from procurement cycles guarantee it.

The alignment discourse is a distraction. Local models on consumer hardware, unconstrained foreign providers, and enterprise no-retention deployments attest to this. The moment capable computer-use models run locally, guardrails become irrelevant. Anthropic’s recent disclosure of Chinese operators using Claude Code for autonomous intrusions is instructive: one operator hitting thirty targets with minimal human intervention. By their own account, model hallucinations did more to slow the attackers down than any guardrails.

If defenders can thank AI for anything, it will be a fundamental reassignment of value, a revamping of capacity, and a necessary reimagining of what’s possible.

Feeble attempts to conjure tens of thousands of competent practitioners out of thin air have clearly floundered. Thankfully, getting more bodies isn’t the only way to increase capacity anymore. AI offers exactly that. It invites us to revisit implicit ROI calculations we abandoned long ago. We can now reconsider activities that required human intervention but were deemed too incremental and repetitive to be consequential: processing every document in a breach disclosure, pre-processing logs at scale, reverse engineering tangential codebases to better understand malicious code. These were not impossible tasks; they were tasks we decided not to attempt. That calculus has changed.

However, we must be clear-eyed about what we are adopting. These systems are non-deterministic. We are integrating a new form of evaluative power that is commoditized and cheap but also largely outside our control. Their outputs need to be wrangled into predictably acceptable parameters. The organizations that operationalize AI effectively will be those that learn to harness uncertainty within acceptable bounds rather than pretend it doesn’t exist.

What the market is missing (and desperately requires) are organizations that function as step-down transformers: converting raw frontier capability into security outcomes. Frontier labs are racing toward general capability while treating security as one of several potential markets. The result is a gap between what models can theoretically accomplish and what defenders can reliably deploy. Someone must bridge that gap with products and services that translate commoditized evaluative power into deployable autonomy.

This means investment in experimentation to redefine security problems in terms of what AI can make tractable, improve, or solve without waiting for archaic vendors to catch up. The threat actor(s) using Claude Code to maximize their operational capability didn’t stumble into competence. They iterated, tested, and created a harness for ready deployment with the human as far out of the loop as possible. Defenders will need equivalent rigor.

The opportunity is real and sizable. Seizing it requires that security as a practice becomes AI-native. Organizations that treat AI as another line item will find themselves overwhelmed by an operational tempo they cannot match. Those who internalize it as a fundamental shift, on both sides of the adversarial line, have a chance to redefine the dynamics of the security space. The value generated in 2026 and beyond is entirely concentrated in filling that gap between frontier capability and operational deployment.
Juan Andres Guerrero-Saade (JAGS), Senior Technical Fellow and VP of Intelligence and Security Research, SentinelLABS

 

Hemispheric Crossfire | US–Venezuela Cyber Operations Drag in the Big Three

As of late 2025, Venezuela has already shifted from a chronic crisis to a genuine flashpoint. U.S. carrier groups and expanded maritime operations in the Caribbean, public talk of “closing” Venezuelan airspace, and speculation about regime‑change scenarios have raised the temperature dramatically. Caracas, for its part, is signaling a willingness to fight a long guerrilla struggle and “anarchize” the environment if the U.S. moves militarily. At the same time, Venezuela has deepened its alignment with Russia, Iran, and China, explicitly seeking security guarantees, capital, and military assistance from all three.

In such an environment, a realistic 2026 development is the partial exposure of U.S. offensive cyber and information operations targeting Venezuela. This doesn’t mean Hollywood‑style leaks of every covert program; it looks more like a mosaic of glimpses: A social media platform announces a takedown of coordinated inauthentic networks seeding narratives aimed at Venezuelan military factions and diaspora communities; A contractor leak reveals tooling used to profile Venezuelan officers, union leaders, and local elites; A regional report connects seemingly independent media outlets and meme sources back to U.S.-linked funding and infrastructure, blurring the line between strategic communications and covert influence.

None of this is unprecedented. Great powers all play in this space, but the political salience of Venezuela today means the blowback will be sharper and more public than usual.

That exposure offers raw material for counter‑narratives and operations by Caracas’ backers. Russia is already running well‑funded Spanish‑language disinformation and propaganda campaigns across Latin America, often in coordination with partner state media, with a long‑standing focus on undermining U.S. standing in the region. Iran has used Venezuela as a beachhead for sanctions evasion, proxy networks, and anti‑U.S. activity, including leveraging IRGC and Hezbollah-linked structures to expand its reach in the hemisphere. China, meanwhile, is quietly consolidating intelligence collection capabilities via regional ground stations, telecom infrastructure, and proximity to key undersea cables, assets Western analysts already flag as potential platforms for surveillance of U.S. communications.

In 2026, we should expect to see cyber and information operations explicitly framed as “defending Venezuela from U.S. aggression”, but operationally aimed at the United States and its closest partners.

• Russian and Venezuela‑aligned influence networks will likely amplify any evidence of U.S. IO/espionage, real, exaggerated, or fabricated, into Spanish and English‑language campaigns targeting U.S. domestic audiences, Latin American publics, and the Venezuelan diaspora.
• Iranian‑linked actors can be expected to piggyback on the crisis to probe U.S. critical infrastructure and financial networks under an “Axis of Authoritarianism” narrative, using the Venezuela storyline to justify escalation in cyber operations they were running for other reasons anyway.
• Chinese‑linked capabilities are more likely to manifest as intensified collection and mapping, SIGINT on U.S. deployments, diplomatic traffic, and commercial flows, rather than loud influence campaigns, but that data will feed the same broader alignment.

For CTI teams, the prediction isn’t some “ big Venezuela cyber war,” it’s a convergence problem. A Venezuelan crisis becomes the pretext that ties together Russian, Iranian, Chinese, and local pro‑regime operators into loosely synchronized campaigns: hack‑and‑leak operations targeting U.S. policy debates; cross‑platform disinformation linking Venezuela to border, drugs, and migration narratives; the probing of U.S. energy, maritime, and telecom infrastructure under the cover of regional tension.

Expect to see Spanish‑language infrastructure and personas show up in incidents that ultimately impact U.S. and European networks and more clusters where attribution threads run through Caracas and Moscow/Tehran/Beijing at the same time. The organizations most likely to feel this first are those at the seam lines: energy, logistics, telecom, diaspora media, and NGOs with one foot in the U.S. and one in the region.
Tom Hegel, Distinguished Threat Researcher, SentinelLABS

 

China’s Fifteenth Five Year Plan

A new Five-Year Plan from the Chinese Communist Party means a new hit-list for China’s hackers.

After Xi came into power in 2013, he set about issuing development goals for science and technology in China not seen since the leadership of Mao Zedong. The most notable, Made in China 2025 was released two years later in 2015. After American opprobrium reached its peak in the first Trump administration, China slowly withdrew MIC2025 from the limelight. American attention to the strategy led to significant collection difficulties for the PRC as the US FBI and other government agencies prioritized defense of targeted technologies in the private sector and at US research institutions, like universities.

In 2021, the PRC released publicly only a vague outline of the Party’s Medium- to Long-Term Development Plan for Scientific and Technological Innovation, which set innovation goals for 2025, 2030, and 2035. Foreign attention to MIC2025 led the Party to mark the full content of the plan as “internal circulation only.”

The 15th Five-Year Plan promises to push some of those privately-held development goals into the spotlight. The PRC central government will release the official 15th FYP in 2025, and will delegate much of the details about achieving its objectives to government ministries. Ministries will release their more-detailed version of the 15th FYP in late 2025 or early 2026. Those documents create a political demand signal for provincial governments and bureaucracies to work towards realizing.

Contracted hackers looking to pilfer western technology and sell it to the highest bidder in China will consult those documents to identify the technologies their customers are likely to pay good money for. If your industry is on the list of targeted technologies, buckle up.
Dakota Cary, Senior Security Advisory Consultant

 

Organized Cybercrime | More Integrated, Streamlined & Aggressive

Commodities and Cartels

Ransomware and infostealers are now commodity features. We’ve blown past this milestone in the last couple of years. Consider ransomware and data exfiltration as givens in the event of any opportunistic breach. While the days of the ‘big brand’ extortion operations are waning, we are seeing more smaller, organized groups offering à la carte services, including ransomware, but ultimately, this is just another feature available in ‘run of the mill malware’.

The blending of infostealer and ransomware-style features into more swiss-army knife tools and services will attract a broader set of criminals, a natural evolution already underway, given the heavy reliance of modern attacks on the infostealer logs ecosystem.

This also overlaps with the trend towards more ‘Cartel-style’ operations or ‘alliances’ which consolidate disparate malicious services into more all-encompassing “MaaS” offerings.

Ransomware & Initial Access Brokers

As these cartels and service ecosystems solidify, the relationships that underpin initial access are tightening as well. Ransomware groups continue to work closely with IABs (Initial Access Brokers), with an increasing number of threat actors publicly and aggressively attempting to recruit ‘trusted’ IABs. Groups like Sicarii advertise special advantages to others willing to partner with them.

Additionally, we can expect to see IABs starting to offer more targeted bundles consisting of curated credential sets. For example, IABs will start offering ‘chains’ based on cumulative sets of related credentials (chain of VPN->O365->Cloud Console access for a target). There are some specializing in this now, but we expect this to become more mainstream as the infostealer log ecosystem, which feeds many IABs, continues to explode.

Increasing Attacks Will Offer Defenders Fewer IOCs and Artifacts

There are some interesting micro trends within these smaller, more obscure, operations. One such trend is the omission of ransom notes and other noisy filesystem artifacts, and threat actors moving towards more direct follow-ups via emails and phone calls to initiate communications.

We have seen groups like “Penguin Cartel’ operate in this way, and we expect adversaries to increasingly embrace these alternate methods of first notification in extortive attacks.

Businesses Will Keep Losing Data, Encryption Not Required

This operational “quieting” aligns with another growing trend: attackers no longer need to encrypt data to profit from it. This is far from new, but it is increasing. More crimeware actors eschew encryption entirely, opting to extort victims to prevent release of the exfiltrated data. Groups like Kairos and WorldLeaks are current examples of this model.

More Automation, More Upscaling

While the “AI-revolution” has yet to fully transform the downstream atomic artifacts of crimeware, cybercriminals are taking advantage of various automation options, using AI to augment and scale-up their output.

An increasing number of actors are leveraging AI agents, Telegram Bots and similar features both to automate discovery and sales of their product and C2 activities. This has long since been a practice in the traditional infostealer community, but we are seeing an uptick of this across the crimeware landscape.

Pressure Escalates Tactics

Threat actors are continuing to apply real-world violence (VaaS) to ensure their profitability. Naming-and-shaming via data leak sites will remain a permanent feature of the landscape, but we will see further pressure being applied to business clients, customers, family members and entities that are peripheral to the victim. One common manifestation of this is swatting groups being called upon to apply pressure to financial crime victims.

Additionally, threat actors will continue to leverage regulatory and compliance laws to apply pressure and time leak announcements around critical events such as earnings calls or M&A negotiations.
Jim Walter, Senior Threat Researcher, SentinelLABS

 

Living Off Apple’s Land | Latent Powers and Stolen Trust

Last year, we noted how threat actors were making hay abusing AppleScript’s spoof-friendly ability to create password dialog boxes to gain elevated privileges, but as many unfortunate victims have been finding out this year, that’s far from all AppleScript is good for.

ClickFix is the new social-engineering kid-on-the-block for every stripe of threat actor from nation state APTs to opportunistic cryptowallet-stealing cybercriminals. Dropping a simple two-line AppleScript that opens an innocuous webpage, perhaps a support portal for some legit technology, with up to 10000 blank lines ending with a few malicious lines of code is a ridiculously simple but effective method of social engineering.

2026 will see the continuation of both techniques. However, as old as Python and as powerful as PowerShell, AppleScript has a lot more juice left in it from a threat actor point of view.

We are just beginning to see the first signs of adversaries making use of AppleScript’s Objective-C (AS-ObjC) bridge — a wonderful technology that brings the power of Apple’s Foundation and AppKit frameworks, including NSWorkspace, to simple AppleScripts. In the past, we’ve seen AS-ObjC’s newer cousin JXA (JavaScript for Automation) gain traction in red-teaming tools like Apfell; it’s a small conceptual leap from there to the (arguably) easier world of AppleScript Objective-C.

That opens up a whole new world of in-memory scripting power that otherwise usually requires a compiled binary and readily-detectable file writes. Will we see threat actors lean into this old, built-in, not-widely known, yet incredibly powerful way of programming Mac computers? If you’re a threat actor, it’s a Living-off-the-Land technology dream come true. If you’re a defender, it’d be smart to start thinking about what that looks like from a telemetry point-of-view in 2026. And while we’re on the topic of powerful, Apple Framework-enhanced scripting languages, Swift scripting is a thing worth keeping in mind, too.

On macOS, ClickFix was a necessity-is-the-mother-of-invention response to Apple’s plugging of the Gatekeeper workaround. However, you don’t need a bypass to Apple’s increasingly strict code signing and notarization rules if your malware is signed with a valid developer ID.

Illicit trade in verified Apple Developer accounts is something we’ve seen increase in the latter half of 2025, and it’s only a matter of time before we see these abused by more malware authors. Temporary they may be, as Apple is quick to nix such accounts once identified, but even a short-lived campaign can do a lot of damage against the right targets.

The lesson for defenders is not to treat validly code signed executables as some kind of exception to detection rules. Signed code tells a defender little more than that it passed Apple’s automated checks and that the code has a name attached to it. In the case of malware, that’s almost certainly not the name of a threat actor.
Phil Stokes, macOS Research Engineer, SentinelLABS

 

The AI Reckoning | Consolidation, Censorship, and Economic Fallout

Specialized Models Will Belong to Those Who Can Make Them

Over the next few years, we’ll watch a huge number of AI companies simply disappear.

The generic “copilot for X” and “AI workspace” products that dominated pitch decks in 2023–2024 will be reborn as bloodless, checkbox features inside Microsoft 365, Google Workspace, and other large platforms. The quality will be worse than the specialized startups they replace, but that won’t matter because they’ll be easy to buy on an enterprise contract, come bundled with existing tools, and be turned on with a toggle in an admin console.

The result will look like a mass extinction. Valuations will implode and the easy money will evaporate. The tech influencer class on X will still push the “996 grindset mentality” even as the few humbled survivors of the crash pivot from “owning the category” to cutting costs and delivering durable value to a smaller, demanding set of customers.

But this is also exactly the environment in which truly specialized organizations start to matter. These smaller entrants will sit in narrow, high-stakes domains: cybersecurity, law, finance, industrial control, biotech…

In those areas, the winners will be teams that have quietly built a repeatable data and training pipeline, have access to proprietary datasets, and can deploy smaller models that are integrated into specific workflows, regulations, and hardware.

Advances in training efficiency, data curation, and model compression will be among the most valuable pieces of this puzzle, and they will increasingly move out of public view. Labs will publish less, national-security programs will classify more, and a handful of specialized shops will jealously guard their pipelines.

The Bubble Pops in a Poisoned Reality

AI is unpopular as an idea. For most consumers it means glitchy chatbots, over-eager automation at work, auto-generated spam, and marketing departments screaming about “AI-powered” everything. The underlying capabilities are real, but the experience is mostly annoyance, precarity, and a strong sense that someone else is getting rich off a thing that is happening to you, not for you.

On top of that resentment, we’ve layered a classic asset bubble. Capital has flooded into anything AI: driving valuations, headcount, and infrastructure spending far beyond what current use-cases justify. In the last year, large tech companies have fired workers while bragging about “AI efficiencies,” even when they’re mostly just undoing years of over-hiring.

The important prediction isn’t “a bubble exists”; it’s how people will react when it finally hits the wall. Within the next year we should expect a dot-com–scale drawdown in AI equity and private valuations: a broad repricing of pure-play “AI companies,” at least one of today’s marquee AI darlings valued at less than a third of its peak, and a long tail of late-stage startups ruthlessly zeroed-out. The hyperscalers will survive because AI is one line item inside a much larger machine; most everyone else will discover that they built a feature, not a business.

The crash will happen in a reality already saturated with synthetic content. In the scramble to justify their spend, organizations are using models to flood every channel with low-cost output: SEO sludge, autogenerated news, endless pitches, synthetic “user reviews,” fake engagement. Previously trusted sites and platforms are already quietly tilting from human-written to machine-written material because the unit economics are irresistible. The problem is they are using last decade’s metrics: what is the actual economic value of Daily Active Users when the content they are consuming is slop that nobody can monopolize?

As the synthetic layer of our online experience deepens, models are trained and retrained on their own exhaust and on rival models’ curated “knowledge bases”, wiki-like sites and reference corpora that are themselves partially or wholly machine-written. Systems start to treat these partisan or synthetic compilations as “ground truth” simply because they look like structured authority.

The targeted threat of “model poisoning” becomes the inescapable threat of “reality poisoning” and the line between what actually happened and what the machine inferred as plausible will vanish.

This increasingly synthetic environment directly undermines the business case that justified the bubble in the first place. Search gets worse, watered down, and commoditized. Feeds become vacuum sealed bubbles where nothing breaks containment. Analytics get noisier and less reliable. Conversion rates slip as users learn to distrust what they see on screens. Enterprises that bought AI to “supercharge knowledge work” find that their internal knowledge bases are now clogged with plausible nonsense that’s harder and harder to audit. The marginal ROI on yet another AI integration rapidly decays.

So when the capital tide goes out, the public story will be simple and hostile. “AI took my job and ruined the internet.” The actual big picture may be composed of macro economics, overcapacity, and misallocated capital, but the emotional truth will be that AI made jobs less secure, the information environment less trustworthy, and the daily experience of technology spammy and brittle.

In the aftermath, the models will remain, the infrastructure will remain, and the incumbents will survive by using them where they produce actual value. What won’t survive will be broad-based cultural, political, and financial enthusiasm.

In the next year, we will end up with powerful systems embedded deep in a few dominant platforms, operating in a permanently contaminated data environment, surrounded by a public that no longer believes the marketing and cannot trust the outputs.

Dual-Use Will Eat Alignment and Turn Into Regional Censorship

AI and LLM development are on track to become core pillars of national defense. Questions about “U.S. vs. China vs. everyone else” will move out of policy think-tanks and into mainstream geopolitics. Behind closed doors, frontier systems will be evaluated less as “products” and more as strategic infrastructure: tools that can rewrite the balance of cyber offense, intelligence gathering, and information operations both at home and abroad.

In this world, statements of “public model alignment” will become less important. The loud, visible debates about fairness, bias, and “responsible AI” will continue, but the most consequential work on offensive AI capabilities will move into secure facilities, export-controlled supply chains, and gray markets. The question will shift from “Is this system aligned with human values?” to “Is this system aligned with our national interests?”

Because AI systems are inherently dual-use, offensive capabilities and control affordances will be developed in parallel. The same model that politely refuses to discuss certain topics in a consumer chat interface will have close cousins tuned for intrusion discovery, vulnerability triage, targeted influence, and automated exploitation. Many of those capabilities will originate in state-backed programs, but they won’t stay there. They’ll diffuse into law enforcement, domestic security services, and private contractors, where they will be applied to civilian populations as instruments of soft control and, when desired, hard power.

That logic will leak out into the consumer layer as regionalized safety controls. As these technologies scale, they will increasingly mirror existing patterns of information control. Providers will ship different rule-sets and behaviors by jurisdiction, the way streaming platforms already fragment their catalogs country by country. Providers will claim that this represents “localization” efforts — where differences in language and cultural references are updated for the target population. What they are really localizing is the range of thinkable thoughts within a language model.

Whatever their marketing stance on “neutrality” or aversion to particular ideological labels, major providers will have very strong incentives to align their models with local statutes, regulatory guidance, and informal political red lines. If a given government can threaten licenses, data-center permits, key executives, or revenue streams, the “alignment layer” becomes one more lever for the powerful. Governments will jump at the opportunity to tweak refusal patterns, soften the model’s treatment of this history, or remove guidance that might make protests more effective.

Over time, legislators, regulators, authoritarian regimes, and litigators will get a much sharper sense of where these levers sit inside these systems: how content filters work, what knobs exist for toxicity, radicalization, and persuasion, or how model-delivered advice translates into real-world actions. The volume and specificity of legal and policy demands on these knobs will expand accordingly.

Engineering teams at these companies will spend less time debating abstract philosophical framings and more time implementing tightly scoped, jurisdiction-specific constraints designed by lawyers and national security officials.

The result will be a stratified ecosystem:

• Public, region-locked models that are heavily constrained will become the systems most people will interact with day to day.
• Institutional and security-grade models, derived from the same or larger bases but deployed inside governments, defense contractors, and domestic security agencies, will be used to profile, predict and shape human behavior at scale.
• Informal and illicit models will be leaked, stolen, or quietly licensed and recirculate similar capabilities into criminal markets and non-state actors.

In all three layers, “alignment” will be eaten by dual-use. The systems will be “aligned” to institutional goals, not to a shared, global notion of human flourishing. The public will experience this as an explosion of region-specific censorship and weirdly divergent realities between models that reflect different value systems.

In short, the coming wave of LLM censorship by major U.S. and allied companies is the civilian-facing expression of a deeper shift. Once AI is framed first as a strategic asset and only secondarily as a consumer product, dual-use incentives dominate. Alignment becomes a branch of national security and regulatory compliance, and the map of model behavior starts to trace the borders of political power rather than the contours of an egalitarian reality.
Gabriel Bernadett-Shapiro, Distinguished AI Research Scientist, SentinelLABS

 

Zero or No Trust | Interconnected Services Lead to Increasingly Devastating Intrusions

Zero Trust Architecture networks have been increasingly ubiquitous over the last five years, with the pandemic driving many organizations to rapidly adopt and implement related technologies to support the sudden uptick in remote work. Threat actors were slower to adapt through 2020-2022, as there were plenty of targets who had not jumped on the ZTA bandwagon. Early adopters targeting these environments made headlines by compromising often tech-forward organizations, a far cry from the companies typically in the news for huge ransomware attacks against legacy networks.

In 2025, there were several campaigns where actors targeted highly interconnected environments by focusing on identity providers. The ShinyHunters campaign abusing OAuth relationships in certain Salesforce user environments is a notable example: granting OAuth access to the Data Loader app enabled the attackers to access the victim environment and exfiltrate data using a Salesforce tool intended to do exactly that. Similarly, in August 2025 attackers abused the Salesloft Drift application to hijack OAuth rights to harvest cloud service and SaaS credentials from the targeted environment.

There is huge potential for actors who identify improperly configured or abandoned OAuth-enabled applications. This was demonstrated in 2024 when Midnight Blizzard struck gold by discovering a legacy application in Microsoft’s test environment that enabled high-privileged access to corporate environments. For several years, skilled cloud attackers have been working on tools that map both resources and OAuth relationships in target environments.

While gaining access to such a high value environment as a major cloud service and operating system provider may not be feasible for most actors, increases in automated scanning and data evaluation will only make finding new, well-connected targets easier.

Based on the increased prevalence of Zero Trust environments, an increased attacker focus and understanding of SaaS identity providers, and the rise in sophistication of tools used to identify relationships between identities and assets in organizations’ environments, we believe there is a significant risk for attacks that misuse the new forms of “trust” used to authenticate applications within environments.

A potential evolution we may see in 2026 is tooling that not only targets one SaaS application and its downstream connections, but likely has some degree of automation or evaluation through agentic AI analysis to continue performing more phases of intrusion based on findings from the previous phase.
Alex Delamotte, Senior Threat Researcher, SentinelLABS

 

AI-Driven Threats | Blurred Attribution and the DPRK Wildcard

The use of AI by adversaries will likely manifest in two ways outside of the ongoing discourse. The vast majority of attackers’ use of AI to date has been around driving greater efficiency and automating existing parts of their intrusion lifecycle. The intelligence assessments to date tend to skew towards technical improvements and capabilities.

If we look back on past assessments of emerging technologies — and let’s be honest, AI is without a doubt an emerging technology — two unexpected things tend to happen.

First, threat actors’ use of new technologies almost inevitably blurs existing assessment lines, typically around tradecraft and attribution. If we apply this to AI, the most likely upcoming shift will be lower-level/smaller groups gaining access to capabilities that were previously used to define government-affiliated programs. In particular, AI’s ability to provide language capabilities will bring low-level cybercriminals into the realm of government programs with full linguistic capabilities. This was an incredibly important capability distinction that is likely to end in the coming year solely because of AI.

The second likely outcome will be an almost inevitable surprise from DPRK’s AI use. DPRK cyber activities have previously caught intelligence organizations off-guard multiple times. Examples range from destructive attacks geared towards stopping a movie release through the current IT workers situation.

Additionally, AI has proven highly useful and effective to DPRK efforts, again the IT workers are a great example. When we pair these realities with the vast amount of illicit revenue generated by DPRK’s efforts at stealing cryptocurrency, we see an interesting situation emerging.

We have a cyber effort known to produce surprises, actively leveraging AI in a large and also previously unforeseen manner, and producing large amounts of revenue for the regime through cyber actions, both cryptocurrency theft and IT workers payments.

There is a high likelihood some level of these illicit gains will be reinvested into the DPRK cyber programs to increase their scope, scale, and impact–programs that are already actively pushing the bounds of AI use. While we do not have an expected outcome specifically, the likelihood of an unexpected, large, AI-driven surprise from DPRK is something we should be mindful of and prepared to tackle on the defensive side.

Steve Stone, SVP, Threat Discovery & Response

 

Looking Ahead & Protection Now

Moving ahead demands strong, decisive leadership based on confident security choices and the courage to evolve. For all those committed to a safer and more resilient future, SentinelOne is ready to help secure every aspect of your business. Contact us to learn more about cybersecurity built for what’s next.

Artificial intelligence (AI) is now squarely on the frontlines of information security. However, as is often the case when the pace of technological innovation is very rapid, security often ends up being a secondary consideration. This is increasingly evident from the ad-hoc nature of many implementations, where organizations lack a clear strategy for responsible AI use.

Attack surfaces aren’t just expanding due to risks and vulnerabilities in AI models themselves but also in the underlying infrastructure that supports them. Many foundation models, as well as the data sets used to train them, are open-source and readily available to developers and adversaries alike.

Unique risks to AI models

According to Ruben Boonen, CNE Capability Development Lead at IBM: “One problem is that you have these models hosted on giant open-source data stores. You don’t know who created them or how they were modified, and there are a number of issues that can occur here. For example, let’s say you use PyTorch to load a model hosted on one of these data stores, but it has been changed in a way that’s undesirable. It can be very hard to tell because the model might behave normally in 99% of cases.”

Recently, researchers discovered thousands of malicious files hosted on Hugging Face, one of the largest repositories for open-source generative AI models and training data sets. These included around a hundred malicious models capable of injecting malicious code onto users’ machines. In one case, hackers set up a fake profile masquerading as genetic testing startup 23AndMe to deceive users into downloading a compromised model capable of stealing AWS passwords. It was downloaded thousands of times before finally being reported and removed.

In another recent case, red team researchers discovered vulnerabilities in ChatGPT’s API, in which a single HTTP request elicited two responses indicating an unusual code path that could theoretically be exploited if not addressed. This, in turn, could lead to data leakage, denial of service attacks and even escalation of privileges. The team also discovered vulnerabilities in plugins for ChatGPT, potentially resulting in account takeover.

While open-source licensing and cloud computing are key drivers of innovation in the AI space, they’re also a source of risk. On top of these AI-specific risk areas, general infrastructure security concerns also apply, such as vulnerabilities in cloud configurations or poor monitoring and logging processes.

AI models are the new frontier of intellectual property theft

Imagine pouring huge amounts of financial and human resources into building a proprietary AI model, only to have it stolen or reverse-engineered. Unfortunately, model theft is a growing problem, not least because AI models often contain sensitive information and can potentially reveal an organization’s secrets should they end up in the wrong hands.

One of the most common mechanisms for model theft is model extraction, whereby attackers access and exploit models through API vulnerabilities. This can potentially grant them access to black-box models — like ChatGPT — at which point they can strategically query the model to collect enough data to reverse engineer it.

In most cases, AI systems run on cloud architecture rather than local machines. After all, the cloud provides the scalable data storage and processing power required to run AI models easily and accessibly. However, that accessibility also increases the attack surface, allowing adversaries to exploit vulnerabilities like misconfigurations in access permissions.

“When companies provide these models, there are usually client-facing applications delivering services to end users, such as an AI chatbot. If there’s an API that tells it which model to use, attackers could attempt to exploit it to access an unreleased model,” says Boonen.

Red teams keep AI models secure

Protecting against model theft and reverse engineering requires a multifaceted approach that combines conventional security measures like secure containerization practices and access controls, as well as offensive security measures.

The latter is where red teaming comes in. Red teams can proactively address several aspects of AI model theft, such as:

• API attacks: By systematically querying black-box models in the same way adversaries would, red teams can identify vulnerabilities like suboptimal rate limiting or insufficient response filtering.
• Side-channel attacks: Red teams can also carry out side-channel analyses, in which they monitor metrics like CPU and memory usage in an attempt to glean information about the model size, architecture or parameters.
• Container and orchestration attacks: By assessing containerized AI dependencies like frameworks, libraries, models and applications, red teams can identify orchestration vulnerabilities, such as misconfigured permissions and unauthorized container access.
• Supply chain attacks: Red teams can probe entire AI supply chains spanning multiple dependencies hosted in different environments to ensure that only trusted components like plugins and third-party integrations are being used.

A thorough red teaming strategy can simulate the full scope of real-world attacks against AI infrastructure to reveal gaps in security and incident response plans that could lead to model theft.

Mitigating the problem of excessive agency in AI systems

Most AI systems have a degree of autonomy with regard to how they interface with different systems and respond to prompts. After all, that’s what makes them useful. However, if systems have too much autonomy, functionality or permissions — a concept OWASP calls “excessive agency” — they can end up triggering harmful or unpredictable outputs and processes or leaving gaps in security.

Boonen warns that components, such as optical character recognition (OCR) for PDF files and images which multimodal systems rely on to process inputs, “can introduce vulnerabilities if they’re not properly secured”.

Granting an AI system excessive agency also expands the attack surface unnecessarily, thus giving adversaries more potential entry points. Typically, AI systems designed for enterprise use are integrated into much broader environments spanning multiple infrastructures, plugins, data sources and APIs. Excessive agency is what happens when these integrations result in an unacceptable trade-off between security and functionality.

Let’s consider an example where an AI-powered personal assistant has direct access to an individual’s Microsoft Teams meeting recordings stored in OneDrive for Business, the purpose being to summarize content in those meetings in a readily accessible written format. However, let’s imagine that the plugin doesn’t only have the ability to read meeting recordings but also everything else stored in the user’s OneDrive account, in which many confidential information assets are also stored. Perhaps the plugin even has write capabilities, in which case a security flaw could potentially grant attackers an easy pathway for uploading malicious content.

Once again, red teaming can help identify flaws in AI integrations, especially in environments where many different plugins and APIs are in use. Their simulated attacks and comprehensive analyses will be able to identify vulnerabilities and inconsistencies in access permissions, as well as cases where access rights are unnecessarily lax. Even if they don’t identify any security vulnerabilities, they will still be able to provide insight into how to reduce the attack surface.

The post How red teaming helps safeguard the infrastructure behind AI models appeared first on Security Intelligence.

Artificial intelligence (AI) and machine learning (ML) have entered the enterprise environment.

According to the IBM AI in Action 2024 Report, two broad groups are onboarding AI: Leaders and learners. Leaders are seeing quantifiable results, with two-thirds reporting 25% (or greater) boosts to revenue growth. Learners, meanwhile, say they’re following an AI roadmap (72%), but just 40% say their C-suite fully understands the value of AI investment.

One thing they have in common? Challenges with data security. Despite their success with AI and ML, security remains the top concern. Here’s why.

Full steam ahead: How AI and ML get smarter

Historically, computers did what they were told. Thinking outside the box wasn’t an option — lines of code dictated what was possible and permissible.

AI and ML models take a different approach. Instead of rigid structures, AI and ML models are given general guidelines. Companies supply vast amounts of training data that help these models “learn,” in turn improving their output.

A simple example is an AI tool designed to identify images of dogs. The underlying ML structures provide basic guidance — dogs have four legs, two ears, a tail and fur. Thousands of images of both dogs and not-dogs are provided to AI. The more pictures it “sees,” the better it becomes at differentiating dogs.

Learn more about today’s AI leaders

Off the rails: The risks of unauthorized model modification

If attackers can gain access to AI models, they can modify model outputs. Consider the example above. Malicious actors compromise business networks and flood training models with unlabeled images of cats and images incorrectly labeled as dogs. Over time, model accuracy suffers and outputs are no longer reliable.

Forbes highlights a recent competition that saw hackers trying to “jailbreak” popular AI models and trick them into producing inaccurate or harmful content. The rise of generative tools makes this kind of protection a priority — in 2023, researchers discovered that by simply adding strings of random symbols to the end of queries, they could convince generative AI (gen AI) tools to provide answers that bypassed model safety filters.

And this concern isn’t just conceptual. As noted by The Hacker News, an attack technique known as “Sleepy Pickle” poses significant risks for ML models. By inserting a malicious payload into pickle files — used to serialize Python object structures — attackers can change how models weigh and compare data and alter model outputs. This could allow them to generate misinformation that causes harm to users, steal user data or generate content that contains malicious links.

Staying the course: Three components for better security

To reduce the risk of compromised AI and ML, three components are critical:

1) Securing the data

Accurate, timely and reliable data underpins usable model outputs. The process of centralizing and correlating this data, however, creates a tempting target for attackers. If they can infiltrate large-scale AI data storage, they can manipulate model outputs.

As a result, enterprises need solutions that automatically and continuously monitor AI infrastructure for signs of compromise.

2) Securing the model

Changes to AI and ML models can lead to outputs that look legitimate but have been modified by attackers. At best, these outputs inconvenience customers and slow down business processes. At worst, they could negatively impact both reputation and revenue.

To reduce the risk of model manipulation, organizations need tools capable of identifying security vulnerabilities and detecting misconfigurations.

3) Securing the usage

Who’s using models? With what data? And for what purpose? Even if data and models are secured, use by malicious actors may put companies at risk. Continuous compliance monitoring is critical to ensure legitimate use.

Making the most of models

AI and ML tools can help enterprises discover data insights and drive increased revenue. If compromised, however, models can be used to deliver inaccurate outputs or deploy malicious code.

With Guardium AI security, businesses are better equipped to manage the security risks of sensitive models. See how.

The post The straight and narrow — How to keep ML and AI training on track appeared first on Security Intelligence.

Cybersecurity requires creativity and thinking outside the box. It’s why more organizations are looking at people with soft skills and coming from outside the tech industry to address the cyber skills gap. As the threat landscape becomes more complex and nation-state actors launch innovative cyberattacks against critical infrastructure, there is a need for cybersecurity professionals who can anticipate these attacks and develop creative preventive solutions.

Of course, a lot of cybersecurity work is mundane and repetitive — monitoring logs, sniffing out false positive alerts, etc. Artificial intelligence (AI) has been a boon in filling the talent gaps when it comes to these types of tasks. But AI has also proven useful for many of the same things that creative thought brings to the threat table, such as addressing more sophisticated threat actors, the rapid increase of data and the hybrid infrastructure.

However, many companies are seeing the value of AI, especially generative AI (gen AI), in handling a greater share of creative work — not just in cybersecurity but also in areas like marketing and public relations, writing and research. But are these organizations using AI in a way that could threaten the importance of human creativity in threat detection?

Why creativity is important to cybersecurity

The very simple reason why cybersecurity requires innovative people is that threat actors are already coming up with novel approaches to how to get into your system. Are they using gen AI to launch their attacks? You bet they are; phishing emails have never been more grammatically constructed or realistic. But before AI was available, threat actors were designing social engineering attacks that attracted clicks. Now, they have advanced beyond “how can we lure in victims” to “how can we get more out of a single attack after we lure in the victims.”

Creativity isn’t just coming up with new ideas. It is also the ability to see things through a big-picture lens and discern historical data or where to find information you might not know you need to look for. For example, creative thought is required for the following security tasks:

• Threat hunting or predicting a threat actor’s move or finding their tracks in a system
• Finding buried evidence in a forensic search
• Understanding historical data in anomaly detection
• Ability to tell a real email or document versus a well-designed phishing attack
• Verifying new zero day attacks and other malware variants found in otherwise unknown vulnerabilities

AI can augment human creativity, but gen AI gets a lot of things wrong. Users have found themselves in situations where AI claimed plagiarism on original work or AI hallucinations offered false information that nullified the research of human analysts. AI algorithms are also susceptible to bias that could lead to false positives.

Explore AI cybersecurity solutions

AI’s role in creative cybersecurity and beyond

While many creative people, cybersecurity professionals and beyond, see gen AI as a mixed blessing, many embrace the technology because it is a huge timesaver.

“Gen AI can help prototype much faster because the large language models can take over the refactoring and documentation of code,” wrote Aili McConnon in an IBM blog post. Also, the article pointed out, AI tools can help users create prototypes or visualize their ideas in minutes versus hours or days.

Creativity married to AI can help identify future leaders. According to research from IBM, two-thirds of company leaders found that AI is driving their growth, with four specific use cases — IT operations, user experience, virtual assistants and cybersecurity — most commonly favored by leaders.

“A Learner will typically copy predefined scenarios using out-of-the-box technologies,” Dr. Stephan Bloehdorn, Executive Partner and Practice Leader, AI, Analytics and Automation-IBM Consulting DACH, was quoted in the study. “But a Leader develops custom innovations.”

Over-reliance on AI?

As gen AI becomes more ubiquitous in the workplace and as more creative folks and leaders rely on it as a way to put their ideas in motion, are we also relying on the technology to the point that it could lead to a degradation of other important necessary skills, like the ability to analyze data and create viable solutions?

It is unclear if organizations are over-relying on gen AI, according to Stephen Kowski, Field CTO at SlashNext Email Security+, but it is becoming more of a designed feature due to unintended consequences related to resource allocation in organizations.

“While AI excels at processing massive volumes of threat data, real-world attacks constantly evolve beyond historical patterns, requiring human expertise to identify and respond to zero-day threats,” said Kowski in an email interview. “The key is achieving the right balance where AI handles high-volume routine detection while skilled analysts investigate novel attack patterns and determine strategic responses.”

Yet, Kris Bondi, CEO and Co-Founder of Mimoto, isn’t worried about AI leading to a degradation of skills — at least not for the foreseeable future.

“One of the biggest challenges for cybersecurity professionals is having too many alerts and too many false positives. AI is only able to automate a small percentage of responses. It’s more likely that AI will eventually automate additional requirements for someone deemed to be suspicious or the elevation of alert so that a human can analyze the situation,” Bondi said via email.

However, organizations should watch out for AI’s role in defining threat-hunting parameters. “If AI is the sole driver defining threat hunting parameters without spot-checks or audits, the threat intelligence approach could eventually be focused in the wrong area. The answer is more reliance on critical thinking and analytical skills,” said Bondi.

Embracing creativity in an AI-driven world

AI overall, and gen AI in particular, are going to be part of the business world going forward. It is going to play a vital role in how organizations and analysts approach cybersecurity defenses and mitigations. But the soft skills that creative thought depends on will still play an important and necessary role in cybersecurity.

“Rather than diminishing soft skills, AI integration has the opportunity to elevate the importance of communication, collaboration and strategic thinking, as security teams must effectively convey complex findings to stakeholders,” said Kowski. “The human elements of cybersecurity — leadership, adaptability and cross-functional partnership — become even more critical as AI handles the technical heavy lifting.”

The post Will AI threaten the role of human creativity in cyber threat detection? appeared first on Security Intelligence.

Human communication is multimodal. We receive information in many different ways, allowing our brains to see the world from various angles and turn these different “modes” of information into a consolidated picture of reality.

We’ve now reached the point where artificial intelligence (AI) can do the same, at least to a degree. Much like our brains, multimodal AI applications process different types — or modalities — of data. For example, OpenAI’s ChatGPT 4.0 can reason across text, vision and audio, granting it greater contextual awareness and more humanlike interaction.

However, while these applications are clearly valuable in a business environment that’s laser-focused on efficiency and adaptability, their inherent complexity also introduces some unique risks.

According to Ruben Boonen, CNE Capability Development Lead at IBM: “Attacks against multimodal AI systems are mostly about getting them to create malicious outcomes in end-user applications or bypass content moderation systems. Now imagine these systems in a high-risk environment, such as a computer vision model in a self-driving car. If you could fool a car into thinking it shouldn’t stop even though it should, that could be catastrophic.”

Multimodal AI risks: An example in finance

Here’s another possible real-world scenario:

An investment banking firm uses a multimodal AI application to inform its trading decisions, processing both textual and visual data. The system uses a sentiment analysis tool to analyze text data, such as earnings reports, analyst insights and news feeds, to determine how market participants feel about specific financial assets. Then, it conducts a technical analysis of visual data, such as stock charts and trend analysis graphs, to offer insights into stock performance.

An adversary, a fraudulent hedge fund manager, then targets vulnerabilities in the system to manipulate trading decisions. In this case, the attacker launches a data poisoning attack by flooding online news sources with fabricated stories about specific markets and financial assets. Next, they launch an adversarial attack by making pixel-level manipulations — known as perturbations — to stock performance charts that are imperceptible to the human eye but enough to exploit the AI’s visual analysis abilities.

The result? Due to the manipulated input data and false signals, the system recommends buying orders at artificially inflated stock prices. Unaware of the exploit, the company follows the AI’s recommendations, while the attacker, holding shares in the target assets, sells them for an ill-gotten profit.

Getting there before adversaries

Now, let’s imagine that the attack wasn’t really carried out by a fraudulent hedge fund manager but was instead a simulated attack by a red team specialist with the goal of discovering the vulnerability before a real-world adversary could.

By simulating these complex, multifaceted attacks in safe, sandboxed environments, red teams can reveal potential vulnerabilities that traditional security systems are almost certain to miss. This proactive approach is essential for fortifying multimodal AI applications before they end up in a production environment.

According to the IBM Institute of Business Value, 96% of executives agree that the adoption of generative AI will increase the chances of a security breach in their organizations within the next three years. The rapid proliferation of multimodal AI models will only be a force multiplier of that problem, hence the growing importance of AI-specialized red teaming. These specialists can proactively address the unique risk that comes with multimodal AI: cross-modal attacks.

Cross-modal attacks: Manipulating inputs to generate malicious outputs

A cross-modal attack involves inputting malicious data in one modality to produce malicious output in another. These can take the form of data poisoning attacks during the model training and development phase or adversarial attacks, which occur during the inference phase once the model has already been deployed.

“When you have multimodal systems, they’re obviously taking input, and there’s going to be some kind of parser that reads that input. For example, if you upload a PDF file or an image, there’s an image-parsing or OCR library that extracts data from it. However, those types of libraries have had issues,” says Boonen.

Cross-modal data poisoning attacks are arguably the most severe since a major vulnerability could necessitate the entire model being retrained on an updated data set. Generative AI uses encoders to transform input data into embeddings — numerical representations of the data that encode relationships and meanings. Multimodal systems use different encoders for each type of data, such as text, image, audio and video. On top of that, they use multimodal encoders to integrate and align data of different types.

In a cross-modal data poisoning attack, an adversary with access to training data and systems could manipulate input data to make encoders generate malicious embeddings. For example, they might deliberately add incorrect or misleading text captions to images so that the encoder misclassifies them, resulting in an undesirable output. In cases where the correct classification of data is crucial, as it is in AI systems used for medical diagnoses or autonomous vehicles, this can have dire consequences.

Red teaming is essential for simulating such scenarios before they can have real-world impact. “Let’s say you have an image classifier in a multimodal AI application,” says Boonen. “There are tools that you can use to generate images and have the classifier give you a score. Now, let’s imagine that a red team targets the scoring mechanism to gradually get it to classify an image incorrectly. For images, we don’t necessarily know how the classifier determines what each element of the image is, so you keep modifying it, such as by adding noise. Eventually, the classifier stops producing accurate results.”

Vulnerabilities in real-time machine learning models

Many multimodal models have real-time machine learning capabilities, learning continuously from new data, as is the case in the scenario we explored earlier. This is an example of a cross-modal adversarial attack. In these cases, an adversary could bombard an AI application that’s already in production with manipulated data to trick the system into misclassifying inputs. This can, of course, happen unintentionally, too, hence why it’s sometimes said that generative AI is getting “dumber.”

In any case, the result is that models that are trained and/or retrained by bad data inevitably end up degrading over time — a concept known as AI model drift. Multimodal AI systems only exacerbate this problem due to the added risk of inconsistencies between different data types. That’s why red teaming is essential for detecting vulnerabilities in the way different modalities interact with one another, both during the training and inference phases.

Red teams can also detect vulnerabilities in security protocols and how they’re applied across modalities. Different types of data require different security protocols, but they must be aligned to prevent gaps from forming. Consider, for example, an authentication system that lets users verify themselves either with voice or facial recognition. Let’s imagine that the voice verification element lacks sufficient anti-spoofing measures. Chances are, the attacker will target the less secure modality.

Multimodal AI systems used in surveillance and access control systems are also subject to data synchronization risks. Such a system might use video and audio data to detect suspicious activity in real-time by matching lip movements captured on video to a spoken passphrase or name. If an attacker were to tamper with the feeds, resulting in a slight delay between the two, they could mislead the system using pre-recorded video or audio to gain unauthorized access.

Getting started with multimodal AI red teaming

While it’s admittedly still early days for attacks targeting multimodal AI applications, it always pays to take a proactive stance.

As next-generation AI applications become deeply ingrained in routine business workflows and even security systems themselves, red teaming doesn’t just bring peace of mind — it can uncover vulnerabilities that will almost certainly go unnoticed by conventional, reactive security systems.

Multimodal AI applications present a new frontier for red teaming, and organizations need their expertise to ensure they learn about the vulnerabilities before their adversaries do.

The post Stress-testing multimodal AI applications is a new frontier for red teams appeared first on Security Intelligence.

The rising influence of artificial intelligence (AI) has many organizations scrambling to address the new cybersecurity and data privacy concerns created by the technology, especially as AI is used in cloud systems. Apple addresses AI’s security and privacy issues head-on with its Private Cloud Compute (PCC) system.

Apple seems to have solved the problem of offering cloud services without undermining user privacy or adding additional layers of insecurity. It had to do so, as Apple needed to create a cloud infrastructure on which to run generative AI (genAI) models that need more processing power than its devices could supply while also protecting user privacy, stated a ComputerWorld article.

Apple is opening the PCC system to security researchers to “learn more about PCC and perform their own independent verification of our claims,” the company announced. In addition, Apple is also expanding its Apple Security Bounty.

What does this mean for AI security going forward? Security Intelligence spoke with Ruben Boonen, CNE Capability Development Lead at IBM, to learn what researchers think about PCC and Apple’s approach.

SI: ComputerWorld reported this story, saying that Apple hopes that “the energy of the entire infosec community will combine to help build a moat to protect the future of AI.” What do you think of this move?

Boonen: I read the ComputerWorld article and reviewed Apple’s own statements about their private cloud. I think what Apple has done here is good. I think it goes beyond what other cloud providers do because Apple is providing an insight into some of the internal components they use and are basically telling the security community, you can have a look at this and see if it is secure or not.

Also good from the perspective that AI is constantly getting bigger as an industry. Bringing generative AI components into regular consumer devices and getting people to trust their data with AI services is a really good step.

SI: What do you see as the pros of Apple’s approach to securing AI in the cloud?

Boonen: Other cloud providers do provide high-security guarantees for data that’s stored on their cloud. Many businesses, including IBM, trust their corporate data to these cloud providers. But a lot of times, the processes to secure data aren’t visible to their customers; they don’t explain exactly what they do. The biggest difference here is that Apple is providing this transparent environment for users to test that plane.

Explore AI cybersecurity solutions

SI: What are some of the downsides?

Boonen: Currently, the most capable AI models are very big, and that makes them very useful. But when we want AI on consumer devices, there’s a tendency for vendors to ship small models that can’t answer all questions, so it relies on the larger models in the cloud. That comes with additional risk. But I think it is inevitable that the whole industry will be moving to that cloud model for AI. Apple is implementing this now because they want to give consumers trust to the AI process.

SI: Apple’s system doesn’t play well with other systems and products. How will Apple’s efforts to secure AI in the cloud benefit other systems?

Boonen: They are providing a design template that other providers like Microsoft, Google and Amazon can then replicate. I think it is mostly effective as an example for other providers to say maybe we should implement something similar and provide similar testing capabilities for our customers. So I don’t think this directly impacts other providers except to push them to be more transparent in their processes.

It’s also important to mention Apple’s Bug Bounty as they invite researchers in to look at their system. Apple has a history of not doing very well with security, and there have been cases in the past where they’ve refused to pay out bounties for issues found by the security community. So I’m not sure they’re doing this entirely out of the interest of attracting researchers, but also in part of convincing their customers that they are doing things securely.

That being said, having read their design documentation, which is extensive, I think they’re doing a pretty good job in addressing security around AI in the cloud.

The post Cybersecurity awareness: Apple’s cloud-based AI security system appeared first on Security Intelligence.

Have you ever wished you had an assistant at your security operations centers (SOCs) — especially one who never calls in sick, has a bad day or takes a long lunch? Your wish may come true soon. Not surprisingly, AI-driven SOC “co-pilots” are topping the lists for cybersecurity predictions in 2025, which often describe these tools as game-changers.

“AI-driven SOC co-pilots will make a significant impact in 2025, helping security teams prioritize threats and turn overwhelming amounts of data into actionable intelligence,” says Brian Linder, Cybersecurity Evangelist at Check Point. “It’s a game-changer for SOC efficiency.”

What is an AI-driven SOC co-pilot?

AI-driven SOC co-pilots are generative AI tools that use machine learning to help security analysts run and manage the SOC. Common co-pilot tasks include detecting threats, managing incidents, triaging alerts, predicting new trends and patterns for attacks and breaches and automating responses to threats. Co-pilots may be proprietary tools built by the company for their specific needs or commercially available cybersecurity co-pilots such as Microsoft Copilot.

For example, a co-pilot can review alerts and use AI to predict which are most likely to be a high priority. This reduces a common issue in SOCs: false positives. The analysts can then focus on the alerts that are most likely to be a real threat. Because they are not chasing down noncritical alerts, analysts have more time to spend on actual threats and are more likely to be successful in containing the threat.

Co-pilots can take many different forms in a SOC. Analysts can use the co-pilot similarly to how many people use ChatGPT, assigning it a specific task such as incident response. The analyst enters information about a specific incident, and the co-pilot analyzes data to suggest possible causes as well as how the organizations should respond to the incident. However, you can also use co-pilots to automate parts of the workflow without human intervention, such as monitoring current firewalls and detecting vulnerabilities.

Explore AI cybersecurity solutions

Benefits of using AI-driven SOC co-pilots

Businesses that turn to AI-driven co-pilots to help manage their SOC see a wide range of benefits. Common benefits include:

• Improved productivity: Because it can process a much higher volume of data than even the most efficient cybersecurity analyst, a co-pilot gets significantly more work done in less time. With humans and machines working together, co-pilots are able to more effectively monitor the SOC with fewer human resources.
• Additional time for cybersecurity professionals to complete high-level tasks: When co-pilots handle manual and repetitive tasks, analysts have more time for higher-level tasks such as strategy and analytics. Analysts are more likely to be fully engaged when their day is filled with more interesting work, which reduces burnout.
• Fewer errors: Humans make mistakes, especially with manual tasks such as reviewing logs. While AI tools are only as “smart” as the algorithm and the training data used for the algorithm, they are often able to spot patterns that may be undetectable to humans. This reduces errors and prevents issues that can lead to a breach or attack.
• Quicker response to threats: Whereas humans may not recognize an area of vulnerability or may be slower to respond, a co-pilot uses automation to respond and send a notification immediately. Co-pilots also don’t take bathroom or lunch breaks; they are always “at their desk,” leading to faster response times.
• Reduced impact of worker shortage and skills gaps: When cybersecurity positions are not filled or the analyst does not have the right skills for the job, the company’s risk increases. AI-driven co-pilots can help reduce open positions by taking on various manual tasks, which means greater coverage by the SOC.

Will AI-driven SOC co-pilots replace humans?

Like many AI tools, co-pilots can take over many manual and repetitive tasks currently done by humans. However, the fear of AI replacing the need for humans in the SOC is not likely to become reality. Setting up co-pilots to operate without human oversight or intervention would likely be a mistake. But businesses that have analysts and co-pilots work together can see a reduction in risk, better responses and higher employee satisfaction.

While co-pilots can be the first line of defense in the SOC, companies should set up gen AI tools so that humans remain the ultimate decision-makers. For example, an analyst may set up an automation with an AI-driven co-pilot to monitor and prioritize alerts based on set criteria. Yet, as threat actors begin using new tactics, the analyst may need to change the criteria to catch the latest threats. Once the co-pilot identifies a high-priority alert, the human can ask the tool to analyze the situation and provide recommended next steps. The analyst then uses human judgment to make the best decisions in the situation and instructs the tool to take the next action, such as shutting down systems or taking the network temporarily offline.

Putting AI-driven co-pilots into action in the SOC

When it comes to putting co-pilots in action, consider starting on a small scale with a limited use case. Many organizations use a commercial product to start, leaving open the option to create a proprietary tool in the future. Creating a list of time-consuming tasks in the SOC, especially those that are error-prone or frustrating for analysts, will help you determine which use case to start with. After launching the tool, a single analyst can gather feedback and make changes.

Upon seeing success, your team can begin expanding the use of co-pilots to additional analysts and use cases. By taking a measured approach to using co-pilots and continuously soliciting feedback from the analysts, businesses can create a partnership between analysts and co-pilots that improves human job satisfaction while also keeping the organization more secure.

The post How AI-driven SOC co-pilots will change security center operations appeared first on Security Intelligence.

“A computer can never be held accountable, therefore a computer must never make a management decision.”

– IBM Training Manual, 1979

Artificial intelligence (AI) adoption is on the rise. According to the IBM Global AI Adoption Index 2023, 42% of enterprises have actively deployed AI, and 40% are experimenting with the technology. Of those using or exploring AI, 59% have accelerated their investments and rollouts over the past two years. The result is an uptick in AI decision-making that leverages intelligent tools to arrive at (supposedly) accurate answers.

Rapid adoption, however, raises a question: Who’s responsible if AI makes a poor choice? Does the fault lie with IT teams? Executives? AI model builders? Device manufacturers?

In this piece, we’ll explore the evolving world of AI and reexamine the quote above in the context of current use cases: Do companies still need a human in the loop, or can AI make the call?

Getting it right: Where AI is improving business outcomes

Guy Pearce, principal consultant at DEGI and member of the ISACA working trends group, has been involved with AI for more than three decades. “First, it was symbolic,” he says, “and now it’s statistical. It’s algorithms and models that allow data processing and improve business performance over time.”

Data from IBM’s recent AI in Action report shows the impact of this shift. Two-thirds of leaders say that AI has driven more than a 25% improvement in revenue growth rates, and 72% say that the C-suite is fully aligned with IT leadership about what comes next on the path to AI maturity.

With confidence in AI growing, enterprises are implementing intelligent tools to improve business outcomes. For example, wealth management firm Consult Venture Partners deployed AIda AI, a conversational digital AI concierge that uses IBM watsonx assistant technology to answer potential clients’ questions without the need for human agents.

The results speak for themselves: Alda AI answered 92% of queries correctly, 47% of queries led to webinar registrations and 39% of inquiries turned into leads.

Missing the mark: What happens if AI makes mistakes?

92% is an impressive achievement for Alda AI. The caveat? It was still wrong 8% of the time. So, what happens when AI makes mistakes?

For Pearce, it depends on the stakes.

He uses the example of a financial firm leveraging AI to evaluate credit scores and issue loans. The outcomes of these decisions are relatively low stakes. In the best-case scenario, AI approves loans that are paid back on time and in full. In the worst case, borrowers default, and companies need to pursue legal action. While inconvenient, the negative outcomes are far outweighed by the potential positives.

“When it comes to high stakes,” says Pearce, “look at the medical industry. Let’s say we use AI to address the problem of wait times. Do we have sufficient data to ensure patients are seen in the right order? What if we get it wrong? The outcome could be death.”

As a result, how AI is used in decision-making depends largely on what it’s making decisions about and how these decisions impact both the company making the decisions and those the decision affects.

In some cases, even the worst-case scenario is a minor inconvenience. In others, the results could cause significant harm. 

Explore AI cybersecurity

Taking the blame: Who’s accountable if AI gets it wrong?

In April 2024, a Tesla operating in “full self-driving” mode struck and killed a motorcyclist. The driver of the vehicle admitted to looking at their phone prior to the crash despite active driver supervision being required.

So who takes the blame? The driver is the obvious choice and was arrested on charges of vehicular homicide.

But this isn’t the only path to accountability. There’s also a case to be made in which Tesla bears some responsibility since the company’s AI algorithm failed to spot the victim. Blame could also be placed on governing bodies such as the National Highway Traffic Safety Administration (NHTSA). Perhaps their testing wasn’t rigorous or complete enough.

One could even argue that the creator(s) of Tesla’s AI could be held liable for letting code that could kill someone go live.

This is the paradox of AI decision-making: Is someone at fault, or is everyone at fault? “If you bring all the stakeholders together who should be accountable, where does that accountability lie?” asks Pearce. “With the C-suite? With the whole team? If you have accountability that’s spread over the entire organization, everyone can’t end up in jail. Ultimately, shared accountability often leads to no accountability.”

Drawing the line: Where does AI end?

So, where do organizations draw the line? Where does AI insight give way to human decision-making?

Three considerations are key: Ethics, risk and trust.

“When it comes to ethical dilemmas,” says Pearce, “AI can’t do it.” This is because intelligent tools naturally seek the most efficient path, not the most ethical. As a result, any decision involving ethical questions or concerns should include human oversight.

Risk, meanwhile, is an AI specialty. “AI is good in risk,” Pearce says. “What statistical models do is give you something called a standard error, which lets you know if what AI is recommending has a high or low potential variability.” This makes AI great for risk-based decisions like those in finance or insurance.

Finally, enterprises need to prioritize trust. “There are declining levels of trust in institutions,” says Pearce. “Many citizens don’t feel confident that the data they share is being used in a trustworthy manner.”

For example, under GDPR, companies need to be transparent about data collection and handling and give citizens a chance to opt-out. To bolster trust in AI use, organizations should clearly communicate how and why they’re using AI and (where possible) allow customers and clients to opt out of AI-driven processes.

Decisions, decisions

Should AI be used for management decisions? Maybe. Will it be used to make some of these decisions? Almost certainly. The draw of AI — its ability to capture, correlate and analyze multiple data sets and deliver new insights — makes it a powerful tool for enterprises to streamline operations and reduce costs.

What’s less clear is how the shift to management-level decision-making will impact accountability. According to Pearce, current conditions create “blurry lines” in this area; legislation hasn’t kept pace with increasing AI usage.

To ensure alignment with ethical principles, reduce the risk of wrong choices and engender stakeholder and customer trust, businesses are best served by keeping humans in the loop. Maybe this means direct approval from staff is required before AI can act. Maybe it means the occasional review and evaluation of AI decision-making outcomes.

Whatever approach enterprises choose, however, the core message remains the same: When it comes to AI-driven decisions, there’s no hard-and-fast line. It’s a moving target, one defined by possible risk, potential reward and probable outcomes.

The post AI decision-making: Where do businesses draw the line? appeared first on Security Intelligence.

With cloud infrastructure and, more recently, artificial intelligence (AI) systems becoming prime targets for attackers, security leaders are laser-focused on defending these high-profile areas. They’re right to do so, too, as cyber criminals turn to new and emerging technologies to launch and scale ever more sophisticated attacks.

However, this heightened attention to emerging threats makes it easy to overlook traditional attack vectors, such as human-driven social engineering and vulnerabilities in physical security.

As adversaries exploit an ever-wider range of potential entry points — both new and old — security leaders must strike a balance to ensure that they’re capable of addressing all risks effectively.

Cyber crime is still a human problem

Despite overwhelming hype, technology is not a panacea. It can’t replace human expertise in every domain, and AI alone can’t match the innately human qualities of intuition and creative thinking. Adversaries know this too, which is why the smarter — and much more dangerous — ones use a blend of human- and technology-powered tactics.

While major technical vulnerabilities tend to make the headlines, the reality is that the weakest link is almost always the human element. Almost all attacks involve a social engineering element, and despite the buzz around generative AI and deepfakes helping scale such attacks, it’s human-to-human interaction where the greatest risks lie.

Synthetic content is now all around us, and people are getting better at telling it apart. Whether we get to the point when that’s no longer the case is a topic for another discussion. But for now, the most dangerous and effective social engineering attacks still depend primarily on human conversations, whether by phone, email or even in person. After all, a seasoned attacker can build trust and forge sham relationships in a way that no AI nor deepfake can match.

Cyber espionage remains a serious threat

Take state-sponsored cyber espionage, for example. Highly trained social engineers are a far cry from the typical rabble of independent cyber crime rackets operating off the dark web, who tend to rely more on scale than targeting specific enterprises and individuals. These attackers may target data systems, but when it comes to their own arsenals, their talents in manipulation and deception are by far their greatest weapons.

Technology still has a long way to go before it can come close to matching the age-old tactics of spycraft.

When facing an attacker who can pose effectively as an internal employee or any other trusted individual, someone relying solely on technology to mitigate the threat stands little chance of protecting themselves. That isn’t a technology failure. It’s a process failure, hence why the human element must always be a key factor in any cybersecurity strategy.

Of course, that’s not to say technology doesn’t have a vital role to play in bolstering your cyber defenses. It most certainly does, not least, because more and more routine threats are being automated or are carried out en-masse by attackers who are less skilled or experienced. The value of technology — especially AI-powered cybersecurity automation — exists primarily in its ability to free up time for security leaders to focus on the threats that technology alone can’t solve.

Explore cybersecurity services

It’s not all about the cloud, either

The majority of business data is now stored in the cloud, and the percentage continues to rise. Many businesses, especially smaller organizations and startups, exclusively use the cloud for data storage and other IT operations. The rise of AI, given how computationally demanding it is, is further accelerating cloud adoption.

Nonetheless, cloud computing isn’t the best option in all situations. On-premises remains the preferred choice for high-performance workloads that require extremely low latencies. In some cases, on-premises computing is also the cheaper option, and that’s unlikely to change in the near future.

Even though more companies are migrating to the cloud, that doesn’t mean they don’t keep sensitive data on-site. For instance, edge computing, which brings data processing closer to where it’s needed, has become a critical enabler in certain use cases. Examples include smart energy grids, remote monitoring of industrial assets and autonomous vehicles. These include cases where you can’t always rely on internet connectivity.

The smarter and better-funded adversaries aren’t just targeting cloud-hosted infrastructure. They’re also setting their sights on local servers and cyber-physical systems, such as industrial control systems and hardware supply chains. The fact that there’s often minimal collaboration between logistics, production and cybersecurity departments makes these risks all the more serious.

Ransomware remains one of the biggest threats targeting on-premises systems despite the small reduction in attacks over the last year. While cloud systems aren’t inherently immune from ransomware attacks, the vast majority target bare-metal hypervisors and local servers. In one recent case, the Akira ransomware group reverted to its earlier double extortion tactics, experimenting with different code frameworks to target systems running ESXi and Linux.

Botnets are another growing concern as the number of IoT devices continues to soar. Used to launch distributed denial of service (DDoS) attacks spanning thousands of devices, these botnets primarily target unsecured IoT devices, like those that monitor and operate industrial machines and critical infrastructure. One recent report discovered that DDoS attacks against critical infrastructure have increased by 55% in the last four years. These attacks don’t directly involve the exfiltration of sensitive data, but given how they can cause widespread disruption, adversaries may rely on them to draw attention away from more serious threats.

Why physical security is still relevant

As security leaders focus on locking down their cloud-hosted assets, they cannot afford to lose sight of the risks facing their physical infrastructure. Sometimes, the easiest way into the cloud is from within.

Even thin clients and dumb terminals — both widely used in high-security environments like healthcare and finance — can potentially give attackers a foothold in wider systems, including cloud infrastructure and remote data centers. Edward Snowden proved that while working at the National Security Agency when he exfiltrated 20,000 government documents stored on the servers in NSA’s headquarters 5,000 miles away. He did so without using any advanced technology. While that happened way back in 2013, and the NSA has long since updated its physical security protocols, the risk is just as relevant today as it was then.

While most thin clients are now protected by multiple layers of security, including encryption and multifactor authentication, these solutions alone can’t fully protect against physical compromise. If an attacker gains access to a terminal — perhaps by way of social engineering — they may be able to compromise it using unauthorized peripherals or by directly manipulating the device’s firmware. This could give them access to the wider network, potentially allowing for the injection of customized malware that goes undetected by regular security scans.

IoT devices are another leading reason behind the expansion of attack surfaces. They often lack adequate security, also giving attackers a potential entry point into the broader computing infrastructures they’re connected to. The fact that these connected technologies are being rolled out en masse in areas like smart cities, critical infrastructure and transportation networks, greatly magnifies such vulnerabilities.

Ultimately, if an attacker is able to get past your physical safeguards, then these connected systems present far easier pathways to an organization’s so-called “crown jewels” than trying to break through multi-layered cloud defenses.

Cloud data is not always the true target

In other cases, data hosted in the cloud might not be the attacker’s end goal. Many companies, such as those subject to stringent data residency regulations or that require high performance for real-time applications, still store their data on on-premises servers.

Some of these systems are air-gapped, meaning they’re entirely disconnected from any other networks, including the Internet itself. While more secure than any cloud-hosted server, at least in theory, their security can’t be taken for granted. For instance, anyone with physical access to the servers may be able to compromise them, either maliciously or accidentally.

Physical security, such as CCTV and biometric security checkpoints, is as important as ever in such cases. But it’s not just about protecting against intentional physical tampering. Indirect attacks orchestrated by highly skilled social engineers can also dupe unsuspecting employees into taking a desired action — such as lending them a biometric security access card.

These are not the sort of adversaries that usually work by email or use AI to scale their attacks – they’re far likelier to deceive someone in person, a tactic as old as humanity itself. In fact, the attacker could be anyone, such as a disgruntled former employee, a hacker operating in the interests of a rival company or even a rogue state.

Bridging the gap between digital and human security

Technology alone can’t protect an organization from the myriad threats out there, and neither can humans keep up with ever-expanding system logs and security information feeds if they’re relying solely on manual processes.

The reality is that you need both, starting with people and using technology to broaden their capabilities. A layered security strategy should typically start with locking down physical access to any data-bearing system or system that is connected to another.

The next layer of defense is the human one. This revolves heavily around security awareness training. But the reality is that many programs are ineffective, either because they lack practical application, are overly reliant on generic content or focus too much on technical factors that are beyond the target audience’s understanding.

Phishing simulations are often similarly limited in their scope, focusing on common lures like trending news topics, a sense of urgency or even outright threats. However, more sophisticated attackers tend to use subtler ways to elicit a response. This could be something as simple as sending messages about a routine policy update regarding company dress code or remote work guidelines. These topics might seem trivial, but they can pique interest, especially when they concern changes to daily routines and work-life balance. Attackers could then use this to dupe unsuspecting victims into divulging sensitive information via a sham survey.

Like any other security measure, physical systems and awareness training will only ever be effective if they’re tested regularly. That’s where physical red teaming comes in. Whereas red teaming in the context of IT focuses on technical measures like penetration testing, physical red teaming is all about having teams try to gain entry to restricted areas and systems. To do so, they might use a blend of simulated social engineering attacks and technology to hack into physical security systems. By attempting to bypass physical security barriers or impersonate staff, red teams can reveal gaps that might otherwise go unnoticed. That’s what makes them a valuable part of any comprehensive information security program.

The post AI and cloud vulnerabilities aren’t the only threats facing CISOs today appeared first on Security Intelligence.