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.

Today, in most countries around the world, virtually every reasonably large city is packed with video cameras. On the one hand, the idea, of course, is to “keep us safe”: to monitor security in the streets, improve road safety and enforce traffic rules, and so on. But there’s the other side of the coin — ubiquitous video surveillance creates both privacy risks and opportunities for unauthorized surveillance We’ve repeatedly posted on our blog about how to protect yourself from surveillance involving IP cameras.

There’s another problem, too: relying too heavily on video surveillance systems can also be dangerous. If your cameras aren’t adequately cyber-secure, attackers may be able to disable them remotely to be able to then enter physical areas supposedly protected by video surveillance without being detected. This issue is especially relevant to home and privately managed surveillance systems — large companies generally do a better job of securing their devices (although there are exceptions there as well).

Disabling or replacing a camera feed is an almost obligatory plot device in heist movies. But unfortunately, this isn’t just a screenwriter’s invention: our recent research uncovered a vulnerability that makes it possible to remotely disable IP cameras made by Intelbras — a popular camera manufacturer. Read on to learn what the problem is, and how to protect your surveillance systems; a detailed technical analysis of the vulnerability is available on our expert blog, Securelist.

When an update does more harm than good

A surveillance camera is essentially a fully-fledged mini-computer, and its firmware needs to be updated regularly. In this case, however, the vulnerability was hidden in the firmware update procedure itself.

Intelbras provides firmware update files on its official website. The firmware can be updated manually from an SD card, or over the local network via the web interface or mobile app. However, during a firmware update, the camera neither required (past tense; a patch has since been issued – see below) authentication nor validated the firmware file before starting the update. As a result, anyone connected to the same Wi-Fi network as the camera could send it an update request. When an update is initiated, the camera reboots, taking it offline for about a minute before it becomes available again. But if the requests are sent repeatedly in a loop, the camera can be kept offline indefinitely.

We investigated this vulnerability on an Intelbras iM3 C (iM3B-C) camera running firmware version v240927 — the latest available at the time of our research. The iM3 C is a smart Full-HD Wi-Fi camera designed for both home surveillance and as a baby monitor. According to Intelbras, the firmware for the iM3 C is also compatible with the iMX C, iM4 C, iM5 SC, iME 360 C, and iM7+ FC models.

This vulnerability has a medium severity rating. However, because of the large number of potentially affected users, the impact of successful exploitation could be significant. Intelbras Mibo Smart — Intelbras’s app for setting up and managing these camera models — has been downloaded more than four million times, with most of its users based in Brazil and elsewhere in Latin America.

We notified Intelbras about the vulnerability, and the company promptly fixed it in a new firmware release — R.260804 (installation instructions for the update are available here).

How to secure your cameras and other smart devices

First and foremost, all Intelbras owners should update their camera firmware as soon as possible — and continue to do so regularly. More generally, it’s a good idea to secure your smart-home infrastructure in advance to reduce the risk posed by other potential vulnerabilities.

• One of the simplest yet most important steps is to change the default settings on both your smart devices and your home network. Be sure to replace the factory-default passwords on all smart devices and on your router — default username/password combinations such as admin/admin or root/admin provide no meaningful protection.
• Protect your home Wi-Fi with a strong password; otherwise, attackers could easily gain access to your local network.
• Disable WPS on your router. WPS is designed to simplify network setup and authentication: you can connect by pressing dedicated buttons on the router and respective device, or by entering an eight-digit PIN. The problem is that this PIN can be brute-forced relatively easily, allowing an attacker to recover the key to your Wi-Fi network fairly quickly.
• Use a strong, unique password for every account that can be used to manage your smart devices through official apps or websites. Where possible, enable two-factor authentication (2FA); the most secure option is generally to use one-time codes generated by authenticator apps. For generating and storing passwords, as well as creating one-time codes, it’s most convenient to use a password manager.
• Put your IP cameras and other smart devices on a separate Wi-Fi network — isolating them from phones, laptops, tablets, NAS devices, and so on. Most modern routers can create at least two Wi-Fi networks (a primary and a guest network). Use the guest network for smart-home devices, but make sure it’s protected with a strong password. If your router supports multiple Wi-Fi networks, consider putting the cameras on a dedicated network of their own. That way, even if the cameras are compromised, attackers won’t be able to reach your other devices.
• Use Smart Home Monitor, available in Kaspersky Plus and Kaspersky Premium. This feature shows all devices connected to your home network, lets you check their security status, and alerts you if an unknown device joins your home Wi-Fi.

