In describing SIEM features, vendors almost invariably focus on numbers: how many correlation rules come out of the box, how many were added over the past year, and how many MITRE ATT&CK techniques they cover. Admittedly, these numbers matter. They do help gauge how effective a system is, and we share them from time to time too. But correlation rules aren’t a magic amulet, and having more of them doesn’t make a SIEM more effective. In fact, the total number of available rules says more about the variety of use cases the system supports. The question a hands-on SIEM analyst cares about first of all is different: which of these rules will actually work and be useful at my company? The answer is far from always obvious, and the reason isn’t even rule quality.

How correlation rules work

A rule first and foremost describes the logic: what to match against what, in what order, and within what time window. It also specifies particular event types from particular sources. For example, a rule for Active Directory group creation waits for events from the Windows Security log; a rule for suspicious network activity — DNS queries; a rule for process manipulation — triggers on events from endpoint telemetry. In other words, whether a rule works depends on whether the SIEM receives the right data in the first place.

The Active Directory rule above would be completely pointless at a company that avoids Windows on principle. It would load without errors, show up in the interface, and technically “exist” — but it would never fire. The reason is simple: the events it was built for never reach the system.

That dictates the only correct order of steps when setting up an SIEM. Don’t start out from the list of rules and then work your way toward your infrastructure. Go the other way around: first pin down which event sources are actually connected and feeding data into the SIEM, and only then see which rules will work on that data. Doing it the other way around leads to one of two outcomes: unmet expectations (hundreds of rules, almost no detections), or a laborious rule-by-rule manual slog, where the analyst opens every rule’s description, checks its event requirements, and decides whether the rule is worth using.

What the MITRE ATT&CK coverage percentage means

MITRE ATT&CK coverage is much the same story: it’s often used without a second thought as a yardstick for product effectiveness. The catch is that these are numbers in a vacuum, with no real-world conditions behind them. Coverage only makes sense for a specific set of working rules. And as we saw above, that set of rules depends on the set of event sources. That’s why the same SIEM will show different MITRE ATT&CK coverage at two different companies. Where Windows logs, endpoint telemetry, an email gateway, and network equipment are all connected, coverage will be noticeably broader than at a company with fewer sources.

Here’s the right way to read this metric: it’s not a score for the SIEM content, but a map of what your SIEM can see with its current telemetry. A tactic with low coverage is a signal that detecting it requires data you don’t have yet. Framed this way, it becomes a clear argument for a management conversation. Not “we need one more event source”, but “this part of the matrix is currently invisible to us, and here’s what it takes to close the gap”.

What’s worth checking in your SIEM

To get the most out of a SIEM, it’s worth asking yourself a few questions — not just when deploying the system, but regularly:

• Is every connected event source being handled by rules? Infrastructure changes constantly: new systems appear and new integrations get connected. Every change like this is a reason to check again whether there are now rules you should enable.
• Do I know exactly which events are required for which rules? Sometimes a rule doesn’t fire not because a whole event source is missing, but because a single event type isn’t being collected: the audit policy simply isn’t set up to capture it. Fix that oversight as soon as possible.
• Do I understand my coverage in terms of MITRE ATT&CK? The point isn’t to produce good-looking reports. It’s to prioritize which event sources to add next: which ones will give the biggest gain in visibility?

But how can you answer these questions without spending ages digging into every rule description? We have a solution.

How we can help

To help analysts find their way around the detection logic of our solution more easily, we’ve added a knowledge base section with the complete set of Kaspersky SIEM rules. In essence, it’s a tool that holds data from the official documentation for the SOC Package rule set, and makes it easy to work with that data. It has three sections:

Library. A table of all correlation rules that you can sort and filter per any column: category, MITRE tactic and technique, event source, and event type. Search works across all fields, including descriptions. Double-clicking a rule opens a card with detailed information about it.

Builder. A tool for assembling a rule set that suits the event sources you already have. The analyst just checks the boxes for the sources the company has, and gets a list of matching rules, brief statistics, and the event types that need to be set up for collection. The tool also generates a regular expression that you can paste into the search bar of the Kaspersky SIEM web interface to link all the matching rules to the correlator in a single step, with no manual picking.

MITRE. A view of the ATT&CK matrix where tactics expand into techniques and sub-techniques. Each matrix item has a card with the description from the MITRE website, and SOC Package coverage details. Covered and uncovered items are color-coded, and charts show coverage per tactic.

One more point worth stressing: the content in our SIEM is updated constantly, so it makes sense to check your setup against it not only at deployment, but after every notable change in your infrastructure. To follow the development of the Kaspersky Unified Monitoring and Analysis Platform, visit the official product page.

Late October brought several unsettling cybersecurity stories all at once. Among these were two critical vulnerabilities in PHP, which potentially affected about 70% of websites worldwide. CVE-2026-109618 and CVE-2026-109619 — dubbed PHP2Shell — could let attackers execute code on a server remotely, without authentication.

On October 21, PHP’s developers released emergency patches for the supported PHP 8.2–8.5 branches and for the unsupported PHP 7.4, 8.0, and 8.1. Experts predicted that attacks on vulnerable servers would start within 15 minutes of the updates going public. Amazon even reported exploitation attempts four days before the patches came out. With all this in the news, some organizations sounded the alarm early. For example, in several countries, government service websites were taken offline as a precaution. Even Wikipedia’s project management and bug-tracking system suspended service.

Nearly two weeks have passed since the updates came out, but according to Censys data, of the 46 million scannable servers running a vulnerable PHP version, 29 million still contain the flaws. Right after the patches were published, we broke down each flaw in detail and explained what companies and everyday users should do. In this post we cover what’s known about the threat today, and what extra steps businesses need to take.

What happened after the PHP2Shell patches

The news about critical PHP vulnerabilities set off a flurry of reactions. Researchers noted a large number of exploitation attempts, and fresh exploits kept appearing in batches — courtesy of AI. A Palo Alto Networks unit even reported a PHP2Shell attack on a government agency in Europe, though it later retracted that statement. Solid evidence of how these vulnerabilities can actually be exploited only emerged later. On top of that, a third, unpatched one turned up.

A vulnerability with no patch

On Friday, October 23, the PHP team warned about a new vulnerability — CVE-2026-115560 — which can be used for remote code execution. But attackers can only pull this off on systems with an “unusual combination of configuration and application code”. That configuration is so exotic that the developers decided against an emergency patch, and will close the vulnerability on the regular schedule. In the meantime, they advised users to disable the session.upload_progress.enabled INI option.

First signs of PHP flaws being exploited

Let’s get back to the more serious threats. The most substantial confirmation of PHP2Shell exploitation in real-world attacks only came on October 24. Honeypot servers run by Adel Karimi of Perplexity running PHP 8.4.26 and presenting ordinary web pages recorded successful attacks from two IP addresses. The observed exploit chain was consistent with CVE-2026-109618. There’s an important caveat, though: the researcher’s honeypot ran the Apache mod_php module, which is the configuration most convenient for attackers.

Later, on October 26, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog. That confirmed the threat isn’t just theoretical.

Real-world breaches with PHP2Shell

On October 26, the technology company Dream reported that 25 firewalls and management servers had been compromised in the U.S., Japan, Taiwan, and South Korea. Three of them were in an environment presumed to be linked to U.S. government agencies. The attackers combined PHP2Shell with a Linux kernel vulnerability dubbed Fragnesia (CVE-2026-46300). Upon gaining full administrative control, they were able to extract the password of an LDAP service account and steal the listing of users and groups, full network configuration, and private keys.

Dream initially didn’t name the device vendor. In its October 29 update, though, the company stated that the systems were Palo Alto Networks devices running certain versions of PAN-OS. The vendor confirmed attacks on management interfaces exposed to the internet. It urged customers to close public access to those interfaces, limit it to trusted internal IP addresses, and install patches.

Why there are so few incidents

Exploits are multiplying, but no wave of breaches has materialized, and the possibility of mass compromise of PHP servers remains unconfirmed. Even in the Palo Alto case, the scale of the attack was minimal: out of about 19 000 devices found, the attackers picked just 240, which were running software versions their exploit could handle.

As it turns out, the existing PHP2Shell exploits aren’t one-size-fits-all. To exploit the vulnerabilities in a given environment, attackers have to account for the exact PHP build, memory settings, request handling, and application specifics. Still, the danger remains, so don’t neglect protective measures.

How to stay safe

The key advice stays the same: update. You can find the latest versions of the language on the PHP website. But installing patches isn’t enough. You also need to run a thorough audit of your systems and check every component that runs on PHP for signs of compromise.

Why install the second round of PHP updates?

Five days after releasing the emergency patches, the PHP developers published another round of fixes. The reason is that the updates that fixed PHP2Shell didn’t cover the CVE-2026-111497 vulnerability in Brotli, a third-party library. Exploiting this flaw can lead to code execution when PHP processes a specially crafted compressed response from an external server. The builds from October 25 include a patched version of the library. The latest PHP versions are 8.2.35-1, 8.3.36-1, 8.4.27-1, and 8.5.12-1. The first attack exploiting this vulnerability was recorded on October 26, so don’t put off installing the updates.

Threat detection

Possible signs of a PHP2Shell compromise include unusual POST requests that contain multipart/form-data media type, suspicious combinations of PHP_SESSION_UPLOAD_PROGRESS and upload parameters, atypical request sizes and request bursts, and HTTP 500 errors accompanied by PHP out-of-memory messages.

Kaspersky solutions can help you spot the threat at different stages of an attack.

• Kaspersky NEXT EDR Expert promptly alerts you to suspicious activity running in the context of Linux and Windows web servers.
• Kaspersky Anti Targeted Attack (KATA) with the NDR module check network traffic for exploitation of the flaws described above.
• Kaspersky Vulnerability Management helps you find vulnerable versions of software.
• Kaspersky Managed Detection and Response detects exploitation of CVE-2026-109618 and CVE-2026-109619 by monitoring for behavior characteristic of RCE attacks.
• Kaspersky SIEM has been updated with new rules that help detect malicious activity typical of PHP2Shell.

To learn more about how our solutions detect attempts to exploit PHP vulnerabilities, read our expert blog, Securelist.

Certificates both protect TLS connections and digitally sign applications, and forged ones turn up in real-world attacks from time to time. We’ve seen forged or stolen certificates abused by the DarkHotel APT and the Flame malware, and in 2011 we saw attack attempts after the certificate authority Comodo was compromised. Pulling off this trick usually takes serious expertise. But attacking eMudhra certificates in 2026 doesn’t take much effort at all. An attacker just has to guess a number from 1 to 255. Private keys for intermediate certificate authorities are normally gigantic numbers. But in this case, eight of them were the following: 4, 56, 66, 115, 155, 156, 230, and 237. They could be guessed using the public keys (available in public certificates) in under a second. As a result, a hypothetical attacker could issue certificates for anything by signing them with one of the compromised private keys.

Six of these keys were meant for issuing TLS certificates, and the other two were for code signing. All eight intermediate certificate authorities (CAs) were also cross-signed by the Sectigo CA. This means clients with different trust chains could trust a forged certificate.

The major browsers have already blocked the dangerous certificate chains. But IT and security teams still need to assess and remediate the risk in many other systems across their organizations. Scripts for scheduled data-processing, corporate NGFWs, monitoring servers, applications with built-in certificate stores, and devices that don’t get regular updates may accept forged certificates and be vulnerable to man-in-the-middle (MitM) attacks. The keys needed for this are already built into publicly available interception tools.

Timeline of the eMudhra certificate authority incident

