Cisco Talos’ Vulnerability Discovery & Research team recently disclosed four vulnerabilities in MediaArea MediaInfoLib library.

The vulnerabilities mentioned in this blog post have been patched by their respective vendor, in adherence to Cisco’s third-party vulnerability disclosure policy.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.

MediaArea vulnerabilities

Discovered by Dimitrios Tatsis of Cisco Talos.

MediaArea produces digital media analysis open-source software, as well as support tools for file investigation. MediaInfoLib provides a UI for technical and tag data for video and audio media files. Talos discovered four vulnerabilities in MediaInfoLib.

TALOS-2026-2367 (CVE-2026-25104), TALOS-2026-2368 (CVE-2026-25713), TALOS-2026-2371 (CVE-2026-28764), and TALOS-2026-2374 (CVE-2026-22554) are heap-based buffer overflow vulnerabilities in various functionalities of MediaInfoLib (version(s): 26.01). All can lead to arbitrary code execution. An attacker can provide a malicious file to trigger these vulnerabilities.

Cisco Talos Blog – ​Read More

• Security teams need high-quality, labeled datasets to train threat hunters and incident responders, validate detection logic, and develop robust analytic models. 
• EvidenceForge helps teams overcome the limitations of anonymized or stale public datasets, while avoiding the cost and complexity of setting up real infrastructure and performing manual attack simulations to create their own.
• The tool incorporates sophisticated timing models and assigns specific roles to users and systems, generating realistic malicious activity, background noise, and “red herrings” to optimize data realism. 
• The tool generates correlated logs across 20+ Windows, Linux, and network monitoring formats using a canonical event model that ensures causal and temporal consistency.

Good data is hard to find… and to create

A lot of important work in security depends on having realistic log data to work with, and a lot of that work gets blocked, watered down, or quietly skipped because the data just isn’t available. The use cases come up constantly: teaching threat hunters, incident responders, and detection engineers with datasets that have known ground truth; validating that a detection fires on the right activity without drowning in false positives; and training ML models that need labeled, balanced, multi-source telemetry at scale.

These are different problems with the same root cause. You need realistic, labeled security logs and you can’t get them easily. The options are limited:

• Real production telemetry is a compliance problem. Public datasets are often so heavily anonymized they no longer resemble the original log sources. The LANL dataset and OpTC are well-known examples of data scrubbed to the point of being generic event representations rather than actual telemetry. What isn’t anonymized is stale, narrow, and over-recycled.
• You can generate data yourself using attack simulation frameworks like Atomic Red Team or MITRE Caldera, but that requires real infrastructure, is time-consuming to operate, and scales poorly when you need variety. 
• You can hire a red team, which trades complexity for money but still takes weeks and produces only the specific scenario they ran. 

Synthetic generators seem like an obvious solution and many existing ones are genuinely useful tools, but they share a common architectural limitation: They generate events independently, one format at a time, with no shared state across log sources. The result is datasets where events don’t tell a coherent story. For example, a process in Sysmon doesn’t connect to the same process in standard Windows logs, or a network logon doesn’t leave a consistent connection trace. More capable tools support attack chains and MITRE ATT&CK mapping, but even then, they generate individual events rather than simulating something that happened, with all the prerequisite and consequent evidence that real activity would produce. Realistic background noise is largely absent.

What analysts detect when they call data synthetic is the absence of a coherent causal story. The logs don’t line up because they emit each log entry independently from the others, and they are not modeling a series of connected events.

The answer: A new kind of synthetic data

EvidenceForge is a new open-source project from Cisco Talos that approaches the problem differently. It features a single canonical event model, causal ordering, realistic background noise, and AI-assisted scenario authoring. The result is a synchronized dataset across 20+ log formats (Windows, Linux, network, and endpoint detection and response [EDR] telemetry), complete with ground truth documentation and an analyst briefing.

One honest note: No purely synthetic dataset will fool a seasoned analyst in every case, but that’s okay. The goal is fidelity that’s good enough to be useful, not something that’s indistinguishable from production.

