In this episode, we unpack state-sponsored and phishing trends from the 2025 Talos Year in Review. Amy and Martin Lee explore the alarming rise of internal phishing campaigns that bypass traditional perimeter defenses, including the widespread weaponization of Microsoft 365’s Direct Send feature. Beyond simple phishing, we analyze the aggressive, blended operations of state-sponsored actors from China and North Korea who are combining high-level zero-day exploits with sophisticated social engineering. From the “Dear Leader” interview test to the reality of fake developer personas, we break down exactly how these adversaries are infiltrating modern organizations.

View the 2025 Year in Review here.

Cisco Talos Blog – ​Read More

• As macOS adoption grows among developers and DevOps, it has become a high value target; however, native “living-off-the-land” (LOTL) techniques for the platform remain significantly under-documented compared to Windows. 
• Adversaries can bypass security controls by repurposing native features like Remote Application Scripting (RAS) for remote execution and abusing Spotlight metadata (Finder comments) to stage payloads in a way that evades static file analysis. 
• Attackers can move toolkits and establish persistence using built-in protocols such as SMB, Netcat, Git, TFTP, and SNMP operating entirely outside the visibility of standard SSH-based telemetry. 
• Defenders should shift from static file scanning to monitoring process lineage, inter-process communication (IPC) anomalies, and enforcing strict MDM policies to disable unnecessary administrative services.

As macOS adoption in the enterprise reaches record highs, with over 45 percent of organizations now utilizing the platform, the traditional “security through obscurity” narrative surrounding the OS has been rendered obsolete. Mac endpoints, once relegated to creative departments, are now the primary workstations for developers, DevOps engineers, and system administrators. Consequently, these machines have become high-value targets that serve as gateways to source code repositories, cloud infrastructure, and sensitive production credentials. 

Despite this shift, macOS-native lateral movement and execution tradecraft remain significantly understudied compared to their Windows counterparts. This research was conducted to address this critical knowledge gap. Through a systematic validation of native macOS protocols and system binaries, it is demonstrated how adversaries can “live off the land” (LOTL) by repurposing legitimate administrative tools. By weaponizing native primitives, such as Remote Application Scripting (RAS) and Spotlight metadata, intentional OS security features can be bypassed to transform standard system functions into robust mechanisms for arbitrary code execution and fleet-wide orchestration.

The macOS enterprise blind spot 

macOS is no longer a niche operating system. According to the Stack Overflow 2024 Developer Survey, a third of professional developers use macOS as their primary platform. These machines represent high-value pivot points, often holding source code repositories, cloud credentials, and SSH keys to production infrastructure. 

Despite this trend, the MITRE ATT&CK framework documents far fewer techniques for macOS than for Windows, and recent industry reports indicate that macOS environments prevent significantly fewer attacks than their Windows or Linux counterparts. To address this disparity, community-driven resources such as LOOBins (living-off-the-orchard binaries) have emerged to catalog native macOS binaries that can be repurposed for malicious activity. This research aims to further close that gap by systematically enumerating the native pathways available for both movement and execution.

Remote command execution: Weaponizing native primitives 

Establishing a remote shell is the first step in any post-exploitation chain. While SSH is the standard, native macOS features provide several alternatives that can bypass traditional monitoring. 

Remote Application Scripting as a Software Deployment Tool (T1072) 

Remote Application Scripting (formerly known as Remote Apple Events or RAE) was introduced to extend the capabilities of the AppleScript Inter-Process Communication (IPC) framework across a network. By utilizing the Electronic Program-to-Program Communication (“eppc”) protocol, administrative tasks and application automation can be performed on remote macOS systems. This mechanism allows a controller machine to send high-level commands to a target machine, which are then processed by the “AppleEventsD” daemon. 

The Open Scripting Architecture (OSA) is utilized as the standardized framework for this inter-application communication and automation on macOS. Through the exchange of Apple Events, this architecture enables scripts to programmatically interact with the operating system and installed applications, providing the functional foundation for the “osascript” utility. 

Traditionally, RAE is viewed as a lateral movement vector; however, this research demonstrates that it can also be utilized as a standalone Software Deployment Tool for Execution (T1072). 

Adversaries attempting to use RAE for complex payloads often encounter Apple’s intentional security features, specifically the -10016 Handler Error. This restriction prevents the “System Events” application from executing remote shell commands via do shell script, even when RAE is globally enabled.