More camera-security and smart-device tips and stories:

• Five rules to stop IP cameras from spying on you
• Webcam hacking, Korean-style: 120,000 IP cameras compromised
• Camera surveillance: myth or reality
• Network camera security: bad, worse, and terrible
• How to secure your smart home

Yesterday, two critical vulnerabilities were disclosed in PHP, the scripting language used by many websites and online services: CVE-2026-109618 and CVE-2026-109619. Attackers can exploit them to remotely execute commands on any server running PHP, with no authentication required. The exploit has been dubbed PHP2Shell.

The PHP security team announced an upcoming emergency update on October 20 and released patches fixing the vulnerabilities the following day.

We’ve already covered the technical details of these vulnerabilities and explained what companies and server administrators should do. You may have safely skipped that news because you don’t run any servers — but unfortunately, the issue is not limited to businesses.

Nearly 70% of websites run on PHP, including services we use every day: wikis, online stores, smart devices with web interfaces, home network-attached storage (NAS), smart-home controllers, and much more.

Today, we explain how these vulnerabilities could affect you personally and what you can do to reduce the risks.

How the vulnerabilities can affect home users

Account and personal-data theft

The vulnerability allows an attacker to steal authentication tokens from server memory. These tokens essentially act like electronic passes — telling a website that the user has already signed in. As a result, an attacker may be able to access someone else’s account without entering a password or two-factor authentication code, putting messages, documents, delivery addresses, order histories, and other confidential information at risk.

Loss of files on home devices

If you have network-attached storage (NAS) or a video surveillance system at home that uses a vulnerable PHP version, it may also be at risk. Depending on what level of access they gain, attackers could potentially copy, delete or encrypt files they can access.

Malware infection

If an attacker gains access to a vulnerable website, they can use it in virtually any way they want: trick visitors into downloading a malicious file or clicking on a phishing link, display dangerous instructions, replace payment forms or login pages with malicious ones — the list goes on and on. As a result, someone visiting a legitimate website could not only lose access to their account, but also lose money or accidentally infect their device with malware.

Below are examples of services directly affected by the vulnerabilities.

Which services are affected by the PHP vulnerabilities

Jeedom

Jeedom is a smart-home platform that lets users control lighting, sensors, heating, blinds and home IoT devices. Attackers could abuse this in many ways: they could disable the alarm, track when the homeowner is away, access video from the door intercom, and more.

The developers confirmed that the new vulnerability affects their application, and have already released an emergency update — Jeedom 4.6.2. Users need to run the update twice for it to work. The developers say a fully fixed version for home users will be released in the coming days.

Websites we use every day

As mentioned above, PHP is used by roughly 70% of websites. This doesn’t mean every one of them is vulnerable: it depends on the PHP version in use and whether the site owners have already updated it. Many government websites in Europe have already suspended operations because of the new vulnerability.

Unfortunately, a website may still be vulnerable even if it appears to be working normally. An attacker could potentially take control of any legitimate website whose server hasn’t been patched yet. They could fake payment or login pages, host malicious files, or persuade users to download an “urgent update” that is actually malware.

Ordinary users have no reliable way to check whether such instructions or files are safe, so be sure to use reliable anti-phishing and antivirus protection. If you suspect that your data may have been stolen, check the active sessions in your account settings. If you spot suspicious activity or devices you don’t recognize, sign out of all active sessions and change your password. Use a password manager — it can generate a truly strong, unique password that you won’t have to memorize yourself.

Computer games

Bad news for gamers: some video games whose servers use PHP are also at risk. If you don’t want attackers to get hold of your accounts, be sure to update the passwords for your gaming platforms, stores and accounts.