The core idea: One event, many formats 

Most synthetic log generators are a collection of independent emitters. Each one knows how to produce its own format but doesn’t share state with the others. You can see the seams the moment you cross-reference across sources. 

EvidenceForge inverts that. Every piece of evidence flows from a single canonical SecurityEvent object. That object carries a timestamp and event type, plus over 30 composable context objects populated as needed: ProcessContext (PID, parent PID, image, command line), NetworkContext (src/dst IP and port, Zeek UID, shared across Zeek, EDR, and SNORT®), AuthContext (username, LogonID, logon type, result), DnsContext and HttpContext (protocol-layer detail that fans out into the corresponding Zeek log types), and many more. Emitters read only the fields relevant to their format.

The consequence of shared contexts is that emitters cannot disagree. There is one PID, one LogonID, one timestamp, and one Zeek UID. The engine is also OS-aware: Windows hosts produce Security Events and Sysmon while Linux hosts produce syslog and bash history, each according to the OS assigned to each host in the scenario. 

All of this is driven by a scenario configuration file: a YAML document describing the environment (hosts, users, network topology) and an optional attack storyline. The engine reads that file and produces the correlated dataset. 

What the engine produces 

From a single scenario, EvidenceForge generates several correlated log formats:  

• Windows Security Events (30 event IDs covering authentication, process lifecycle, Kerberos, persistence, account management, and more) 
• Sysmon (10 event IDs) 
• EDR/XDR telemetry 
• Linux syslog 
• bash history 
• Zeek logs in JSON format 
• Snort IDS alerts 
• Firewall logs 
• Web server access logs 
• Forward HTTP proxy logs 

The exact output logs depend on a combination of the components in the simulated environment, and which log sources you may have opted to disable. 

Every attack scenario also produces two companion documents.  

• “ENVIRONMENT.md” is an analyst briefing consisting of organizational context, network layout, user roles, naming conventions — everything an analyst would need before diving into the logs, with zero information about the attack itself.  
• “GROUND_TRUTH.md” documents exactly what happened including a narrative, a timeline, and key IOCs. 

Causality, not just sequence 

Real logs are both temporally and causally ordered. Before a domain logon, there’s a Kerberos TGT, then a TGS. Before a TCP connection to a hostname, there’s a DNS query. This is the physics of how the protocols work.

EvidenceForge ships with a composable rule engine that auto-generates prerequisite events with realistic timing offsets so that each event sits exactly where an analyst would expect to pivot to it: 

• A logon in the scenario expands to the Kerberos exchange that made it possible. 
• A connection to a named host gets the DNS resolution inserted beforehand. 
• A privileged admin command generates downstream audit events. 

Network visibility is a first-class concept 

Most synthetic generators are too visible, meaning that every connection gets a log, regardless of whether a sensor would have seen it. Real networks don’t work that way. Traffic between hosts on the same VLAN may never cross a SPAN port. East-west traffic in a segmented network may be invisible to perimeter sensors. A TAP at the internet edge sees outbound traffic but nothing internal. 

EvidenceForge lets you declare sensor placement in the scenario: SPAN or TAP, monitored segments, and direction. The engine determines which connections each sensor could realistically observe and only emits network logs where they’d actually appear. If your environment has a monitoring gap, the generated data has that same gap, which is exactly the kind of thing analysts need to learn to reason about.

AI co-develops the story; a script generates the evidence 

The hard part of realistic synthetic data is scenario design, not generation. Describing a coherent attack lifecycle with the right tactics, techniques, and procedures (TTPs); realistic sequencing; and plausible actor behavior requires research and protocol knowledge most people don’t carry in their heads.

EvidenceForge addresses this with Claude/Codex skills. You bring intent (an attack type, an environment, a training objective), the AI brings research and technical scaffolding (a guided interview, MITRE ATT&CK TTP research), and together you collaboratively develop the attack narrative, resulting in a validated YAML scenario file.