To bypass this, a methodology was developed that treats “Terminal.app” as an execution proxy. Unlike “System Events”, “Terminal.app” is designed for shell interaction and accepts remote “do script” commands. To ensure payload integrity and bypass AppleScript parsing limitations (such as the -2741 syntax error), Base64 transport encoding is utilized. This transforms multi-line scripts into flat, alphanumeric strings that are decoded and executed in a two-stage process: 

1. Deployment: A single RAE command instructs the remote “Terminal.app” to decode the Base64 string into a temporary path and apply chmod +x. 
2. Invocation: A second RAE command explicitly invokes the script via “bash”, ensuring a proper shell context.

Remote Application Scripting for Lateral Movement (T1021.005) 

While RAE can be weaponized for execution, its primary function remains the facilitation of inter-process communication (IPC) across a network. In a lateral movement context, RAE is utilized to control remote applications by targeting the “eppc://” URI. This allows for the remote manipulation of the file system or the retrieval of sensitive environmental data without the need for a traditional interactive shell. 

For example, the command in Figure 4 can be used to remotely query the Finder for a list of mounted volumes on a target machine, providing an adversary with immediate insight into the victim’s network shares and external storage:

Because these actions are performed via Apple Events rather than standard shell commands, they often bypass security telemetry that focuses exclusively on process execution trees, making RAE a discreet and effective vector for lateral movement.

AppleScript execution via SSH 

AppleScript is macOS’s built-in scripting language for automation. While RAE is a viable application control mechanism, Apple security controls prevent RAE from launching applications; they must already be running. Additionally, RAE must be enabled on the target. To circumvent these obstacles, osascript can be invoked directly over SSH. 
 
Passing osascript the system info command over SSH returns critical environmental details:

For arbitrary command execution, AppleScript’s do shell script handler can be invoked over SSH. In the following example, do shell script is used to write a file to the target:

While SSH alone can accomplish shell tasks, osascript provides access to graphical user interfact (GUI) automation and Finder manipulation through Apple Events IPC rather than spawning shell processes. This creates a significant telemetry gap, as most endpoint detection tooling has less visibility into IPC-driven actions than standard shell process trees.

socat remote shell 

socat (SOcket CAT) is a command line utility for establishing bidirectional data streams between two endpoints. It supports a wide range of socket types including TCP, UDP, Unix domain sockets, and pseudo terminals (pty). 

In a lateral movement context, socat can establish an interactive shell on a target without relying on SSH. The target runs a listener that binds a login shell to a TCP port with pty allocation, and the attacker connects to it from a remote machine. 

On the target, the listener spawns an interactive bash session for each incoming connection with pty forwarding:

From the attacking machine, connecting to the listener provides a fully interactive terminal: 

On the target, the reuseaddr,fork options allow multiple connections and reuse of the port, while pty,stderr on the exec gives the connecting client a proper terminal with stderr output. On the sender side, raw,echo=0,icanon=0 puts the local terminal into raw mode so that control characters and signals pass through to the remote shell correctly. 

SSH is the de facto mechanism for gaining remote shell access on remote hosts, and as a result, it is where most detection engineering efforts are focused. socat achieves the same outcome, fully interactive terminal access, but operatesentirely outside the SSH ecosystem. There are no sshd logs, PAM authentication events, or “authorized_keys” to manage, which means detection pipelines built around SSH telemetry would not catch this activity.

Covert data transfer: Finder metadata abuse 

A notable constraint of RAE is its inability to write file contents directly. To work around this, we can abuse the Finder Comment (“kMDItemFinderComment”) field, which is stored as Spotlight metadata. 

Writing payloads to Finder Comments 

A notable constraint of RAE is its inability to write file contents directly. To circumvent this, threat actors can abuse the Finder Comment field (“kMDItemFinderComment”) — a component of Spotlight metadata stored as an extended attribute. By storing a payload within metadata rather than the file’s data fork, they can bypass traditional file-based security scanners and static analysis tools, which typically focus on executable code and script contents. 

Because Finder is scriptable over RAE, the comment of a file on a remote machine can be set via the “eppc://” protocol. By Base64 encoding a payload locally, a multi-line script can be stored within this single string field. The make new file command handles the creation of the target file, ensuring that no pre-existing file is required:

The payload resides entirely within the Spotlight metadata, a location that remains largely unexamined by standard endpoint detection and response (EDR) solutions. This creates a stealthy staging area where malicious code can persist on the disk without triggering alerts associated with suspicious file contents. 

Extraction and execution 

On the target, extraction and execution is a single line. mdls reads the comment, base64 -D decodes it, and the result is piped to “bash”: 