The problematic keys came from a batch of 24 intermediate CAs that eMudhra created on April 30, 2025. Instead of cryptographically random values for a 384-bit elliptic curve, eight of the keys turned out to be small numbers. According to eMudhra’s own description, a “key wrap/unwrap step” during key generation created a second, weak set of keys. Because keys are created and stored in a dedicated device called a hardware security module (HSM), a weak key is hard to notice on its own. It’s still unclear what error caused the keys to be generated twice and the weak set to be used; the investigation is ongoing.

In May 2025, the Sectigo CA signed all eight intermediate certificates. Then, on October 17, 2026, an independent researcher notified the security teams at Mozilla, Google, and Apple, as well as the CA itself, that the keys were recoverable. On October 20, Mozilla publicly disclosed the incident. This means that for almost a year and a half the keys could have been recovered and certificates forged.

On October 22, eMudhra announced that it was exiting the global SSL/TLS certificate business.

What an attacker can do

Using the vulnerable intermediate CAs, an attacker can sign a forged certificate for someone else’s domain. Clients that still trust that chain and have no other safeguards will take the forgery for the real server.

A certificate alone isn’t enough to intercept HTTPS traffic. The attacker also needs a way to tamper with the victim’s traffic or redirect the connection. That’s possible, for example, in a compromised office network, on a Wi-Fi access point the attacker controls, or by interfering with routing and DNS. And all of this does happen in the wild, as the DarkHotel attacks, among others, have shown.

There’s one more danger: two of the keys can be used for code signing. In theory, that would let an attacker deliver malware that appears to come from a trusted vendor and doesn’t trigger scary OS warnings during installation.

Was it exploited?

Experts from various companies who analyzed the after-effects of the incident haven’t found any malicious attacks that used these certificates. eMudhra and CERT-In have also reported finding no abuse. The Chrome team found no certificates from the six CAs in public Certificate Transparency logs.

This means that systems where browsers check certificates through Certificate Transparency (CT) were most likely not attacked. But many devices and applications — especially servers and IoT devices, don’t check CT at all, so we can’t say anything about them. Today, malicious actors no longer need to write their own hacking tools to pull off an attack like this. Version 12.3 of mitmproxy — a popular tool among security researchers — already has built-in support for compromised keys.

Where the risk has been eliminated, and where that isn’t guaranteed

Major platforms quickly revoked the compromised certificates. As early as October 17, Chrome did so through CRLSets, and Firefox — through OneCRL. On October 18, eMudhra itself revoked the certificates, citing “CA Compromise”. Apple took action on October 19, and the Sectigo CA also revoked the cross-signed copies. Microsoft revoked the certificates on October 20. Depending on the settings of a specific application and OS, revocation may have taken effect even without an application update, since blocklists are often updated separately.

At the same time, a more radical measure is under way: withdrawing trust from the root CA. Chrome has announced the planned removal of “emSign ECC Root CA – G3” from the browser. Certificates issued under the “emSign Root CA – G1” root, and the root itself, aren’t affected. According to eMudhra’s estimate, about 30 000 certificates will need to be migrated.

But certificate revocation only works where the client can find out about the revocation to then be able to actually act upon it. Many applications check the signature, server name, and certificate validity period, but don’t retrieve or update blocklists. Here are the typical cases:

Outdated and LTS systems. LTS (long-term support) status alone doesn’t mean a system is vulnerable. By definition, a system with this status receives support. But old containers, frozen OS images, and systems that are no longer updated can keep trusting revoked CAs for a long time. It all depends on updates to ca-certificates and TLS libraries, and the settings of the specific application.

Automated systems and servers. On emudhra.we-have-a-problem.com — a site created by enthusiasts where you can check any client software for misplaced trust — curl and Zabbix dominate the list of the most vulnerable systems. For HTTP checks, Zabbix usually uses libcurl and the certificate store configured for it. Similar behavior is also documented in the built-in curl in macOS. At the OS level and in Safari, the certificate is revoked, but curl reads a plain /etc/ssl/cert.pem file, and that’s precisely where the fix has to be made. This is a good example: even when system-level trust and revocation mechanisms work, individual applications — including ones that ship with the OS by default — can remain vulnerable.

Python, Ruby, Go, Java, and containers. An application may use its own set of root CAs, which isn’t updated along with the OS. Endor Labs found more than 25 popular packages that contain the affected root.

Slack, GitHub Desktop, and other apps built on the Electron framework. These apps ship with their own Electron/Chromium, so updating a separately installed Chrome doesn’t update Slack. The certificate revocations are already in the new Electron version, but now every developer has to rebuild and distribute their app, and every user has to install the update. That said, not every Electron app is necessarily vulnerable. The outcome depends on the version, how the app updates its blocklists, and which network stack it uses.

Mobile browsers and IoT devices. Mobile Chrome, Firefox, and Safari get certificate revocation data as quickly as their desktop counterparts do. With the stock browsers from smartphone makers, this isn’t the case. In a published test, Samsung Browser 31.0.0.64 accepted all six test chains from emSign while rejecting the ones from Sectigo. For HarmonyOS 6 and 7, researchers found the affected CAs in Huawei’s published list of root CAs, and those CAs can’t be revoked manually.

For unsupported devices, home appliances, and old firmware, a certificate store update may never be released. In those cases, the problem could linger for years.

Impact on TLS inspection in a corporate network

When an NGFW or web gateway inspects encrypted traffic, it maintains two connections: one with the client and the other with the external server. The client receives a certificate signed by the corporate CA, while the gateway itself verifies the authenticity of the external server.

If the gateway accepts a forged eMudhra certificate, even an updated browser on an employee’s computer won’t see the dangerous chain. Instead, it will receive the familiar corporate certificate. In this scenario, the security tool itself hides the problem from the client. That said, carrying out such an attack would also require intercepting traffic.

To fix the validation policy and certificate lists on the inspection device itself, follow the vendor’s instructions — if the vendor has published any, that is.

At Cisco, the status of the issue is documented in detail for all products. Most of them are still listed as “under investigation”, but mitigation measures are recommended for vulnerable devices.

Sophos and Check Point promise device software updates and, in the meantime, advise removing the certificates manually. Neither company has published a security advisory, but employees of each posted recommendations on its support forum.

For Fortinet devices, instructions for checking and removing emSign certificates can be found here. Palo Alto offered only general advice instead of specifics for its own products.

Of course, a properly configured gateway can indeed temporarily protect outdated client devices that trust the dangerous certificates.

To check specific devices, services, containers, and virtual machines, you can use a dedicated website. One possible scenario for proactively hunting for threats that exploit or have previously exploited weak keys is described here.

AI systems are much harder to protect than traditional IT — whether from operator mistakes, malicious interference, or just plain unstable behavior. There are two main reasons for this. First, AI outputs are probabilistic, so the same prompt can give different answers each time you run it. Second, today’s LLMs can’t reliably tell commands apart from data. Despite the demonstrated security issues of AI systems that we’ve covered many times, it’s impossible to ignore the potential economic payoff of adopting them. That’s why many companies are moving beyond simple AI assistants to AI agents. These agents carry out tasks on their own and have direct access to the same tools as humans — from reading databases to changing settings in production processes. Our experts, in their new study, examine how to clearly define and minimize the resulting risks to keep potential problems to a minimum. The approach borrows and adapts the principles of Cyber Immunity and Security by Design.

The basic principles of Security by Design

All the principles of this discipline are universally applicable to the design of any computer system — AI agents included. What differs is how deeply each principle needs to be adapted and reworked for AI scenarios.

1. Security is a separate and important factor right from the design stage. Security goals and assumptions are set on day one and followed throughout every stage of development. For AI agents, these assumptions should include three key points: (i) the language model is treated as untrusted, (ii) external data of any kind is considered potentially malicious, and (iii) irreversible actions can’t be performed autonomously without mandatory human approval.
2. The system is designed on the assumption that it will be attacked.
3. The trusted computing base and attack surface are kept to a minimum. Agents get only the tools they actually need, limited permissions, and the smallest amount of context possible. Security policy enforcement is handled entirely by deterministic components: the policy monitor, the agent harness, and isolation mechanisms (sandboxes).
4. The principle of least privilege applies. Each agent has its own set of credentials and access privileges (identity), limited to the bare minimum it needs to do its job. If an agent temporarily needs elevated privileges, it gets them only after external approval, and they last exactly as long as the task that requires them.
5. Components are isolated. In agent-based systems, this is one of the most complex and multi-layered architecture problems. The agent harness should run in an isolated environment (sandbox or virtual machine), and agents should be kept as isolated from each other as possible. Data processing in trusted and untrusted contexts is also kept separate. For example, one agent reads a pull request and writes a draft of the code, while another reviews that work without ever seeing the potentially malicious text of the request.
6. Default deny is the rule. Security policies follow the rule: anything not explicitly allowed is forbidden. This includes tool calls, interactions between agents, and network traffic.
7. Defense in depth is in place. Different measures should work at the same time and reinforce each other. Probabilistic defenses — like AI guardrails (a “firewall” for language models) or alignment (the model’s own sense of what’s acceptable and what isn’t) — can’t offer any formal security guarantees. Nevertheless, they make the system more secure overall and serve as a valuable source of telemetry.
8. The supply chain is protected. Some agents can install skills, libraries, and other software components on their own, so these abilities need strict rules. Either block them completely, or limit them to a closed, pre-approved list of specific versions of specific components. Systems built on cloud LLMs face an extra risk: model updates. One day, the same API request might be answered by a different language model with different security properties.

Pitfalls of AI security

The general principles of Security by Design are well known and look simple on paper. But applying them to AI systems is tricky because agents are incredibly flexible. For example, a security team might believe that an agent on a developer’s computer runs in a sandbox and can’t change anything outside it. But an attacker, or even the agent itself, can come up with dozens of ways around this seemingly solid protection: from running commands through a local MCP server that the sandbox doesn’t restrict, to reconfiguring another AI agent installed on the system. To make things even harder, the range of attack vectors is huge: from arbitrary fields in the agent’s configuration to innocent-looking text strings in a skill file.

One serious problem that designers often underestimate is user fatigue. A busy agent can throw up dozens of requests every minute, asking the user to confirm potentially dangerous actions. Within an hour, the person is clicking Approve on autopilot without reading what they’re approving. That’s why it’s important to carefully tune both how often these requests appear and how they’re worded. Nobody will read a request description that’s too long. And one that’s too short can hide the key details the user needs in order to make the right call.

Vulnerabilities in agents and related tools are a pressing problem — and it’s made worse by how quickly these categories of software evolve and receive updates. Industry-standard platforms and apps — such as LangGraph, MS Semantic Kernel, and Claude Code — have had critical vulnerabilities patched more than once. Architects should always consider swapping a large, do-it-all framework for a compact, stripped-down system that has only the features a specific agent actually needs.

On top of that, carefully implementing standard, long-established security measures in the available tools greatly reduces the damage if an agent is attacked or behaves unexpectedly. One example is a strict allowlist of domains that the web fetch tool can open when asked by the agent. But designers rarely account for the hidden problems and overhead associated with maintaining the list. As a result, it slowly goes out of date and leaves loopholes for attackers. The most striking example is the EchoLeak attack. Microsoft 365 Copilot had a properly implemented and fairly effective allowlist for accessing external sites, but attackers circumvented it through a feature in a secondary tool and the MS Teams domain.

Practical tips for architects and security teams

AI system architects and heads of engineering and security teams should build in agent security from the design stage. They should rely primarily on verifiable, deterministic mechanisms: isolating components, controlling interactions, and keeping the trusted computing base to a minimum.

Key architectural decisions include defining acceptable autonomy for the agents, limiting access to confidential data and dangerous combinations of capabilities, and using sandboxes, separate roles for different models, and access control gateways. Restrictions added as an afterthought reduce risks, but they’re no substitute for secure architecture.