To buy time for updates, some developers temporarily took their services offline. Final Fantasy XIV, Pokemon Champions, games from Bandai Namco Entertainment, Uma Musume: Pretty Derby, Granblue Fantasy, Shadowverse: Worlds Beyond, and many others went into emergency maintenance. Nintendo Switch Online and the GOG and Steam stores were also affected.

Unfortunately, there’ve also been more drastic consequences. Yesterday, the developers of World Quest announced that the game would shut down permanently after 15 years: it relied on outdated infrastructure that would have been extremely difficult and costly to fix. For the same reason, the mobile game Please Save My Pandemonium! shut down after more than ten years of operation.

Home network-attached storage (NAS)

“Home clouds” have become popular in recent years for good reason: many users prefer to keep backups of their data at home rather than online. A number of companies make NAS devices, and at least three — QNAP, Synology and ASUSTOR — have said the vulnerabilities affect their products. An update has also been released for Unraid, an operating system for home servers, network storage and media servers.

QNAP

The manufacturer confirmed that the vulnerabilities affect several versions of its NAS operating systems — QTS and QuTS hero — as well as applications including QuMagie, Note Station 3 and certain versions of QVR Surveillance. A successful attack could put photos, documents, notes and camera recordings at risk.

At the time of publication of this blogpost, QNAP is still preparing updates, so the main priority is to temporarily disconnect NAS from the internet. QNAP recommends disabling port forwarding on the router — to prevent NAS from automatically opening ports — and allowing access to the management panel only from the home network or through a VPN.

Synology

Both vulnerabilities have been officially confirmed in PHP packages 7.3, 7.4, and 8.0–8.4, as well as in Mail Station and Synology Calendar. Fixes have already been released for PHP, starting from version 7.4, as well as for Mail Station and Synology Calendar. PHP 7.3 won’t be fixed. The company separately notes that the PHP component built into its operating system cannot be reached from outside the device, so the risk of attack is very low.

ASUSTOR

ASUSTOR also officially confirmed both vulnerabilities, and immediately removed PHP 7, 7.3, 7.4, and 8.1 packages from App Central. The company recommends immediately backing up your data, removing older PHP packages, and using PHP 8.3 or 8.4.

Unraid

In today’s operating-system update, PHP was upgraded to version 8.4.27 with fixes for the vulnerabilities. The developers recommend that all users update to Unraid 7.3.4. Containers with their own PHP installation must be updated separately: the new PHP version in the operating system doesn’t replace PHP inside containers.

At the time of publication, we haven’t found public confirmation from other major manufacturers (such as TerraMaster, UGREEN, Buffalo, or Western Digital) that their devices are affected by these vulnerabilities — only user discussions on forums.

But the fact that only some NAS manufacturers have confirmed the problem so far doesn’t guarantee that your devices are safe — especially if they’re fairly old or come from a lesser-known or defunct manufacturer. In that case, first disconnect the devices from the internet while keeping them accessible only on the local network, and then investigate whether they’re vulnerable.

Nextcloud cloud storage

Nextcloud is a free, open-source platform for creating your own cloud storage, serving as an alternative to Google Drive, Dropbox, and Microsoft OneDrive. It lets you store and synchronize files across devices, share them with other users, and work with documents, photos, calendars and contacts. The data can be stored on your own server or NAS rather than on a third-party company’s servers.

If you store important data in Nextcloud, check how your cloud instance is configured. If you use Nextcloud All-in-One, update to version 14.4.1 where the vulnerability has already been fixed.

If your Nextcloud installation is configured differently, you need to update PHP yourself on the device or server.

How to protect your devices and data

• Use phishing and malware protection. Our security solution automatically blocks phishing pages and malware, even when attackers place them on legitimate websites.
• Keep an eye on updates. If you have network-attached storage, a smart-home system, a home server, a media server, or any other device with a web interface, first check the manufacturer’s website and install all available updates. If no update is available yet, temporarily disable internet access to the device.
• Use strong passwords. Most people reuse the same password, or variations of it, across multiple websites. If an attacker finds one of those passwords on a vulnerable server, they may be able to compromise your other accounts as well. We recommend generating and storing strong, unique passwords in Kaspersky Password Manager so you don’t have to remember your credentials yourself. Be sure to enable two-factor authentication on all important accounts — ideally using one-time codes generated by the same password manager.
• Keep an offline backup of important files. Don’t rely on cloud storage alone — make sure you keep a backup of all important documents on both a hard drive and an external device. For more information on how to make backups properly, see our article The internet remembers not quite everything.