Persistence via LaunchAgent 

This approach can be paired with a LaunchAgent for persistence. A plist in “~/Library/LaunchAgents” that executes the extraction chain at user login allows the payload to run automatically. 

Our initial attempt using mdls inside the LaunchAgent failed because Spotlight may not be fully initialized when LaunchAgents fire. The fix was to replace mdls with osascript calling Finder directly to read the comment:

Talos confirmed this successfully executes the payload at login. It is worth noting that macOS prompts the user to approve the bash execution at login, which is a visible indicator of background activity. The plist contains no payload, only a reference to metadata, so static analysis of the LaunchAgent would not reveal the malicious content. 

Lateral Tool Transfer techniques 

Once attackers achieve execution, they must move their toolkit across the environment. Several native protocols were validated for tool transfer (T1570). 

Standard protocols: SCP and SFTP 

SCP (Secure Copy Protocol) and SFTP (SSH File Transfer Protocol) are the most straightforward methods, operating over SSH and available out-of-the-box on any macOS system with Remote Login enabled.

SMB-based transfer 

Server Message Block (SMB) is a network file sharing protocol commonly associated with Windows environments, but macOS includes native support for both SMB client and server functionality. In a lateral movement context, an attacker can mount a remote SMB share and access its contents as if they were local files. 

This method of setting up an SMB share on the victim requires SSH access. The following command creates a shared directory, loads the SMB daemon, and creates the share.

With the share created, the next step is mounting it from the attacker machine. Attempting this action with the mount command failed due to an authentication error.

To resolve this issue, GUI access to the victim machine was required. On the victim machine, navigate to System Settings > General > Sharing > File Sharing > Options. Located here is the option to store the user’s account password on the computer. Even though this is labeled as “Windows File Sharing”, it was required to properly authenticate the user when using the mount utility. 

However, this entire GUI dependency can be avoided by using osascript to mount the share instead of mount:

This mounts the share to “/Volumes/share” without requiring the GUI configuration step. With the share mounted, any file copied into the mount directory appears on the victim immediately. 

Netcat-based transfer 

nc (netcat) is a well-known general-purpose networking utility that ships with macOS. It can be utilized to open arbitrary TCP and UDP connections, listen on ports, and pass data between them. 

The simplest pattern involves piping commands directly into a netcat listener. On the target, a listener is established that pipes incoming data directly to sh:

From the attacking machine, a command is then echoed into nc targeting the victim’s IP and port:

The attacker sends the curl google.com command over the wire, which is caught by the victim’s listener and executed by sh. The resulting output confirms successful execution on the target. 

Netcat can also facilitate file transfers through several different methods. An attacker could invoke a fetch to a remote system where a script or payload is hosted, or start a simple HTTP server on their own machine to perform ad hoc tool transfer.

Git-based transfer 

git is a version control system ubiquitous in software development. Its prevalence on developer machines and reliance on SSH as a transport make git push a practical file transfer mechanism. The technique requires initializing a repository on the target and setting receive.denyCurrentBranch updateInstead. By default, git refuses pushes to a branch that is currently checked out on the remote. This setting overrides that behavior and updates the working tree on push, landing files on disk the moment the operation completes. 

First, a receiving repository is initialized on the target over SSH:

On the attacker, a local repository is created with the payload, and the remote is pointed at the target:

After the push, “script.sh” exists on the target at “~/repos/project/script.sh”. Additional file transfers only require adding new files, committing, and pushing again. Because git operates over SSH, the transfer is encrypted and uses the same authentication established for command execution. 

TFTP (Standard and unprivileged) 

TFTP (Trivial File Transfer Protocol) is a lightweight, unauthenticated file transfer protocol that operates over UDP. macOS includes both a TFTP server and client. The server is not active by default but can be started through launchd. 

With root access on the target, the system’s built-in TFTP plist activates the server in a single command:

This serves “/private/tftpboot” on the standard TFTP port (UDP 69). The TFTP system plist does not provide the -w flag to the tftpd process. Without it, the server only allows writes to files that already exist. A placeholder file must be created on the target for each file being transferred:

From the attacker, the payload is pushed to the target: 

In a post-exploitation scenario without root access, tftpd can still be deployed by loading a user-created plist from “/tmp” on a non-standard port. This variant passes the tftpd -w flag, which allows write requests to create new files, removing the placeholder requirement. 

SNMP trap-based transfer 