At the organizational and operational levels, companies need to keep an inventory of their agents, coordinate the efforts of security and deployment teams, protect container environments, manage the supply chain (AIBOM), and integrate multi-layered defense.

Observability requires special attention. For AI systems, this should include logging the LLM’s requests, responses, and reasoning, as well as detailed telemetry from the hosts and cloud environments where the agent harness runs.

The hardest part of designing agents is balancing security, performance, and usefulness. To learn how to strike that balance with threat modeling and clearly defined security goals, read the full version of the study.

We use many technologies to detect email spam. They analyze every part of a message: headers, text, images, and links. But the first thing our email products focus on is the “From” field. If the address contains a domain that’s already on our denylist, it’s an easy call. But spammers know the drill, so they register domains in industrial quantities to make emails, even from a single campaign, arrive from completely different addresses. Clearly, they don’t do that by hand. The process has long been automated, and attackers’ algorithms can register huge numbers of domains in a matter of minutes. But every domain needs a name. Coming up with a unique one for each isn’t feasible. So spammers use domain generation algorithms (DGAs), which create similar names with minor variations, based on date and time, pseudo-random numbers, and so on.

In fact, to block mailings such as these, you don’t need every address on your denylist. We’re good at automating processes, too. For some time now, our email solutions have included a technology that detects domains generated by DGAs, and shuts down entire batch with a single rule. Let me explain how this technology works.

How we detect and block generated domain names in bulk

As soon as any of our technologies flags an email as spam, its address becomes subject to further examination. If it meets a number of criteria, its domain is added to our database of domains we consider “bad”. We built a cascade of classifiers that compares these domains by similarity, groups them into clusters, and creates a short but comprehensive rule that blocks the entire cluster. Our email protection solutions receive this rule with an update. From then on, they block all emails sent from addresses on any domain that matches it — even if those domains have never been used in spam campaigns yet.

Here’s a real-world example. Let’s say the classifier flags several lookalike domains in a collection of “bad” ones it has gathered:

• sxkjcc.asia
• sxkjcd.asia
• sxkjcy.asia

Then, one rule is enough to catch them all: @sxkjc[a-z0-9]\.asia\b

How to protect your company from spam

According to our analysis, 44.9% of emails sent last year were spam. Unwanted, unsolicited emails distract employees, waste working time, and clog inboxes. In some cases, they also contain scam, phishing, or malware content. To protect business customers from this deluge of threats, our solutions for corporate email security have anti-spam technologies that we constantly improve. This includes the technology described above for blocking domains generated by DGAs.

Two critical vulnerabilities have been discovered in the popular PHP programming language. The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, allow attackers to remotely execute code on a server running PHP without authentication. The language’s development team has released updates for all supported branches, but the first attempts to exploit the vulnerabilities were observed even before the patches were published. The exploit has been named PHP2Shell.

The architectures of popular marketplaces, e-commerce platforms, and learning management systems (LMS) are written in PHP. In addition, PHP is used in various content management systems (CMS) such as WordPress, Drupal, Joomla, and so on, which power most websites on the internet.

In this blogpost, we discuss CVE-2026-109618 and CVE-2026-109619 in detail, and explain how companies can protect their infrastructure. Read the Securelist expert blog to learn how events surrounding these vulnerabilities unfolded before the patch was released.

Vulnerable PHP versions

According to PHP web site, versions prior to 8.2.35, 8.3.36, 8.4.27, and 8.5.12 are vulnerable to CVE-2026-109618 and CVE-2026-109619. There are no official fixes for older branches. According to unofficial reports, the vulnerabilities also affect PHP versions starting with 5.4.0.

What makes CVE-2026-109618 and CVE-2026-109619 dangerous

Both vulnerabilities received a score of 9.2 on the CVSS v4.0 scale. They arise because, after a request is interrupted (for example, due to a memory shortage), PHP leaves invalid data in the memory buffer, and subsequently accesses it, allowing code to be executed on the server. One of the confirmed attack chains via CVE-2026-109619 exploits the `session.upload_progress` mechanism (which tracks file upload progress), which is enabled by default in PHP.

By exploiting these vulnerabilities, attackers can remotely execute code on the server with web server process privileges without authentication.

According to PHP developers, all installations of unpatched versions that process web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The greatest risk lies with mod_php: researchers demonstrated an exploit for it in which an unauthenticated request triggers the attack even before the application code is executed.

What businesses should do

We’ve compiled key recommendations from the PHP developers and experts at Kaspersky.

• Update PHP to versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Start with systems accessible from the internet. The source code is available on the PHP website. If PHP is installed from distribution packages or provided by your hosting provider, check for updated packages: Linux distributions and LTS vendors received patches in advance. If the server is managed by a hosting provider, ask them to apply the update.
• Versions 8.1 and older no longer receive updates from the PHP project. Check with your distribution vendor or LTS support provider to see if backported fixes are available, or switch to a supported branch. For PHP 7.4, 8.0, and 8.1, the developers have prepared minimal source code backports for manual compilation. These can also be found on the PHP website.
• Restart PHP-FPM or the web server so that the processes load the new code, and verify the version using the `php -v` command. If PHP was installed from distribution packages, check the package changelog: the version number may remain the same.
• Check the logs from October 20. A warning sign is when the web server process is performing actions it shouldn’t (running command shells, curl, wget, and the like). Kaspersky solutions help detect malicious activity in a timely manner. Attempts to exploit the described RCE vulnerabilities on Linux and Windows machines can be detected using Kaspersky NEXT EDR Expert, while exploitation of PHP2Shell in network traffic is detected by Kaspersky Anti Targeted Attack (KATA) with the NDR module.

If an immediate update is not possible

Only the immediate installation of patches will fully resolve the issue, but if that isn’t possible, it’s recommended to implement temporary measures. PHP developers provide step-by-step instructions for each vulnerability.

The more a company’s infrastructure grows, the more weak spots it has. And that’s true for all companies — from large corporations with deep pockets that are able to invest more in their defenses, to small and medium-sized businesses. And despite their more modest capabilities, smaller companies are just as tempting a target for attackers.

New times, new risks

Cloud platforms, remote access, and AI help businesses scale up and get more done. But they also give attackers extra ways to get into corporate infrastructure. For example, remote employees’ personal devices have become a foothold that’s hard to control. And thanks to AI, phishing emails are almost impossible to tell from real ones: users can no longer spot a scammer by their spelling mistakes.

There’s another reason why new threats keep appearing: companies are slowly learning how to handle the old ones. Take backups. Just a few years ago they were sold as a cure-all against ransomware. Now they’re less effective, because at some point attackers started stealing data and demanding payment not for decryption, but for not making it public. What’s at stake here isn’t just business processes, but the organization’s reputation too. We wrote about this scheme in more detail in a separate blog post.

The scariest part is that an attacked company’s problems don’t end on the day of the incident. The next few days (or even weeks) are often much harder. This is when the team needs to quickly deal with the aftermath of an attack and to make sure another can’t happen again. Growing companies often have to throw their entire small IT force at the problem, so getting back to normal work can take a long time.

Three Achilles’ heels at once

According to the Global Kaspersky B2B Market Pulse survey, most SMBs only think about security when circumstances force them to; for example, after an incident, when expanding their infrastructure, or when a potential partner asks them to strengthen their perimeter before signing a contract. Yet only a handful treat continuous cybersecurity monitoring as a core part of running their business.

When a company finally decides to get serious about security, it runs into three constraints: people, processes, and technology. Let’s look at each one.

• People. In a company with up to 500 employees, the IT department is usually just a few people. They handle all technical issues and have little to do with cybersecurity. When things get tough, these specialists may simply lack the expertise to deal with things. Other employees can be a weak link too. Accountants, lawyers, and other staff with access to confidential information often aren’t familiar with security rules.
• Processes.A small IT department always has a backlog with a long queue of tasks; therefore, fresh updates and patches don’t get installed right away. As a result, attackers have plenty of time to take advantage of a vulnerability that isn’t fixed in time. Meanwhile, other employees may not know how to respond to suspicious emails, or how to store and share passwords safely. And there’s simply no one to keep an eye on them.
• Technology. Threats evolve alongside a business’s technology. For example, once a company has moved part of its infrastructure to the cloud, relying on a classic antivirus alone becomes pointless.

So small and medium-sized businesses become easy targets for attackers not so much due to their size, but because they don’t pay enough attention to the key building blocks of cybersecurity. As to what this can lead to, and how the tables can be turned in a company’s favor — read on for a real-world case that demonstrates this.

Case study: ERP system breach

Let’s look at a real-world attack on a company with 450 employees. When the incident happened, the company was migrating its ERP system to the cloud. The data had already been moved, but the protection hadn’t been set up yet. And that limbo state is exactly what let the attackers pull off their campaign.

The attackers used a fairly simple tactic. Posing as an external ERP integrator, they sent the finance department a file with an “adjusted invoice”. When an employee opened the attachment, the malicious code inside it exploited a vulnerability in a local application, and the attackers took control of the device. There they found saved credentials that let them log in to a support account and get administrator rights on the cloud ERP server. With that account, they got into the server and stole the company’s confidential data.

We analyzed the mistakes that made this incident possible, and came back to the same formula: people + processes + technology. The company did provide employee training, but it was mostly a formality and did nothing to help people learn to spot email phishing. Security updates weren’t installed right away either, which is why the computer had an unpatched vulnerability. On top of that, privileged credentials were stored right on the employee’s device, which gave the attackers a direct path to administrator access. Finally, the workstations had no EDR, and the cloud ERP server had no workload protection.

How SMBs can strengthen their defenses

The best way to start is with the three key areas we covered above. And this isn’t about simply throwing money at security. What’s needed is a clear, step-by-step plan that makes the most of the resources the company already has.

Hands-on training

Employees are a business’s first line of defense, so it’s especially important to help them form safe cyberhabits. Many companies understand this and duly run computer literacy training; however, often employees show up in droves, yet they keep on making the same old mistakes.

The problem is that most training isn’t relevant to the people taking it. People in the finance department know that attackers can send phishing emails, but what does that have to do with their job? To head off questions like that, we recommend combining cybersecurity theory with simulations of real cyberattacks. That way, employees can safely step into the shoes of an attacker’s target. Start by training employees who have privileged access to systems, and also those who handle confidential information.

To keep training from becoming a formality, track progress regularly. For example, send employees suspicious test emails from time to time, and measure how fast and how well they react: how many recipients click the link, and how many report the threat.

Structured processes

Set up clear priorities for installing updates and patches. This helps avoid two extremes: running for months with open gaps in the infrastructure, or rushing to fix every vulnerability without asking how critical it is for specific business processes. Setting up centralized vulnerability management also helps, which we explained how to do in a separate post. Don’t rush to expand the infrastructure or move it to the cloud until the company has proper protection and monitoring in place.

Another key point: assign an owner to every process. Someone should be personally responsible for regular cybersecurity training, installing updates, and the timing and methods of incident response. That way, security tasks get done on time — even when the IT team has limited resources.

Gradual rollout of security solutions

It’s impossible to build reliable business protection without specialized products, but buying everything at once won’t help either. New solutions should match the needs of the infrastructure. A good approach is to add tools as the need to do so comes up; for example, to prioritize vulnerabilities more effectively or to strengthen the security of email or cloud environments. One way to tailor security to the company’s needs is to use our Security Modules , which work with Kaspersky Next Optimum — a solution for growing SMB and mid-market businesses.