What other risks can your home devices face? Read our articles:

• Trojan TV, or the new risks of malicious proxies
• Ransomware now taking aim at personal backups
• Is your TV box renting out your network?
• Is your router secretly working for foreign intelligence?
• Three common attacks on Linux in homes
• How to secure your smart home

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.

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.

On September 15 this year, Google published details of patches for 110 vulnerabilities in its own Google Pixel smartphones. Among all the disclosed flaws, CVE-2026-58704 stands out the most, for it appears that this zero-day is being exploited in targeted attacks.

In today’s post, we talk about what’s so special about the Google Pixel, and why these devices get security updates all of their own – separate from regular Android updates. We also cover the vulnerabilities addressed in this latest update, with a special focus on the mentioned, most dangerous one – CVE-2026-58704 – and wrap up with tips on how to both protect your device and avoid becoming a victim of cyberattack on it.

Why do Google Pixel phones get security updates separate from Android?

The reader might reasonably wonder: I’ve already installed this month’s Android security updates on my Google Pixel. Isn’t that the same thing? Google Pixel does run on Android and receives those security updates, which are detailed in the monthly Android Security Bulletin. However, manufacturers of Android-based devices use different sets of hardware and software components. That’s why, alongside vulnerabilities common to all Android devices, there are security issues specific to individual manufacturers’ devices.

For its own smartphones, Google publishes separate security updates, covered by a dedicated Pixel Update Bulletin. Rather than replacing the Android Security Bulletin, this document complements it by detailing vulnerabilities specific to devices manufactured by Google. Other Android smartphones also receive similar updates from their manufacturers.

The Pixel Update Bulletin for September 2026 clearly shows why Google needs separate updates for its smartphones in the first place. Many of the vulnerabilities it fixes affect specific Pixel hardware (or hardware-related) components: the modem, bootloader, GPU, fingerprint scanner components, and other parts of the device. On smartphones from other manufacturers, these features might rely on entirely different hardware and software components, so the fixes listed in the Pixel Update Bulletin don’t apply to those phones.

That said, these vulnerabilities could still be relevant for Pixel owners who’ve flashed their devices with custom ROMs. Switching to a different OS doesn’t alter the device’s hardware components, and may not replace the firmware. Therefore, the vulnerabilities themselves may persist, but whether patches are available, and how they’re installed, depends on the specific OS.

CVE-2026-58704: a zero-day vulnerability being actively exploited in the wild

Now let’s look closer at the specific vulnerabilities Google fixed in September. The most significant one is the above-mentioned CVE-2026-58704.

This vulnerability affects the Cellular Modem component, which handles the smartphone’s communication with cellular networks. It stems from a logic error in the code, which, under certain conditions, allows bypassing the intended permission check.

Successful exploitation of CVE-2026-58704 lets attackers escalate privileges on the smartphone to gain broader access to its functions and data. Note that the attack takes place over a cellular network and the threat actors need low-level privileges on the targeted device to start with.

In practice, this means attackers can’t exploit CVE-2026-58704 to attack a Pixel from just anywhere over the internet, as they’d apparently need to either compromise the cellular network the target smartphone is already connected to or, more likely, force it to connect to a malicious base station under their control.

Google hasn’t disclosed all the details of this vulnerability yet, and the related report is not publicly accessible. As a result, the technical details that would show how easy it is for attackers to exploit CVE-2026-58704 remain unknown pending installation of the patches on all devices.

Nevertheless, Google claims that there are signs of limited exploitation of CVE-2026-58704.

What we know about the other 109 vulnerabilities

Of the remaining 109 vulnerabilities found in Google Pixel devices, only one is rated moderate; the others are either high (62) or outright critical (46). Nine of these flaws fall into the RCE (remote code execution) category. This means that if an attacker successfully exploits one of these vulnerabilities, they can remotely force the device to run malicious code. The exact conditions for the attack depend on the specific vulnerability.