SNMP (Simple Network Management Protocol) is used for monitoring and managing network devices. SNMP traps are unsolicited notifications sent from agents to a management station over UDP port 162. The trap payload can carry arbitrary string data under custom OIDs, which can be repurposed as a data transfer channel. macOS ships with the necessary net-snmp tools: snmptrap (“/usr/bin/snmptrap”) on the sender and snmptrapd (“/usr/sbin/snmptrapd”) on the receiver. 

The approach works by Base64 encoding a file, splitting it into fixed-size chunks, and sending each chunk as an SNMP trap payload under a custom OID in the private enterprise space (“1[.]3[.]6[.]1[.]4[.]1[.]99999”). A trap handler on the receiving end reassembles the chunks and decodes the file. The protocol uses three message types: “FILENAME” signals the start of a transfer, “DATA” carries a Base64 chunk, and “END” triggers reassembly. 

On the receiver, a trap handler processes incoming traps:

The snmptrapd daemon is then configured on the target to route all incoming traps to the handler and started in the foreground:

On the sender, a script handles the encoding, chunking, and transmission. Each chunk is sent as a separate SNMP trap with a short delay between sends to avoid overwhelming the receiver:

The sender initiates the transfer: 

The target receives the transfer:

The matching MD5 hashes confirm the file was transferred and reassembled intact. 

Socat file transfer 

The socat shell established in the above “socat remote shell” section can also serve as a file transfer channel. Because the listener provides a fully interactive bash session, file contents can be written to the remote host by injecting a heredoc through the connection. This means socat alone handles both remote command execution and tool transfer without requiring any additional services or listeners. 

With the socat listener running on the target, the attacker delivers a file by piping a heredoc-wrapped cat command through a socat connection:

Detection and defensive considerations 

Defending against LOTL techniques requires a shift from simple network alerts to granular process and metadata analysis. 

Network indicators 

Inbound TCP traffic on port 3031 (the “eppc” port) and unusual SNMP/TFTP traffic on internal LAN segments should be monitored for potential unauthorized activity. 

Endpoint indicators (EVM) 

Through mapping to the Open Cybersecurity Schema Framework (OCSF), an open-source effort to deliver a simplified and vendor-agnostic taxonomy for security telemetry, high-fidelity signatures for these behaviors were identified: 

• Suspicious lineage: Process trees following the pattern launchd -> AppleEventsD -> Terminal -> sh/bash. 
• Metadata monitoring: Frequent or unusual calls to mdls or writes to “com.apple.metadata:kMDItemFinderComment”. 
• Command line anomalies: base64 --decode commands originating from GUI applications or osascript executions containing “of machine “eppc://…”” arguments. 

Native security controls and hardening recommendations 

Several built-in macOS security mechanisms can be configured to mitigate the risks associated with native primitive abuse: 

• Transparency, Consent, and Control (TCC) restrictions: The “Automation” category within TCC is designed to regulate inter-application communication. By enforcing strict TCC policies via Mobile Device Management (MDM), unauthorized Apple Events between applications — such as a script attempting to control “Terminal.app” or “Finder” — can be blocked. 
• MDM Policy Enforcement: RAE and Remote Login (SSH) should be disabled by default across the fleet. These services can be managed and restricted using MDM configuration profiles (e.g., the “com.apple.RemoteAppleEvents”payload) to ensure they are only active on authorized administrative hosts. 
• Service hardening: Unnecessary network-facing services, such as tftpd and snmpd, should be explicitly disabled. The removal of these launchd plists from “/System/Library/LaunchDaemons” (where permitted by System Integrity Protection) or the use of launchctl disable commands prevents their use as ad-hoc data transfer channels. 
• Application firewall and Stealth Mode: The built-in macOS application firewall should be enabled and configured in “Stealth Mode.” This configuration ensures the device does not respond to unsolicited ICMP or connection attempts on common ports, reducing the visibility of the endpoint during internal reconnaissance. 

Conclusion 

The research presented in this article underscores a fundamental reality of modern endpoint security. The same primitives designed for administrative convenience and system automation are often the most potent tools in an adversary’s arsenal. By moving beyond traditional exploit-based attacks and instead LOTL, attackers can operate within the noise of legitimate system activity.

From the weaponization of the “eppc” protocol to the creative abuse of Spotlight metadata and SNMP traps, it is clear that the macOS attack surface is both vast and nuanced. These techniques demonstrate that even within a “walled garden” ecosystem, native pathways for movement and execution remain accessible to those who understand the underlying architecture. 