The YAML is version-controllable, shareable, and editable. Once it exists, generation is entirely deterministic: a Python script reads the config and produces all the correlated log evidence.

This separation is the optimal balance of what each technology is good at. AI excels in narrative coherence, TTP research, and protocol knowledge. A deterministic script excels at the thousands of cross-referenced field values, causal prerequisite chains, and inter-format consistency checks that make up a realistic dataset. This would overwhelm even a capable LLM at scale, and hallucinated field values or subtle inconsistencies would undermine the whole point.

A typical scenario costs pennies in API calls to co-develop, and the data generates in seconds or minutes rather than the hours or days an LLM-based approach would require. EvidenceForge also produces identical output every run because randomness is seeded. Built-in validation checks the scenario for schema correctness and cross-reference integrity before generation runs, and the AI can automatically fix most errors it finds.

Making the background convincing 

Attack events are only useful if analysts have to work to find them. Noise quality matters as much as signal quality. 

EvidenceForge’s baseline engine generates several types of realistic background noise, including: 

• Legitimate lateral movement patterns (backup agents, monitoring tools, AD replication, application-to-database traffic) 
• User and application-driven network activity (web browsing, SMB file share access, RDP sessions, scheduled service polling) 
• Per-user diversified command pools, depending on user role 
• Red herrings (suspicious-looking events or patterns that are benign) 

Timing is just as important as content. Volume-level realism without burst-level texture still looks synthetic. EvidenceForge uses three complementary timing models:

• A Hawkes process for user activity, a self-exciting model where each event makes the next more likely for a short window, then decays, matching how people actually work in bursts
• A periodic envelope for large-scale structure (Monday login storms, Friday drop-off, and near-zero weekends)
• Periodic intervals plus jitter for modelling recurring automated events like scheduled tasks, background updates, and other system and service traffic 

Most timing details are exposed in the scenario or engine config files, so you can tweak them to make them as realistic as you like for your simulated environment. 

Getting started 

EvidenceForge is available on GitHub. Clone the repo and follow the install instructions in the README. 

The core experience is a guided conversation. Start the /eforge:scenario command and describe what you want. You can be as specific or as vague as you like. Bring a fully formed scenario and the AI helps translate it into a valid configuration; bring a rough idea and it asks the right questions, fills in the gaps, and makes suggestions until you have something technically coherent and satisfyingly realistic. From there, the skill leads you through validation, generation, and a brief automated data quality evaluation. You come out the other end with a complete, correlated dataset and companion documents. A full CLI is also available for scripted workflows.

What will you build? 

EvidenceForge removes the data bottleneck. The question becomes what you do with that. The following are just a few examples: 

• Build a SOC analyst training program with scenarios tailored to your environment. 
• Test detections against controlled, labeled datasets before they go near production. See whether they fire on the attack and how they behave against realistic noise.
• Generate the labeled training data your ML model needs.  
• Stress-test a new SIEM or detection pipeline against volume and variety you control. 
• Create repeatable practice exercises that can be regenerated on demand after tuning.

The scenarios themselves are shareable artifacts. A scenario developed for one team can be shared, adapted, or built on by others. The right mental model is high-fidelity training and testing data — not a production telemetry substitute — but within that framing, the use cases are broad.

Cisco Talos Blog – ​Read More

May 2026 showed how fast routine business activity can turn into real security exposure. ANY.RUN observed phishing campaigns, fileless malware delivery, credential theft, OTP interception, and remote access abuse targeting organizations across industries. 

From fake invitations and banking portals to compromised B2B websites and Word Online lures, the month’s attacks had one thing in common: they were built to look normal long enough to delay detection. 

Here are the major attacks from May and what SOC teams should take away from them. 

Key Business Risks That Stood Out in May Attacks 

The most important lesson from May’s attacks is that many of these campaigns were designed to hide inside normal business activity long enough to create real exposure. 