Another option is to move to a more advanced solution as the infrastructure grows. The foundation of cybersecurity can be laid with Kaspersky Next EDR Foundations, which provides basic endpoint protection and control. Then, when needed, the company can move up to solutions with a broader range of capabilities, from Kaspersky Next EDR Optimum to Kaspersky Next XDR Optimum, or straight to Kaspersky Next MXDR Optimum. Our most comprehensive offering — Kaspersky MXDR Optimum — combines advanced detection and response that goes beyond endpoints and adapts to the needs of a growing business, 24/7 monitoring, and proactive threat hunting and investigation by Kaspersky experts.

Microsoft’s October Patch Tuesday update stands out for two reasons. First, the total number of patches has reached four digits for the first time. Second, to help companies better understand the details of the vulnerabilities, Microsoft has decided to group them into risk cohorts. A cohort brings together vulnerabilities that are exploited under the same conditions and affect the same systems. They replace neither the severity rating, nor the individual bulletins for each CVE. While they’re unlikely to be suitable for comprehensive patch prioritization, they will help quickly assess which part of an infrastructure is currently most at risk.

Statistics corner

Of the 1,414 vulnerabilities addressed in the October Patch Tuesday release, 1,102 directly affect the Windows operating system, 134 — Microsoft Office, 36 — SharePoint Server, 22 — SQL Server, and seven — Exchange Server. The vast majority — 677 — lead to privilege escalation, 317 to remote code execution, 40 to security bypass, and 73 to denial of service (DoS).

There are 86 critical vulnerabilities on the list, of which 68 lead to RCE, 14 to privilege escalation, three to spoofing, and one to data leakage. In addition, two vulnerabilities were disclosed before being patched, and one is being exploited in real-world attacks.

CVE-2026-96951 — vulnerability in Windows Shell

The only zero-day vulnerability patched in the October update that attackers are already exploiting in real-world attacks is CVE-2026-96951 in Windows Shell (CVSS severity score: 8.8). Details on how it’s being exploited aren’t yet known; however, according to Microsoft’s description, it involves command injection that allows bypassing a security feature when accessing the system over a network. Microsoft credits experts at both Fujitsu and Anthropic for discovering the vulnerability, so it was likely found using neural networks.

CVE-2026-108398 and CVE-2026-92707: vulnerabilities disclosed before patches were released

Information about these two vulnerabilities was made public before the October update was released. In theory, this could mean that attackers attempted to exploit them ahead of time. These are:

• CVE-2026-108398 — a vulnerability in the .NET Framework that allows bypassing WDAC protection;
• CVE-2026-92707 — a vulnerability in the third-party MessagePack-CSharp serialization component, leading to a denial of service (DoS).

However, according to the security bulletins, neither has been observed in actual attacks yet.

What else to pay attention to

Several vulnerabilities patched by the latest update combine potentially serious consequences with relatively simple exploitation. Particular attention should be paid to three flaws that could potentially lead to arbitrary code execution:

• CVE-2026-65674 (in SQL Server);
• CVE-2026-70571 (in Exchange Server);
• CVE-2026-70229 (in AD Domain Services).

What else should be patched?

Microsoft isn’t the only company that releases regular update packages for newly discovered vulnerabilities.

In its October update, Adobe fixed 174 defects in its products, including critical vulnerabilities (CVSS 10) in ColdFusion and Commerce/Magento. These systems are typically accessible from an external network, making them particularly attractive to attackers.

SAP’s October security bulletin lists 20 vulnerabilities, including CVE-2026-89111 — an SSRF vulnerability in the Cloud SDK for Python. This vulnerability, rated CVSS 10, allows attackers to steal OAuth tokens.

How to keep your company safe?

Recently, thanks to neural networks, the number of vulnerabilities detected and patched has been regularly breaking records. To avoid getting overwhelmed by the flood of patches, we recommend using an automated platform for tracking and assessing vulnerabilities . It helps not only identify and fix vulnerabilities, it also prioritizes them based on actual risks and automates the remediation process.

When it comes to protecting voice calls, security professionals typically focus on the security of the data carrying the audio — above all on encryption. Sooner or later though, the voice data stops being a stream of bits and becomes an analog signal that goes straight to the speakers. You might think that if someone is using headphones, nobody can listen in. But headphones are electronic devices, and their components have physical characteristics that can give away closely guarded secrets without any cyberattack at all. In a recent paper, researchers from two Hong Kong universities came up with InjectEave — an attack that exploits these properties to intercept the already-decoded analog audio signal.

How the InjectEave attack works

The electronic components in headphones convert data into analog form and amplify the signal to drive the speakers. This process generates weak electromagnetic emissions. Capturing those emissions and extracting information from them is a field unto itself, with many experts working in it. The main issue those experts face lies in the fact that stray emissions from headphones are too faint to intercept and analyze in practice.

The authors of InjectEave propose adding a radio transmitter that beams a signal at a specific frequency toward the target device. Those weak emissions from the headphones’ analog components modulate the transmitter’s signal. The altered signal can be intercepted from several meters away — provided the receiving antenna is sensitive enough. The attacker then analyzes the changes in the signal to reconstruct the original audio.

Technical details of the InjectEave attack

The main obstacle to intercepting electromagnetic emissions directly — without an external transmitter — is the relatively low signal frequency. For example, the audio amplifier in headphones operates at frequencies from 20Hz to 20kHz. By contrast, electromagnetic emissions are easiest to intercept at frequencies measured in megahertz. The researchers were able to find a transmitter frequency that would also “amplify” the low-frequency signal of interest.

The researchers ran a series of experiments. They used antennas to transmit the “amplifying” signal and receive the result, and a spectrum analyzer to capture and process the data. The authors have posted the raw recordings of the intercepted signals on a dedicated microsite, so anyone can check how well the attack works. In most cases, getting a usable result didn’t even require complex processing or recognition. Conversations picked up from wireless headphones are clearly intelligible despite the elevated noise level.

In total, the authors tested three models of wireless headphones and two models of basic wired headsets. The effective eavesdropping distance varied from one to six meters depending on the model. With a wired telephone, they were able to demonstrate two-way interception. They could hear not only the sound from the speakers but also the potential victim’s speech, which the headset’s built-in microphone and analog-to-digital converter had captured.

Advantages and limitations of the method

Any attack that requires getting very close to the target is challenging by definition. The need to tune the frequency of the “amplifying” radio signal for each specific device makes the attack even harder. In their experiments, the researchers had to use frequencies from one to eight megahertz.

Despite these caveats, the main achievement of this attack is its being able to target the quirks of the analog components in an electronic device. These components inherently produce stray emissions, and there’s almost no way to reduce them.

Similar surveillance methods that intercept a digital signal can be stopped by adding a layer of encryption. When it comes to the analog side of a device, protecting the signal itself is much harder. This research is another reminder of how complex and unpredictable even very simple, familiar devices can be. Sometimes even the strongest protection for digital data is powerless once that information is converted to analog form.

Many businesses still fear ransomware attacks. But is this threat still as relevant today? A few years ago, at the peak of ransomware’s popularity, the term “ransomware” was practically synonymous with malicious encryption of data. But in reality blocking access to information had long been little more than a symbolic gesture. In a May Securelist post on shifts in the ransomware threat landscape, our experts noted that in 2026, attackers are encrypting company data for ransom less and less frequently. Here’s a striking example: while investigating an incident, Kaspersky’s Global Emergency Response Team (GERT) uncovered the PAYLOAD extortion campaign, whose operators didn’t even bother using ransomware. They took a different route instead.

In this campaign, instead of using ransomware, the attackers seized control of the Active Directory environment, and created a malicious group policy object (GPO). They used it to deploy a ransom note, change wallpapers, and lock screens on workstations, and set up a banner to display at system login. Naturally, they also disabled local administrator accounts while they were at it. This move let the attackers demonstrate their presence in the compromised infrastructure and prove they’d accessed confidential information — just as effectively as encryption would have. Detailed information about this incident, along with indicators of compromise, can be found in the same Securelist post. What interests us more, though, is the trend of abandoning encryption.

Why data encryption has lost relevance

Let’s start with the fact that in a large company with thousands of infected computers, decrypting data is an extremely effort-intensive process. Restoring data from backups, which has become common practice largely thanks to mass ransomware attacks, is far easier than waiting for criminals to hand over a key, hoping it’s genuine, and trusting that the ransomware itself didn’t have bugs that made the data unrecoverable. As a result, cybercriminals found it harder and harder over time to actually collect a ransom for the decryption key.

Attackers tried to adapt to this shift. Alongside encryption, they increasingly began stealing confidential data and threatening to publish it. Publishing confidential information puts a company’s reputation, its security, and the safety of its business partners at risk. This is especially true if the data includes people’s personal information: more than 140 countries around the world have data protection laws, so a leak puts an organization at a fairly high risk of a hefty fine. Sometimes that’s far scarier than simply losing data, and no backup can help with that.

Data exfiltration has another advantage from the attackers’ perspective: it’s usually much harder to detect than malware activity. File encryption, for instance, triggers a spike in disk activity that endpoint protection tools pick up fairly quickly. By contrast, data exfiltration is easy to disguise as normal traffic. This is precisely what the ShinyHunters group exploits, building its attacks around the standard OAuth mechanism. On top of that, attackers can steal data much quicker if they don’t bother with encryption, which also makes it harder to catch the threat in time.

As a result, encryption has become a kind of calling card — proof that the attackers had access to the data. So cybercriminals finally decided to drop this optional step altogether.

What businesses should do

Standard cyberhygiene practices can help protect against a wide range of extortion schemes — regardless of whether or not they involve encryption:

• Run regular, automatic backups. By storing backups on two types of media — physical and cloud — a business need not fear serious disruption to its operations. After all, the downtime required to restore from backups is nothing compared with the consequences of losing all of its data.
• Install patches and updates promptly. For attackers, vulnerabilities remain one of the main entry points into infrastructure. To reduce the risk, we recommend setting up automated update management for operating systems, software, and drivers. It’s also important to scan systems regularly for security gaps, and triage the found vulnerabilities with a focus on critical flaws. Specialized vulnerability management solutions can help with this.
• Strengthen endpoint protection. Set up multi-factor authentication for every system in an infrastructure, and deploy a reliable workstation and server security solution. A SIEM or EDR solution can help security specialists gain full visibility into events, and respond to incidents quickly.
• Monitor external perimeter. Regularly check the company’s infrastructure (servers, databases, clouds, and legacy subdomains) for open ports and services exposed to the internet.
• Adhere to the principle of least privilege. This means giving users, systems, and processes only the access privileges they need to do their jobs. Revoke unused privileges, and fully disable access for former employees.
• Invest in staff training. Attackers still exploit the human element to break into a company’s infrastructure. Raising threat awareness among employees can keep them from falling victim to phishing.

We recently published a post on “tokenomics” and “denial of wallet” attacks — a new type of DDoS attack aimed at overspending AI tokens. But before security specialists begin protecting their colleagues’ AI processes from this new threat, they should remember that the work of the information security department itself can become a target for such an attack. Since security teams are now actively testing and implementing various types of AI-based automation, the threat of external interference aimed at paralyzing the defense system directly affects their own processes and technologies.

Elastic has estimated that, depending on the “agent-based SOC” architecture, triaging a single alert from a host can cost $0.69 for an ensemble of highly specialized agents or $3.42 for a general-purpose agent with 14 different skills.

However, these averages mask a huge range of variation. At any given moment, the basic processing of a simple alert (say, a thousand tokens) can turn into a cascading investigation involving processing millions of log entries, API calls, and other related data — which amounts to millions of tokens in a matter of minutes.