For defenders, the primary takeaway is that visibility remains the most effective deterrent. By shifting focus from static file analysis to the monitoring of process lineage, inter-process communication, and metadata anomalies, these “bad Apples” can be identified and neutralized. As macOS continues its expansion into the enterprise core, the documentation and detection of these native techniques must remain a priority for the security community. 

Cisco Talos Blog – ​Read More

DarkSword and Coruna are two new tools for invisible attacks on iOS devices. These attacks require no user interaction and are already being actively used by bad actors in the wild. Before these threats emerged, most iPhone users didn’t have to lose sleep over their data security. Protection was really only a major concern for a narrow group — politicians, activists, diplomats, high-level business execs, and others who handle extremely sensitive data — who might be targeted by foreign intelligence agencies. We’ve covered sophisticated spyware used against such a group before — noting how hard to come by those tools were.

However, DarkSword and Coruna — discovered by researchers earlier this year — are total game-changers. This malware is being used for mass infections of everyday users. In this post, we dive into why this shift happened, why these tools are so dangerous, and how you can stay protected.

What we know about DarkSword, and how it can target your iPhone

In mid-March 2026, three separate research teams coordinated the release of their findings on a new spyware strain called DarkSword. This tool is capable of silently hacking devices running iOS 18 without the user ever knowing something is wrong.

First, we should clear up some confusion: iOS 18 isn’t as vintage as it might sound. Even though the latest version is iOS 26, Apple recently overhauled its versioning system, which threw everyone for a loop. They decided to jump ahead eight versions — from 18 straight to 26 — so the OS number matches the current year. Despite the jump, Apple estimates that about a quarter of all active devices still run iOS 18 or older.

With that cleared up, let’s get back to DarkSword. Research shows that this malware infects victims when they visit perfectly legitimate websites that have been injected with malicious code. The spyware installs itself without any user interaction at all: you just have to land on a compromised page. This is what’s known as a zero-click infection technique. Researchers report that several thousand devices have already been hit this way.

To compromise a device, DarkSword uses a six-vulnerability exploit chain to escape the sandbox, escalate privileges, and execute code. Once it’s in, the malware harvests data from the infected device, including:

• Passwords
• Photos
• Chats and data from iMessage, WhatsApp, and Telegram
• Browser history
• Information from Apple’s Calendar, Notes, and Health apps

On top of all that, DarkSword lets attackers scoop up crypto-wallet data, making it essentially dual-purpose malware that functions as both a spy tool and a way to drain your crypto.

The only bit of good news is that the spyware doesn’t survive a reboot. DarkSword is fileless malware, meaning it lives in the device’s RAM, and never actually embeds itself into the file system.

Coruna: how older iOS versions are being targeted

Just two weeks before the DarkSword findings went public, researchers flagged another iOS threat dubbed Coruna. This malware is capable of compromising devices running older software — specifically iOS 13 through 17.2.1. Coruna uses the exact same playbook as DarkSword: victims visit a legitimate site injected with malicious code which then drops the malware onto the device. The whole process is completely invisible and requires zero user interaction.

A deep dive into Coruna’s code revealed it exploits a total of 23 different iOS vulnerabilities, several of which are tucked away in Apple’s WebKit. It’s worth reminding that, generally speaking (outside the EU), all iOS browsers are required to use the WebKit engine. This means these vulnerabilities don’t just affect Safari users — they’re a threat to anyone using a third-party browser on their iPhone as well.

The latest version of Coruna, much like DarkSword, includes modifications designed to drain crypto wallets. It also harvests photos and, in certain instances, email data. From what we can tell, stealing cryptocurrency seems to be the primary motive behind Coruna’s widespread deployment.

Who created Coruna and DarkSword — and how did they end up in the wild?

Code analysis of both tools suggests that Coruna and DarkSword were likely built by different developers. However, in both cases, we’re looking at software originally created by state-affiliated companies, possibly from the U.S. The high quality of the code points to this; these aren’t just Frankenstein kits cobbled together from random parts, but uniformly engineered exploits. Somewhere along the line, these tools leaked into the hands of cybercrime gangs.

Experts at Kaspersky’s GReAT analyzed all of Coruna’s components and confirmed that this exploit kit is actually an updated version of the framework used in Operation Triangulation. That earlier attack targeted Kaspersky employees, a story we covered in detail on this blog.

One theory suggests an employee at the company that developed Coruna sold it to hackers. Since then, the malware has been used to drain crypto wallets belonging to users in China; experts estimate that at least 42 000 devices were infected there alone.