• Phishing turned into direct access risk: May campaigns did not stop at fake login pages. They led to credential theft, OTP interception, remote access tool installation, and possible account takeover. 
• Trusted workflows became attack paths: Fake invitations, Word Online pages, banking portals, legitimate B2B websites, and RMM tools helped attackers lower suspicion and delay detection. 
• Fileless and browser-based techniques reduced visibility: Blob-generated pages, injected scripts, PowerShell execution, and in-memory payloads made some attacks harder to catch with traditional file or network-based controls. 
• Credential theft created broader business exposure: Stolen email, browser, banking, and session data can open the door to BEC, fraud, SaaS compromise, supplier risk, and lateral movement. 
• Delayed certainty became the biggest SOC problem: When teams cannot quickly confirm whether access was stolen, remote access was installed, or C2 activity happened, response slows and business risk grows. 

Main Targets in May Attacks 

May’s campaigns were concentrated around the business functions and user groups that attackers can use to reach valuable accounts, financial workflows, and internal systems. For CISOs, this helps show where security reviews, detection coverage, and response playbooks should be prioritized first. 

1. Routine Invitations Created High-Impact Access Risk for U.S. Organizations 

In May, ANY.RUN tracked a fake invitation phishing campaign targeting U.S. organizations. The attack used familiar event-style lures to guide users through what looked like a normal invitation flow. Behind that flow, attackers could move victims toward credential theft, OTP interception, and in some cases remote access tool delivery. 

Check detailed breakdown 

This campaign shows how a simple business interaction can turn into an access incident. The user does not need to open an obviously malicious file or interact with a suspicious-looking page. They only need to follow an invitation that feels familiar. From there, the risk can expand from one employee action to exposed credentials, compromised mailboxes, unauthorized remote access, and wider business exposure. 

CISO priority: Security leaders should treat fake invitation flows as more than phishing noise. These attacks test whether the SOC can connect email, browser, identity, and remote access signals fast enough to understand real exposure. ANY.RUN helps teams safely open the full flow, observe credential and OTP collection, identify possible remote access tool delivery, and pivot to related infrastructure before the same campaign reaches more users. 

2. Business Document Lures Put LATAM Enterprises at Credential Theft Risk 

ANY.RUN also analyzed an Agent Tesla campaign targeting enterprises in Latin America. The attack used familiar business-document themes, including purchase orders, invoices, payroll files, and procurement requests, to reach employees who regularly work with external files and supplier communication. 

Check detailed breakdown 

This type of attack goes after the business functions where one stolen credential can quickly create financial and operational exposure. If attackers gain access to email accounts, browser credentials, FTP logins, or other stored data, the risk can move beyond one infected endpoint. It can support BEC, supplier fraud, cloud account compromise, and wider access across company systems. 

Business risk to reduce: Finance, procurement, and payroll inboxes should be treated as high-risk business entry points. A suspicious invoice or purchase order is not only an attachment problem; it may be the first sign of credential theft that can later support fraud or unauthorized access. With behavior-based sandbox analysis, teams can quickly confirm whether a file executed, what data it tried to collect, and which accounts need immediate protection. 

3. Compromised B2B Websites Turned Trusted Browsing into Fileless Malware Risk 

May also showed how legitimate B2B websites can be abused to deliver malware without relying on obvious malicious files. In this activity, attackers used compromised websites and injected scripts to move users toward PowerShell execution, in-memory payload delivery, and outbound C2 communication. 

Check technical details on X 

This is dangerous as the attack starts from a place employees may already trust. The website can look legitimate, the traffic may not stand out at first, and the malicious activity becomes clearer only later in the chain. For enterprises, that means a normal browsing session can turn into fileless execution before the SOC has enough evidence to react. 

Detection gap to close: This is where reputation-based controls are not enough. A known business website can still become part of the attack chain, and fileless execution may leave fewer obvious artifacts for Tier 1 teams to catch. ANY.RUN gives analysts a way to see what happens after the page loads: script behavior, PowerShell activity, memory execution, process injection, and C2 communication. That turns a suspicious browsing event into a response-ready case. 