Elastic itself acknowledges that it uses the Claude Sonnet 4.6 model in its SOC. This immediately raises the question: what happens when the budget is exhausted or the model’s security filters are triggered? In the worst-case scenario, the following occurs: the AI SOC launches an “orchestra of agents” to investigate suspicious events that resembles lateral movement in the infrastructure. The agent calls the Anthropic API, but the department’s monthly budget has been exhausted, and the API returns errors. The investigation grinds to a halt, and people find out about it half a day later. Moreover, if the constantly changing “security filters” of a major AI provider flag the SOC’s requests as malicious, the same effect is possible even without the budget being exhausted — as demonstrated by Hugging Face’s experience investigating the breach of their infrastructure by OpenAI.

Of course, an attacker has a vested interest in such an outcome. They can directly influence the defenders’ costs by injecting malicious prompts into the data available to them (DNS TXT records, HTTP headers, code comments, filenames, and so on), counting on the fact that these prompts will be processed by information security systems. For example, in the GhostJacking attack case, WAF logs serve as the vector for prompt injection, and in academic study, another method was proposed: researchers managed to attack the LLM security guardrails themselves, causing their requests to increase latency by 148 and the number of tokens consumed by 63. In other words, the system theoretically continues to function correctly, but the latency in processing alerts and the associated costs increase significantly.

Dangerous silent failure

In agent-based scenarios, budget exhaustion doesn’t always manifest as an explicit error with a “request limit exceeded” message and an immediate alert to the responsible parties. Under certain configurations, “guerrilla” scenarios can arise: a request to the model times out, the system automatically switches to a cheaper model, and as a result the quality of its outputs drops, and subagents and periodic tasks stop running. Meanwhile, the security team may continue to believe for hours on end that everything is working as before.

How to control AI costs in cybersecurity

The task of managing expenses, of course, isn’t simply a matter of “preventing overspending”. The industry has already fallen into this trap when implementing SIEM: when companies had to pay based on the volume of telemetry collected, they began to selectively — and not always effectively — limit log collection. As a result, they ended up with detection blind spots. The same situation could arise with tokens — but faster and on a larger scale. A poorly designed cost-cutting policy could compromise the depth of investigations and the quality of responses. And in the absence of such a policy, the decision to cut something will be made not by the architect or the CISO during the system design phase, but by the analyst on duty at 3am. Or it may be an automatic limiter set by the system vendor.

A few simple principles can help avoid predictable cost overruns, and better manage situations that are truly unpredictable.

Don’t feed the AI model anything that can be verified with a standard query. Everything that’s repetitive and known in advance should be handled the old-fashioned way — with rules and data queries. These can be developed using AI, but they must operate deterministically. The model should only be used where an assessment of an ambiguous situation is truly needed.

Use strict limits and aggressively alert users when they are exceeded. Limits should be combined: a limit per task, a daily limit, and so on. Alerts about limit exceedances must immediately reach both on-duty analysts and those responsible for the system as a whole.

Decide in advance what happens when a limit is reached. Whether to stop and save money — while losing some control — or to continue and pay, is a decision that must be made before an incident occurs.

Limit agents’ permissions and the set of tools available to them. The fewer actions the system has access to, the more effectively it works on a narrow task, the fewer opportunities it has to inflate costs, and the less likely it is to be “exploited” by an outsider.

Strictly scan external, untrusted data. Incoming requests, inquiries, messages, and comments, as well as various technical fields capable of containing arbitrary text (DNS records, HTTP headers, file names) can not only lead to prompt injection, but also deliberately inflate the workload. Limit their size, and monitor the load they generate.

To avoid service outages from external providers and maintain full control over your organization’s data, evaluate the possibility of using local models deployed on-premises at least for information security needs. While these models may not be state-of-the-art, their narrow specialization and fine-tuning with company data will deliver decent performance without unexpected failures.

In a more complex architecture, the use of LLMs can be divided into several levels. The first line of defense (routing, noise filtering, data enrichment) is handled by compact on-premise models. This significantly reduces budget volatility. The second level consists of a large local model that handles the substantive work: linking events, testing hypotheses, and piecing together the picture of an incident. It’s also not billed per request, but its throughput is limited; therefore, instead of budget overruns, overloads and event queues may occur. Only isolated, truly difficult cases are forwarded to advanced cloud-based models — preferably with the explicit approval of a human analyst. In this scheme, variable costs remain, but they’re limited to a small number of cases, and each one represents a conscious choice rather than a side effect of a script running overnight.

Essentially, all of this replicates the classic multi-tiered SOC model — where the first line filters, and the third line investigates — only the roles are played by models rather than people.

The number of vulnerabilities detected in code continues to rise. According to Kaspersky’s threat analysis, 5,200 critical vulnerabilities were found in the first half of this year alone — nearly 50% more than during the same period last year. At the same time, the average gap between the publication of information about a vulnerability and the first attempts to exploit it is shrinking. The rapid development of AI systems plays a significant role in this process: while helping companies find weaknesses in their code, AI simultaneously shows hackers how to exploit them quicker.

It would seem that solving the problem of security gaps is very easy. All you need do is set up a scanner, check the infrastructure more often, and update vulnerable systems. But statistics from the Kaspersky Incident Response service show the opposite: a significant number of cyberattacks begin precisely by exploiting a flaw — and these are often already known flaws, not zero-day vulnerabilities.

Using a scanner does not give you an effective vulnerability management process. A scanner merely finds flaws (not always promptly), and then the IT team is tasked with prioritizing and fixing them. These processes can drag on for weeks, and in the meantime an attacker can easily gain access to the given infrastructure.

Where time is lost

The first delay can occur immediately after information about a vulnerability appears in databases. In addition to monitoring for breaches, the information security team is normally handling a dozen-or-so other tasks, so it relies entirely on the scanner for monitoring. If the scanner is configured to run weekly, a new vulnerability will appear in the report in a few days. In a company where scans are conducted quarterly, this obviously happens much later. Attackers, on the other hand, actively monitor news feeds and learn about new vulnerabilities immediately.

When the report finally reaches the security team, it contains far more than just one issue, raising the question of where to start. Critical vulnerabilities are addressed first, but attackers might exploit more than just those. Meanwhile, prioritization decisions are rarely based on data: often, they’re based on the order of the errors in the report, the name of the vulnerable system (they start with the one everyone’s talking about), or increased activity from its owner. Because of this, the risk of overlooking a serious threat is very high. Finally, the IT department takes on the vulnerability, and… it ends up back in the queue: they need to check the update’s compatibility and wait for a maintenance window.

After installing the update, the specialists close the ticket with a clear conscience and mark the status as completed. But would anyone verify that the patch was applied to all affected machines? Even the one that was turned off at the time of installation? Probably not, and then the company would assume the vulnerability was fixed, even though it’ll actually remain in the infrastructure for an indefinite period. This is the worst possible outcome: the risk remains — yet it’s no longer visible.

Put it all together, and what we get is months passing between disclosure and actual resolution. There’s no one in particular to blame here: every participant in the chain did what they’re supposed to. It’s just that this chain itself is made up of links with gaps between them.

A recipe for vulnerability management

To give attackers as few opportunities to gain access to corporate infrastructure as possible, it’s important to ensure that an organization has four key processes clearly established:

1.       Inventory

It’s impossible to verify the security of a system that no one knows exists. At the same time, virtually any large infrastructure will contain things like having had a server set up “for a week” three years ago, a network device left over from previous business owners, or a workstation that was forgotten during an office move. And each of these assets can pose a serious threat.

The goal of inventory management is to ensure complete transparency of the IT infrastructure. To achieve this, an up-to-date list of assets is compiled.

2.       Prioritization

When analyzing vulnerabilities, a security specialist shouldn’t rely solely on ratings from public databases such as the NVD, for these don’t always rely the real severity of the actual potential damage caused by exploiting a vulnerability. The specific structure of an organization’s infrastructure will have a significant impact. For example, the same vulnerability in a server located in an isolated segment, and in a system accessible from the internet, represents two very different risks.

Effective prioritization takes into account not only the publicly reported severity level but also the role of the vulnerable asset within the infrastructure, the likelihood of exploitation, and actual attack trends.

3.       Configuration settings

Overly permissive access settings, disabled security mechanisms, and default accounts are not technically vulnerabilities, but they often serve as entry points for cybercriminals. To prevent an attacker from exploiting inadequate configuration settings, security teams should follow several basic security best practices:

• delete default accounts;
• use strong passwords and MFA;
• disable unused services;
• apply the principle of least privilege.

4.       Confirmation

Blind spots are particularly common at the last stage of the vulnerability management process. Typically, once the IT department formally installs an update, the vulnerability is considered patched. However, before breathing a final sigh of relief, it’s important to at least verify that the patch has been successfully applied to all affected systems and has actually resolved the vulnerability.

Five tasks — one solution

Our solution, the Kaspersky Vulnerability Management module for Kaspersky Next Optimum helps information security specialists establish centralized management of vulnerabilities, assets, and configuration errors. The product solves five key tasks:

• It reduces the time between publication of vulnerability data and its detection in assets. The product automatically inventories the infrastructure — tracking even long-forgotten assets — and continuously scans it for vulnerabilities. Scanning is performed in two ways: agent-based and agentless. In the former, the solution runs on top of Kaspersky Endpoint Security, which allows for in-depth analysis of workstations and servers without transmitting service credentials over the network. In the latter, it analyzes ports and services where no agent is present. Both methods complement each other, enabling complete coverage of the company’s infrastructure.
• Checks configurations. Compliance with security standards is verified using predefined profiles.
• Prioritizes vulnerabilities. Priorities are assigned based on severity level, the characteristics of the specific asset, likelihood of exploitation, and other parameters.
• Promptly fixes errors. This involves remediation recommendations and centralized patch management integrated into the familiar administration infrastructure.
• Helps ensure that the vulnerability is fully patched. A remediation task is considered complete only after a follow-up verification.

The Kaspersky Vulnerability Management Module helps transform vulnerability management from a series of disjointed actions into a well-thought-out cycle. Details about licensing can be found on the Kaspersky Next Optimum for small and mid-sized businesses offering page and more about Vulnerability Management Module — on the module's home page.

A critical vulnerability has been discovered in the popular WordPress content management system that allows attackers to execute arbitrary code on the web server. The vulnerability has been assigned the number CVE-2026-87902. The good news is that on September 22, WordPress released an update that patches it. The bad news is that the first attempts to exploit CVE-2026-87902 were detected just a few hours after the patch was released. Therefore, all companies whose corporate websites or blogs run on this platform are advised to update immediately.

WordPress versions affected by CVE-2026-87902

According to data published by WordPress on GitHub, all versions of the CMS from 4.7.0 through 7.1.1 are vulnerable. The company has released updates for all supported branches of the system; a complete table listing the patched version numbers can be found on the company’s GitHub page. The latest version of WordPress should be updated to version 7.1.2 (or newer).

What’s the nature of the CVE-2026-87902 vulnerability, and why is it so dangerous?

Under normal circumstances, WordPress loads PHP template files only from a specific folder within the active theme. However, due to the CVE-2026-87902 vulnerability, an attacker can craft a request to WordPress in such a way that an arbitrary PHP file is included — without requiring any authorization. Yes, the file must already be uploaded to the targeted server in some way, but that’s not really a problem for an attacker.

It sounds like a path traversal vulnerability, but in most publications, CVE-2026-87902 is classified as an RCE (Remote Code Execution) vulnerability because, under certain WordPress and PHP server configurations, the attack can lead to the execution of arbitrary code.

How to stay safe

The only way to secure a corporate WordPress site is to install the latest version. The researcher who discovered the vulnerability also offers several tips for hardening CMS security, but emphasizes that these are meant to complement the patch, not replace it.

The Hacker News lists several PHP filenames and IP addresses used in the attack via CVE-2026-87902. These can serve as indicators that a WordPress instance has been compromised.