Another 88 vulnerabilities fall into the elevation of privilege (EoP) category. These let an attacker who’s already gained a certain level of access to the device expand their privileges. The CVE-2026-58704 vulnerability discussed above falls into this same category, which is why the September bulletin lists 89 EoP vulnerabilities in total.

Finally, 10 vulnerabilities can lead to information disclosure (ID), and two more to denial of service (DoS). In short, that’s a hefty list of flaws, so Google Pixel owners shouldn’t wait around to install the patches.

How to avoid becoming a victim

Google Pixel owners can install the update that fixes the vulnerabilities covered in this post by following this path: Settings → Security & privacy → System & updates → Security update → Install. Keep in mind that the phone will automatically restart to finish installing the update.

To keep your phone secure we recommend the following general measures:

• Install security updates on your phone regularly and promptly – whether it’s a Google Pixel, an Android smartphone from a different manufacturer, or even an iPhone.
• Avoid installing apps from questionable sources.
• Read reviews before installing apps from official stores, since malware isn’t uncommon there too. Users who have already been burned will often sound the alarm in the reviews long before store moderators get around to removing the dangerous app.
• Install a reliable security solution to keep you from downloading malware, and warn you about suspicious activity on your device.

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.

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.

Security researchers have found a way to hack a Boeing 737 with a device no bigger than a coin. The 737 is one of the most widely used airliners in the world, so chances are you’ve flown on one yourself at least once.

The attack requires installing a small device in a port that’s accessible through a hatch on the outside of the plane. According to the researchers, this port is regularly within reach not just of maintenance crews, but of other airport and airline staff too. And installing the device takes less than 60 seconds. So let’s talk about what this mysterious little device actually is, what it can do, and whether it’s still safe to fly on a Boeing 737.

Why hacking a plane is harder than hacking a car

Most of us have gotten used to the idea that our computers and phones can be hacked. It’s probably the most common topic on this blog. But we’ve also covered attacks on less common targets: cars, robot lawnmowers, automated card shufflers, bikes, and even mattresses. In today’s world, all of these (and many other) devices contain tiny (or not-so-tiny) computers.

Airplanes are no exception. A modern airliner is packed with computers — some of which handle critical functions: from calculating takeoff parameters to controlling the flight itself. But there’s one key difference: airliner manufacturers, unlike the makers of most smart home gadgets, take security very seriously, which makes it far harder to reach these systems from the outside.

Maybe that’s precisely why the idea of hacking a real plane has been tempting the most inquisitive security researchers for years. A team at the University of California San Diego and Oberlin College — the researchers who finally pulled it off — spent more than a decade wrestling with the problem. As mentioned above, the main challenge in hacking a plane is that its critical systems aren’t connected to the external internet. Because of that, studying plane-related attack vectors wasn’t seen as especially promising within the cybersecurity research community: reaching isolated systems remotely is extremely difficult, and the odds of an attacker gaining physical access were considered very low.

Two other successful projects changed that assumption for UC San Diego researchers Kirill Levchenko and Aaron Schulman: a hack of the Chevrolet Impala, and research into payment card skimmers. The car hack led their team to buy secondhand Boeing 737 computer components and build their own test rig. The skimmer research gave them the idea for a small physical device that could plug directly into the plane’s internal systems.

After studying the Boeing 737’s circuit diagrams, the researchers found a port accessible from outside the plane — protected only by an unlocked hatch. That port connects to a data channel called the ARINC 429 bus, which links the plane’s flight management computer (FMC) to its multifunction control and display unit (MCDU).

 A “bus driver” at the controls

On their test rig, the researchers checked what would happen if they connected to the ARINC 429 bus through this port and sent electrical signals more powerful than the ones the Boeing’s components normally exchange with one another. It turned out that doing so let them override legitimate commands with their own. From there, all that was left was building a device small enough to fit into the port they’d found.

Step by step, the team built a device compact enough to slot into the unprotected port. The finished version set them back less than US$100, and appears to have been built largely from off-the-shelf parts: a small microcontroller, electronics for communicating with the bus, and a Wi-Fi module. That last part could potentially help the device connect to the plane’s public in-flight Wi-Fi network, giving the attacker access over the internet, and eventually letting them control the device remotely. And the whole thing takes less than a minute to install into the port.