4. OTP Phishing Showed How Fast Financial Access Can Be Weaponized 

ANY.RUN tracked a large-scale phishing campaign impersonating a U.S. financial institution. The campaign used a multi-step flow to collect usernames, passwords, OTP codes, and email verification data. Its infrastructure was also highly reusable, with hundreds of related phishing domains already identified. 

Check technical details on X 

This attack highlights a dangerous shift: MFA does not remove phishing risk when attackers can intercept OTPs in real time. Once users submit credentials and verification codes, attackers can move closer to account takeover, fraud, and unauthorized access before security teams have a clear picture of what happened. 

For enterprises, the lesson goes beyond one banking-themed campaign. Any organization that relies on login codes, email verification, or user-driven authentication flows needs to understand where those flows can be copied, replayed, or abused. 

MSSP priority: The priority is to move from single-alert handling to campaign-level detection. Blocking one domain will not stop an operation built on reusable templates and rotating infrastructure. ANY.RUN Threat Intelligence helps MSSPs connect related phishing pages, infrastructure, and recurring artifacts, so teams can prove whether authentication data was exposed and help clients act before stolen access becomes fraud or account takeover. 

5. Fake Word Online Lures Turned Document Access into Remote Control 

Another May attack started with an Outlook email and redirected users to a fake Word Online / OneDrive-style page. Instead of pushing an obvious malware download, the chain moved through software installation stages and eventually led to remote access through ScreenConnect, with additional activity used to hide the installed tools. 

Check technical details on X 

This is the kind of attack that creates real confusion inside security operations. On the surface, the user is trying to open a business document. Deeper in the chain, the attacker is setting up remote access through tools that may look similar to normal IT or support activity. 

For MSSPs, this is especially dangerous as one alert may not immediately look like a full compromise. A fake document page, a silent installer, an RMM tool, and concealment activity may appear as separate weak signals unless the team can connect them fast. 

Access question for leaders: This attack should push CISOs and MSSPs to ask a harder question: not “Did malware run?” but “Did someone gain hands-on access to the environment?” Remote access abuse is dangerous because it can look close to legitimate IT activity while giving attackers a path back into the network. Teams should expose the full chain from phishing page to installer behavior, RMM deployment, concealment activity, and follow-on access signals to can contain the access path before it becomes persistence. 

6. BlobPhish Exposed a Blind Spot in Browser-Based Credential Theft 

May also brought attention to BlobPhish, a credential-phishing campaign targeting Microsoft 365, major U.S. financial institutions, and webmail services. Instead of loading a phishing page in the usual way, the attack generated the page directly inside the browser using blob objects, keeping the malicious content in memory. 

Check technical details on X

 This matters as many phishing defenses still depend on what can be seen in the email, URL, or network request. BlobPhish weakens that visibility. The page can appear after the browser builds it locally, which makes the attack harder to judge using traditional signals alone. 

For CISOs, this creates a dangerous gap between what the user experiences and what the security stack can clearly prove. For MSSPs, it raises the investigation burden across clients: teams need to understand not only where the user clicked, but what the browser created after the click. 

Visibility gap to close: BlobPhish shows why phishing response cannot stop at URL checks. The real danger is the gap between what the user sees in the browser and what security teams can prove afterward. ANY.RUN allows teams to reproduce the browser-side flow safely, observe how the phishing page is generated, and capture the credential-theft behavior that may not be visible through standard inspection alone. For CISOs and MSSPs, this closes a critical evidence gap before stolen accounts turn into BEC, SaaS compromise, or client-wide exposure. 

Give Your SOC the Visibility May’s Attacks Demand with Enterprise Suite 

May’s attacks made one thing clear: the earliest signs of compromise are often hidden inside normal workflows. A user follows an invitation, opens a supplier file, visits a trusted website, enters an OTP, or previews a document, and the SOC may only see scattered signals until the risk has already moved forward. 