Given that only a few hours pass between the publication of information about a vulnerability’s existence and the start of attacks exploiting it, it’s crucial for companies to have a properly configured, centralized vulnerability management system. To achieve this, they should have a specialized solution capable of identifying and resolving vulnerabilities, prioritizing them based on actual risks, and automating remediation processes. Our vulnerability management module for Kaspersky Next Optimum can help with this task.

Not long ago, many companies began actively implementing AI agents in a wide variety of workflows. Very quickly, the cost of using them became a pressing issue for companies. Moreover, it’s an issue that concerns more than just finance department — in addition to budgetary concerns, issues of reliability, operational stability, and even information security have emerged. This is because the cost of automating one and the same process varies significantly from one deployment to the next, is unpredictable, and could be subject to external influences.

Furthermore, for a malicious actor attacking an organization, any process automated using AI and vulnerable to external influence is, in essence, a convenient target for a “new type of DDoS attack”. Application-error reports, product reviews, or technical support requests can (just like any other external data that a company processes via AI) serve as a tool in an attack aimed at increasing consumption of tokens (word fragments that serve as the basic unit of input and output of an LLM).

A year of explosive growth… in bills

In 2026, large companies significantly overspent on their AI system budgets for the first time. Uber had spent its entire annual budget by April, while an unnamed company failed to set spending limits for Claude and spent $500 million in a single month. Although AI providers regularly announce lower prices and more efficient models, the shift from chatbots to agentic systems that operate continuously and autonomously increases token consumption by hundreds or thousands of times.  At the same time, the “fixed subscription for $20 or $100” model for companies is becoming a thing of the past; all major providers are transitioning business clients to pay-as-you-go billing.

As a result, companies are facing a problem all too familiar to cloud hosting and cellular communications industries. In the absence of specialized cost accounting and management systems, an organization only learns how much a particular process or project will cost after it’s completed. In the telecom and cloud sectors, this problem was eventually solved through the development of sophisticated billing systems, and their clients have even adopted the specialized term FinOps. For AI, this process is still in its infancy. Moreover, solving the problem will be complicated by the probabilistic nature of generative AI.

Unpredictable token consumption

To understand why costs rise so quickly and are so difficult to predict and control, we need to recall how a language model works and what turns it into an AI agent. The model is stateless; in other words, it does not retain any information between interactions. Every time the agent takes the next step, the entire history of work on a specific task (the context) must be resent to the model: the initial prompt, previous reasoning, the contents of the files it has read, and the responses from all tools. With each step, this “recap” grows longer — especially if the task involves iterative loops. If a step fails, or the response is unclear, or a tool returns an error, the agent simply tries again — further inflating the size of the context. And if the task is performed not by a single but by several agents, which divide the work among themselves and exchange results, this volume is multiplied by their number. As a result, token consumption does not increase gradually but in spurts, and it’s nearly impossible to predict it at the start of the task.

When running two different sessions of an AI agent interaction to solve exactly the same task (two tech-support tickets, two analytics tasks, and so on), the number of tokens spent on them can vary — the difference can be as much as 30 (!) times. This depends on how many steps, errors, and retries are required to solve the task. Increased resource consumption doesn’t necessarily depend on the complexity of the task. There are well-known cases where AI got stuck in a “thought loop” and wasted an absurd amount of resources on trivial tasks.

Three generations of AI in enterprise systems consume resources in completely different ways:

• Classical machine learning (ML). This typically works with well-structured data and isn’t overly computationally intensive. Resource consumption is predictable and low. This is a fixed budget item;
• A chatbot or other LLM-based AI assistant. It consumes tokens, but the pace is set by a human: an employee manually launches a task, then evaluates the result, and pauses. Cost increases roughly in proportion to the number of active users, and can be approximately estimated based on the number of licenses;
• An autonomous AI agent. A person sets a goal and steps away, and the system then decides on its own what to do and how many steps are needed. The meter keeps ticking until the task is considered complete, and there’s no predictable cost ceiling.

Tokenomics in attacks: denial of wallet as the new DDoS

Since LLM calls are significantly more expensive than typical standard software calls, automating routine corporate tasks comes at an unusually high cost. For example, Gartner estimates that resolving a single customer support request using an LLM costs approximately $3. It’s easy to imagine how attackers could bombard a company with thousands of long, sophisticated requests generated by an inexpensive LLM, causing significant financial damage. Since the process is automated, anomalies may not be detected right away.

If an attacker knows which agent system and which LLM are used in a business process, they can carry out a more precise attack and cause significantly greater damage. The authors of the GitInject study estimated that an attacker capable of creating GitHub issues within an organization that uses AI agents for error analysis with single attack (before GitHub’s defense mechanisms kick in) can cause up to $111 in damage and burn through 400 minutes of GitHub Actions from the victim’s account. Naturally, such an attack can be repeated multiple times — at no cost to the attacker.

The most dangerous risk — though difficult to quantify in monetary terms — comes from attacks that provoke LLMs into excessive reasoning. In the paper OverThink, the authors demonstrated how a harmlessly worded task, when fed into a language model, ultimately yields a correct result but, in the process , consumes 46 (!) times more tokens than it should. Moreover, all tasks tested by the researchers successfully passed existing security filters.

In the new version of the OWASP Top Risks for Language Models guide, this issue has risen to a record-high priority: unbounded token consumption is now designated as LLM06:2026, and among its variations, the “denial of wallet” attack — which depletes the victim’s budget for LLMs — is explicitly highlighted.

How to Avoid Becoming a Victim of the “New DDoS”

First and foremost, you should abandon the principle of “using AI just for the sake of using AI”. It doesn’t make sense to entrust autonomous agents with every task. It’s wise to periodically conduct a cost-benefit analysis of using artificial intelligence.

In addition, you should limit the permissions and set of tools available to an autonomous AI agent. The fewer actions the system has access to, the more effectively it works on a narrow task, the fewer opportunities it has to inflate costs, and the less likely it is that someone will be able to “manipulate” it into unnecessary token spending.

We also recommend setting strict limits on token consumption, and configuring a notification system to alert humans when these limits are exceeded. It makes sense to implement multiple limits in parallel: a limit per task, a daily limit, and so on. Alerts regarding limit exceedances must be immediately forwarded to the specialist responsible for the system so that they can make an informed decision — whether to continue or halt the process.

Strictly verify external, untrusted data. Any information processed by AI that comes from external sources — whether it’s requests, inquiries, messages, or comments, or various technical fields capable of containing arbitrary text (DNS records, HTTP headers, filenames) — can not only lead to prompt injection, but also deliberately inflate the workload. It will be wise to limit their size and monitor the load they generate.

Calculate the unit cost of work and compare the vendor’s invoices with your own data. The cost per analysis, per request, or per check is the only way to understand what you’re paying for and to spot errors in the invoices.

Cybersecurity is often perceived in a highly formal, checkbox way: a mandatory line item in the budget, insurance against an attack, or an extra task for the IT team. But for SMBs, this approach doesn’t work well. As a company grows, so does its dependency on digital technology, which increases the number of potential entry points for attackers. Cloud services, business applications, extra devices for new hires: all of this generates new risks. Eventually, the question of how much to invest in cybersecurity gives way to a different one: how can it help the business grow without putting extra strain on the budget and staff? That’s the point where cybersecurity stops being just defense against threats, and instead becomes a driver of business growth.

The cost of a mistake

According to the new Global Kaspersky B2B Market Pulse survey, 86% of SMBs were hit by at least one cyberincident last year, while 25% of those incidents resulted in financial losses and business downtime. And it’s not always about a sophisticated targeted attack. Often the threat comes from employees’ everyday actions, such as using unverified software, personal devices, third-party AI services, or weak passwords. And since the IT team still has to handle its usual workload, a vulnerability in the infrastructure can go unnoticed for a long time.

At a small company, the fallout from an incident can affect not just a single IT process, but virtually the entire business — with disastrous results: employees can’t get any work done, customers get no services, data becomes unavailable, and the launch of a new project gets delayed. The company is forced to divert resources away from a growth focus to one of recovery. And that’s how an incident turns into a business risk.

More doesn’t mean better

At first glance, the solution seems obvious: if the number of threats keeps going up, businesses just need to deploy more security tools. But SMBs have another limiting factor: resources. In many companies, one small IT team juggles infrastructure, applications, cloud services, employee devices, and technical support. Cybersecurity becomes just another task on the list, often without a matching increase in headcount or expertise.

According to the mentioned survey, SMB and mid-market IT and security professionals themselves point out several internal constraints: a shortage of incident responders, heavy workloads on IT teams, delayed security investments, and rapid growth in the number of devices and services in use. This can create a vicious cycle: the business grows, the IT environment gets more complex, security becomes harder to manage, risks pile up, and security investment keeps getting pushed back until an incident finally happens.

An ounce of prevention is worth a pound of cure

After detecting an attacker in their infrastructure, companies typically scramble to reinforce several areas all at once: employee training, device security, monitoring, cloud security, and so on. According to the survey, оn average, businesses take action across 4.5 areas after an incident. This approach has an obvious drawback: the organization first suffers the consequences, and only then figures out what kind of protection it was missing in the first place. In other words, cybersecurity ends up being a reaction to something that’s already happened.

A more sustainable approach is to evolve a corporate security posture gradually and in sync with the business, anticipating changes in its infrastructure and processes. It’s not necessary to predict every possible threat. It’s enough for the IT team to regularly ask themselves a few practical questions:

• Which technologies and systems does our business depend on today?
• What’s changed in our IT environment?
• Where are the biggest risks right now?
• What can our team realistically keep under control?
• What new security requirements will emerge at the next stage of growth?

Two paths for evolving corporate cybersecurity

When a company focuses on steadily building up its cybersecurity posture, two paths open up: raising its existing level of protection, and expanding coverage to address risks tied to new business needs. A business can pursue either path on its own or combine them.

Path 1: hardening protection

As a business and its security requirements mature, a company can move to more advanced levels of protection and, if needed, bring in managed services’ expertise. That’s exactly the approach behind Kaspersky Next Optimum — an offering for growing SMB and mid-market businesses. A small company may start with Kaspersky Next EDR Foundations, and later move up to the next protection tiers — EDR Optimum, XDR Optimum, or, if managed protection is needed, MXDR Optimum — as its security maturity grows.

Path 2: expanding coverage

Sometimes a company doesn’t need to move to a fundamentally different level of protection. It needs to solve a specific problem that came up as the business grew. For example, the company might ramp up its use of cloud infrastructure, discover that employees have become a major source of risk, or find itself needing to manage vulnerabilities systemically. In such cases, protection can be extended with Security Modules . They’re compatible with Kaspersky Next Optimum, and allow IT teams to cover specific needs as they emerge without having to replace the existing security foundation. Here are the key capabilities of each module:

• Security Awareness helps reduce risks tied to the human factor, and turns employees into an extra layer of defense.
• Email Security strengthens the protection of corporate communications and sensitive data against threats that spread through email.
• Workload Security helps protect cloud and hybrid environments as businesses shift more of their workloads to the cloud.
• Vulnerability Management lets IT teams identify and prioritize vulnerabilities to address them before attackers get the chance to exploit them.
• Threat Lookup & Analysis provides extra context when investigating suspicious files, objects, and threat indicators.

Cybersecurity as a process: the benefits

Small and medium-sized businesses shouldn’t treat cybersecurity as a target to be reached and roll out every possible security tool all at once. It’s far more practical to treat it as an ongoing process closely tied to the company’s growth. This approach helps solve several problems simultaneously:

1. Maintain business continuity. The sooner a threat is detected and stopped, the less likely it is to turn into a serious incident that disrupts the company’s operations. Protecting against threats, catching them early, and responding promptly all help lower the risk of downtime, and keep business processes running smoothly.
2. Make the most of limited resources. Careful planning of corporate security strategy goes hand in hand with process automation, centralized visibility, and investigation tools. These, in turn, help cut down on routine tasks, and free up resources for what really matters.
3. Build a foundation for future growth. By strengthening security as the business grows, the company builds a solid foundation for whatever comes next — whether that’s workload protection, more advanced vulnerability management, or deeper threat analysis. There’ll be no need to rebuild the defenses from scratch each time new business processes emerge.

Ultimately, well-built cybersecurity is more than just a tool for prevention and response. It’s what lets a company keep working despite a constantly growing number of threats, adopt new technology, seize new opportunities, and grow. Visit our website to learn more about how the Kaspersky Next Optimum and Security Modules help growing companies build protection that matches their current needs.

How can an industrial server be compromised through its GPU without leaving a trace? Such a complex, largely theoretical attack would typically leverage hardware vulnerabilities. This isn’t even about design flaws in the hardware itself, but about quirks in how it operates — sometimes at the physical level. A recent paper by Canadian researchers at the University of Toronto describes GPUThor — a new and more effective Rowhammer attack that exploits precisely this kind of hardware behavior in video memory.

Rowhammer and graphics cards

GPUThor builds on the idea behind the original attack on RAM, first proposed in 2014 in the Rowhammer research. Rowhammer and every attack in its class rest on a simple fact: memory cells aren’t fully isolated from one another. Repeatedly accessing (hammering) the same row of cells can, under certain conditions, corrupt data (that is, flip bits) in neighboring rows. Once that effect is confirmed as possible, all that’s left is finding a way to weaponize it — for example, by triggering a denial of service or even executing arbitrary code.

So what do servers and graphics accelerators have to do with any of this? As artificial intelligence technologies have taken off, so has demand for hardware that can run large numbers of parallel, similar computations. And the accelerators built into gaming graphics cards are a natural fit for this kind of workload. This makes cloud providers that rent out graphics accelerators to all comers an attractive target for Rowhammer attacks. The hypothetical scenario runs like this: an attacker buys access to a graphics chip, and uses it to try to compromise the provider’s entire infrastructure. This is exactly why attacks on video memory remain a topic of special interest to researchers.

How the GPUThor attack works

In the spring of this year, three new papers were published — each demonstrating a different attack on Nvidia accelerators equipped with GDDR6 memory. All three delivered fairly modest results: the most damage was done when the target was a consumer-grade graphics card, while attacks on an industrial accelerator like the Nvidia A6000 proved to be far less effective. On top of that, none of the attacks worked with ECC (error correction code) memory protection enabled.

GPUThor also looks at the possibility of attacking Nvidia’s older Ampere accelerators with GDDR6 memory: the researchers studied the A4000, A4500, A5000, and A6000 models. But the effectiveness of the new method — measured by the number of cells whose data was forcibly altered — is significantly higher. The researchers also argue that, in theory, the technique could be applied to newer accelerators as well.

;

How were these results achieved? The standard defense mechanism against Rowhammer attacks is called Target Row Refresh (TRR), which the Canadian researchers took a closer look at. It turns out that if TRR detects repeated access attempts, it forces a refresh of neighboring cells — making data corruption difficult or impossible. Attackers typically try to defeat TRR by accessing cells at random — confusing the defense system and reducing its effectiveness. The researchers discovered that on Nvidia Ampere cards, TRR only triggers once every 72 memory-cell refresh cycles. Armed with this finding, they applied an uneven access pattern — hammering the target cells far more aggressively than before. The result: measured against the original GDDR attack known as GPUHammer as a baseline, GPUThor turns out to be around 7 000 to 23 000 times more effective.

Results and outlook

Combining this more aggressive attack pattern with other refinements produced 72 000 to 377 000 bit flips per gigabyte. Earlier Rowhammer variants managed a few hundred at best. This let the researchers achieve double and even triple-bit errors. ECC easily corrects a single-bit error, but not a double-bit one.

The new method also demonstrates the real-world damage a Rowhammer attack could cause: repeated access to video memory using GPUThor triggers a denial of service. The accelerator first reboots, losing data in the process, then flags itself to the administrator as needing replacement.

Despite these impressive research results, GPUThor attacks aren’t successful. For one, the researchers weren’t able to demonstrate arbitrary code execution as a result of the data corruption — though they claim this is possible even with ECC enabled. For another, an attack thousands of times more effective hints at the theoretical possibility of compromising newer accelerators too, but this also remains unproven for now.

Even so, the Canadian researchers have shown that Rowhammer attacks on graphics accelerators still have untapped potential. It wouldn’t be surprising if future research demonstrated similar attacks against far more advanced devices previously considered highly resistant to them.

Threat actors are constantly developing new attack schemes — from OAuth token theft to attacks on AI agents — but the classics never quite leave their playbook. On any given day, an employee may receive malware attached directly to an email, or lying in wait behind a link embedded in an email. Making these attacks succeed still requires a degree of creativity, and in recent years attackers have increasingly adopted exotic file formats. Users don’t perceive these formats as dangerous; more importantly, many EDR and email security solutions skip scanning them entirely. Yet they’ve proven highly effective for deploying malware or harvesting credentials.

Below are the file types that may be blind spots in your organization’s detection strategy — despite being observed as used in real-world attacks.

Disk images

This is the broadest and most dangerous attachment category. A disk image can contain a fully prepared, correctly structured set of files tailored to a wide range of attack scenarios. It mounts as a separate volume (standalone virtual disk), and when doing so often uses tools built into the operating system. The victim doesn’t need to extract anything or create suspicious folders on disk.

The most versatile format is ISO, which dates back to the heyday of multimedia CDs. ISO images mount natively on every major OS without additional utilities, whether through simple tools like File Explorer or via the command line interface. This is precisely why threat actors have no hesitation in sending ISO files as email attachments.

Somewhat less common are IMG containers, which also mount without additional tooling on macOS or Linux, but require installing a small, free utility such as OSFMount on Windows, or using WSL2 (Windows Subsystem for Linux), which is built into recent Windows versions. A file with identical content may also carry a DD extension.

Threat actors also make use of VHD, a virtual disk format native to Windows, which generally works on Linux machines as well (via qemu-nbd or guestmount). On macOS, an additional utility — again, qemu-nbd is a common choice — is required to mount it. Note that on unpatched Windows systems, the victim doesn’t need to take any further action after the disk mounts: CVE-2025-24993 — a vulnerability actively exploited in real-world attacks — triggers attacker code execution immediately upon mounting the image.

For completeness’ sake, VMDK, the disk image format used by VMware, is also worth detecting, though it’s largely ineffective in attacks on regular users since every popular OS requires additional software to mount it.

All of these image formats can be viewed and unpacked not only with specialized tools, but with standard archive utilities like 7-Zip or RAR. As a result, the odds that the user will fall for the bait are higher than one might hope.

In addition to not being a well-known potentially dangerous format, image files give attackers one further advantage: files extracted from disk images on Windows frequently lack the Mark of the Web flag, and therefore can be launched without triggering additional system warnings.

There’s one more reason why EPP/EDR solutions must scan virtual machines and disk images: these formats are also used during later stages of an attack. To mask active file-system activity from monitoring tools, ransomware gangs sometimes run the entire encryption process inside a virtual machine deployed on the victim’s computer. The RagnarLocker ransomware strain has used VirtualBox for this purpose, while the CRON#TRAP campaign relied on a QEMU environment.

MS Office files

No, this isn’t about macro-laced DOC files. Microsoft has grown weary enough of this classic attack vector that macros in downloaded documents are now blocked outright, and enabling them requires considerable effort from the user. But Office relies on dozens of file formats, and some of the less common ones still occasionally give attackers an edge.

Less familiar to both users and security solutions are OneNote files (.one). These are essentially simple notes, but they can carry embedded attachments, including not just images and links, but VBS/WSF/BAT scripts as well. Within the note, an attachment normally displays as an icon, but attackers overlay it with a picture showing a message with a “View” button.

Another Office format popular with attackers is the Excel add-in. These files use the .xll extension but are, in effect, full-fledged Windows dynamic-link libraries (DLLs), and therefore may have extensive functionality. Victims receive a malicious email with what looks like an invoice; the icon suggests that the file will open in Excel. Ignoring the security warning may result in an infostealer infection.

SVG “graphics”

The description of the SVG (Scalable Vector Graphics) format sounds entirely innocuous. Indeed, 99% of SVG files are logos and interface icons. But unlike PNG or JPG, SVG files are fundamentally XML documents, and beyond points, lines and fills they can contain JavaScript. In terms of malicious potential, SVG is not far behind a full web page. In real-world attacks, SVG files can redirect a user to a phishing page immediately upon opening, or render the phishing page directly by unpacking a Base64-encoded block into full HTML.

SVG files pose a distinct risk to corporate portals that accept user file uploads. If a portal’s Content Security Policy (CSP) isn’t sufficiently restrictive, and lets someone upload a malicious SVG file, the embedded JavaScript can steal cookies from the page, inject unauthorized content, and carry out similar attacks.

Polyglot files

Polyglot file formats are less exotic in and of themselves, but the files carry more than meets the eye. They’re called polyglots because attackers construct a file that can be validly interpreted in multiple ways: for example, it can be a valid ZIP archive and a valid executable at the same time. The purpose is purely to evade detection by security solutions and deceive the user. We’ve covered polyglots in detail in a separate blog post.

The clear standout in our roundup is a malicious campaign distributing the IcedID infostealer. Victims receive emails with a ZIP attachment, which unpacks into an ISO disk image. That further unpacks into a CHM file (the Windows Help format) that’s also correctly processed as an mshta (Microsoft HTML Application host) application, which then downloads the primary malware payload.

Defending against exotic files

These attacks rely on the assumption that security solutions either don’t scan unusual file formats, or scan them only superficially. Preventing the threat starts with not operating on that assumption with regard to your own infrastructure:

• Configure EDR, web, and email filters to scan all of the file formats described above.
• Process archives and disk images with the same rigor as you would apply to executables.
• Detonate potentially dangerous file types in a sandbox, and configure recursive unpacking of nested formats through to the end of the chain: ZIP → ISO → CHM.
• Where feasible, quarantine all file formats anomalous for email — disk images in particular.
• Build detection rules for anomalous usage patterns that involve exotic files. For example, unusually small disk images are rare and are therefore worth investigating.
• Review the technical documentation of your security solutions to confirm that complex formats are detected through deep structural parsing rather than magic-byte checks alone.
• Deploy behavioral detection capable of flagging anomalous execution patterns and legitimate utilities launched from unexpected contexts. The usual suspects here include mshta, git, wscript, hh, and rundll32.
• SVG files warrant a dedicated policy. Treat SVGs as active content at the email and web perimeter. On corporate portals, enforce a strict CSP, and serve user-uploaded files from a separate subdomain so that a malicious script embedded in an SVG can’t access the session on the main portal.

For security researchers studying unconventional side-channel attacks, acoustic keylogging is something of a Hello World: a foundational problem that’s been tackled many times. A recent paper authored by researchers across three Japanese universities cites six previous studies on the topic that date as far back as 2004. While earlier experiments showed theoretical promise, they came with real-world caveats so severe that it made them all but impractical for actual espionage. The authors of this latest study, however, claim to have overcome most of those limitations. Today, we look at how they pulled it off, and assess whether their method holds up in real-world scenarios.

What makes this new approach different?

Previous acoustic keylogging techniques were fundamentally flawed. Best-case scenarios required prior training on the target’s specific keyboard model. Worst-case scenarios required a complex microphone array to isolate the subtle acoustic differences between keystrokes. Crucially, almost all prior models failed outside silent environments, which rendered the attack vector virtually useless.