The researchers dubbed their attack “Bus Driver”, apparently a play on words: “bus” refers to both a passenger vehicle and the data channel that lets a system’s components talk to each other. The attack lets someone step into that channel and swap out the commands being sent — effectively controlling the bus.

What the improvised Boeing 737 hacking device can actually do

An unprotected port, a coin-sized device, access to the bus: that’s all and well and good, but what did the researchers actually manage to pull off? What kind of damage can this tiny implant do? As it turns out, quite a lot — potentially even fatal. By gaining the ability to tamper with the data flowing between the flight management computer and the control and display unit, the researchers found they could interfere with several critical aspects of how the plane operates.

First, the implant can alter the data used to calculate takeoff and landing parameters. For example, it can change the plane’s recorded zero-fuel weight, which throws off the calculation of the speeds needed for a safe takeoff.

The device can also manipulate the assumed temperature value pilots use to determine how much engine thrust is needed at takeoff. Feed the system the wrong numbers, and under certain conditions the plane could end up with insufficient thrust to take off safely — potentially even going off the end of the runway. Faulty calculations during landing carry similarly serious risks.

The implant can also change the route the autopilot is following. On a long flight, a deviation of just a few degrees — subtle enough to go unnoticed — could be enough to send the plane badly off course so it runs out of fuel somewhere over open ocean.

Beyond that, an attacker could use the device to steer the plane into the airspace of a country that isn’t part of its approved flight path. That kind of deviation can also have deadly consequences: the history of civil aviation has seen more than one case of a passenger plane being mistakenly shot down by the military after straying into restricted airspace.

Of course, the odds of a deviation like this slipping past both pilots and air traffic control are very low, but disasters tend to happen exactly when several human errors line up.

Finally, the device doesn’t just let someone change flight parameters, it lets them hide those changes from the pilots. For instance, an attacker could load a new route into the flight computer while simultaneously altering what’s shown on the MCDU display, so the pilots keep seeing the original route.

That said, the researchers note that in most cases an attentive crew would catch the discrepancy. The correct data still shows up on other cockpit displays, and switching to manual control lets pilots disengage the autopilot and take back control of the plane.

So, should we all switch to trains?

To wrap up, I’ll try to put the longtime aerophobes (and anyone this article has just turned into one) at ease. The researchers themselves say that despite everything they’ve learned, they still fly on Boeing 737s. And to avoid causing any real-world trouble, they deliberately left out exactly which port they used in their experiments.

The researchers also reached out to Boeing back in 2020 to share their findings. Boeing took the information seriously and worked on addressing the issue.

Specifically, the researchers suggested Boeing either remove the vulnerable port or seal it with epoxy resin to physically rule out the possibility of someone plugging in an unauthorized device. There are more involved options too, like redesigning the internal bus’s electrical protections so a rogue device can’t override the real signals, and adding systems that can detect this kind of attack in the first place.

Longer term, the researchers recommend that Boeing, along with other aircraft manufacturers, adopt cryptographic authentication for the messages passed between avionics components.

Whether Boeing acted on this specific advice or came up with its own fixes isn’t publicly known. When Wired reporters asked the company about it, the response was fairly vague:

“Our technical experts are confident that the layers of protection in place on the airplane, including within the system design and the operating environment, provide sufficient mitigation to significantly limit the feasibility and risk of real-world attacks.”

So no, there’s apparently no need to swear off Boeing 737 flights just yet. That said, I happen to have a lot of respect for trains, so I won’t try to talk you out of traveling by rail or using other ways of getting around either. I’ve actually written about train hacking on this blog before, though in that case the goal was constructive, not destructive.

Cars, lawnmowers, card shufflers, bikes, smart mattresses — it’s not even an exhaustive list of the devices that hackers have successfully tampered with. What else was hacked? Find out in our other posts:

• Botnets on wheels: the mass hacking of dashcams
• Car hacking via Bluetooth
• Five hacks that were (mostly) just for laughs
• Vulnerabilities in a toy robot permitting snooping. Seriously
• Ecovacs robot vacuums get hacked

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.