That is where ANY.RUN Enterprise Suite gives security leaders stronger control. Teams get full sandbox functionality, private analyses, multi-platform analysis across Windows, macOS, Linux, and Android, advanced privacy controls, SSO, team management, API access, workspace analytics, and TI Lookup & YARA Premium to validate threats faster and investigate sensitive cases without losing visibility or control. 

With these capabilities, enterprise teams can: 

• Reduce investigation delays by safely analyzing suspicious files, URLs, scripts, and phishing flows in real time. 
• Confirm business exposure faster by seeing whether credentials, OTPs, remote access tools, C2 traffic, or fileless execution were involved. 
• Protect sensitive investigations with private analyses, advanced privacy controls, SSO, and team-based access. 
• Improve SOC efficiency with shared workflows, workspace analytics, API access, and full task history. 
• Strengthen detection coverage with TI Lookup & YARA Premium to connect related infrastructure, IOCs, and attack patterns. 
• Support enterprise-scale response with longer VM timeout and analysis across major operating systems. 

ANY.RUN’s 10th-anniversary special offers are available until May 31, making this a timely opportunity for SOCs, MSSPs, and enterprise security teams to expand threat analysis and intelligence capabilities, reduce investigation delays, and respond with more confidence.

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps SOC, MSSP, and enterprise security teams detect threats earlier, and investigate incidents faster. 

With its Interactive Sandbox, Threat Intelligence Lookup, TI Feeds, and YARA Search, ANY.RUN gives teams the visibility they need to analyze suspicious files, URLs, scripts, phishing pages, and malware behavior in real time. Security teams can safely observe full attack chains, extract IOCs, investigate related infrastructure, and turn unclear alerts into evidence they can act on. 

Trusted by more than 15,000 organizations and 600,000 security professionals worldwide, ANY.RUN supports faster triage, stronger threat visibility, and more confident response across modern SOC workflows. 

The post Major Cyber Attacks in May 2026: Fake Invitations, Agent Tesla, BlobPhish, and More appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Imagine handing your smartphone over for repair. A couple of days later, you pick it up — and great, it’s working again! But you won’t even realize that your device has been injected with malicious code, allowing attackers to access your smartphone even when it’s locked.

This is the beginning of the story shared by Kaspersky ICS CERT researchers, Alexander Kozlov and Sergey Anufrienko, at the Black Hat Asia 2026 conference. They managed to uncover a vulnerability that flips conventional assumptions about smartphone and IoT security on their head. Its core lies at the very heart of Qualcomm chips.

What is BootROM?

To grasp the severity of this discovery, we first need to look at how a modern device powered by a Qualcomm chip boots up. Think of it as a fortress with multiple layers of security. Each subsequent layer verifies the pass issued by the previous one. The bedrock foundation — the most trusted layer of them all — is the BootROM, a read-only memory baked directly into the silicon that can’t be modified once it comes off the fab.

The BootROM is the very first thing to run when a device powers on. It verifies the signature of the next bootloader, which in turn verifies the next, building a chain of trust all the way up to the operating system. If an attacker can compromise this chain at the BootROM level, it’s game over: the malicious code will execute before the main operating system even has a chance to load.

This is exactly what attackers can do by exploiting the CVE-2026-25262 vulnerability discovered by Kaspersky ICS CERT researchers.

Emergency Download Mode as an entry point

The research began with a protocol called Sahara. This is a component of Emergency Download Mode (EDL). Manufacturers and service centers use it to revive bricked devices: the phone is connected to a computer via USB, and a special utility program signed by the manufacturer (in this case, Qualcomm) is uploaded to it.

Sahara is implemented directly within the ARM PBL (Primary Boot Loader) — the BootROM itself. This means the protocol runs before any operating system boots, before any user access privileges are checked, and before any security controls are activated. The device simply waits for a USB connection, ready to accept data.