As for DarkSword, cybercriminals have already used it to compromise users in Saudi Arabia, Turkey, and Malaysia. The problem is exacerbated by the fact that the attackers who first deployed DarkSword left the full source code on infected websites, meaning it could easily be picked up by other criminal groups.

The code also includes detailed comments in English explaining exactly what each component does, which supports the theory of its Western origins. These step-by-step instructions make it easy for other hackers to adapt the tool for their own purposes.

How to protect yourself from Coruna and DarkSword

Serious malware that allows for the mass infection of iPhones while requiring zero interaction from the user has now landed in the hands of an essentially unlimited pool of cybercriminals. To pick up Coruna or DarkSword, you simply have to visit the wrong site at the wrong time. So this is one of those cases where every user needs to take iOS security seriously — not just those in high-risk groups.

The best thing you can do to protect yourself from Coruna and DarkSword is to update your devices to the latest version of iOS or iPadOS 26, as soon as you can. If you can’t update to the newest software — for instance, if your device is older and doesn’t support iOS 26 — you should still install the latest version available to you. Specifically, look for versions 15.8.7, 16.7.15, or 18.7.7. In a rare move, Apple patched a wide range of older operating systems.

To protect your Apple devices from similar malware that will likely pop up in the future, we recommend the following:

• Install updates promptly on all your Apple devices. The company regularly releases OS versions that patch known vulnerabilities — don’t skip them.
• Enable Background Security Improvements. This feature allows your device to receive critical security fixes separately from full iOS updates, reducing the window for hackers to exploit vulnerabilities. To enable it, go to Settings → Privacy & Security → Background Security Improvements and turn on the Automatically Install
• Consider using Lockdown Mode. This is a heightened security setting that limits some device features but simultaneously blocks or significantly complicates attacks. To enable this, go to Settings → Privacy & Security → Lockdown Mode → Turn On Lockdown Mode.
• Reboot your device once a day (or more). This stops fileless malware in its tracks, since these threats aren’t embedded in the system and disappear after a restart.
• Use encrypted storage for sensitive data. Keep things like crypto wallet keys, photos of IDs, and confidential info in a secure vault. Kaspersky Password Manager is a great fit for this; it manages your passwords, two-factor authentication tokens, and passkeys across all your devices while also keeping your notes, photos, and docs synced and encrypted.

The idea that Apple devices are bulletproof is a myth. They’re vulnerable to zero-click attacks, Trojans, and ClickFix infection techniques — and we’ve even seen malicious apps slip into the App Store more than once. Read more here:

• Predator vs. iPhone: the art of invisible surveillance
• AirBorne: Attacks on Apple devices through vulnerabilities in AirPlay
• Are your Bluetooth headphones spying on you?
• SparkCat trojan stealer infiltrates App Store and Google Play, steals data from photos
• Banshee: A stealer targeting macOS users

Kaspersky official blog – ​Read More

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed one Foxit Reader vulnerability, and six LibRaw file reader vulnerabilities.

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all 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.

Foxit use-after-free vulnerability

Discovered by KPC of Cisco Talos.

Foxit Reader allows users to view, edit, and sign PDF documents, among other features. Foxit aims to be one of the most feature-rich PDF readers on the market, and contains many similar functions to that of Adobe Acrobat Reader.

TALOS-2026-2365 (CVE-2026-3779) is a use-after-free vulnerability in the way Foxit Reader handles an Array object. A specially crafted JavaScript code inside a malicious PDF document can trigger this vulnerability, which can lead to memory corruption and result in arbitrary code execution. An attacker needs to trick the user into opening the malicious file to trigger this vulnerability.

LibRaw heap-based buffer overflow and integer overflow vulnerabilities

Discovered by Francesco Benvenuto of Cisco Talos.

LibRaw is a library and user interface for processing RAW file types and metadata created by digital cameras. Talos analysts found 6 vulnerabilities in LibRaw.

TALOS-2026-2330 (CVE-2026-20911), TALOS-2026-2331 (CVE-2026-21413), TALOS-2026-2358 (CVE-2026-20889), and TALOS-2026-2359 (CVE-2026-24660) are heap-based buffer overflow vulnerabilities in LibRaw, and TALOS-2026-2363 (CVE-2026-24450) and TALOS-2026-2364 (CVE-2026-20884) are integer overflow vulnerabilities. Specially crafted malicious files can lead to heap buffer overflow in all cases. An attacker can provide a malicious file to trigger these vulnerabilities.

Cisco Talos Blog – ​Read More