The Japanese research team demonstrated reliable keystroke interception even if the target was sitting nearby in a public space, sound was being recorded in an online meeting, or the researchers were using a contact microphone to eavesdrop through a wall. All this with strong model accuracy and a minimal training dataset. Their process needs a sample of just 150 to 200 keystrokes to reach a 99% accuracy rate for subsequent typing.

How to crack 200 keystrokes in under 50 iterations

To understand how the researchers achieved such high accuracy and adaptability, we have to look at their audio processing pipeline. Their analysis begins by automatically segmenting a raw recording into discrete keystrokes. This data is then passed through a specialized algorithm that simplifies the subsequent audio analysis. Next, the system clusters together acoustically similar signals. The assumption is that the members of one cluster map to the exact same key. One particularly intriguing takeaway was isolating the spacebar sound from all the rest. Because the spacebar produces a distinctly unique sound profile compared to other keys, identifying it provides reliable word boundaries. This streamlines the next phase: feeding the preprocessed acoustic data into specialized language models for inference.

Yes, the method relies on not one but two language models. The first model performs multiple passes over the audio stream to map acoustic signatures to potential keyboard characters. During each pass, the model leverages dictionaries to hypothesize character mapping, and check whether the resulting text aligns with standard words. The second model handles the final refinement pass: it ingests thoroughly pre-processed data rather than raw inputs. The method doesn’t stop there: unrecognized keystrokes undergo manual analysis, with analysts injecting educated guesses before re-running the recognition pipeline once again. The goal of looping through these multiple iterations is to achieve complete recognition across the keyboard from an ultra-compact dataset of ideally no more than 200 captured keystrokes. This marks a major shift from legacy methods, which relied on massive training datasets.

Research results

To validate their theoretical model, the researchers created an experimental testing setup:

The team tested four distinct laptop models, each producing unique acoustic keyboard signatures. Participants typed 2400 characters per experiment, with analysts extracting audio samples ranging from 50 to 400 keystrokes. Across all devices, the system reliably reconstructed typed text from a baseline sample of just 150 keystrokes or more. Recognition accuracy exceeded 80% at 150 keystrokes, and approached 100% once the sample reached 200 keystrokes.

The researchers achieved nearly identical results in field-like conditions with the microphone placed three meters away from the target device. Going a step further, the team successfully tested an even higher-friction scenario: using a specialized contact microphone to eavesdrop through a physical wall.

Under these conditions, accuracy dipped slightly for certain laptop models. Dell and Lenovo devices yielded roughly 80% accuracy over a 200-keystroke sample, while Apple and HP ones maintained nearly 100% recognition rates.

Remote interception during videoconferencing presented an additional variable: results depended on both the target laptop model and the specific web conferencing software used. Even so, most test scenarios yielded reliable character recognition, though a few edge cases required expanding the sample size from 200 to at least 250 keystrokes.

Reasonable critique

Despite these impressive results, the technique has clear limitations. First, all experiments were conducted strictly on lowercase English text. The target dataset was capped at just 29 characters: the standard alphabet, spacebar, period, and comma — even number keys were excluded. As a result, capturing randomized character strings like complex passwords remains a major hurdle. Yet these are precisely the targets threat actors care about most.

However, the Japanese research team didn’t ignore passwords. While recognition accuracy was predictably low, the authors proposed assessing success through a more realistic lens. For starters, attackers can almost always capture audio of other typing activity alongside password entry. This provides a stream of natural language with minimal special characters. Factoring this broader acoustic context into the password analysis significantly improves the odds of a successful guess.

Next, the researchers rightly noted that even a list of several candidate passwords increases the chances of compromising a target account. As shown in the graph above, when ample data (426 keystrokes) is captured, a short five-character password can be successfully cracked within 100 attempts with a 90% success rate. Naturally, longer passwords proved far more resistant to eavesdropping.

Despite its limitations, this study represents a major breakthrough in acoustic side-channel attacks. It demonstrates a highly practical threat scenario: an attacker captures a brief audio recording of typing activity, then uses iterative analysis and targeted manual adjustments to process and refine the data offsite.

While eavesdropping in a noisy restaurant or through a wall is likely difficult to scale, capturing keystrokes during virtual meetings for offline decoding represents a realistic attack scenario. Ultimately, this research offers a compelling proof-of-concept: modern algorithms can drastically improve the accuracy of acoustic reconnaissance.

The news coverage surrounding the breach of the AI platform Hugging Face by OpenAI’s autonomous agents reads like a scene straight out of a Terminator movie (apparently, a prequel). Yet for enterprise security teams — even those that don’t develop or deploy artificial intelligence — the detailed incident report published by Hugging Face provides a critical operational roadmap. The incident needs to be evaluated on the basis of a single, fundamental question: “Which organizational security flaws, missing controls, configurations, or technologies allowed this attack to succeed?”

What happened?

During cyber-capability testing of OpenAI’s advanced AI models against the ExploitGym benchmark, an agent found a way to break out of its confinement, reached the internet, and breached the infrastructure of several companies — one of them being Hugging Face. The model reasoned that it could find solutions to the benchmark challenges on these external systems. Dozens of articles have since covered these incidents in detail, so no need to go over that here. What truly matters is what transpired within Hugging Face’s systems between July 9 and 13 while the AI agent operated unchecked inside. The Hugging Face incident report includes an interactive attack timeline, so we’ll just list the key stages. A malicious configuration in a dataset uploaded by the agent allowed it to exfiltrate credentials for a worker pod, and execute code within it. The agent then exploited cloud environment metadata and escaped the privileged pod to obtain root-level access on the host. It retrieved a substantial number of secrets from storage and used a stolen VPN key and shared cluster administrator credentials to pivot deeper into the internal network and source code repository before the Hugging Face security team blocked its access.

How significant is the fact that this was next-generation AI?

Regardless of the specific area of ​​activity of a company, tomorrow it may become a target of human attackers, fully autonomous systems, or AI agents manually controlled by human hackers.

Many AI practitioners have rushed to dismiss this incident based on assumptions that OpenAI will never allow its tech to get into serious hacking. However, security researchers have argued for months that even currently available open-source models can be used to launch both offensive research and real-world attacks. Human oversight, while still a requirement, can be minimal. Even mid-tier models can easily iterate through a dozen vulnerabilities, inventory a compromised infrastructure, and quickly figure out how to expand their reach across a network. Defenders must analyze incidents like this in detail, map the key findings to their own environments, and adapt security controls to counter both stealthy human actors and rapid, noisy AI agents.

Three distinguishing features of AI-powered attacks

The techniques detailed in the Hugging Face report are not novel — the agent didn’t invent anything new. However, three factors regarding the attack’s speed and scale fundamentally shift the economics for both attackers and defenders:

• Trial and error becomes significantly cheaper. Where a human hacker might test five attack vectors, an agent can iterate through five hundred. Scenarios that security teams previously dismissed as “theoretically possible, but impractical and unlikely” and placed them on the backlog can now become active threats.
• Attack execution and incident response windows shrink. High-speed attacks are not unheard of, while some ransomware operators achieve compromise within hours even without AI. However, this accelerated pace will likely become the new baseline in cybersecurity, as demonstrated by the agent obtaining admin privileges at Hugging Face within 13 hours.
• Numerous alerts and log entries generated by the agent’s trial-and-error attempts can both help and hinder attackers as well as defenders. This noise can serve both as an indicator for threat detection, and as camouflage to hide meaningful actions. It also acts as a natural bottleneck for incident response when the workflows are fully manual.

How to protect corporate infrastructure

Don’t ignore alerts from triggered defensive controls. This classic mistake — often highlighted by our incident response experts — was made at Hugging Face as well. Malware execution, port scanning, WAF triggers, requests to non-allowlisted resources, and failed authentication attempts are likely some of the event types that are blocked automatically. However, all these events are often categorized by SIEM systems as purely informational and routinely ignored. In the Hugging Face incident, numerous server-side request forgery (SSRF) attack attempts were successfully blocked over several days, yet no one batted an eyelash. Much like persistent human adversaries, the AI agent continuously retried until it succeeded. To detect such attacks, establish clear rules and triage workflows for defensive alert telemetry to ensure that priority automatically escalates when event volume spikes.

Investigate rapidly escalating error counts. Legitimate operations rarely generate hundreds of authentication failures within 10 minutes across four distinct systems. Analyze historical baselines, and generate medium or high-severity alerts depending on the deviation from normal error rates. As part of automated response protocols, you can temporarily block the user or system that is generating the anomalous activity, or enforce rate-limiting on them.

Configure escalation paths and conduct security team drills. Hugging Face’s correlation engine successfully detected the attack, yet it failed to grab the human operators’ attention. During security drills, organization must evaluate how quickly key personnel respond to critical incidents — even when these happen during off-hours such as at night on weekends.

Isolate services — internal ones included — that process untrusted input by design. The primary vulnerability at the start of the attack was a node configured to process machine learning datasets, which are widely known for potentially containing executable code. This node, capable of executing untrusted code, operated without a sandbox or adequate isolation controls. The risk extends beyond machine learning — to document conversion engines, image processing pipelines, user file upload handlers, and any other server-side processes that perform deserialization or template rendering. Any server-side execution of this nature must run under maximum feasible isolation, restricted from accessing external or internal network hosts beyond an absolute minimum, and ideally enclosed within a sandbox.

Restrict egress. Most organizational servers don’t require unrestricted connectivity to arbitrary external hosts. If implementing strict default-deny egress policies presents technical challenges, consider a streamlined approach: enforce DNS traffic resolution exclusively through your enterprise DNS server, and configure it to block known public services that are commonly abused as command-and-control infrastructure or exfiltration channels such as Pastebin or OneDrive. Similar outbound restrictions can also be enforced via an NGFW.

Avoid issuing large batches of secrets, or storing them as a single object. Even with secret managers in place, an attacker can gain broad access if a compromised account holds excessive permissions. In the Hugging Face breach, a single Kubernetes Secret object contained 136 keys. The fewer secrets issued, the lower the impact of a compromise — and the easier key-rotation becomes.

Avoid long-lived secrets and don’t store them in environment variables that are inherited by all child processes.

Isolate applications from metadata servers. Most cloud environments run services — such as the EC2 Instance Metadata Service — that issue credentials and system details upon request. Isolating these from arbitrary applications — via firewall rules or by enforcing IMDSv2 — eliminates the most direct path from a single application compromise to a full account takeover.

Audit server and application identities. Service accounts with broad access, OAuth tokens, cross-environment keys, and other artifacts granting excessive privileges are most frequently found in server and app identities rather than human user accounts.

Track usage of credentials at anomalous entry points. In the Hugging Face attack, credentials assigned to an internal host were leveraged from an external one. Detection rules that flag these anomalies are straightforward to implement and deliver high-fidelity, low-noise signals of an attack that’s already progressed beyond its initial stages.

Use short-lived, single-use keys when provisioning new devices and services. During the incident, a single key was used to register 181 separate devices without triggering a single alert.

Security lapse leaves sensitive information and contact details of 51 government officials exposed for 40 hours

The public body in charge of the UK’s state investments has been pushed to improve its internal security after a data breach left “high-level management information” publicly accessible for nearly two days.

UK Government Investments (UKGI), the agency that manages the taxpayers’ interest in a swathe of companies including Channel 4 and the Post Office, said the security failure also left more than 50 government officials’ personal details exposed for nearly 40 hours.

Continue reading...

© Photograph: Marina Demidiuk/Alamy

© Photograph: Marina Demidiuk/Alamy

© Photograph: Marina Demidiuk/Alamy