The communication scheme looks simple: the device sends a handshake (HELLO) to the computer, the computer selects the mode, a cycle begins to upload the utility program in chunks, and finally, the device executes the uploaded code. And it was within the verification logic of these very file chunks that the vulnerability was identified.

Write-what-where: the core of the vulnerability

In technical terms, the bug introduced by the developers is classified as CWE-123: Write-What-Where Condition. This is about as bad as it gets when it comes to flaws in low-level programming. An attacker can write arbitrary data to an arbitrary address in the device memory.

Without diving too deep into the technical weeds, suffice it to say that by exploiting the discovered vulnerability, attackers can gain access to any data on the device, including user-entered passwords, files, contacts, geolocation data, as well as the hardware sensors like the camera and microphone. In certain scenarios, complete control over the device is possible. Just a few minutes of physical access to the device via a cable connection, and the gadget has been compromised. This creates a risk if you hand your smartphone over to a repair shop, pass it to someone else to set up and install apps on, or just leave it unattended.

Which devices are affected

The CVE-2026-25262 vulnerability affects the following Qualcomm chip series: MDM9x07, MDM9x45, MDM9x65, MSM8909, MSM8916, MSM8952, and SDX50 — every single version released to date, until the vulnerability is patched by the manufacturer.

These are no obsolete museum pieces. The MDM9207, which we used for the bulk of our research, is integrated into modem modules for the internet of things (IoT), industrial equipment, smart home devices, healthcare monitoring systems, logistics trackers, and banking terminals. The MSM8916 powers many budget smartphones, while the SDX50 is used in automotive control units.

How vulnerable devices get attacked

The catch is that the attacker needs physical access to the device to pull this off. In the real world, this translates to:

• Smartphone repairs at third-party repair shops, where the phone is left for several hours
• Customs checkpoints in certain countries, where devices are withheld, inspected, and then returned
• Lost and found scams, where your phone is stolen, tampered with, and then mysteriously found
• Corporate espionage via an insider or a rogue employee

With just a few minutes of physical access to the device an attacker can plant a backdoor so deep inside that standard research tools won’t even detect it in most cases.

Why there’s no patch — and what to do

Qualcomm was notified of the discovery in March 2025 and confirmed the vulnerability in its chips. To identify it, the vendor reserved CVE-2026-25262, and on April 20, 2026, Kaspersky ICS CERT published technical information on the vulnerability and recommendations for users.

Qualcomm included this vulnerability in its May security bulletin. While fixing already-made devices is fundamentally impossible, the company promised to make all future chips without this vulnerability.

If you currently own a device with an affected chip, use our recommendations below to help mitigate the risk of infection.

• Enforce strict physical control: don’t leave your devices unattended, especially when traveling or on business trips.
• Choose only authorized service centers for repairs and maintenance.
• Regularly update your firmware — this won’t patch the BootROM vulnerability, but it can eliminate many related vulnerabilities at higher levels.
• Use a Kaspersky for Android on your device. This will safeguard your gadget from other threats that, combined with this vulnerability, could lead to unpredictable consequences.

If you notice that your gadget with a vulnerable Qualcomm chip starts acting up — overheating when idle, reporting unexpected spikes in network traffic, or exhibiting strange app behavior — you may have fallen victim to this vulnerability. You can wipe the malicious code and reset your device to its baseline state simply by completely cutting its power. This means either pulling the battery or letting it drain all the way to zero until the gadget shuts down entirely. In this case, the malicious code will most likely not persist on the device — during our research, we were unable to confirm that it could achieve persistence in non-volatile memory.

Want to learn more about severe vulnerabilities in Android phones? Check out these posts:

• Attacks on 5G networks: the arms race continues
• Are geolocation services spying on you?
• Pixnapping vulnerability: unblockable screenshots of your Android phone
• Data theft during smartphone charging
• Trojan embedded in fake Android smartphones

Kaspersky official blog – ​Read More