Zero Day Initiative

As we ramp up to the premier automotive and charging station hacking competition, Pwn2Own Automotive 2026 in Tokyo, the Trend Micro Zero Day Initiative (ZDI) is providing a preliminary look at one of the main targets: the Alpitronic HYC50 High-Power Charger.

The HYC50 series represents the leading edge of fast-charging infrastructure, blending complex high-voltage power electronics with a robust, networked digital control system. For Pwn2Own contestants, the digital attack surface is often the most accessible path to a top-tier bounty. This post serves as a hardware identification primer, guiding researchers through the core components that make up the device's control and low-voltage sections.

This is strictly a hardware reconnaissance report. We encourage all participants to begin their deep-dive analysis ahead of the contest.

Section 1: The Development Hardware Enclosure

Participants in Pwn2Own Automotive 2026 will be provided with a modified hardware setup to simplify the research process. This setup isolates the low-voltage control and digital boards from the high-voltage power stack, allowing for safer and more focused analysis.

The following image shows the custom enclosure housing the core digital and communication components extracted from the larger HYC50 unit.

The low-voltage control and digital stack mounted in the custom development case. Note the external power inputs and clearly labeled network ports for easy connectivity.

This case contains the primary application processor, communication interfaces (Ethernet, CAN), and critical memory components that govern the charger's operation, payment, and network connectivity.  Additionally, you will find the touchscreen and NFC interfaces readily accessible on the front of the case.

Section 2: Core Digital Control Board (DCB)

The central brain of the Alpitronic HYC50 is the main digital control board. This PCB is responsible for managing the charger's state machine, handling OCPP (Open Charge Point Protocol) communication, managing user authentication, and orchestrating the power modules.  The main application processor and its memoires reside on a customized System On a Module (SOM) that attaches to the main board via a 200 pin SO-DIMM header. We’ll discuss the SOM specifically in the next section.

Top of the main Digital Control Board (DCB)

Bottom of the main Digital Control Board (DCB)

The DCB features several key components of interest to security researchers:

Close-up of the PLC controller

Ethernet interfaces for accessing the management interface

The SOM residing on the DCB along with the LCD and COMM board interfaces. Note the 4-pin header marked “CON_SOM_UART” in the upper left corner of the picture.

The local MPU (STM32G0B1) and possible test ports (missing conformal coating)

Section 3: SOM

The main processing components of the charger reside on a 208-pin module that is plugged into the DCB.  The module is custom, however it is heavily based on the VAR-SOM-6UL design produced by Variscite.   It is a variant that contains an eMMC device but appears to be lacking the Wi-Fi devices that a standard VAR-SOM-6UL is advertised with.  That’s not surprising because the radio functions of the charger are handled by a separate board.  Thus, it is very possible that this “custom” SOM is simply a cost-reduced version with some unneeded parts de-populated from the off-the-shelf version.

Top and Bottom views of the SOM (System On a Module)

The custom SOM features several key components of interest to security researchers:

Main top side components. i.MX6 and DDR memory

Main bottom side component. SanDisk eMMC memory

Section 4: Communication Board (COMM)

The HYC50 relies on several interfaces for communication, and much of that capability is housed on the COMM board attached to the door of the enclosure.  This board is connected to the DCB through the single large connector. There appear to be two 4G LTE radios and they share the same antenna.  Two SIM card slots exist, possibly to support those radios.  There’s a third radio module that’s likely providing the Wi-Fi and Bluetooth functions on its separate antenna.  Thereis also a USB port, but it is not accessible from the outside of the enclosure.   Finally, this board appears to interface to the screen’s touch function while the display appears to fed by the DCB directly.  In addition to the board pictures, a picture of its arrangement in the charger’s enclosure will be included for clarity.

Top side of the communication board (COMM) showing two 4G LTE  controllers

Bottom side of the COMM board

HYC50 enclosure door layout

The COMM board  features several key components of interest to security researchers:

The 4G LTE module (lower left) and the Wi-Fi/BT module (upper right)

Section 5: Additional Observations

1)  The HYC50 is a mature product with documentation available online.  Do not neglect to search for documents that might assist your effort.  Installation and operational manuals exist in various locations.

2)  If you are one of the few who were approved to receive a development case for research, please be aware that these are custom, hand-built, experimental devices.  Before powering up, look/listen for any fasteners that may have come loose during shipping.   Correct those before applying power to the unit to avoid damage.

Conclusion

The Alpitronic HYC50 offers a rich and complex target for Pwn2Own researchers. This preliminary look identifies the core digital components, memory, and — crucially — the physical debug and manufacturing interfaces that may be leveraged for the contest.

We look forward to seeing the innovative research that will be brought to bear on the HYC50 at Pwn2Own Automotive 2026. Happy hunting, and may the bounty be ever in your favor!

Follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches and visit the Pwn2Own Automotive 2026 page for rule updates and bounty lists.

In our previous Kenwood DNR1007XR blog, we detailed the internals of the Kenwood in-vehicle infotainment (IVI) head unit and provided annotated pictures of the main PCB. In this post, we aim to outline the attack surface of the DNR1007XR in the hopes of providing inspiration for vulnerability research.

We will cover the main supported technologies that present potential attack surfaces, such as USB, Bluetooth, Android Auto, Apple CarPlay, Kenwood apps, and more.

All information has been obtained through reverse engineering, experimenting, and combing through the following resources:

·      DNR1007XR product page
·      DNR1007XR instruction manual
·      DNR1007XR quick start guide
·      Kenwood Portal app
·      Kenwood Remote S app

USB

The DNR1007XR is equipped with a single USB-A port that operates at USB 2.0 speeds, providing the necessary interface for wired Android Auto and Apple CarPlay.

The USB port also supports playback of audio files from a USB flash drive. The supported audio filetypes and their associated extensions are:

·      MP3 (.mp3)
·      WMA (.wma)
·      AAC-LC (.m4a)
·      WAV (.wav)
·      FLAC (.flac, .fla)
·      Vorbis (.ogg)
·      DSD (.dsf, .dff)

As well as audio, a USB flash drive can also be used to play back video files. The supported video filetypes and their associated extensions are:

·      MPEG-1 (.mpg, .mpeg)
·      MPEG-2 (.mpg, .mpeg)
·      H.264 / MPEG-4 (.mp4, .m4v, .avi, .flv, .f4v)
·      WMV (.wmv)
·      MKV (.mkv)

Robustly parsing and decoding these file formats is notoriously complicated and error-prone, which makes for a potentially rewarding attack surface.

USB flash drives must be formatted as either FAT16, FAT32, exFAT, or NTFS for the head unit to be able to read them.

SD Card

A full-sized SD card slot is tucked away behind the screen and is used for audio/video playback as well as updating map data. As previously mentioned, a large attack surface is exposed when parsing audio and video files. Map updates are likely a good research target, too.

SD cards must be formatted as either FAT16, FAT32, exFAT, or NTFS for the head unit to be able to read them.

Bluetooth

Bluetooth version 5 is supported by the head unit and is used for making and receiving phone calls, as well as playing audio from a paired mobile phone. The following Bluetooth profiles are officially documented in the user manual:

·      Hands Free Profile v1.7
·      Serial Port Profile
·      Phonebook Access Profile
·      Audio/Video Remote Control Profile (AVRCP) v1.6
·      Advanced Audio Distribution Profile (A2DP)
o   Supporting codecs: SBC, AAC, or LDAC

Android Auto, Apple CarPlay, and the Kenwood apps also utilise Bluetooth in varying capacities.

Interrogating the unit shows a few more Bluetooth services that are not documented; these could be a great area to research. Judging by the service names, they may all be related to Kenwood apps.

Wi-Fi

The head unit provides a WiFi access point that is primarily used for wireless Android Auto and Apple CarPlay. There is no intention for the end user to directly connect to this network and there is no officially documented way of acquiring the password. However, internal research has discovered multiple methods to obtain the password.

Once connected to the access point, the following ports are open:

·      TCP: 7000, 8086, 8888, 5355, 22
·      UDP: 67, 5353, 5355, 34613, 50842

TCP 22 is an SSH server and can be logged into. As per the competition rules, "If the entry leverages hardcoded credentials and/or exposed encryption keys, the entry must leverage an additional vulnerability to gain code execution to be in scope."

TCP 7000, 8086, and 8888 are all running non-standard services and are likely great places to research further.

Android Auto and Apple CarPlay

Both wired and wireless Android Auto and Apple CarPlay are supported without the need for a 3rd party app to be installed on the paired mobile phone. When using the wireless versions, the paired phone connects to the aforementioned secured WiFi network to establish a high-bandwidth channel for data to be sent and received.

When connecting using a USB cable, the WiFi network isn't used by Android Auto or Apple CarPlay, but it is still active.

Kenwood

Kenwood offers 2 Android/iOS apps to interface with the DNR1007XR. The first app is the Kenwood Portal App, which allows users to transfer photos from a mobile phone to the head unit over Bluetooth. The transferred photos can then be viewed as a slideshow on the head unit or be used as the wallpaper.

This presents an interesting attack surface, especially if the DNR1007XR itself performs any complex image handling tasks on the received images, such as resizing or converting between different image formats. The user-supplied images also need to be persisted to the head unit's filesystem, further expanding the attack surface.

The second app is the Kenwood Remote S app, which connects to the head unit over Bluetooth and allows for multimedia control such as selecting a radio station, skipping a track, and more. The Bluetooth Audio/Video Remote Control Profile (AVRCP) is designed for this exact task; however, no research was performed to confirm if the Remote S app takes advantage of AVRCP.

There are a few other Kenwood apps available, but they are not listed as supported on the DNR1007XR product page and therefore have not been explored.

Open Source Software

A list of open source licences can be viewed from the head unit by navigating to Settings -> System -> Open Source Licenses. There's no guarantee these open source projects are actually used by the unit.

Summary

We hope that this blog post has provided enough information about the DNR1007XR threat landscape to guide vulnerability research. Not every attack surface has been mentioned, and we encourage researchers to investigate further.

We are looking forward to Automotive Pwn2Own again in Tokyo in January 2026 at Automotive World, and we will see if IVI vendors have improved their product security. Don’t wait until the last minute to ask questions and register! We hope to see you there.

You can find me on Twitter @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

For the upcoming Pwn2Own Automotive contest, a total of 3 head units have been selected. One of these is the double DIN Kenwood DNR1007XR that offers a variety of functionality such as Android Auto, Apple CarPlay, USB media playback, wireless mirroring and more.

This blog post presents photos of the DNR1007XR including highlighting interesting internal components. A hidden debugging interface is also detailed which can be leveraged to obtain a shell.

Figure 1: Kenwood DNR1007XR

External

Tucked away behind the screen is a full-sized SD card slot that can be accessed by tilting the screen downwards. The SD card is used to play audio/video files as well as updating map data. This seems like an attack surface worth researching.

Figure 2: SD card slot

There's also a single USB port routed from the back of the unit that is used for:

·      Wired Android Auto
·      Wired Apple CarPlay
·      Audio playback
·      Video playback

Internal

Moving on to the internals, the DNR1007XR comprises multiple interconnected boards, with the most interesting board being located at the top of the unit. Removing a few screws and metal plates gives access to this board, which contains the main processor, eMMC, flash, and a Bluetooth / WiFi radio module.

Figure 3: Main board

Towards the center is the main Dolphin+ TCC8034 System on a Chip (SoC), which is marketed as an “IVI and Cluster solution” that supports running Android, Linux, and QNX. The SoC contains two 32-bit ARM cores and is running Linux. Last year's Kenwood target utilized a similar TCC8974 SoC; more information can be found here.

Figure 4: Dolphin+ TCC8034 SoC

Further to the right is a Kioxia THGBMJG7C2LBAU8 16GB eMMC chip which contains the main device firmware.

Figure 5: Kioxia eMMC

Below the eMMC chip and to the left is a Winbond 25Q256JVFM 256Mb serial flash chip that contains unknown data.

Figure 6: Winbond flash

Finally, to the left of the SoC is a Murata radio that handles Wi-Fi and Bluetooth operations. Searching around for the exact model number that's etched onto the radio's shielding doesn't return much information but the FCC documents for the DNR1007XR state that this is the Murata LBEE6ZZ1WD-334. This module has no public datasheet available and isn't listed on Murata's site.

Figure 7: Murata radio

Debug Connector

On the right edge of the main board is a suspicious-looking connector that lines up with a thin gap in the outer housing. This connector exposes a Linux login prompt over UART at 115200bps. Logging in with the correct credentials will spawn a shell.

Figure 8: Debug connector

Summary

Hopefully, this blog post provides enough information to kickstart vulnerability research against the DNR1007XR. Keep an eye out for another blog coming this Friday that covers the threat landscape of the DNR1007XR.

We are looking forward to Automotive Pwn2Own again in January 2026, and we will see if IVI vendors have improved their product security. We hope to see you there.

Until then, you can find me on Twitter @ByteInsight, and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

It’s the final patch Tuesday of 2025, but that doesn’t make it any less exciting. Put aside your holiday planning for just a moment as we review the latest security offering from Adobe and Microsoft. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for December 2025

For December, Adobe released five bulletins addressing 139 unique CVEs in Adobe Reader, ColdFusion, Experience Manager, Creative Cloud Desktop, and the Adobe DNG Software Development Kit (SDK). Don’t panic at that large of a CVE count. Most of those are simple cross-site scripting (XSS) bugs in Adobe Experience Manager. There are a few Critical-rated DOM-based XSS bugs in the mix, so don’t ignore this patch by any means – just don’t panic at the large number of CVEs. I wouldn’t panic over the update for ColdFusion either, but Adobe does set the deployment priority for this fix as 1. They note there are no known active attacks for the CVEs, but there are several arbitrary code execution bugs being fixed. Also, if you’re running ColdFusion, make sure you check out one of their lockdown guides. The one for ColdFusion 2025 can be found here.

The update for Adobe Reader is smaller than expected, with only two of the four CVEs addressed leading to code execution. Not that I’m complaining – I just expected more. The patch for the Adobe DNG Software Development Kit also fixes four CVEs, with one of those leading to code execution. Finally, the update for Creative Cloud Desktop fixes a single Important-rated bug.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Besides the fix for ColdFusion, all of the updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for December 2025

Microsoft ends the year by releasing a paltry 56 new CVEs in Windows and Windows components, Office and Office Components, Microsoft Edge (Chromium-based), Exchange Server, Azure, Copilot, PowerShell, and Windows Defender. One of these bugs came through the ZDI program. Of the patches released today, three are rated Critical while the rest are rated Important in severity. Counting the third-party Chromium updates listed in the release, it brings to total number of CVEs to 70.

Counting the CVEs released today, that being Microsoft’s total count to 1,139 CVEs patched in 2025. Again, this is not counting the numerous updates for Azure Linux and CBL Mariner released earlier this month as these should be considered Linux CVEs being applied to Azure properties. That makes 2025 the second-largest year in volume, trailing 2020 by a mere 111 CVEs. AS Microsoft’s portfolio continues to increase and as AI bugs become more prevalent, this number is likely to go higher in 2026.

Microsoft lists one bug under active attack, but two others as publicly known at the time of the release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug under active attack:

-    CVE-2025-62221 - Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
This is the only bug listed as under active attack for this month, and – at least on the surface – looks similar to a bug patched in October. However, the bug back in October was a race condition where this is a Use After Free (UAF). It allows an attacker to perform a privilege escalation on an affected system. These types of bugs are often combined with a code execution bug to take over a system. It appears to affect every supported version of Windows, so if you must prioritize, this should be on the top of your list.

-    CVE-2025-62554/62557 - Microsoft Office Remote Code Execution Vulnerability
Here we are again, looking at two Office bugs where the Preview Pane is an attack vector. For those counting (like me), that makes 11 months in a row with a Critical-rated Office bug, including the Preview Pane as an attack vector. If you’re a Mac user, you are out of luck, as updates for Office LTSC for Mac 2021 and 2024 are not available. Let’s hope Microsoft gets those out before exploitation begins.

-    CVE-2025-62562 - Microsoft Outlook Remote Code Execution Vulnerability
At first glance, I thought this was another Preview Pane issue, but it isn’t. In fact, this is only rated Critical for SharePoint Enterprise Server 2016 – it’s rated Important for everything else. However, the CVSS is the same (7.8) for all affected platforms. For this bug, the attacker would need to convince a user to reply to a specially crafted email. It’s not clear why this is worse on SharePoint 2016, but if you are running this version in your enterprise, don’t skip this update.

-    CVE-2025-64671 - GitHub Copilot for Jetbrains Remote Code Execution Vulnerability
This is the bug listed as publicly known, and it’s a command injection bug in Copilot that allows an unauthorized user to execute their code on an affected system. It’s listed as local, but it’s likely that a remote attacker could socially engineer someone to trigger the command injection. By exploiting a malicious cross-prompt injection in untrusted files or Model Context Protocol (MCP) servers, an attacker could piggyback extra commands onto those permitted by the user’s terminal auto-approve settings, causing them to be executed without further confirmation. I expect we’ll see many more bugs like these in 2026.

Here’s the full list of CVEs released by Microsoft for December 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Since we’ve already covered all of the Critical-rated CVEs, let’s move straight into looking at the other code execution bugs patched in the December release. As expected, most are Office-related open-and-own bugs where the Preview Pane is not an attack vector. There’s also the now ubiquitous bug in the RRaS service. There’s a bug in the Windows Resilient File System (ReFS) resulting from a heap overflow that could be reached over the network, but authentication is required. That’s similar to the bug in Azure Monitor. According to Microsoft, “An attacker with local network access to an Azure Linux Virtual Machine running Azure Monitor could exploit a heap overflow to escalate privileges to the syslog user, enabling execution of arbitrary commands.” The fix for the PowerShell bug is the other publicly known vulnerability this month and will require more than just a patch. The bug itself is a simple command injection, but after applying the update, when you use the Invoke-WebRequest command, you’ll receive a security warning message. You’ll also likely need to reboot after installing the patch, so make sure you complete that to fully address the vulnerability.

Moving on to the privilege escalation bugs receiving patches this month, most simply lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bug in Windows Shell could lead to elevating levels of code execution integrity – moving from Low to Medium integrity to escape AppContainer isolation. The vulnerability in RRAS requires an authenticated and domain-joined user, but it could allow an attacker to execute code on a target system. There’s an odd bug in the Brokering File System that’s listed as Elevation of Privilege, but it reads as a Denial of Service (DoS). A standard user could crash a system through a UAF. That sure does sound like a local DoS to me. Finally, there’s a bug in Exchange server that was reported by the National Security Agency (NSA). Microsoft says exploitation is unlikely, but NSA. It does seem like a fair amount of preparation is needed to exploit this bug, but NSA. Also, updates for Exchange Server 2016 and 2019 are not available as they are out of support. If you’re still using those you need to upgrade to the Extended Security Update (ESU) program.

Speaking of Exchange, there’s also a spoofing bug in the server that allows attackers to spoof the “From” email address displayed to the user. This bug was not reported by the NSA, but still, the UI misrepresentation could be used by attackers to spoof critical information. Kudos to Microsoft for deciding to fix the issue. The other spoofing bug corrected this month is in SharePoint and manifests as a cross-site scripting (XSS) bug.  

There are only four information disclosure bugs getting patched this month, and fortunately, all of these bugs only result in info leaks consisting of unspecified memory contents or memory addresses. The bug in Windows Defender also requires the attacker to be a part of a specific user group.

The December release contains fixes for three Denial-of-Service (DoS) bugs, and their descriptions mirror what we saw in the November release. While they all state that an attacker could deny service over a network (or locally) to that component, the two DirectX Graphics Kernel bugs state they could be used by a low-privilege Hyper-V guest to cause a DoS on the Hyper-V environment. It’s not clear how this would occur, but it if you’re running Hyper-V, don’t overlook these patches.

No new advisories are being released this month.

Looking Ahead

We start the patch process again in 2026 on January 13, and I’ll be back then with my analysis and thoughts about the release. Until then, merry christmahanakwanzika, stay safe, happy patching, and may all your reboots be smooth and clean!

I’ve made it through Pwn2Own Ireland, and while many are celebrated those who served their country in the armed services, patch Tuesday stops for no one. So affix your poppy accordingly, and let’s take a look at the latest security offerings from Adobe and Microsoft. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for November 2025

For November, Adobe released eight bulletins addressing 29 unique CVEs in Adobe InDesign, InCopy, Photoshop, Illustrator, Illustrator Mobile, Substance 3D Stager, Format Plugins, and Adobe Pass. Nine of these CVEs were reported by Trend ZDI researcher Michel DePlante. He discovered the bugs fixed by the patch for Adobe Format Plugins. If you must prioritize, the update for InDesign fixes four Critical-rated bugs. All could lead to arbitrary code execution. The fix for Illustrator for iPad also fixes five Critical-rated code execution bugs. However, the update for Illustrator only has two code execution CVEs. It’s interesting to see the difference between the mobile and desktop versions. The patch for Photoshop addresses a single code execution bug. There are four Critical-rated code execution bugs fixed by the Substance 3D Stager update. The patch for InCopy corrects three code execution bugs. The final patch from Adobe this month fixes a privilege escalation bug in Adobe Pass.

Overall, this month’s Adobe release is (thankfully) not that exciting. None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. All of the updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for November 2025

This month, Microsoft took pity on patch managers around the world and released a mere 63 CVEs Windows and Windows Components, Office and Office Components, Microsoft Edge (Chromium-based), Azure Monitor Agent, Dynamics 365, Hyper-V, SQL Server, and the Windows Subsystem for Linux GUI. Of the patches released today, four are rated Critical and 59 are rated Important in severity. One of these CVEs came through the Trend ZDI program. Counting the third-party Chromium updates listed in the release, it brings to total number of CVEs to 68.

This release is a far cry from the 177 CVEs we saw last month, although I don’t think anyone will complain. That brings the total CVEs addressed by Microsoft so far this year to 1,084. This is not counting the numerous updates for Azure Linux and CBL Mariner released earlier this month, as these should be considered Linux CVEs being applied to Azure properties. This drop could also be due to the fact that this is the first month where Windows 10 is not receiving updates. We will see what December brings and how close we end up to the record total of CVEs set back in 2020.  

Microsoft lists one bug under active attack, but none are publicly known at the time of release. Let’s take a closer look at some of the more interesting updates for this month, starting with the bug under active attack:

-    CVE-2025-62215 - Windows Kernel Elevation of Privilege Vulnerability
This is the bug currently under exploit, but Microsoft offers no indication of the extent of the exploitation. It’s also interesting to note there’s a race condition here, and it shows that some race conditions are more reliable than others. Bugs like these are often paired with a code execution bug by malware to completely take over a system. If you must prioritize, this should be at the top of your list.

-    CVE-2025-62199 - Microsoft Office Remote Code Execution Vulnerability
Another month – another Office bug where the Preview Pane is an attack vector. Interestingly, Microsoft notes user interaction is required despite the Preview Pane, so it’s not clear how this would be exploited. Maybe if a user previews an attachment? Still, at this point, it’s time to consider disabling the Preview Pane in Office until Microsoft clears these bugs up.

-    CVE-2025-60709 - Windows Common Log File System (CLFS) Driver Elevation of Privilege Vulnerability
While this bug is not under active attack and simply leads to executing code as SYSTEM, I highlight this bug as CLFS has been exploited multiple times over the last few years. I will admit that I may have some recency bias with this as I just saw a presentation at the Countermeasure conference in Ottawa discussing CLFS exploitation. Still, the presentation showed how CLFS has been recently abused by threat actors.

 -    CVE-2025-62222 - Agentic AI and Visual Studio Code Remote Code Execution Vulnerability
While there have been a few bugs impacting CoPilot, this is the first bug specifically calling out Agentic AI with a code execution bug. Based on the description, exploitation of this vulnerability would not be trivial. However, with a little bit of social engineering, it could allow remote attackers to execute their code on a target GitHub repository. There are several bugs impacting CoPilot receiving patches this month, but this one stands out above the others. If you’re using Agentic AI, pay attention here, or you could find yourself dealing with something more than just AI hallucinations.

Here’s the full list of CVEs released by Microsoft for November 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the remaining Critical patches, the update for Nuance PowerScribe 360 stands out not for impact, but for servicing. To update to a non-affected version, you will need to either contact your Customer Success Manager (CSM) or Technical Support for the latest version. So much for “just patch”. There’s an elevation of privilege (EoP) in DirectX that could lead to SYSTEM privileges, but there’s no indication why this one is Critical while an identical one is Important. The final Critical patch for November addresses a command injection in Visual Studio. The only interesting thing here is that exploitation would require prompt injection, CoPilot Agent interaction, and triggering a build. That’s far from trivial, but I would love to see what sort of CoPilot interaction is required.

Moving on to the remaining code execution bugs, there are a half-dozen open-and-own in various Office components. In these cases, the Preview Pane is not an attack vector. The bug in Azure Monitor Agent sounds more severe than its Important rating. An unauthenticated attacker could execute their code on affected systems without user interaction. While it doesn’t fall into the realm of wormable, it definitely lands in the world of yikes. The bug in GDI+ also garners a yikes from me as it gets the highest CVSS rating this month at 9.8. An attacker could get code execution over the network without user interaction. GDI+ bugs typically involve viewing an image, but this bug could impact web services that “are parsing documents that contain a specially crafted metafile, without the involvement of a victim user.” The SharePoint bug is another deserialization bug – similar to the one we saw exploited in-the-wild back in July. This requires authentication, but in previous attacks, this type of bug was paired with an auth bypass to exploit affected systems. The bug in the Windows Subsystem for Linux GUI requires user interaction, but patching means updating from the command line versus installing a patch. Finally, there are a couple of bugs in the RRAS protocol, which always seem to have something fixed each month.

Looking at the privilege escalation bugs receiving patches this month, most simply lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. Others could lead to elevating levels of code execution integrity – moving from Low to Medium integrity or Medium to Local System for code execution. The EoP in Configuration Manager allows attackers to get configuration manager administrator privileges. The bugs in Administration Protection could allow an attack to bypass these protections and execute code as an administrator. There’s an interesting bug in OneDrive for Android that allows attackers to “gain unauthorized access to system resources,” which could then be used for further compromise. Finally, the patch for SQL Server corrects a SQL injection bug. The attacker would get the privileges of the process running the query, so if the query has elevated privileges, so does the attacker.

There are only two Security Feature Bypass (SFB) patches in November, and both have CoPilot as a component. One is a simple path traversal in the Visual Studio Code CoPilot Chat Extension. An attacker could use this to bypass file protections. The other bug is due to the improper validation of generative AI output by CoPilot on Visual Studio. This could also be used to bypass file protections.

There are only a few information disclosure bugs getting patched this month, and fortunately, the majority of these bugs only result in info leaks consisting of unspecified memory contents or memory addresses. The bug in Dynamics 365 (On-Premises) leaks the ever-elusive “sensitive information”. I should also point out that the bugs in License Manager were silently patched last month and are now being documented. I won’t shout from this soapbox for too long, but these are definitely a bad thing™ and should not be done.

The November release contains fixes for three Denial-of-Service (DoS) bugs, and their descriptions are somewhat – obtuse. While they all state that an attacker could deny service over a network (or locally) to that component, two of them state they could be used by a low-privilege Hyper-V guest to cause a DoS on the Hyper-V environment. It’s not clear how this would occur, but it if you’re running Hyper-V, don’t overlook these patches.

Finally, there are two spoofing bugs in Dynamics 365 Field Service (online) that manifest as cross-site scripting (XSS) bugs. Of course, a simple patch won’t fix these. Instead, you’ll need to go to the Power Platform admin center and apply the updates from there.

No new advisories are being released this month. However, there was an update to the latest servicing stack updates ADV990001.

Looking Ahead

The final Patch Tuesday of 2025 will be on December 9, and I’ll be back then with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Welcome to the third and final day of Pwn2Own Ireland 2025. So far, we’ve awarded $792,750 for 56 unique 0-day bugs, and we still have 17 attempts to go! We’ll be updating this blog with live results as we have them, so refresh often.

That’s all folks! Pwn2Own Ireland has come to a close. In total, we awarded $1,024,750 for 73 unique 0-day bugs. We’ve seen some amazing research over the last few day, and we can’t thank our competitors enough for bringing their hard work and innovation to the contest. We also thanks all of the vendors who participated and special thanks to our partner Meta and co-sponsors Synology and QNAP. Their support has been invaluable in the success of the event. And of course - we have to congratulate the Summoning Team for winning Master of Pwn. They had some great bugs in multiple categories, and winning Master of Pwn shows their hard work preparing for the contest paid off. Here are the final Master of Pwn standings:

Our next event will be in Tokyo on January 21-23, 2026.. Join us for Pwn2Own Automotive then. See you in Japan!

WITHDRAW - CyCraft Technology has withdrawn their attempt against the Amazon Smart Plug.

FAILURE - Unfortunately, Daniel Frederic and Julien Cohen-Scali of Fuzzinglabs could not get their exploit of the QNAP TS-453E working within the time allotted.

SUCCESS/COLLISION - Xilokar (@Xilokar) used four bugs - including a auth bypass and an underflow - to exploit the Phillips Hue Bridge, but one of the bugs collided with a previous entry. He still earns $17,500 and 3.5 Master of Pwn points.

SUCCESS - Chris Anastasio of Team Cluck used a single type confusion bug to exploit the Lexmark CX532adwe printer. He earns himself $20,000 and 2 Master of Pwn points.

SUCCESS - Ben R. And Georgi G. of Interrupt Labs used an improper input validation bug to take over the Samsung Galaxy S25 - enabling the camera and location tracking in the process. They earn $50,000 and 5 Master of Pwn points.

SUCCESS/COLLISION - Yannik Marchand (kinnay) used three bugs - including an Incorrect Implementation of Authentication Algorithm - to exploit the Phillips Hue Bridge, but the other two bugs collided with bugs seen previously in the contest. He still earns $13,500 and 2.75 Master of Pwn points.

SUCCESS - David Berard of Synacktiv used a pair of bugs to exploit the Ubiquiti AI Pro in the Surveillance Systems category. The impressive display (including a round of Baby Shark) earns him $30,000 and 3 Master of Pwn Points.

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a hard-coded cred and an injection to take over the QNAP TS-453E. These unique bugs earn him $20,000 and 4 Master of Pwn points.

SUCCESS/COLLISION - Team Viettel used two bugs to exploit the Lexmark CX532adwe. While their heap based buffer over was unique, the other bug has been seen earlier in the contest. They still earn $7,500 and 1.5 Master of Pwn points. #Pwn2Own

SUCCESS - Team @Neodyme used a single integer overflow to exploit the Canon imageCLASS MF654Cdw. Their unique bugs earns them $10,000 for the 8th round win and 2 Master of Pwn points. #Pwn2Own

SUCCESS - Interrupt Labs combined a path traversal and an untrusted search path bug to exploit the Lexmark CX532adwe. They got a reverse shell and loaded Doom on the LCD. We couldn't play it though. Still awesome to see. They earn themselves $10,000 and 2 Master of Pwn points.

SUCCESS/COLLISION - The Thalium team from Thales Group (@thalium_team) needed 3 bugs to exploit the Phillips Hue Bridge, but only their heap based buffer overflow was unique. The others were seen earlier in the contest. They still earn $13,500 and 2.75 Master of Pwn points.

COLLISION - Evan Grant used a single bug to exploit the QNAP TS-453E, but, unfortunately, it had been used earlier in the contest. He still earns $10,000 and 2 Master of Pwn points. #Pwn2Own

SUCCESS - namnp of Viettel Cyber Security used a crypto bypass and a heap overflow to exploit the Phillips Hue Bridge. They earn $20,000 and 4 Master of Pwn points, which catapults them in the Top 5 in Master of Pwn standings.

WITHDRAW - Team Z3 has withdrawn their WhatsApp entry.

COLLISION - Bongeun Koo (@kiddo_pwn) and Evangelos Daravigkas (@freddo_1337) of Team DDOS used a single bug to exploit the QNAP TS-453E, but the bug has been previously seen in the contest. Their work still earns them $10,000 and 2 Master of Pwn points.

FAILURE - Unfortunately, Frisk and Opcode from the Inequation Group ctf team could not get their exploit of the Meta Quest 3S working within the time time allotted. They were able to cause a DoS, but did not achieve code execution.

Welcome to Day Two of Pwn2Own Ireland 2025. Yesterday, we awarded $522,500 for 34 unique 0-day bugs. The Summoning Team took a slim lead in the Master of Pwn, but big changes could happen today as we have 19 more attempts today. We’ll be updating this blog with results as they come in, so refresh often!

Day Two of Pwn2Own Ireland 2025 is complete! We saw some great work today, with the exploit of the Samsung Galaxy being the big highlight. So far, we have awarded $792,750 for 56 unique 0-days. Tomorrow look to be even more exciting with another Galaxy attempt, a Met Quest attempt, and (of course) that big WhatsApp exploit everyone is talking about. Saty tuned as we provide real-time results throughout the day. Here’s the current Master of Pwn leader board. The Summoning Team has a commanding lead, but with WhatsApp being worth 100 points, anything can happen.

SUCCESS - Pwn2Own veterans PHP Hooligans used an OOB Write bug to exploit the Canon imageCLASS MF654Cdw printer. Their fifth round win earns them $10,000 and 2 Master of Pwn points.

Veteran competitors showing their skills

SUCCESS/COLLISION - Dinh Ho Anh Khoa and Phan Vinh Khang of Viettel Cyber Security used a unique command injection and two bugs that collided with previous bugs to exploit the Home Automation Green. They earn $12,500 and 2.75 Master of Pwn points.

Returning Master of Pwn champs getting started with a win

SUCCESS/COLLISION - Ho Xuan Ninh (@Xuanninh1412), Hoang Hai Long (@seadragnol) from Qrious Secure used 5 bugs to exploit the Phillips Hue Bridge, but only 3 were unique. They still earn $16,000 and 3.75 Master of Pwn points.

SUCCESS - Chumy Tsai (http://github.com/Jimmy01240397) of CyCraft Technology used a single code injection bug to exploit the QNAP TS-453E. His unique bug earns him $20,000 and 4 Master of Pwn points.

A canine confirmation for CyCraft Technologies

OUT OF SCOPE - Although Sina Kheirkhah's exploit of the Synology BeeStation Plus was successful, the entry was ruled out of scope for the competition.

SUCCESS/COLLISION - Team Neodyme used two bugs to exploit the Home Assistant Green, but only one was unique. They still earn $15,000 and 3 Master of Pwn points.

SUCCESS - TwinkleStar03 (@_twinklestar03) from the DEVCORE Intern Program used a unique stack based buffer overflow to get a sixth round win against the Canon imageCLASS MF654Cdw. He earns $10,000 and 2 Master of Pwn points.

COLLISION - Rafal Goryl from PixiePoint Security succeeded in exploiting the Phillips Hue Bridge, but the bugs he used were collisions with a previous entry. He still earns $10,000 and 2 Master of Pwn points.

COLLISION - Enrique Castillo (@hyprdude), McCaulay Hudson (@_mccaulay), Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) successfully exploited the Synology CC400W camera, but the bug they used was known to the vendor. They still earn $15,000 and 1.5 Master of Pwn points.

SUCCESS - Le Trong Phuc (chanze@VRC) and Cao Ngoc Quy (Chino Kafuu) of Verichains Cyber Force chained two unique bugs - including an auth bypass - to exploit the Synology DS925+ and run code as root. Their work earns them $20,000 and 4 Master of Pwn points.

FAILURE - Unfortunately, Tri Dang from Qrious Secure could not get his exploit of the Samsung Galaxy S25 in the time allotted. #Pwn2Own

SUCCESS - Ken Gannon / 伊藤 剣 of Mobile Hacking Lab, and Dimitrios Valsamaras of Summoning Team used five different bugs to exploit the Samsung Galaxy S25. They earn $50,000 and 5 Master of Pwn points.

COLLISION The PHP Hooligans used a buffer overflow to exploit the Phillips Hue Bridge, but the bug had been previously seen in the contest. They still earn $10,000 and 2 Master of Pwn points.

SUCCESS - Mehdi & Matthieu from team Synacktiv used a buffer overflow to exploit the Phillips Hue Bridge. Their unique bug earns them $20,000 and 4 Master of Pwn points.

SUCCESS - Team Neodyme (@Neodyme) used three bugs to exploit the Amazon Smart plug. In doing so, they earn themselves $20,000 and 2 Master of Pwn points.

COLLISION - The PHP Hooligans did exploit the QNAP TS-453E, but the bug they used was previously seen in the contest. They still earn $10,000 and 2 Master of Pwn points. #Pwn2Own

SUCCESS - Nao and @ExLuck99 from ANHTUD used a heap-based buffer overflow to exploit the Lexmark CX532adwe, but we penalized for a rules violation. The still earn $10,000 and 2 Master of Pwn points.

SUCCESS/COLLISION - ChatGPT helped Team ANHTUD as they used 3 bugs - 1 collision, 1 unique SSRF and 1 cleartext storage of sensitive information - to exploit Home Automation Green. They finished with just 45 seconds remaining. Their work earns them $16,750 and 3.75 Master of Pwn points.

COLLISION - Our final attempt of the day is a collision. Le Tran Hai Tung (@tacbliw), namnp and Le Duc Anh Vu (@vulda) of Viettel Cyber Security collided with a previous entry while exploiting the Canon mageCLASS MF654Cdw. They still earn $5,000 and 1 Master of Pwn points.

Welcome to Day One of Pwn2Own Ireland 2025! We have 17 attempts today with some exciting research on display. We’ll be posting results here as we have them, and follow us on Twitter, Mastodon, and Bluesky.

Day One has come to a close and we haven’t had a single failure! We awarded $522,500 for 34 unique bugs on the first day of the contest. Here’s how the Master of Pwn leader board currently sits:

Of course, there’s plenty of time left with some big exploits still to come. Stay tuned for the results from Day Two and Three!

SUCCESS - Team Neodyme used a stack based buffer overflow to exploit the HP DeskJet 2855e. They earn $20,000 and 2 Master of Pwn points.

Daniel Kilimnik of Team Neodyme shows off his successful exploitation

SUCCESS - Nguyen Hoang Thach (@hi_im_d4rkn3ss), Tan Ze Jian, Lin Ze Wei, Cherie-Anne Lee, Gerrard Tai of STARLabs (@starlabs_sg) used a heap based buffer overflow to exploit the @CanonUSA imageCLASS MF654Cdw. They earn themselves $20,000 and 2 Master of Pwn points.

A successful attempt against the Canon printer

SUCCESS - @Tek_7987 & @_Anyfun (@Synacktiv) used a stack overflow to achieve rootlevel code execution on the Synology BeeStation Plus. They earn $40,000 and 4 Master of Pwn points in the process.

Pwned by Synactiv

SUCCESS - Bongeun Koo (@kiddo_pwn) and Evangelos Daravigkas (@freddo_1337) of Team DDOS used a magnificent eight different bugs - including multiple injections - to complete their SOHO Smashup of the QNAP Qhora-322 + QNAP TS-453E. They earn $100,000 and 10 Master of Pwn points.

Demonstrating root level access

ZDI Analysts Neal Brown (left) and Mat Powell observe Bongeun Koo and Evangelos Daravigkas of Team DDOS

WITHDRAW - Bongeun Koo (@kiddo_pwn) and Evangelos Daravigkas (@freddo_1337) of Team DDOS was withdrawn their attempt of the Philips Hue Bridge.

SUCCESS - SHIMIZU Yutaro (@shift_crops) of GMO Cybersecurity by Ierae, Inc. used a stack based buffer overflow to exploit the Canon imageCLASS MF654Cdw. Their second round win earns them $10,000 and 2 Master of Pwn points.

Nyan cat makes an appearance courtesy of GMO Cybersecurity

SUCCESS - Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) used a pair of bugs to gain code execution on the Synology DiskStation DS925+. He earns himself $40,000 and 4 Master of Pwn points

The Summoning Team has root access on the Synology

ZDI Analysts Vincent Lee and Mat Powell observe the attempt from Sina Kheirkhah

SUCCESS - Stephen Fewer (@stephenfewer) of Rapid7 (@rapid7) used three bugs, including an SSRF and a command injection, to exploit the Home Assistant Green (which isn't actually green). He earns himself $40,000 and 4 Master of Pwn points.

Stephen Fewer has root on the Home Assistant Green

SUCCESS - Sang Nguyen Thien (@gnas0x0018) and mistsu of Team ANHTUD used four bugs - including multiple types overflows and an OOB Read - to exploit the Phillips Hue Bridge. Their outstanding work earns them $40,000 and 4 Master of Pwn points.

Team ANHTUD’s winning entry

SUCCESS/COLLISON - McCaulay Hudson (@_mccaulay) of Summoning Team (@SummoningTeam) successfully exploited the Home Assistant Green with four bugs - one unique SSRF and three bug collisions. They still earn $12,500 and 2.5 Master of Pwn points.

Summoning Team was here - again

SUCCESS - dmdung (@_piers2) of STAR Labs SG Pte. Ltd used a single OOB access bug to exploit the Sonos Era 300 smart speaker. In doing so, he earns $50,000 and 5 Master of Pwn points.

uid=0 means dmdung has root on the Sonos speaker

SUCCESS - Team PetoWorks [SungJun Park (@howrealsung), Wonbeen Im (@D0b6y), Dohyun Kim (@d0now_kim), and Juyeong Lee (@ju_cheda)] used a Release of Invalid Pointer or Reference bug to exploit the Canon printer at Pwn2Own. They $10,000 and two Master of Pwn points for their third round win.

Configuration issues couldn’t stop Team PetoWorks

SUCCESS - YingMuo (@YingMuo), HexRabbit (@h3xr4bb1t), LJP (@ljp_tw) from DEVCORE Research Team and nella17 (@nella17tw) from DEVCORE Intern Program used multiple injections and a format string bug(!) to exploit the QNAP TS-453E. Their unique bugs earn them $40,000 and 4 Master of Pwn points.

Who said format string bugs don’t exist anymore?

SUCCESS - Hank Chen (@hank0438) of InnoEdge Labs used an auth bypass and an OOB write to exploit the Phillips Hue Bridge. His second round win earns $20,000 and 4 Master of Pwn points.

Hank Chen provides an enlightening exploit

SUCCESS - Sina Kheirkhah (@SinSinology) and McCaulay Hudson (@_mccaulay) of Summoning Team (@SummoningTeam) used a pair of bugs to exploit of the Synology ActiveProtect Appliance DP320. That rounds their day off with another $50,000 and 5 more Master of Pwn points.

Fingerprints on the screen can’t hide root access

SUCCESS - Emanuele Barbeno, Cyrill Bannwart, Yves Bieri, Lukasz D., Urs Mueller of Compass Security (@compasssecurity) combined an arbitrary file write and cleartext transmission of sensitive data to exploit the Home Assistant Green. The unique bugs in their third round win earns them $20,000 and four Master of Pwn points.

ZDI Analyst Bobby Gould (right) overlooks the work done by the Compass Team

SUCCESS - Nguyen Ba Nam Dung and Vu Chi Thanh from Team ANTHUD used a single heap based buffer overflow to exploit the Canon imageCLASS MF654Cdw on their third and final attempt. Their fourth round win earns them $10,000 and 2 Master of Pwn points.

Third time’s a charm

Welcome to Pwn2Own Ireland 2025! We have some amazing spooky entries for this year’s contest, and a potential of up to $2,000,000 - including our largest ever single prize for a 0-click in WhatsApp for $1,000,000. As always, we began our contest with a random drawing to determine the order of attempts. If you missed it, you can watch the replay here.

The complete schedule for the contest is below (all times Irish Standard Time [UTC +1]).

Note: All times subject to change

Tuesday, October 21 – 0930

Bongeun Koo (@kiddo_pwn) and Evangelos Daravigkas (@freddo_1337) of Team DDOS targeting SOHO SMASHUP (QNAP Qhora-322 + QNAP TS-453E) in the SOHO category for $100,000 and 10 Master of Pwn Points.

Team Neodyme (@Neodyme) targeting HP DeskJet 2855e in the Printers category for $20,000 and 2 Master of Pwn Points.

Nguyen Hoang Thach (@hi_im_d4rkn3ss), Tan Ze Jian, Lin Ze Wei, Cherie-Anne Lee, Gerrard Tai of STARLabs (@starlabs_sg) targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

@Tek_7987 and @_Anyfun (both working at @Synacktiv) targeting Synology BeeStation Plus in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Tuesday, October 21 – 1130

Stephen Fewer (@stephenfewer) of Rapid7 (@rapid7) targeting Home Assistant Green in the Smart Home category for $40,000 and 4 Master of Pwn Points.

SHIMIZU Yutaro (@shift_crops) of GMO Cybersecurity by Ierae, Inc. targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology DiskStation DS925+ in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Bongeun Koo (@kiddo_pwn) and Evangelos Daravigkas (@freddo_1337) of Team DDOS targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Tuesday, October 21 – 1400

Team PetoWorks (SungJun Park(@howrealsung), Wonbeen Im(@D0b6y), Dohyun Kim(@d0now_kim), Juyeong Lee(@ju_cheda)) targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

McCaulay Hudson (@_mccaulay) of Summoning Team (@SummoningTeam) targeting Home Assistant Green in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Team ANHTUD targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

dmdung (@_piers2) of STAR Labs SG Pte. Ltd targeting Sonos Era 300 in the Smart Home category for $50,000 and 5 Master of Pwn Points.

You can watch the live stream of this attempt here.

Tuesday, October 21 – 1500

YingMuo (@YingMuo), HexRabbit (@h3xr4bb1t), LJP (@ljp_tw) from DEVCORE Research Team and nella17 (@nella17tw) from DEVCORE Intern Program targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Tuesday, October 21 – 1600

Emanuele Barbeno, Cyrill Bannwart, Yves Bieri, Lukasz D., Urs Mueller of Compass Security (@compasssecurity) targeting Home Assistant Green in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Hank Chen (@hank0438) of InnoEdge Labs targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Team ANHTUD targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

Sina Kheirkhah (@SinSinology) and McCaulay Hudson (@_mccaulay) of Summoning Team (@SummoningTeam) targeting Synology ActiveProtect Appliance DP320 in the Network Attached Storage category for $50,000 and 5 Master of Pwn Points.

Wednesday, October 22 – 0930

Viettel Cyber Security targeting Home Assistant Green in the Smart Home category for $40,000 and 4 Master of Pwn Points.

PHP HOOLIGANS targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

Ho Xuan Ninh (@Xuanninh1412), Hoang Hai Long (@seadragnol) from Qrious Secure targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1000

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology BeeStation Plus in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1100

Chumy Tsai (github.com/Jimmy01240397) @ CyCraft Technology Intern targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1130

Team Neodyme (@Neodyme) targeting Home Assistant Green in the Smart Home category for $40,000 and 4 Master of Pwn Points.

TwinkleStar03 (@_twinklestar03) from DEVCORE Intern Program targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

Rafal Goryl (@voix44er) of PixiePoint Security targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1200

Enrique Castillo (@hyprdude), McCaulay Hudson (@_mccaulay), Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting Synology CC400W in the Surveillance Systems category for $30,000 and 3 Master of Pwn Points.

Wednesday, October 22 – 1300

Le Trong Phuc (chanze@VRC) and Cao Ngoc Quy (Chino Kafuu) of Verichains Cyber Force targeting Synology DiskStation DS925+ in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1400

Team ANHTUD targeting Lexmark CX532adwe in the Printers category for $20,000 and 2 Master of Pwn Points.

Ken Gannon / 伊藤 剣 (@yogehi) of Mobile Hacking Lab, and Dimitrios Valsamaras (@Ch0pin) of Summoning Team (@SummoningTeam) targeting Samsung Galaxy S25 - Remote in the Mobile Phones category for $50,000 and 5 Master of Pwn Points.

You can watch a live stream of this attempt here.

Mehdi & Matthieu @Synacktiv targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1430

Team Neodyme (@Neodyme) targeting Amazon Smart Plug in the Smart Home category for $20,000 and 2 Master of Pwn Points.

Wednesday, October 22 – 1500

PHP HOOLIGANS targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1600

Team ANHTUD targeting Home Assistant Green in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Tri Dang (@trichimtrich) from Qrious Secure targeting Samsung Galaxy S25 - Remote in the Mobile Phones category for $50,000 and 5 Master of Pwn Points.

You can watch a live stream of this attempt here.

Wednesday, October 22 – 1700

PHP HOOLIGANS targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Wednesday, October 22 – 1800

Viettel Cyber Security targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

Thursday, October 23 – 0930

Chris Anastasio of Team Cluck targeting Lexmark CX532adwe in the Printers category for $20,000 and 2 Master of Pwn Points.

Daniel Frederic and Julien Cohen-Scali of Fuzzinglabs (@fuzzinglabs) targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Xilokar (@[email protected]) targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

CyCraft Technology targeting Amazon Smart Plug in the Smart Home category for $20,000 and 2 Master of Pwn Points.

Thursday, October 23 – 1030

Interrupt Labs targeting Samsung Galaxy S25 - Remote in the Mobile Phones category for $50,000 and 5 Master of Pwn Points.

You can watch a live stream of this attempt here.

Thursday, October 23 – 1130

Viettel Cyber Security targeting Lexmark CX532adwe in the Printers category for $20,000 and 2 Master of Pwn Points.

Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam) targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Yannik Marchand (kinnay) targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

David BERARD of @synacktiv targeting Ubiquiti AI Pro in the Surveillance Systems category for $30,000 and 3 Master of Pwn Points.

Thursday, October 23 – 1230

Team Neodyme (@Neodyme) targeting Canon imageCLASS MF654Cdw in the Printers category for $20,000 and 2 Master of Pwn Points.

Thursday, October 23 – 1330

Interrupt Labs targeting Lexmark CX532adwe in the Printers category for $20,000 and 2 Master of Pwn Points.

Evan Grant (@stargravy) targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Thalium team from Thales Group (@thalium_team) targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Thursday, October 23 – 1500

Eugene (@3ugen3) of Team Z3 targeting WhatsApp - Zero-Click Remote Code Execution in the Messaging category for $1,000,000 and 100 Master of Pwn Points.

Thursday, October 23 – 1530

Bongeun Koo (@kiddo_pwn) and Evangelos Daravigkas (@freddo_1337) of Team DDOS targeting QNAP TS-453E in the Network Attached Storage category for $40,000 and 4 Master of Pwn Points.

Viettel Cyber Security targeting Philips Hue Bridge in the Smart Home category for $40,000 and 4 Master of Pwn Points.

Thursday, October 23 – 1700

Frisk and Opcode from the Inequation Group ctf team targeting Meta Quest 3S - No Interaction LPE - Self Jailbreak in the Wearables category for $30,000 and 3 Master of Pwn Points.

If you just want to read the rules, click here. Updated as of November 21 to expand the Alpitronic target scope and to clarify the model of the ChargePointHome Flex model number.

 Now entering its third year, Pwn2Own Automotive returns to Automotive World in Tokyo on January 21 – 23, 2026. Over the last two years, we’ve awarded more than $2,000,000 for the latest in automotive exploitations, and this year looks to be even better.

As always, we’re pleased to be working with our cohorts over at VicOne again. Their help was instrumental in the success we had at our first event, and we’re glad to be partnering with them once more. Tesla also returns as a sponsor. They’ve worked with us since 2019, and their help has been crucial in advancing the state of the art in automotive research. This year, we’re introducing a new supercharger category, and Alpitronic has joined as a partner and provided their Level 3 charger as a target. Superchargers are a whole new level of targets, and we’re interested to see what researchers bring. Finally, the Open Charge Alliance joins as a partner and brings their OCPP Compliance Test Tool (OCTT) as a target. To say that we’re charged up for this year’s event is a horrible pun, but a true statement. We can’t wait to see what researchers bring to the contest.

As with other Pwn2Own events, we’ll have a random drawing to determine the schedule of attempts the day before the contest, and we will proceed from there. As always, if you have questions, don't hesitate to get in touch with us at [email protected]. We will be happy to address your issues or concerns directly.

Now on to the six categories we’ll have for this year’s Pwn2Own Automotive event:

-- Tesla
-- In-Vehicle Infotainment (IVI)
-- Level 3 Electric Vehicle (EV) Chargers
-- Level 2 Electric Vehicle (EV) Chargers
-- Open Charge Alliance
-- Automotive Operating Systems

Let's start with everyone's favorite category.

Tesla

Since its introduction to Pwn2Own in 2019, the Tesla category has always been a highlight, with some of the most innovative research being demonstrated on the EV. At the inaugural Pwn2Own Automotive, the team from Synacktiv exploited it twice on their way to winning Master of Pwn. Contestants can register an entry against the Tesla Model 3/Y (Ryzen-based) equivalent bench top unit, and it wouldn’t surprise me if someone needs to run their exploits in an RF enclosure to prevent interference with vehicles that might be driving by.  Also note that while a Tesla is available as a prize, not every successful attempt will win the vehicle itself. Some targets will require you to exploit multiple subsystems to reach the selected target. The prize amount is based on where the final code execution occurs. Some of the targets have add-ons available, but to drive away in your new ride, you need to target one of the entries marked “Vehicle Included” in the table below. Also note that the targets have changed a bit this year to keep things interesting.

As usual, there are a few “add-ons” you can go for if you really want to show your stuff.

Back to top

In-Vehicle Infotainment (IVI) Systems

Other highlights from the inaugural contest were found in the IVI category, which saw the NCC Group put a playable version of Doom on an Alpine system. More than just stereos, the modern IVI is the gateway to your car’s internal systems. Navigation, in-car internet, and Wi-Fi are provided through these devices, but they also serve a connection to other vehicle systems through the CAN bus – making them a ripe target for attackers. These devices are also retrofitted to existing vehicles to modern capabilities – and perhaps modern vulnerabilities as well. This year, we’ve made it a little more complicated than in year’s past, so be sure to review the rules for the full details. Here are the systems available as targets in the IVI category:

Back to top

Level 3 Electric Vehicle (EV) Chargers Category

This is a new category for us this year and is brought to us by our new partner Aplitronic. Level 3 chargers are usually referred to as “superchargers”, and we expect some super exploits to be demonstrated at the event. We’ll have two options for this category: Field Mode and Lab Mode. For the Field Mode option, the door of the target will be closed, with no access to internal components. An attempt against this target must be launched against one of the following attack surfaces:  Charging Connector, NFC, or Touch Screen. The LAN interface is out of scope for this option. For the Lab Mode option, the door of the target will be opened, and the charger internals will be accessible to the contestant. An attempt against this target may be launched against the one following attack surfaces in addition to the ones listed in the Field Mode option: LAN(s), USB, CAN, or JTAG. 

For both options, entries requiring ARP spoofing, DNS spoofing, MITM, software downgrade attack, System on Module (SoM) swap attack, WAN/SIM(s) attack, Payment Terminal, or any assumptions involving control over external infrastructure are out of scope. For the field mode, NFC card cloning is out of scope.

Back to top

Level 2 Electric Vehicle (EV) Chargers Category

At previous Pwn2Own Automotive events, this proved to be the most popular category with every charger targeted at least once. Last year, contestants also demonstrated how the EV chargers could be used to communicate – and thus exploit – to the vehicle itself. The Tesla wall charger returns as a target, and it is joined by the Ford Connected Charger as well. Attack surfaces in scope for the contest include mobile apps, Bluetooth Low Energy (BLE) connections, and the OCPP protocol could all allow threat actor to cause harm to an EV. There’s no official bonus for style points; but we always love exploits that make us laugh. An attempt in this category must be launched against the target's exposed services or against the target’s communication protocols/physical interfaces that are accessible to a typical user.

As we did last year, there are a couple of additional challenges you can add on to your attempt. The first extra challenge is a Charging Connector Protocol/Signal Manipulation attack. The entry must gain code execution on the EV Charger and the resulting payload must manipulate the protocol and/or signals being transmitted via the Charging Connector. If you can accomplish this, you’ll earn an extra $10,000 and 1 more Master of Pwn point. Really want a challenge? Then go for the Charging Connector Attack. For this one, the entry must originate from the Charging Connector and compromise the EV Charger. If you accomplish this one, it earns you an additional $20,000 and 2 more Master of Pwn points.

Back to top

Open Charge Alliance

New for this year’s event is the Open Charge Alliance category. According to their charter, “The goal of the Open Charge Point Protocol (OCPP) is to provide a uniform method of communication between charge points and central systems.” As such, the protocol could prove an attractive attack surface for attackers. The OCPP Compliance Test Tool (OCTT) is the target in this category with a $15,000 award. As this is a new category, please read the rules carefully and ask any questions you may have to ensure your entry is valid.

Back to top

Automotive Operating Systems

It’s odd to think of operating systems within a car, but they are there – and they’re there in abundance. If you drive a recent Mercedes, Subaru, Mazda, or Toyota, there’s a good chance you’re also driving something with Automotive Grade Linux (AGL) installed. How do these onboard OSes compare to their desktop counterparts? Previous events saw AGL successfully targeted. This year, Entries against the AGL target are eligible for an additional $10,000 bonus if the entry leverages vulnerabilities in the BlueZ or the ConnMan subsystems. It will be intriguing to see if the other OSes are targeted this year. An attempt in this category must be launched against the target's exposed services/features or launched against the target’s communication protocols that are accessible to a typical user.

Back to top

Master of Pwn

No Pwn2Own contest would be complete without crowning a Master of Pwn, which signifies the overall winner of the competition. Earning the title results in a slick trophy, a different sort of wearable, and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2026).

For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it. If the contestant decides to remove an Add-on Bonus during their attempt, the Master of Pwn points for that Add-on Bonus will be deducted from the final point total for that attempt.

The Complete Details

The full set of rules for Pwn2Own Automotive 2026 can be found here. They may be changed at any time without notice. We highly encourage potential entrants to read the rules thoroughly and completely should they choose to participate. We also encourage contestants to read this blog covering what to expect when participating in Pwn2Own.

Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at [email protected] to begin the registration process. (Email only, please; queries via social media, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing the day before the contest to determine the contest order. Registration closes at 5:00 p.m. Japanese Standard Time on January 15, 2026.

The Results

We’ll be blogging and tweeting results in real-time throughout the competition. Be sure to keep an eye on the blog for the latest information. We’ll also be posting live results on Twitter, Mastodon, LinkedIn, and Bluesky, so follow us on your favorite social platform for the latest news, and keep an eye on the #P2OAuto hashtag for continuing coverage.

We look forward to seeing everyone in Tokyo, and we look forward to seeing what new exploits and attack techniques they bring with them.

With special thanks to our Pwn2Own Automotive 2025 partners, Tesla, Alpitronics and the Open Charge Alliance, for providing their assistance and technology. Thanks also to the researchers from VicOne for their guidance and recommendations.

I’m currently in Cork, Ireland as we prepare for Pwn2Own Ireland, but that doesn’t stop patch Tuesday from coming. Take a break from your scheduled activities and let’s take a look at the latest security offerings from Adobe and Microsoft. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for October 2025

For October, Adobe released 12 bulletins addressing 36 unique CVEs in Adobe Connect, Commerce, Creative Cloud Desktop, Bridge, Animate, Experience Manager Screens, Substance 3D Viewer, Substance 3D Modeler, FrameMaker, Illustrator, Dimension, and Substance 3D Stager. Likely the most important of these is the update for Substance 3D Stager, which addresses five Critical-rated code execution bugs. The fix for Dimension corrects four code execution bugs. The patch for Illustrator contains only two bugs, but both lead to code execution. The update for Commerce should also be given priority as it fixes five different CVEs, including two security feature bypasses. The patch for FrameMaker fixes two Critical-rated code execution bugs.

The update for Connect has three bugs, but two are simply cross-site scripting (XSS) issues. The fix for Animate has four bugs, but only two are Critical. Three out of the four bugs in Substance 3D Viewer are rated Critical. The patch for Experience Manager Screens takes out three XSS bugs. The Substance 3D Modeler patch fixes a single code execution bug. There’s also just a single bug addressed by the Creative Cloud patch. And finally, the update for Bridge corrects one code execution and one memory leak.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. All of the updates released by Adobe this month are listed as deployment priority 3.

Microsoft Patches for October 2025

This month, Microsoft released a monstrous 177 new CVEs in Windows and Windows Components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, Hyper-V, .NET and Visual Studio, Github, Exchange Server, BitLocker, and Xbox. Of the patches released today, 16 are rated Critical, one is rated Moderate, and the rest are rated Important in severity. One of these CVEs came through the Trend ZDI program. Counting the third-party updates listed in the release, it brings to total number of CVEs to a staggering 195.

This release represents the largest monthly release of all time for Microsoft and puts them one above the number of CVEs they released last year. With two months left in 2025, this will at least be the second busiest year of security patches from Microsoft with an outside shot of passing 2020 (1,250 total CVEs). This month’s huge volume could be related to the end of Windows 10 support. Microsoft could be pushing as much as possible for those still running the OS. Otherwise, it seems that large releases are the new normal for Microsoft. Let’s hope these are quality updates that do not cause harm or regressions in other software. The last thing we need is (more) people afraid of applying security patches.

Microsoft lists three bugs under active attack at the time of releases and three others as publicly known. Let’s take a closer look at some of the more interesting updates for this month, starting with the bugs under active attack:

-    CVE-2025-24990 - Windows Agere Modem Driver Elevation of Privilege Vulnerability
This bug allows attackers to elevate to administrative privileges on systems where the Agere modem drivers are installed. The problem is that these drivers ship natively on supported Windows versions. Since these are legacy drivers, the solution is to remove the offending files. Microsoft gives no indication of how widespread these attacks are, but considering the vulnerable files are on all Windows systems, you should treat this as a broad attack and update quickly.

-    CVE-2025-59230 - Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
This privilege escalation bug allows threat actors to execute their code as SYSTEM on an affected target. These types of bugs are often paired with a code execution bug to completely take over a system. Again, there’s no indication on how widespread these attacks may be, so test and deploy these patches rapidly – especially since all versions of Windows are impacted.

-    CVE-2025-47827 - MITRE CVE-2025-47827: Secure Boot bypass in IGEL OS before 11
This one is a bit of an odd duck, but I’m fascinated by it. IGEL is a Linux-based OS designed to be app centric and modular. According to the vendor, apps can be delivered irrespective of the underlying OS. If anything, that makes this even more intriguing. Somehow, an attacker was able to get physical access to a device in this configuration and bypass the secure boot feature to gain access. Marvelous. I would suspect this to be an extremely targeted attack, but this impacts all supported versions of Windows, so don’t sleep on the patch.

-    CVE-2025-59287 - Windows Server Update Service (WSUS) Remote Code Execution Vulnerability
This bug is not listed as being under active attack, but I suspect it will be targeted soon. This is a CVSS 9.8 bug that allows remote, unauthenticated attackers to exploit code with elevated privileges without user interaction. That means this is wormable between affected WSUS servers. Since WSUS remains a critical piece of anyone’s infrastructure, it’s an attractive target for those looking to do harm. If you use WSUS, don’t hesitate to test and deploy this update quickly.

Here’s the full list of CVEs released by Microsoft for October 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the remaining Critical patches, there are multiple Office patches leading to code execution where the Preview Pane is an attack vector. These continue to haunt Microsoft month after month, so hopefully they can know these out soon. There’s a bug in the Graphics component that rates a CVSS 9.9, but the description does little to detail why this rating is so high. There are several Azure bugs listed in this release, but they have already been resolved and require to further action. An Azure bug you will need to patch is in the Container Instances and would allow and attacker to execute code in the targeted guest environment. That’s the same for the final Critical-rated bug in the Azure Compute Gallery. There’s also a third-party AMD bug that should get some attention. According to Microsoft, “Updates to mitigate this vulnerability in Azure Confidential Computing's (ACC) AMD-based clusters are being developed but are not yet complete.” However, it is public, so watch for any news about exploitation.

Moving on to the other code execution bugs, there are only around 30 in this month’s release and most of these are simple open-and-own in various Office components. In these cases, the Preview Pane is not an attack vector. The bugs in SharePoint Server to require authentication, but the level of privileges needed is not high. There’s a bug in the RDP client, but it requires connecting to a malicious RDP server to exploit. Stepping into the wayback machine, we see several bugs in the Internet Information Services (IIS) that could lead to code execution if a user opened a maliciously crafted file. That’s the same exploit scenario for the bug in the Remote Desktop Protocol. Finally, Microsoft celebrates Halloween by resurrecting Internet Explorer one more time for a patch. Just when you thought IE was gone, it always returns – like Michael Myers chasing the Final Girl, it’s unstoppable.

This month’s batch of Elevation of Privilege (EoP) makes up over half of this release with over 80 patches. Fortunately, most of these bugs lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. Others could lead to elevating levels of code execution integrity – moving from Low to Medium integrity or Medium to Local System for code execution. I should point out that the updates for Bluetooth were silently patched in September and are now just being documented. This is a terrible practice for many reasons, but I won’t go down that rabbit hole right now. Notable exceptions to these are the bugs in Exchange Server. An attacker could use these bugs to take over the mailboxes of all Exchange users, read emails, or download attachments. The bug in the Azure Monitor Agent would allow a threat actor to any read a file on the system with NT SYSTEM privileges from an ARC-enabled VM. Two of the kernel bugs allow any user to crash a system, which sounds like a DoS to me rather than an EoP. There are a couple of bugs that require extra work, too. The vulnerability in Azure Connected Machine Agent need to upgrade to the latest version. For the Virtual Based Security (VBS) enclave, in addition to the patch, you need to apply the Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates, which has been updated to account for the latest changes. Finally, the bug in the Xbox gaming service allows an attacker to delete a specific file, which could be turned into an EoP by those who know.

There are 10 security feature bypass (SFB) patches in this month’s release, with six of those being bypasses of Windows BitLocker. Obviously, these require physical access to a device, but considering one of the actively attacked bugs this month has the same constraint, I wouldn’t ignore these. The bug in Windows Hello could bypass facial or fingerprint recognition. The bypass in ASP.NET could smuggle an HTTP request to bypass front-end security controls or hijack other users’ credentials. For this patch, you’ll also need to take extra steps to ensure your ASP.NET Core application is protected. These steps are listed in the bulletin and vary based on implementation. The bug in RDP could allow an attacker to bypass RDP authentication. The last SFB for the month is in the kernel and allows attackers to decrypt driver settings that would otherwise be obfuscated.

The October release contains over a dozen information disclosure updates, and as expected, most of these bugs only result in info leaks consisting of unspecified memory contents or memory addresses. There are (of course) some notable exceptions. The bug in Cryptographic services could leak secrets or privileged information belonging to the user of the affected application. The vulnerability in ADFS could allow an attacker to obtain Single Sign-On (SSO) cookies in ADFS logs. The bug in the Failover Cluster component could expose any data that is put in the system logs on the Compute Instance including cleartext passwords. In addition to the patch, you should have all impacted users change their passwords. The bug in the Windows Push Notifications exposes memory addresses belonging to the “EventLog” Windows service. There’s a flaw in .NET, .NET Framework, and Visual Studio that could expose PII on affected systems. Finally, the bug in the Taskbar could expose “secrets or privileged information” – for whatever that’s worth.

This month contains 10 different spoofing bugs that require attention (and three that don’t). The bug in the JDBC Driver for SQL allows attackers to trick a target into connecting to a malicious server. There’s not much data about the Data Sharing bug, but authentication is required. The Exchange bug just states, “unauthorized attacker to perform spoofing over a network.” That’s the same description for the NTLM Hash Disclosure and File Explorer bugs. The bug in Confidential Virtual Machines restricts that statement to local users, and the Playwright bug restricts it to adjacent networks.

There are 10 patches for Denial-of-Service (DoS) bugs in this release. As usual, Microsoft provides no actionable information about these bugs. Instead, they simply state that an attacker could deny service over a network (or locally) to that component. The only patch of note is for Office, which states that the Preview Pane is an attack vector – although Microsoft also notes user interaction is required, so it’s not clear how the DoS is triggered.

There’s a Tampering bug in the SMB client, but it requires a machine-in-the-middle (MITM) to be exploited. The October release is rounded out with a cross-site scripting (XSS) bug in Dynamics 365 (on-prem).

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on November 11, and assuming I survive Pwn2Own Ireland, I’ll be back then with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

In April of 2025, my colleague Mat Powell was hunting for vulnerabilities in Autodesk Revit 2025. While fuzzing RFA files, he found the following crash (CVE-2025-5037 / ZDI-CAN-26922, addressed by Autodesk in July 2025):

Is this an exploitable crash? From the debugger output crash point as seen above, unclear whether anything is controllable.

At around this time, my colleague Nitesh Surana uncovered a highly impactful cloud-based supply chain vulnerability in Axis Communications Plugin for Autodesk Revit. This vulnerability made it possible for a malicious actor to force the distribution of corrupted RFA files to Axis plugin users globally, which Autodesk Revit would parse upon use of the Axis Communications plugin. Refer to the blog post here for a full discussion of his research.

Since Trend ZDI was aware of this supply-chain vulnerability, we had a strong interest in determining whether a corrupted RFA file could lead to remote code execution on clients’ machines. I set out to determine the exploitability of the crash shown above. Ultimately, I was able to demonstrate that it could be used reliably for full remote code execution. Thus, in addition to showing the vulnerability of Autodesk Revit, we proved beyond doubt the severity of the Axis plugin supply chain vulnerability.

This article will be devoted to explaining how I reached arbitrary code execution from the crash point shown above. Of particular interest is the technique I used to achieve ROP execution. See the section “Level Up”. Finally, there will be a video showing the ultimate combined effect of a supply-chain attack exploiting the Axis vulnerability and the RCE in Autodesk Revit.

General Assessment of the Root Cause

In investigating the crash, the primary tools I relied upon were IDA Pro and WinDBG with Time Travel Debugging (TTD). Also, due to the modular nature of the Revit application, by which functionality is distributed among many dozens of DLLs, I was able to rely on the presence of export symbols to aid in my understanding. In the paragraphs below I will summarize my findings.

Despite Revit being an extremely heavy application, I was gratified to find that TTD easily captured a full trace of the process when loading the sample RFA. When using TTD in this way, I recommend disabling page heap. Page heap adds a great deal of memory bloat, with little offsetting benefit: when TTD is in use, time travel can be used to determine heap allocation and heap free stacks when necessary.

Tracing tainted data backwards from the crash point, it soon became evident from symbols that a deserializer was involved. The tainted value seen at the crash point was written by a constructor:

This code constructs an object of size 0x10 and initializes it with the first 8 bytes set to 0xffffffffffffffff and the second 8 bytes set to 0. Stepping out backwards in time travel reveals that the constructor sub_1810FDC70 was called from a method named Utility!ARuntimeClass::createObject.

Further tracing revealed that the method Utility!ArchiveClassMaps::loadClass is responsible for reading the type from the input file. In the input file, the type is identified by a 16-bit integer. I noticed that loadClass passes this index value as a2 to the following function:

This proved to be a sort of “Rosetta Stone” for all the numbered types known to the deserializer. It returns a pointer to a PersistentClass structure describing the serializable type indicated by the index a2. The PersistentClass structures for the first 0xb types are found sequentially at the static address unk_180F80FC0, while pointers to the rest are found in the array a1. The size of that array can be seen by examining the bounds check performed in Utility!ArchiveClassMaps::loadClass.

A bit more reversing revealed that offset 0x8 of PersistentClass held a pointer to the corresponding ARuntimeClass, and that offset 0x0 of ARuntimeClass held a pointer to the type name. Armed with this information, I wrote a WinDBG one-liner (okay, two-liner) to dump the names of all types available to the deserializer:

This is intended to be run in WinDBG at the start of sub_1801A4760, so that the array pointera1 is available in @rcx.

The output is quite lengthy, as there is a total of 4,611 types. Abbreviated output is as follows:

Within the list of available types, one finds mostly high-level C++ classes such as ADocument supporting application logic, but also various simple data types such as integers or std::pair types where the first pair member is a simple numeric type. The class index that led to the crashing object is 0xc4, corresponding to the type:

          std::pair< ElementId, ElementIdSetWrapperClass >

We can now understand the code of the constructor sub_1810FDC70described above. It is the default constructor for a pair, where the first element of the pair is of the numeric type ElementId and the second element is a pointer (I assume) to an instance of type ElementIdSetWrapperClass. The constructor initializes the pair’s first element to an ElementId of -1, and it initializes the pair’s second element to nullptr.

Furthermore, now we can make an educated guess as to the root cause of the vulnerability. The application deserializes objects from the input file. Its expectation is that those objects will be instances of the high-level classes, each of which has a vtable pointer at offset 0x0, and where the first entry in the vtable is the destructor. However, the deserializer is also capable of deserializing simple types that do not have a vtable. In our case, the object deserialized was a std::pair< ElementId, ElementIdSetWrapperClass >, and the value at offset 0x0 was not a vtable pointer but rather was -1 (=0xffffffffffffffff). When the application attempted to invoke the object’s destructor, it crashed upon dereferencing that value. What we have, then, is a type confusion vulnerability.

Exploiting the type confusion involves choosing an appropriate object to be deserialized, so that we can control program execution when the application attempts to invoke the destructor via the vtable pointer. First, however, we will need to learn how to understand the format of the input file so that we can manipulate its contents. This became a significant subtask in the exploitation challenge.

Exploring the Autodesk RFA Compound Document Format

From a visual inspection of the RFA file in a hex editor, I surmised that the overall format was an OLE Compound File.

An OLE compound file acts as a miniature filesystem that lives within a file. It contains a structure of directories (known as “storages”), and within the storages there can reside data files (known as “streams”).

By painstaking tracing of tainted data using WinDBG, I was able to determine that the serialized data comes from the stream Global\Latest – that is, from a stream named Latest located within a storage named Global, which itself is located at the root of the RFA compound file. However, there was a further complication. Global\Latest does not contain the literal bytes that will be presented to the deserializer. Rather, I found that the contents of Global\Latest is first processed by a gzip-type decompression routine, which I was able to identify by the export symbols. The un-gzipped data is what is fed to the deserializer, and has the bytes we are interested in, such as the all-important class index discussed above.

To proceed with experimenting on the file, I needed the following two items:

1. A method of editing an OLE compound file, so I could modify the contents of the Global\Latest stream.
2. A way to gunzip the data from the Global\Latest stream, and to gzip it again after modification, using compression compatible with the Revit software.

Presenting CompoundFileTool

To facilitate my research, I wanted a tool that would allow me to easily examine the contents of an OLE compound file and to create new OLE compound files with arbitrary contents. I was not satisfied with the tools I found by searching online and decided to create my own. Together with the publication of this article, we are opening this tool to the community.

Although the OLE compound file format is intended to be a live, editable filesystem, it is not always most convenient to address it in that way. It could also be treated as simply another archive format. The way my tool allows examination of an OLE compound file is by expanding it out into the normal filesystem. It can expand an OLE compound file into a corresponding structure of folders and files on disk. It can also perform the inverse operation to create a new OLE compound file.

You can find the source code here. I hope you find it useful to incorporate it in your fuzzing toolchain whenever you do research on software that consumes compound files.

Decoding Revit’s Gzip Format

The gzip compression used by Revit caused me some confusion for a while. The stream contains a brief header, followed by gzipped data. After the gzipped data, though, I found that there was some sort of padding section consisting of zeroes, and finally another section of high-entropy data.

At first, I did not understand the significance of this final section, so I attempted to ignore it. I mutated an RFA by replacing the gzipped data section with my own gzipped data, keeping the padding and the final data section a constant. Revit rejected this modified file as corrupt.

Moreover, I began noticing worrisome discrepancies. I ran the gzipped data from the Global\Latest stream through a standard gunzip utility and compared it with what was presented to the deserializer, as seen inside the debugger. The two versions were a close match, yet not exact.

After puzzling over this for a while, I discovered that the final section consisted of error correcting codes. Public symbols and diagnostic log text strings found in Utility.dll assisted me in reaching this understanding.

When Revit loads a tampered file, for example, a file that was altered by a fuzzer or by manual insertion of crafted data, there are three possible outcomes. If the damage is minor, the data may be successfully recovered. In that case, the changes made by the fuzzer will be reverted entirely. With somewhat more damage, the error correcting codes will do an imperfect job of restoring the original data. In the case of extensive damage, such as a case in which the gzipped data was replaced by entirely different data, Revit determines from the mismatched error correcting codes that the file is corrupt beyond recovery.

Consequently, to properly control the bytes that will be presented to the deserializer, it was crucial to have the ability to produce a correct error correcting code trailer for the stream. Similarly, to be able to take an existing fuzzed RFA file and extract from it an accurate copy of what the deserializer sees, I needed to mimic Revit’s behavior when it performs error correction. To perform these tasks, I created one additional tool for my chain. I accomplished this by copying a minimal subset of low-level DLLs and configuration files from a Revit install and writing a wrapper in C++ to call the appropriate methods. This took care of the gzip/gunzip as well as the error correction tasks in a single step.

Exploiting the Type Confusion

With those tools in my arsenal, I finally was able to rewrite RFA files at will.

As explained above, the original crash occurred due to deserialization of a type with index 0xc4, which is std::pair< ElementId, ElementIdSetWrapperClass >. I began to ponder which type from the list of available types would give me the best advantage for arbitrary code execution.

Recall that the type confusion bug results in a pointer value being read from offset 0x0 of the deserialized object. The software assumes that this is a vtable pointer, and it proceeds to call the first function pointer in the vtable, which is supposed to be the destructor for the object.

Thus, for successful exploitation, we want to choose an object that has a controllable value at offset 0x0, which will be used as a vtable pointer.

After experimenting for a while with the deserializer, I had an epiphany – an absolutely perfect candidate exists. That type is AString, with class index 0x1f.

Why AString? AString is perfect for our needs. Its memory layout is this:

The data at offset 0x0 within an AString instance is guaranteed to be a valid pointer, avoiding a crash. Furthermore, to what does it point? To a buffer containing attacker-controlled data, as read by the deserializer from the input file! Analysis of the AString deserialization code revealed that it reads string data from the input file in length-prefixed format, not in null-terminated format. Consequently, the contents of the string buffer is entirely unrestricted; we can even include null bytes with impunity. For the attacker, this is pure gold. We’re now ready to start turning the type confusion into a remote code execution exploit using ROP.

Development of the ROP Chain

Before we begin ROP exploitation, we’ll need some ASLR defeat. Examining the modules loaded into the Revit process, I found that there was one that did not support ASLR: RWUXThemeSU2015.dll (SHA256 aab0a6ae39b7f503aa0a77d4c85b8603be11982ad5207dddfb0e2e154a411bf2). One module is all it takes. The size of the .text segment of this module is 72 KB, which is large enough to provide a diverse assortment of ROP gadgets.

RWUXThemeSU2015.dll imports both LoadLibraryW and GetProcAddress. By calling these two functions, we can obtain a pointer to an arbitrary export from an arbitrary DLL in the process without the need for any additional hardcoding of offsets that could introduce fragility. My plan was to retrieve the address of ucrtbase!system and to call that function to obtain arbitrary code execution.

Before I could begin assembling a ROP chain, though, there was one major technical hurdle. In the most straightforward ROP scenario, the attacker starts with a stack smash, giving the attacker the opportunity to write at least the beginnings of a ROP chain to the stack. In that situation, the first gadget pointer of the ROP chain overwrites a return address on the stack, and successive gadget pointers occupy successively higher stack locations. Once the target process performs a ret, instead of fetching a legitimate return address, it fetches the address of the first ROP gadget and transfers control there. ROP execution commences at that point.

Our situation is different. We have no stack smash, so there is no opportunity to write any part of a ROP chain to the stack. Instead, we must do it the other way around; we must modify rsp to point to our controlled memory. This is known as a “stack pivot”.

We have a chicken-and-egg problem, though. To launch a ROP chain, we must modify rsp. But, to modify rsp, we need at least some minimal ability to execute code, which means we need to already be running ROP.

Let’s use IDA to look at the crash site, highlighted in yellow:

Figure 1

Note that rbx is a pointer into an array of objects being destructed, one of which is our AString. The code fetches [rbx] into rcx. At that point, rcx is a pointer to our AString. Next it fetches [rcx] into rax, so rax points to our controlled AString bytes. Finally, it performs call qword ptr [rax], allowing us to perform a call to any address we would like. Essentially, what we have here is the power to execute exactly one ROP gadget, but no more, because the stack is not yet pivoted. You have been granted one wish. Choose wisely.

Recalling that rax points to our controlled AString bytes, what we most want is to move rax into rsp. An ideal gadget would look something like this:

Does any such gadget exist? Regrettably, not. This isn’t surprising, though. Restoring rsp from rax isn’t an idiom that one would expect a compiler to emit. Furthermore, the instruction mov rsp, rax requires 3 opcode bytes (48 8B E0), so the probability of finding this byte sequence purely by chance within the .text segment (e.g., as misaligned bytes of other instructions) is quite low.

Sequences such as push rax; pop rsp or lea rsp, [rax+…] would also be usable, if they could be found.

As a fascinating digression, things are somewhat easier if the address in rax is effectively a 32-bit address, meaning that the upper 32 bits of rax are all zeros. I found this to be the case on Windows 10, where the heap buffer containing AString data tends to be in the 32-bit range 0x00000000- 0xffffffff. In that case, for a stack pivot instruction, instead of mov rsp, rax, we could get away with mov esp, eax. While still not idiomatic, this does have the major advantage that it requires only 2 opcode bytes instead of 3. Perhaps we could find these two bytes by chance (8B E0).

Monster Gadget Hunting

I was unable to find a usable mov esp, eax gadget just by running an off-the-shelf gadget-finding tool (ROPgadget). ROPgadget and similar tools work by scanning the target module and cataloging short runs of instructions ending with a control transfer instruction – usually a ret, but sometimes a jmp or even certain calls. Under favorable circumstances, such an automated tool will turn up a wide enough variety of gadgets to allow you to assemble a ROP chain. Here, though, my needs were a bit different. Rather than a sufficiently varied assortment of gadgets, what I needed was one very specific kind of gadget, and I needed it desperately. It was time to play dirtier.

I loaded RWUXThemeSU2015.dll into a hex editor and looked for any occurrence of 8B E0 (mov esp, eax). This offered the possibility of getting some occurrences that ROPgadget missed because they are not found within short sequences ending with a control transfer instruction. I found 12 matches in all and started examining them manually. One of them looked like this. The instruction 8B E0 (mov esp, eax) is obtained by starting execution with the second byte of the highlighted instruction, which is at address 0000000180003a36:

Figure 2

There is quite a long distance from the first instruction into the final ret, which certainly helps explain why ROPgadget didn’t include this in the ROP gadget catalog it offered me. This gadget, if you can even call it that, is a monster! Could it be useful all the same? I saw several important things right away:

• The function has no looping.
• It also has no exception throws, aborts, or other paths that could lead to process termination.
• There are numerous calls, as seen above. However, they are all calls to imported functions from GDI32.dll. In case of error conditions (which are highly likely, considering how badly we’re abusing the code), GDI32 functions are likely to merely return with an error code, and not cause any critical stop (though, see my note below regarding stack alignment).
• Since there are no stack-based buffers, the compiler has not emitted a stack cookie check at the end of the function.
• Though it’s only typical in 64-bit code, there is no epilog that restores rsp from rbp. Any modifications made to rsp are “sticky”. They will persist to the end of the function and beyond.

In other words, it looks like we might be able to call 0000000180003a36 to get our mov esp, eax stack pivot, and let the rest of this somewhat large function run its course. The ret at the end will then launch into our ROP chain, because rsp has already been pivoted to our controlled memory. Magically, this worked! The monster gadget shown above executed, start to finish, without harming the process, netting me just the required stack pivot. This solved my problem, on Windows 10 at least, where, as noted above, the heap address in rax tends to be reliably in the range ffffffff and lower.

In one respect I was incredibly lucky here. Since the initial value of eax lacked 16-byte alignment (reliably so, it turns out), when transferring this value into rsp and then making numerous GDI calls, those calls could easily have resulted in processor exceptions that would have terminated the process. It was my good fortune that, throughout all those GDI calls, no processor instructions requiring correct 16-byte stack alignment were encountered.

Level Up: A 64-bit Stack Pivot for Windows 11

The exercise above yielded an acceptable stack pivot, but only on Windows 10. On Windows 11, rax will be above ffffffff, so a true 64-bit move is required. I tried more monster gadget hunting, but to no avail. In addition to the techniques mentioned above, I used wildcard searches in the hex editor, for example, to look for a push rax followed soon by pop rsp. Nothing was working.

I was at a dead end and it was time to take a different approach. Mulling my options, and necessity being the mother of invention, my mind began to turn to something I’d only dimly appreciated earlier. Refer again to the flow graph of Figure 1. rbx is the pointer into the array of objects being destructed; every time around the loop, rbx points to the next array element. The code reads the array element into rcx, so rcx is a pointer to the object to be destructed. Every time around the loop, it fetches a new vtable pointer into rax and then calls [rax], which is, according to intention, the corresponding destructor function.

We can use this loop as a weird machine.

That’s right – besides ROP, we have a second weird machine at our disposal: the loop at 0x1802851C0 itself! Within the serialized document, we can specify multiple AString objects. Each time around the loop, when it executes the call qword ptr [rax] instruction, it effectively runs a single gadget of our choosing. Theoretically, perhaps, we don’t even need ROP! We can just specify many AString objects, and for each one, we get to execute a single gadget.

Now, this wouldn’t be the most flexible approach, because we would need to ensure that none of our gadgets disturb registers that the loop requires, especially rbx and to a lesser extent rdi. Worse, we would have to tolerate all register modifications made by the loop. However, we don’t need to use this weird machine to obtain arbitrary code execution. All we need is to use it to get a stack pivot. Then, upon the final loop iteration, we can launch conventional ROP.

Once my mind dared to appreciate the potential power of this new weird machine, the solution to my problem became easy. My idea was to use the loop machine to execute multiple gadgets, successively moving the value from the (original) rax to different locations, until I could finally move it to rsp. Now, if you want a value to end up in rsp, what finer register to move it to first than rbp. Can we move directly from rax to rbp? Indeed, we can!

           0000000180009246 : push rax ; pop rbp ; ret

This is the gadget we will execute the first time around the loop. The data of the first AString will begin with a pointer to this gadget. (Side note: The pop rbp; ret; part of this gadget was emitted by the compiler intentionally. The push rax part emerges from a misaligned reading of the instruction that precedes pop rbp.)

Next, we need a gadget that moves rbp into rsp. That also was easy to locate:

          0000000180001109 : leave ; or eax, ecx ; ret

leave is equivalent to mov rsp, rbp ; pop rbp, and, being a one-byte opcode, leave gadgets are relatively easy to find. This completes the transfer of the (original) rax value into rsp. Control never returns to the loop. Instead, the ret instruction of the leave gadget transfers control to the conventional ROP chain. The ROP chain is located within the first AString, immediately after the pointer to the first loop gadget. This is because the rax value transferred to rbp was the rax value associated with the first AString, not the second AString. In summary, I used a somewhat constrained, loop-based weird machine to execute a stack pivot, allowing me to continue execution with a conventional, full-fledged ROP weird machine. And right there is one of the most beautiful things I’ve ever created.

Adventures in Windows x64 ROP

The final major subtask in crafting this exploit was to compose the ROP chain itself.

ROP tends to be considerably more difficult on 64-bit Windows than on 32-bit Windows – even here, where CET is not active – and seems to be somewhat more difficult even than ROP on 64-bit Linux.

Whereas on 32-bit Windows, all function arguments are passed via the stack, on 64-bit Windows the first four arguments are passed via registers, namely rcx, rdx, r8, and r9. Before calling any API, one must utilize gadgets to load the appropriate registers. Moreover, all four of these registers are caller-saved, also known as “volatile” registers, meaning that callees are not responsible for restoring them before returning. Consequently, on Windows, compiled functions rarely end with sequences of instructions that are useful for loading those registers. For example, we will need a gadget to load an argument into rdx, but we won’t find any functions that end with pop rdx; ret, because functions aren’t responsible for restoring rdx before returning.

I have not studied this in depth, but matters seem to be a bit easier on Linux in this regard. Though the situation on Linux seems outwardly similar, in that function arguments are passed via volatile registers (which on Linux are rdi, rsi…), nevertheless, on Linux, the compiler will at times emit sequences usable for loading those registers (for example, pop rsi; ret). This seems to be a peculiarity of the gcc toolchain typically used on Linux.

The difficulty of ROP on 64-bit Windows may account for the relative lack of examples found online. For this reason, I am going to go into some detail on how I constructed my 64-bit Windows ROP chain. For starters: I planned to place some literal strings within the ROP chain to pass as arguments, for example, the command string to pass to ucrtbase!system. To be able to pass a literal string on the ROP stack as an argument, I needed a gadget that would move a stack address (rsp plus an offset) into another register I could work with, and eventually into rcx. Furthermore, as we will see, the ability to obtain a stack address is a generally useful primitive. I found this gadget:

          0x0000000180004c29 : lea rcx, [rsp + 0x20] ; call rax

This is perfect for retrieving a stack address into rcx. The only small trouble is that this gadget does not end with ret. I needed a way to properly resume ROP execution after this gadget. I went with this solution:

This looks like a 3-gadget chain, but it’s a bit more subtle than that. The first gadget pops a certain address into rax, and that address happens to be the address of that very same gadget: pop rax; ret. Now, since the second gadget has already been popped, the next gadget to execute is the third one: lea rcx, [rsp + 0x20] ; call rax. That gadget moves the desired stack address into rcx, then continues by calling rax. To where does this transfer control? To the second pop rax ; ret gadget – because that is what we’ve placed in rax. This pop rax takes the return address that has just been pushed by call rax and pops it back off the stack, moving it into rax but otherwise safely discarding it. Finally, ret continues ROP execution in the normal fashion, starting with the next gadget in stack order following the lea gadget. Keep in mind this technique for cancelling an undesirable return address on the stack, as we will use it again later on.

Genetically Modified Gadgets

As mentioned above, a particular difficulty with ROP on 64-bit Windows arises from the need to load function arguments into registers. Arguments are passed via volatile registers such as rdx, but, since these registers are volatile and are not restored at the conclusion of functions, typically there is a lack of gadgets like pop rdx ; ret. This can make loading arguments quite a tough challenge, because the required gadgets may not exist.

In the section above regarding what I call “monster gadgets”, I discussed how I used a hex editor to search more deeply for opcode sequences that could possibly be useful and then used a disassembler to analyze whether those sequences lead to something that could be used as a gadget, however unconventionally. In this instance, though, I took it one step further and crafted a gadget that didn’t exist. Wait, what? Isn’t the whole point of ROP that you don’t yet have the ability to write to executable memory, so you must rely exclusively on existing sequences of opcode bytes?

Well, that is true – almost true. Let me show you what I found, and how in this instance I was able to create a gadget that wasn’t there at the outset.

Consider the following code, found at 0x00000001800040f9:

Figure 3

Here we have some code that loads rdx, a volatile register we need to load. It loads it from rsi, which is a register we can load easily: Since rsi is callee-saved, gadgets of the form pop rsi ; ret are abundant. Of course, the trouble is that the most important element is missing: After it loads rdx, instead of returning to the ROP chain, the code calls some other function, RWOpenThemeData. Where does that lead?

Figure 4

RWOpenThemeData, it turns out, is a wrapper around a call to a function pointer stored at 18001EE38. As part of DllMain initialization, the module populates this function pointer with the address of UXTHEME! OpenThemeData, obtained using a call to GetProcAddress. Unsurprisingly, after initialization, the module leaves the page containing the function pointer in a PAGE_READWRITE state. All told, nothing prevents our ROP chain from overwriting the function pointer at 18001EE38, radically altering the control flow of the code in Figure 3. What should we choose to write into 18001EE38? How about this, our old standby:

          0x0000000180008e5f : pop rax ; ret

After the jmp rax of Figure 4 jumps to 0x0000000180008e5f, the pop rax will safely consume the return address that had been pushed onto the stack by the call in Figure 3, and execution will continue with ret. The net effect is that we’ve turned the code in Figure 3 into this gadget:

          0x00000001800040f9 : mov rdx, rsi ; mov rcx, rdi ; /* stomp rax */; ret

Voilà! Even though, to start with, the module didn’t seem to contain a gadget for loading rdx, I was able to create one through “genetic modification” by altering a function pointer.

I Told You Loading Registers Was Hard

After considering numerous permutations, I found the following overall plan to be workable:

1. Load the address of the stack-based wide string ucrtbase.dll into rcx and call the LoadLibraryW import of RWUXThemeSU2015.dll.
2. Move the result of LoadLibraryW from rax into more durable storage. I found rbx to be a good choice.
3. Using a write-what-where primitive, which is easily crafted, write the narrow string system into a static writable memory location, and then pop (load) its address into rsi.
4. Invoke the genetically modified gadget at 0x00000001800040f9, described earlier, to move rsi into rdx. This sets up the second parameter for GetProcAddress.
5. Move the module address from rbx into rcx. How to accomplish this is the only major challenge we haven’t yet discussed.
6. The proper arguments for GetProcAddress are now in rcx and rdx. Invoke the GetProcAddress import of RWUXThemeSU2015.dll. The result is in rax.
7. Load the address of the stack-based command line string into rcx and call ucrtbase!system via the function pointer in rax.

As noted in step 5 above, there is still one hole in the plan. We need to find a way to move rbx into rcx, and to do so without disturbing the data in rdx we worked so hard to load. Since rcx is a volatile register, this is challenging to accomplish, though less so than loading rdx was. The solution I found was rather convoluted but at least did not involve any genetic modification:

As you can see, my solution made use of the same stack address retrieval primitive that I discussed earlier, plus a new sequence of four gadgets.

After setting up rcx with a stack address, I invoke the gadget 0x0000000180006a25 to move rbx into rax as a first step. Next, I use the gadget 0x0000000180011dc4, which stores rax into a location just a bit further up on the stack. (Note that this gadget also contains an unwanted xchg. This writes to the ROP stack, but I just barely escape damage because the corrupted gadget address happens to be the one most recently read, which is to say, the address of this very gadget that is currently executing! Since the address has already been read, corrupting it has no effect.) Next, I adjust the stack pointer upward by 8 bytes using a gadget consisting of a single ret, and finally I execute a pop rcx; ret gadget to load rcx from the data that had been stored to the stack. With that, at long last, the parameters are all prepared for the call to GetProcAddress.

I finished the ROP chain as follows:
• I called GetProcAddress
• I moved the result of GetProcAddress from rax into rbx, because rax won’t be preserved by the following gadget
• I used my stack address primitive one final time to load the address of a command string into rcx
• I called ucrtbase!system using the gadget jmp rbx

For the command string I used powershell.exe with the -Command switch, which provides plenty of flexibility for arbitrary code execution. As a final note, ucrtbase!system does not return until the spawned shell process exits. So, if desired, the spawned process could take this opportunity to alter the memory of the Revit process and fix up all the damage, allowing the Revit process to continue without a crash.

I’m releasing my full notes on the ROP chain here.

Miscellaneous Notes and Lessons Learned

Here I would just like to include a few items regarding ROP on 64-bit Windows that did not fit logically into my exposition above but nonetheless may be useful to the reader.

1. When calling any function, keep in mind that the function may need a significant amount of stack space to execute correctly. If you pass a literal on the stack, the function’s execution could easily overwrite the literal, resulting in improper execution. Accordingly, immediately before making the call, execute a sequence of gadgets that advance the stack pointer sufficiently to avoid a conflict. You will have to determine the required amount experimentally.
2. Similarly, if you have performed a stack pivot such as the one described in this article, rsp will likely be pointing within a heap block. If you do not advance the stack pointer sufficiently before you make a call, stack growth during the call may corrupt heap memory below the current block. Then, heap routines such as HeapAlloc and HeapFree, executing on the current thread or any other thread, may detect the corruption and abruptly terminate the process before your exploit is complete. As above, the solution is to advance the stack pointer sufficiently prior to making a call.
3. In the Windows x64 calling convention, callees are entitled to use the 0x20-byte region just above the return address on the stack as a scratch area (“shadow space”). After the return from a function, therefore, you have no guarantee of the integrity of those next 0x20 bytes of the stack. To compensate for this, whenever you call a function from ROP, the very next gadget must immediately advance the stack pointer past this possibly corrupted region.
4. Stack alignment: In the Windows x64 calling convention, rsp is 8-byte aligned at all times; however, the rules for 16-byte alignment are more subtle. Before the first instruction of every function, rsp MUST NOT be 16-byte aligned. Another way to say this is that, before every call instruction, rsp MUST be 16-byte aligned; the call will decrement rsp by 8 and store the return address at the new rsp, so that the first instruction of the callee will execute with a 16-byte non-aligned rsp as expected. When calling functions (or significant portions thereof) from ROP, stack alignment must be considered. Before executing a call to the start of a function, ensure that rsp is 16-byte aligned. In contrast, before executing a jmp to the first instruction of a function, ensure that rsp is not 16-byte aligned. If you use ROP to perform a call or jmp to an instruction somewhere in the middle of a function, you may need to consider stack alignment and bring rsp into 16-byte alignment or 16-byte non-alignment as expected by the code you are calling; apart from prolog and epilog code, most compiled code expects 16-byte aligned rsp. (For the vast majority of typical short gadgets, though, stack alignment is of no consequence.) Changing from 16-byte aligned to 16-byte unaligned rsp or vice-versa within ROP is as simple as executing a single ret gadget. However, a more advanced solution would be needed if, at the start, you do not know the state of rsp alignment with certainty.

Combined Demo: Axis Supply Chain Vulnerabilities + Autodesk Revit RCE

Please refer to this article  by my colleague Nitesh Surana regarding the cloud vulnerabilities he discovered in the Axis Communications Plugin for Autodesk (ZDI-24-1181, ZDI-24-1328, ZDI-24-1329, and ZDI-25-858). Had an attacker taken advantage of those cloud misconfigurations, they could have replaced RFA files in  cloud storage accounts belonging to Axis. Those RFA files would then have been served to Revit users who happen to use the Axis plugin, worldwide, whenever users added Axis products to their models in Autodesk Revit. In this way the attacker would achieve “one-click” remote code execution at scale. The following video simulates the consequences of a supply chain attack. The only simulated part is that a crafted RFA file is introduced artificially, by means of a Fiddler proxy, into the network traffic between Axis cloud storage and the plugin. Once the RFA file is delivered, the Revit application parses it automatically, and the video shows actual execution of the ROP exploit.the video shows actual execution of the ROP exploit.

Conclusion

In this article I have provided you with an overview of how I started with an Autodesk Revit file parsing crash of highly uncertain potential, and turned it into a code execution exploit that is fully reliable even on the latest Windows x64 platform. This RCE is unusually impactful due to the Axis cloud misconfiguration that could have resulted in automatic exploitation during normal usage of the affected products. I hope you have found the techniques discussed here informative and beneficial to your own research.

I would like to thank my colleagues Mat Powell and Nitesh Surana for their contributions to this research. Hopefully, we’ll have more tools and techniques to release in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

While investigating the security posture of various machine learning (ML) and artificial intelligence (AI) frameworks, the Trend Micro Zero Day Initiative (ZDI) Threat Hunting Team discovered a critical vulnerability in the NVIDIA Merlin Transformers4Rec library that could allow an attacker to achieve remote code execution with root privileges. This vulnerability, tracked as CVE-2025-23298, stems from unsafe deserialization practices in the model checkpoint loading functionality. What makes this finding particularly interesting is not just the vulnerability itself, but how it highlights the endemic security challenges facing the ML/AI ecosystem’s reliance on Python’s pickle serialization.

In this post, I’ll walk through the discovery process, demonstrate the exploitation technique, analyze the patch, and discuss why this class of vulnerability continues to plague machine learning frameworks despite years of warnings from the security community.

NVIDIA Transformers4Rec

NVIDIA Transformers4Rec is part of the Merlin ecosystem, designed to leverage state-of-the-art transformer architectures for sequential and session-based recommendation tasks. Transformers4Rec acts as a bridge between natural language processing (NLP) and recommender systems (RecSys) by integrating with one of the most popular NLP frameworks, Hugging Face Transformers (HF). According to NVIDIA, Transformers4Rec makes state-of-the-art transformer architectures available for RecSys researchers and industry practitioners.

Transformers4Rec is widely used in production environments for building recommendation systems, particularly in e-commerce and content platforms. The library integrates with other NVIDIA tools like NVTabular for preprocessing and Triton Inference Server (a target in the inaugural AI category at Pwn2Own Berlin 2025) for deployment, making it a critical component in many ML pipelines.

During our research into ML/AI supply chain security, we decided to audit how various frameworks handle model persistence and loading. Given the popularity of Transformers4Rec in production environments and its integration with PyTorch’s serialization mechanisms, it became an interesting target for analysis. 

The Vulnerability Discovery

The vulnerability exists in the load_model_trainer_states_from_checkpoint function, which is responsible for restoring model states during training resumption or model deployment. While reviewing the codebase, we noticed that this function directly uses PyTorch’s torch.load() without any safety parameters. Here’s the vulnerable checkpoint loading function before the patch:

This immediately raised red flags. The torch.load() function uses Python’s pickle module under the hood, which is notoriously unsafe when handling untrusted data. The pickle protocol allows arbitrary Python objects to be serialized and deserialized, including objects that execute code during the deserialization process.

Understanding the Attack Surface

To understand why this is dangerous, we need to examine how pickle works. When pickle deserializes an object, it can execute arbitrary Python code through methods such as __reduce__. This isn’t a bug – it’s a feature that allows complex objects to control their own serialization process. However, it becomes a severe security vulnerability when loading untrusted pickle files.

The attack surface is particularly concerning because:

1.        Model sharing is common: Data scientists regularly share pre-trained models through repositories, cloud storage, or direct file transfers.

2.        Checkpoint files are trusted: Developers often assume checkpoint files are safe, especially when they appear to come from legitimate sources.

3.        Execution context: The vulnerability executes in the context of the process loading the model, which often runs with elevated privileges in production environments.

Crafting the Exploit

To demonstrate the vulnerability, we created a malicious checkpoint file that would execute arbitrary commands upon loading. The exploit leverages pickle’s __reduce__ method to execute system commands:

When a victim loads this checkpoint file using the vulnerable function, the os.system command executes immediately before any model weights are loaded. This happens because pickle deserializes objects in order, and our malicious object triggers during the deserialization of model_state_dict.

Real-World Impact

The potential impact of this vulnerability can be severe:

— Remote Code Execution: Attackers can execute arbitrary commands on the target system.

— Privilege Escalation: If the ML service runs with elevated privileges (common in production), the attacker gains those privileges.

— Data Exfiltration: Access to training data, model weights, and potentially other sensitive information.

— Supply Chain Attacks: Malicious models could be distributed through model repositories or sharing platforms.

— Lateral Movement: Compromised ML systems could serve as a foothold for broader network intrusion.

The vulnerability is particularly dangerous in automated ML/AI pipelines where models are loaded without human review, such as continuous training systems or automated model deployment pipelines. 

The Patch Analysis

NVIDIA addressed this vulnerability in commit b7eaea5 (PR #802). This changed how checkpoint files are loaded and added additional input validation of serialized python objects.

Figure 1 - The patch adding a custom load function in transformers4rec/torch/trainer.trainer.load_model_trainer_states_from_checkpoint

The Transformers4Rec library now implements a serialization mechanism through serialization.py which restricts deserialization to approved classes.

Figure 2 - The patch adding additional validation in transformers4rec/utils/serialization.py

Here’s the vulnerable checkpoint loading function after the patch:

Lessons Learned and Recommendations

This vulnerability highlights several important lessons for the AI/ML security community:

For Developers:

           • Never use pickle for untrusted data: This cannot be emphasized enough.

           • Never assume checkpoint files are safe: Checkpoint deserialization is vulnerable to supply chain attacks.

           • Always use weights_only=True when using PyTorch’s load functions.

           • Restrict to trusted classes: Restrict deserialization to only trusted classes.

           • Implement defense in depth: Don’t rely on a single security measure.

           • Consider alternative formats: Safetensors, ONNX, or other secure serialization formats should all be considered.

For Organizations:

           • Audit model provenance: Know where your models come from.

           • Implement model signing: Cryptographically verify model integrity.

           • Sandbox model loading: Run deserialization in isolated environments.

           • Regular security audits: Include ML pipelines in security assessments.

For the ML Community:

           • Consider moving away from pickle: The community needs to seriously consider deprecating pickle-based serialization.

           • Update torch to the latest version: The latest version of torch uses weights_only=True by default.

           • Develop secure standards: Establish and enforce secure model serialization standards.

           • Security-first design: Build ML frameworks with security as a primary consideration, not an afterthought

Conclusion

CVE-2025-23298 represents yet another instance of unsafe pickle deserialization in the ML/AI ecosystem. While NVIDIA has patched this specific vulnerability, the underlying issue – the ML/AI community’s continued reliance on inherently unsafe serialization methods – remains. As machine learning systems become increasingly critical to business operations and decisions as the foundation of the AI ecosystem, we can no longer afford to treat security as an afterthought. Rigid security measures and a zero-trust mentality must be central as we develop and push towards agentic AI.

The discovery and coordinated disclosure of this vulnerability (thanks to NVIDIA for their work) hopefully serves as another wake-up call. The question isn’t whether more pickle-related vulnerabilities exist in ML/AI frameworks; it’s how many are currently being exploited in the wild.

Until the community moves away from pickle entirely, we’ll continue to see these vulnerabilities. In the meantime, developers must remain vigilant, implement proper security controls, and treat all model files as potentially hostile. You can find me online here, and you can follow the ZDI team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploitation.

Disclosure Timeline

— 2025-05-22 - Vulnerability reported to vendor
— 2025-08-13 - Coordinated public release of advisory
— 2025-08-14 - Advisory Updated

There’s a crispness in the air – at least here in North America – and with it comes the latest security patches from Adobe and Microsoft. Take a break from your scheduled activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for September 2025

For September, Adobe released nine bulletins addressing 22 unique CVEs in Adobe Acrobat Reader, After Effects, Premiere Pro, Commerce, Substance 3D Viewer, Experience Manager, Dreamweaver, Adobe 3D Substance Modeler, and ColdFusion. Of these, the ColdFusion update is the only Priority 1 patch, although Adobe notes no exploitation has been detected. The patch for Commerce addresses a single, Critical-rated bug that is rated a priority 2. Again, no exploitation is noted. Also of note is the update for Acrobat, which fixes one Critical and one Moderate-rated bugs.

 The patch for After Effects fixes three Important-rated bug fixes three Important-rated bugs. There’s a single bug in Premiere Pro that could lead to code execution. The fix for Substance 3D Viewer addresses three separate code execution bugs. That’s the same for the patch for Substance 3D Modeler. The fix for Experience Manager is the largest patch this month, with seven fixes. However, only one of these is rated Critical. The bug is Dreamweaver corrects a single Cross-Site Request Forgery (CSRF) bug.

 None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Besides the patches for ColdFusion and Commerce, all updates are listed as deployment priority 3.

Microsoft Patches for September 2025

This month, Microsoft released 80 new CVEs in Windows and Windows Components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, Hyper-V, SQL Server, Defender Firewall Service, and Xbox (yup – Xbox!). Of the patches released today, eight are rated Critical, and the rest are rated Important in severity. This puts Microsoft about 100 CVEs ahead of where they were last year in terms of volume. We’ll see if this level of patches remains high throughout the rest of the year.

Microsoft lists one bug as being publicly known at the time of release, but nothing is noted as being under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with a bug rated as a CVSS 9.8:

-    CVE-2025-55232 - Microsoft High Performance Compute (HPC) Pack Remote Code Execution Vulnerability
This is the highest severity bug by CVSS (9.8) for this month, and it certainly earns it. A remote, unauthenticated attacker could gain code execution on affected systems without user interaction, which makes this potentially wormable between systems with the HPC pack installed. Microsoft recommends ensuring HPC Pack clusters are only deployed in secure enclaves. They also recommend blocking TCP port 5999. If you use HPC Pack clusters, definitely put this on the top of your patching list.

-   CVE-2025-54910- Microsoft Office Remote Code Execution Vulnerability
This is now the eighth month in a row where at least one Office component allowed code execution through the Preview Pane. It would be nice is Microsoft could consolidate some of these fixes rather than dragging them out month after month, but I doubt that will happen. I’m getting very close to recommending disabling the Preview Pane for a bit while Microsoft sorts this out.

-    CVE-2025-54918 - Windows NTLM Elevation of Privilege Vulnerability
This privilege escalation allows an authenticated threat actor to escalate to SYSTEM on affected systems over the network. While not a scope change, going from a standard Windows user to SYSTEM is handy. Microsoft also notes that exploit complexity is low, so expect to see threat actors target this one. Definitely test and deploy this update quickly.

Here’s the full list of CVEs released by Microsoft for September 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the remaining Critical patches, there are several in the Graphics Component and Graphics Kernel, but these require an authenticated user and could be considered privilege escalations as much as code execution bugs. There’s also a Critical-rated info leak in the Windows Imaging Component, but considered this only leaks random portions or memory, it’s not clear why this is rated Critical.

Moving on to other code execution bugs, there are quite a few open-and-own bugs in Office components, mostly Excel. There’s the monthly RRAS bugs. There’s a frightening looking bug in SMB Client, but it requires authentication. That’s also true for the NTFS bug. The bug in SharePoint requires Site Owner permissions, but any user who has the ability to create a site on SharePoint has these privileges. The final code execution bug is in the Windows Graphics Component and requires user interaction. All in all, it’s a petty light month for code execution bugs.

That same thing can’t be said about Elevation of Privilege (EoP) bugs, which make up almost half of this month’s release. Fortunately, most of these bugs lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. There are six bugs in the Defender Firewall Service that allow an attacker to escalate from executing code at Medium Integrity to Local Service. The bug in Azure Arc is interesting as it could allow threat actors to add VM Extensions on affected servers. The bug in Azure Connected Machine Agent only leads to SYSTEM, but you’ll need to update the system to the latest version of Azure Connected Machine Agent by hand. The vulnerability in Microsoft AutoUpdate (MAU) for Mac has an unlikely attack scenario but could lead to root on impacted systems. The bug in Virtual Hard Disk could cause a system to crash. That’s also true for the bug in Windows UI XAML Phone DatePickerFlyout, but this could also be leveraged for an AppContainer escape. One of the kernel bugs could also be leveraged for an AppContainer escape as well.

The bug in MultiPoint Services allows an attacker to delete a file, which as we’ve seen, can be used for privilege escalation. The bug in Xbox also allows for a targeted file delete, but it’s unclear if you could turn this into an EoP. For the bug in SMB, I would consider this to be a Spoofing bug since you gain the privileges of the compromised user. There are extra steps available for hardening against relay attacks, and if you haven’t already, you should do those as well. Similar to last month, the patch for SQL Server will take extra handling to ensure you have the correct versions installed. The bug in PowerShell is quite interesting, and (again) some might consider it a Spoofing attack. The bug allows an attacker to hijack a PowerShell Direct session between the admin user on host and a guest VM. This allows an authenticated user to impersonate the admin host user and take any actions to control guest-side operations. Neat.

The September release contains over a dozen information disclosure updates, and as expected, most of these bugs only result in info leaks consisting of unspecified memory contents or memory addresses. This is useful info to have when exploiting components on a system, but otherwise not quite exciting. Other than the Critical-rated bugs already mentioned, the only exception to this is the bug in SQL Server, which could disclose the ever ephemeral “sensitive information”.  ¯\_(ツ)_/¯

There are two Security Feature Bypass (SFB) bugs in this month’s release, and both impact the MapUrlToZone component. As the name infers, these bugs allow URLs to be mapped to the incorrect security zone.

There’s not much information available about the spoofing bug in Office Plus. If you aren’t familiar with it (I wasn’t), Office Plus is a product launched by the Microsoft China team in 2022. It mainly provides users with Office templates, such as PowerPoint templates, through the web version. Based on this, I’m guessing attackers could spoof legitimate users to gain access to Office Plus resources.

There are only three patches for Denial-of-Service (DoS) bugs in this release. As usual, Microsoft provides no actionable information about these bugs. Instead, they simply state that an attacker could deny service over a network to that component.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on October 14, and I’ll be back then with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

We’ve made it through hacker summer camp and made our way to the second Tuesday of the month. Adobe and Microsoft seemed to have survived as well, as they released their latest security patches. Take a break from your scheduled activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for August 2025

For August, Adobe released 13 bulletins addressing 68 unique CVEs in Commerce, Substance 3D Viewer, Animate, Illustrator, Photoshop, Substance 3D Modeler, Substance 3D Painter, Substance 3D Sampler, InDesign, InCopy, Substance 3D Stager, FrameMaker, and Dimension. If you’re looking to prioritize, start with the update for Commerce, which fixes six bugs and is listed as Priority 2. There are eight bugs in the patch for InCopy and all are rated Critical and lead to code execution. The patch for InDesign is quite large with 14 different CVEs being addressed – 12 of which are Critical. The fix for Substance 3D Modeler is also quite large with 13 CVEs. However, most of these are rated Important. That’s a similar story for the fix in Substance 3D Painter. Of the nine CVEs fixed, only one is Critical. There’s also one Critical fix in the patch for Substance 3D Stager, which fixes two bugs in total. The patch for Substance 3D Sampler fixes a single, Important CVE. The Substance 3D family is rounded out with two Critical CVEs for Substance 3D Viewer.

The fix for Animate addresses two bugs, one of which is Critical. The patch for Illustrator contains four fixes. Two of those bugs lead to arbitrary code execution. The single fix for Photoshop also addresses a bug that could lead to code execution. Both of these are typical open-and-own exploits. The patch for FrameMaker contains fixes for five CVEs. The final patch from Adobe this month fixes a single Important-rated bug in Dimension.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Besides the patch for Commerce, all updates are listed as deployment priority 3.

Microsoft Patches for August 2025

This month, Microsoft released a whopping 107 new CVEs in Windows and Windows Components, Office and Office Components, Microsoft Edge (Chromium-based), Azure, GitHub Copilot, Dynamics 365, SQL Server, and Hyper-V Server. Seven of these bugs were submitted through the Trend ZDI program.

Of the patches released today, 12 are rated Critical, one is rated Moderate, one is rated Low, and the rest are rated Important in severity. This puts Microsoft slightly ahead of where they were last year in terms of volume. In fact, this year is the largest volume of fixes from Redmond since 2020, although it’s unlikely they will eclipse that total.

Microsoft lists one bug as being publicly known at the time of release, but nothing is noted as being under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with a bug rated as a CVSS 9.8:

-   CVE-2025-53766 - GDI+ Remote Code Execution Vulnerability
As mentioned, this bug is a CVSS 9.8 as it allows for code execution just by browsing to a malicious webpage. An attacker could also embed a specially crafted metafile into a document and have the target open the file. A worst-case scenario would be an attacker uploading something through an ad network that is served up to users. Ad blockers aren’t just to remove annoyances; they also protect for malicious ads. They’re rare, but they have occurred in the past. Since GDI+ touches so many different components (and users tend to click on anything), test and deploy this one quickly.

-   CVE-2025-50165 - Windows Graphics Component Remote Code Execution Vulnerability
Speaking of browse-and-own, that's exactly what this bug allows as well. Rating a CVSS 9.8, this could lead to code execution by viewing a specially crafted image. Browse-and-own bugs always gain attention from researchers, so even though this is listed as “exploitation less likely”, I would treat this as a critical patch for deployment. 

-    CVE-2025-53731/ CVE-2025-53740 - Microsoft Office Remote Code Execution Vulnerability
This is the seventh month in a row where at least one Office component allowed code execution through the Preview Pane. With so many different components impacted, I doubt these are all patch bypasses. Instead, it appears attackers are mining code that hasn’t been looked at much and finding some gems. Perhaps it’s time to consider disabling the Preview Pane for a bit while the security gnomes in Redmond sort this out.

-    CVE-2025-49712 - Microsoft SharePoint Remote Code Execution Vulnerability
SharePoint has definitely been a hot topic over the last month, with exploits hitting several U.S. government targets. While this bug is not listed as under active attack, it is the same type of bug used in the second stage of existing exploits. The first stage is an authentication bypass, as this vulnerability does require authentication. However, several auth bypasses are publicly known (and patched). Be sure you are up-to-date with ALL of your SharePoint patches and reconsider having them be internet accessible.

Here’s the full list of CVEs released by Microsoft for August 2025:

† Indicates further administrative actions are required to fully address the vulnerability.

Looking at the remaining Critical patches, there are two for Word that also include the Preview Pane as an attack vector. There are three Critical bugs in Hyper-V. One could disclose the ever mysterious “sensitive information” while the other allows VM to spoof their identity in communications with external systems. The other allows code execution on the hypervisor from a guest. The bug in Azure Stack also allows an attacker to disclose information over a network. There’s a juicy code execution bug in the DirectX Graphics Kernel, but it does require authentication. The bug in NLTM is an interesting case. It allows an authenticated attacker to elevate privileges over the network. We’re used to seeing these as local exploits only. Lastly, there’s a Use-After-Free bug in the Windows Message Queuing (MSMQ) component. In this case, the attacker would need to series of specially crafted MSMQ packets in a rapid sequence over HTTP to an affected server. The attacker still needs to win a race condition, but we’ve seen plenty of race condition bugs win Pwn2Own, so don’t rely on that alone.

Including those already discussed, there are over 30 code execution bugs receiving fixes this month. The Important-rated Office components do not have Preview Pane as an attack vector and are the open-and-own variety. There’s also this month’s crop of RRAS fixes. I’m still waiting for any of these to be exploited in the wild, but I’m not holding my breath. There are three additional bugs in MSMQ. Their description seems identical to the Critical-rated bug already discuss, so it’s not clear why these are only listed as Important. If you’re running Web Deploy (msdeploy), you definitely want to test and deploy the patch quickly. An unauthenticated attacker could get code execution simply by sending specially crafted requests to an affected server. The SMB bug requires a user to initiate a connection to an SMB server – usually by clicking a link in email. The bug in Teams came through ZDI. The bug exists within the real time media manager. The issue results from the lack of proper validation of user-supplied data, which can result in an integer underflow before writing to memory. The bug in Desktop Windows Manager requires authentication and reads more like an LPE. The final code execution bug is an AI bug in GitHub Copilot and Visual Studio. It does require a user to trigger the payload, so some form of social engineering will be involved. Still – AI bug – woo hoo!

There are more than 40 elevation of privilege (EoP) bugs in the July release. Thankfully, most of these bugs lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bugs in SQL Server allow an attacker to gain sysadmin privileges. These bugs also require special attention when patching, so pay close attention to version numbers to ensure you are fully protected. There’s a bug in Hyper-V that could allow attackers to overwrite arbitrary file content in the security context of the local system. The SharePoint vulnerability would let attackers gain the privileges of the compromised user. The four bugs in Push Notifications allow for sandbox escapes. The vulnerability in the Connected Devices Platform Service allows someone to go from Medium Integrity Level to Local Service. The bug in Desktop Windows Manager just states that an attacker could gain access to “system resources” leading to further compromise. The EoP in StateRepository API Server file could lead to accessing the rights of the user that is running the affected application. Lastly, if you are an Exchange admin, you have some work ahead of you. Microsoft released a hot fix back in April and is making that change more official. You’ll need to apply the hot fix and implement changes in your Exchange Server and hybrid environment. Dominus tecum.

The August release contains more than a dozen information disclosure patches. As expected, most of these only result in info leaks consisting of unspecified memory contents or memory addresses. This is useful info to have when exploiting components on a system, but otherwise not quite riveting. There are a few exceptions. The info disclosure bug in Exchange allows attackers to determine if an email address is valid. The bugs in MSDTC and Dynamics 365 could leak the ephemeral “sensitive information”. One of the bugs in Azure is listed as public and could leak deployment API and system internal configurations. The bug in Azure Stack Hub is more serious as it could leak administrator account passwords in the logs.

There are only four patches for Denial-of-Service (DoS) bugs in this release. However, Microsoft provides no actionable information about these bugs. Instead, they simply state that an attacker could deny service over a network to that component. The only exception is the bug in Hyper-V. In this case, a low-privileged guest VM could deny service on the Hyper-V host environment.

Moving on to the spoofing bugs in this month’s release, the bug in Remote Desktop manifests as an authorization bypass. Not much is clear around the File Explorer bug other than that user interaction is required. There’s no clear info of the bug in the Security App either, but one could assume an attacker could bypass Security App protections. The spoofing bugs in Exchange are a bit clearer. These vulns allow an attacker to spoof the “5322.From” email address that is displayed to a user – a handy trick for social engineering. Finally, the spoofing bug in Edge would allow for a traffic redirect.

There’s a single tampering bug in Microsoft Exchange, but the only information Microsoft provides in that, “an authorized attacker to perform tampering over a network.” I would guess that means they could mess with people’s inboxes and/or calendars, but who knows. The August release is rounded out by a single cross-site scripting (XSS) bug in Dynamics 365.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on September 9, and I’ll be back then with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

If you just want to read the rules, you can find them here. Updated on 8/15 to clarify printer target models. Updated on 8/22 to clarify scoping for WhatsApp for Windows.

Last year, we moved our consumer-focused Pwn2Own event to our offices in Cork, Ireland, and the event could not have gone better. Despite some dreary Irish skies, much fun was had as researchers from around the world demonstrated their best exploits – and we were reminded that electricity works a little differently in Europe. With that in mind, we’re excited to return to Cork this fall for yet another great Pwn2Own event. We’ll also be returning to some of the great pubs Ireland has to offer in the evenings and wrapping the event up at the historic Cork City Goal.

As you might have guessed from the title, we’re excited to announce that Meta is co-sponsoring this year’s event, and they are hoping to see some great WhatsApp exploits. They are so excited for it, we’re putting up $1,000,000 for a 0-click WhatsApp bug that leads to code execution. We also will have lesser cash awards for other WhatsApp exploits, so be sure to check out the Messaging section for full details. We introduced this category last year, but no one attempted it. Perhaps a number with two commas will provide the needed motivation. We’re also happy to announce the return of Synology and QNAP as co-sponsors of the event. They were amazingly helpful in the setup and configuration of devices last year, and we’re happy to be working with them again.

As for the contest itself, it will run from October 21-24, 2025. As always, the SOHO Smashup category returns, but there are a few tweaks this year that should make it more challenging. We’ve also tweaked the mobile category a bit by adding a new USB attack vector for the phones. Hopefully, we’ll see some interesting research come in demonstrating what could happen if a threat actor has physical access to your device. Last year, we awarded $1,066,625 USD for over 70 unique 0-day vulnerabilities at the contest. We can’t wait to see if 2025 tops that number – especially with a million dollar bounty on the table.

As always, we’ll have a random drawing to determine the schedule of attempts on the first day of the contest, and we will proceed from there. Registration closes at 5:00 p.m. Irish Standard Time on Oct 16th, 2025. There are no exceptions for late entries, so if you have questions, please contact us at [email protected] (note the address). We will be happy to address your issues or concerns directly.

Now on to the specific target categories. We’ll have eight different categories for this year’s event:

-- Mobile Phones
-- Messaging Category
-- The SOHO Smashup
-- Smart Home Devices
-- Printers
-- NAS Devices
-- Surveillance System Devices
-- Wearables Category

Let's take a look at each category in more detail, starting with mobile phones.

The Target Phones

 Back in Amsterdam, where this contest originated, it was originally dubbed “Mobile Pwn2Own” and our focus was strictly on phones. Mobile handsets remain at the heart of this event, and some of the Samsung entries from last year were absolutely smashing. As always, these phones will be running the latest version of their respective operating systems with all available updates installed.

This year, we’re introducing the USB port as an attack vector. The exploits must attack only the USB port exposed to the end user. The target handset will be locked at the start of the attempt. And forget about using fake masks or wonky fingerprints – those attacks are out of scope. Be sure to check out the rules for full details.

Otherwise, contestants must compromise the device by browsing to content in the default browser for the target under test or by communicating with the following short-distance protocols: near field communication (NFC), Wi-Fi, Bluetooth, or Baseband. The awards for this category are:

Back to top

The Messaging Category

My first Pwn2Own experience was in 2009, where just $20,000 was awarded. How times change. WhatsApp is used by more than three billion people globally, and some of the messages transmitted can be quite sensitive. That’s one reason why it’s such a target for a certain sector of threat actors. We offered $300,000 for a 0-click exploit last year, but it appears that didn’t quite meet the “bugs to exploit” equation. Thanks to our partnership with Meta, we have substantially increased that number. We’re also introducing other-than-code execution bugs as prize winners. Since this is a big change and the award amounts are substantial, please contact us with questions prior to the contest so we can clear up any issues or misconceptions. Different phones and operating systems may be used for the targets. For WhatsApp for Windows, both “WhatsApp” and the “WhatsApp Beta” applications are in scope. Check out the rules for the full list. Here’s the full prize list for the Messaging category:

Back to top

The SOHO Smashup

The proliferation of WFH resulted in many enterprises finding their network perimeter relocated to the home office. Threat actors exploiting home routers and consumer devices can use these as a launch point for lateral movements into enterprise resources. We wanted to demonstrate this during the contest, which means the SOHO Smashup category continues to be relevant. You’ll notice this year’s list of eligible devices is quite smaller (and hopefully more complex) than last year’s. We really want to up the difficulty level and really challenge researchers to bring their very best to the contest. If they get both devices within 30 minutes, they earn $100,000 and 10 Master of Pwn points.

Back to top

Smart Home Devices

Technically, this is a new category for this year, but it’s really just combining a couple of other categories we previously had. An attempt in this category must be launched against the target’s exposed network services, RF attack surface, or exposed features from the contestant’s laptop within the contest network.

Back to top

Rage Against the Printers

Printers have long been the source of jokes and memes, but they are also an often overlooked attack surface in your office. The printer category always produces some interesting results, often by playing music it shouldn’t or the occasional Rick Roll. Brother also joins this year’s event as a new target. It will be interesting to see what exploits (and flair) the contestants come up with this year.

Back to top

Network Attached Storage (NAS) Devices

NAS devices make their return to Pwn2Own. This year, QNAP enters as a target alongside the returning Synology devices. An attempt in this category must be launched against the target’s exposed network services, RF attack surface, or from the contestant’s laptop within the contest network. For the Synology DiskStation target, we’ll have several packages enabled and in scope. These packages are as follows:

·      Synology MailPlus Server
·      Synology Drive Server
·      Virtual Machine Manager
·      Snapshot Replication
·      Surveillance Station
·      Synology Photos
·      Synology Office
·      Synology AI Console

Here’s the full table of targets in the NAS category for 2025:

Back to top

Surveillance System Devices

We’ve moved beyond just wireless cameras and decided to consolidate them into the Surveillance category. To have a win in this category, you must target the device that is fully integrated into a surveillance system during the normal state of operations with all necessary configurations completed. Entries that require physical access are out of scope, so no more hitting the reset button on cameras. An attempt in this category must be launched against the target’s exposed network services, RF attack surface, or exposed features from the contestant’s laptop within the contest network.

Back to top

Wearable Devices

We’ve dabbled with wearable devices in the past, but the latest tech from Meta piqued our interest once more. For this year’s event, we are including the Meta Ray-Ban Smart Glasses and the Meta Quest 3/3S as targets. We also have two levels of winning – the bigger prize will go to exploits that require no interaction, but we’ll also award one-interaction exploits as well. Additionally, each target can be targeted remotely, in close proximity, or with limited physical access. We’re hoping that with so many different options to choose from, contestants will bring something interesting for us to see. Here’s the award breakdown for the Wearable Devices category:

Back to top

Master of Pwn

No Pwn2Own contest would be complete without crowning a Master of Pwn, which signifies the overall winner of the competition. Earning the title results in a slick trophy, a different sort of wearable, and brings with it an additional 65,000 ZDI reward points (instant Platinum status in 2026).

For those not familiar with how it works, points are accumulated for each successful attempt. While only the first demonstration in a category wins the full cash award, each successful entry claims the full number of Master of Pwn points. Since the order of attempts is determined by a random draw, those who receive later slots can still claim the Master of Pwn title – even if they earn a lower cash payout. As with previous contests, there are penalties for withdrawing from an attempt once you register for it.

The Complete Details

 The full set of rules for Pwn2Own Ireland 2025 can be found here. They may be changed at any time without notice. We highly encourage potential entrants to read the rules thoroughly and completely, should they choose to participate. We also encourage contestants to read this blog covering what to expect when participating in Pwn2Own.

Registration is required to ensure we have sufficient resources on hand at the event. Please contact ZDI at [email protected] to begin the registration process. (Email only, please; queries via social media, blog post, or other means will not be acknowledged or answered.) If we receive more than one registration for any category, we’ll hold a random drawing to determine the contest order. Registration closes at 5:00 p.m. Irish Standard Time on Oct 16th, 2025.

The Results

We’ll be blogging and tweeting results in real-time throughout the competition. Be sure to keep an eye on the blog for the latest information. Follow us on Twitter at @thezdi and @trendmicro, and keep an eye on the #P2OIreland hashtag for continuing coverage.

We look forward to seeing everyone in Cork, and we look forward to seeing what new exploits and attack techniques they bring with them.

With special thanks to our Pwn2Own Ireland partner Meta

And co-sponsors, Synology and QNAP, for providing their assistance and technology.

©2025 Trend Micro Incorporated. All rights reserved. PWN2OWN, ZERO DAY INITIATIVE, ZDI, and Trend Micro are trademarks or registered trademarks of Trend Micro Incorporated. All other trademarks and trade names are the property of their respective owners.

On January 25th, 2025, the Trend Zero Day Initiative (ZDI) received a report from Kentaro Kawane of GMO Cybersecurity by Ierae regarding a deserialization of untrusted data vulnerability in Cisco Identity Services Engine (ISE). This pre-authentication vulnerability existed in the enableStrongSwanTunnel method of the DescriptionRegistrationListener class. While analyzing this vulnerability, I noticed that the same function was also vulnerable to command injection as root. Cisco patched this initially as CVE-2025-20281(ZDI-25-609), but also released CVE-2025-20337 (ZDI-25-607) to fully address the vulnerability. You’ll see why below.

Exploitation wasn't as straight forward as I'd originally hoped but was ultimately a lot more fun than a normal, run-of-the-mill command injection. In this blog, I'll share how I was able to achieve a root shell on affected installations of Cisco ISE, including an escape from a Docker container where the command injection was actually being executed!

More on all that later, let's take a look at the initial vulnerability.

Getting Command Injection

Below is the enableStrongSwanTunnelmethod, which leads to two vulnerabilities – one being the original report ZDI received, while the other is the subject of this blog. Notably, Cisco disagreed and initially assigned the same CVE to both submissions. Was that the right call? I'll leave that judgement to the reader.

At [1] and [2] above, the originally reported unsafe deserialization is seen.

At [3], though, we see that if an attacker provides a valid serialized Java string array, that value is used to invoke a shell script.

Not only that, but the invokeStrongSwanShellScript function contained another interesting goodie:

The sudo command at [4] was even more exciting. Not only did this look very promising as a command injection vulnerability, but that code would be executed as root.

The logger.debug call at [5] looked helpful, so after reconfiguring log4j to output debug logs, I started by sending some test inputs. A quick aside:

Each of the log outputs below came from making individual POST requests to /deployment-rpc/enableStrongSwanTunnel. The body of these requests were string representations of serialized Java String[] array objects, where the first element of the array contained the command injection.

The following array, as an example, shows in the logs as configureStrongSwan.sh enable x; touch /flag when serialized and sent to that endpoint.

      String[] arr = {"x; touch /flag", ""};

For brevity, in the rest of this blog I have included only the resulting commands executed with bash via exec(). In practice, the vector for triggering each was the vulnerable enableStrongSwanTunnel endpoint.

Now, back to those test inputs:

The log looks great; clearly we can control the value of the second concat at [4] above.

Unfortunately, as the subsequent ls call shows, exploitation wasn't quite so straightforward. Because the exec command calls a bash script on disk and passes the attacker-controlled input as a parameter, we cannot simply break the exec call and execute our own code.

Instead, we need to look at configureStrongSwan.sh to see how that parameter is used.

At [1], we call the enableStrongSwan function when using the enable operation specified at [3] above. Here OPERATION is enable and IKE_ID is our attacker-controlled payload.

At [2], we see the only usage of the passed IKE_ID in the function, as a parameter to another function verifyIpsecConnectionStatus At [3] and [4], we use our attacker-controlled payload to build a swanctl command. The argument $1 at [3] corresponds to the IKE_ID parameter.

Finally, at [5], note that we run this command in the docker container: strongswan-container. This was another piece of the puzzle in place. Perhaps the code is executing in that container? Let's take a look:

Still no dice, but a step closer!

A key thing to notice above is that the vulnerable parameter IKE_ID comes from the script argument stored in the variable $2. Consider the following example from the initial test inputs above:

      configureStrongSwan.sh enable x; touch /flag

Here, arg $2 is simply x;. Not as threatening as we hoped. Additional args $3 and $4 exist containing touch and /flag.txt, but those are never used by the script.

Even when we use quotes or backticks, which prevent bash from splitting the payload, nothing happens on disk. Why is that, though? The value of arg $2 in that example tells the story:

      configureStrongSwan.sh enable "x; touch /flag"

Interestingly, the arg value $2 used as the IKE_ID in configureStrongSwan.sh is actually "x;. This is odd. Normally when sending an argument to a bash script we can expect quoted arguments to be kept together. However, it turns out that Java is handling this command differently than bash would by itself.

Tokenization in Java exec() Calls

To properly craft our final exploit, we must first understand a little bit more about how Java's exec method works. Cisco ISE uses Java 8, so let's take a look at the Open JDK code for that version:

At [5], we see that when a string command is passed to exec(), Java tokenizes it using the StringTokenizer class.

More can be read about the StringTokenizer class in Java 8 here. For the purpose of this blog, though, I'll jump right to the point:

StringTokenizer, by design, does not respect quotes or backticks. Rather, its behavior is to simply split string by the provided token (default value is \t\n\r\f, which is used the exec method). This explains why the IKE_ID value from our test inputs was simply "x; when trying to use quotation marks. By the time bash received our input, it had already been tokenized and thus wasn't parsed as one single argument.

Luckily for us, Bash comes built in with a special variable called the Internal Field Separator (${IFS}). More can be read about the purpose and function of this variable here.

For the purposes of this exploit, the usage is simple: an attacker can simply replace all spaces with ${IFS} and bash will interpret everything as expected. The following examples are effectively the same from the perspective of bash:

With the ${IFS} version, however, Java will see the entire payload as a single token, maintaining the integrity of the command.

Additionally, exec is actually working for us now, and we don't even need to include quotes. Java will tokenize our input and ensure it is passed to bash as a single argument.

We can now run the payload using the ${IFS} variable and, viola!

Finally, code execution! This wasn't quite what I was looking for yet, though. The code is executed in the context of the Docker strongswan-container, but what I really wanted was a full root shell on the ISE server host.

Escaping the Container

We can see from the host machine that strongswan-container is running as privileged:

This is quite the gift from Cisco. Because it is running as privileged, we can leverage the "User-Mode Helpers" technique described in this talk [PDF] by Brandon Edwards and Nick Freeman at Black Hat USA 2019.

I've summarized the details related to this specific container setup. More generic information can be found here. The final payload looked like this:

At [1], a Linux cgroup is mounted.

At [2], we specify a shell script simulate.sh to be executed when the cgroup is emptied.

At [3], simulate.sh is created and configured. Here, I've chosen to echo an SSH public key to the /root/.ssh/authorized_keys file on the ISE server.

At [4], empty the cgroup. This causes simulate.sh to be executed on the host ISE server as root.

Putting It All Together

The above technique is great, but we still can't use spaces. Instead of applying ${IFS} everywhere, I chose to base64-encode the container escape script. Then, the payload sent to the vulnerable endpoint could include a base64 -d call to decode the script and pipe it to bash:

echo${IFS}[base64-encoded-escape-script]${IFS}|${IFS}base64${IFS}-d${IFS}|${IFS}bash

Altogether, the final malicious request looked like this:

And, finally, a root shell!

Conclusion

This bug was a lot of fun to exploit and highlights several good-to-know techniques that can come in handy even for a relatively straightforward bug class like command injection. To summarize, an attacker can leverage a perfect storm of mistakes in Cisco Identity Services Engine to achieve full system takeover as root.

By utilizing the ${IFS} variable in bash, we could get around Java's exec method restraining us from using the space character. Additionally, although the initial command injection was executed inside of a Docker container, we were able to break out of the sandbox and execute code on the host because Cisco configured the container in privileged mode.

Finally, for those following along at home: those two bugs Cisco deemed to be duplicates of each other? They were fixed by two different code changes. The definition of "duplicate" is, again, left to the reader.

Keep an eye out for future blogs where I will go into more detail on vulnerabilities I have found in this area. Until then, you can follow me on Twitter at @bobbygould5 and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

In recent years, there has been an increase interest in the JavaScript engine vulnerabilities in order to compromise web browsers. Notably, vulnerabilities in JIT engines are among the most favorite ones as it provides strong primitives and well-known techniques are already available to facilitate compromise. At Pwn2Own Berlin 2025, Manfred Paul compromised the Mozilla Firefox renderer process using a vulnerability in IonMonkey but did not further escape the JavaScript engine sandbox. IonMonkey is the JavaScript JIT compiler for SpiderMonkey (the Firefox JavaScript and WebAssembly engine) This vulnerability is assigned CVE-2025-4919 and Mozilla swiftly fixed it in Mozilla Firefox 138.0.4 via Security Advisory 2025-36 in the following day. Trend Zero Day Initiative assigned ZDI-25-291 to this vulnerability. Here's a video of the exploit in action:

Note: This blog is heavily reliant on the details provided by Manfred Paul at the Pwn2Own competition.

Introduction

The Ion JIT compiler uses a function called ExtractLinearSum at multiple places to convert a value node into a linear sum expression. The purpose is to be able to reason about subexpressions containing exclusively additions and subtractions. For example, consider the graph of value nodes representing an expression like (x+(2+3)) − (−3). This will always be equal to x+8 which is much easier to reason about in contexts like bounds-check elimination or hoisting. ExtractLinearSum function extracts this simplified form. To understand the details of this function let’s consider its declaration in jit/IonAnalysis.h:

The return type would be struct SimpleLinearSum which is also declared in IonAnalysis.h:

As the comment explains only very simple linear expressions like 𝑥 + 𝑛 with 𝑥 as an arbitrary value node and 𝑛 as an integer constant are supported. A pure constant can also be expressed by setting the term pointer to a NULL pointer. It is important to note that any (integer) expression val can be converted to a SimpleLinearSum. In a trivial case that the expression is not itself an addition or subtraction ExtractLinearSum can simply return a SimpleLinearSum with term set to val and constant set to 0.

The ExtractLinearSum function takes three arguments. The first is simply the expression ins to analyze which should be a value node of integer type. The third is a simple recursion counter (as ExtractLinearSum function can call itself recursively to analyze i.e. the two sides of an addition seperately) which simply keeps track of the recursion depth to prevent stack exhaustion. This parameter will always be left at its default value 0 by callers. The most subtle parameter is however the second one describing as so-called MathSpace. This enum is also declared in IonAnalysis.h:

As the comment explains, this is done to separate two different possible behaviors of the MAdd/Msub nodes: They can optionally have an overflow check that leads to bailout if the operation would overflow the 32-bit signed integer range. If this check is enabled, the semantics of the operation correspond to the actual (infinite) integers. The usage of 32-bits as a representation are merely a speculative assumption possibly leading to bailout if violated. These semantics are represented by the Infinite MathSpace. On the other hand, the compiler can also generate unchecked additions or subtractions. These purposefully truncate the output to the 32-bit integer range as the usage site might perform such a truncation anyways (for example in a pattern like (x+5)|0 the bitwise OR would truncate its operands to 32-bit integers). This corresponds to doing arithmetic modulo 2^32 and thus is represented by the Modulo MathSpace. Finally, the Unknown MathSpace is simply a default value that can be passed into a ExtractLinearSum call. The meaning of this default value is that both of the described math spaces are acceptable and the function will simply pick the appropriate one based on the outermost operation. It will still however make sure to only allow a consistent MathSpace for all involved operations by passing the chosen space to the recursive calls instead of Unknown.

Root Cause

The ExtractLinearSum function is used in a few places in the Ion compiler. The most direct usage happens in jit/FoldLinearArithConstants.cpp where the compiler simply folds complicated linear expressions of mostly constants into one single Madd node. This direct usage will not concern us for the purposes of the vulnerability. The use that leads to the vulnerability is located in the TryEliminateBoundsCheck function inside jit/IonAnalysis.cpp:

The purpose of this function is to merge subsequent bounds check on the same object. For example, consider the following JavaScript operations:

These will generate two separate bounds checks with indices 𝑖 + 4 and 𝑖 + 7. Nodes of type MboundsCheck can check a whole range of indices at once. For this purpose, they store two integer offsets: minimum and maximum. When the bounds check is run the actual indices that are checked correspond to index + minimum and index + maximum where index is the actual input value into the node. In this case, the existing checks will have minimum and maximum both set to 0 (Actually it is possible that for these exact two bounds checks with index 𝑖 and both minimum/ maximum set to 4 (for the first check) and 7 (for the second check) are generated but we will ignore this for the sake of simplicity for now). The above bounds-check elimination pass will now try to merge these two bounds checks into one. To do this, first it is checked that both index expressions are linear sums corresponding to the same term (in this case the variable i). Instead of generating a new MboundsCheck node with index i, the compiler will simply reuse the first bounds-check and adjust the minimum and maximum fields. In this case as the index value of the seconds bounds check is larger by 3 the maximum field would be set to 3, while the minimum remains 0, and the actual index value stays i+4. While creating a clean conceptual difference between wrapping and infinite addition (and subtraction) semantics is a good design choice in SimpleLinearSum it seems like less care was taking at the call sites to make sure only appropriate semantics can be used. For example, bounds checks have inherently infinite semantics. If an array has length 20, then 10 is a valid index, but 2^32 + 10 is not. This means that using the wrapping Modulo math space could lead to wrong results. This becomes quite apparent with an actual bounds-check elimination. Consider an array being indexed at indices i and i+10. Normally i+10 should always be larger by exactly 10 than i so extending the maximum of the first check by 10 would cover it. But if the addition has unchecked Modulo semantics, this no longer holds true as i+10 might then potentially overflow if i is itself a large 32-bit integer like 2^32 − 5. The basic construct to trigger this bug is somewhat simple:

What happens here is that the bitwise OR with 0 will force a truncation to 32-bit integers, so that both the additions become unchecked wrapping additions. By the time that Bounds-Check Elimination phase will run, the bitwise ORs will have been eliminated because or-ing with 0 is a NOP. This leads to two array indices with i + 5 and i + 10 respectively as indices, where both additions are now wrapping. This means that ExtractLinearSum will be able to analyze those expressions, choosing the Modulo MathSpace, returning a SimpleLinearSum with term set to i for both. This in turn leads TryEliminateBoundsCheck to believe that the index of the second bounds check will always be larger by 5 than the first and eliminate it by increasing the first check’s maximum by 5. However, this is clearly incorrect already. If, for example, we set i to 2^31−7 as an index then the first index will be equal to 2^31 – 2 but the second one will be equal to −2^31 + 3, which is not a value covered by the corresponding range. This would not lead to an immediate problem if the involved bounds checks were of the 32-bit integer kind as they would bailout when encountering an index that added to the maximum offset exceeds 2^31 − 1. However, for a bounds check of IntPtr type, this is no problem as long as the length is large enough. We thus need an array with length greater than 2^31 to hit this bug as the bounds check will check up to the actual index (2^31 - 7) + 10 = 2^31 + 3 in the above example. This is probably impossible using normal JavaScript Arrays. Fortunately, Firefox's memory limits are large enough to allow for the creation of some rather huge typed arrays. Therefore we can simply create a Uint8Array of the size we need. As the bug is fundamentally about the confusion between an integer and its 32-bit wrapped version it can only ever be used to access an index off by exactly 2^32 from a valid index. For an addition that is barely overflowing like in the above example an index close to −2^31 can be achieved. This would not be very easy to exploit as it would result in a read and write primitive about 2^31 bytes in memory before the typed array. Therefore, it makes sense to use an even larger array of size 2^32. This will allow any bounds-check to pass as long as index value minimum and maximum are all non-negative signed 32-bit integers.

Triggering the Bug for Out-of-Bounds Read and Write

A simple out-of-bounds read POC might look something like the following:

Here, the bounds checks for the array accesses will again be merged into one. This single bounds check will have index equal to idx1 + 100 but maximum is set to 2^31 – 101 as this is what TryEliminateBoundsCheck computes to be the difference of the two indices again due to ignoring the possibility of wrap-arounds. The training iterations in the loop that are (partially) evaluated by the interpreter instead of JIT-compiled will simply access the indices (−50) + 100 = 50 and (−50) + (2^31 − 10) = 2^31 – 60 which are both in-bounds. For the final evaluation however idx1 will be equal to (2^31 − 200) + 100 = 2^31 − 100, but idx2 will be equal to (2^31 − 200) + (2^31 − 1) − 2^31 = −201 due to the wrap-around behavior. However, the merged bounds-check will still be passed as it will only check that there is a range of 2^31 − 99 valid indices starting from 2^31 – 100 which is true. This leads to the acceptance of a negative index and access to bytes before its start. In this case an out-of-bounds read is performed but the exploit logic is the same for a write primitive. The only thing left to explain is the role of the out object in the code. This is a technical neccessity due to the behavior of the MInt32ToIntPtr node. This node is inserted to convert our 32-bit value idx2 into an actual 64-bit array index. However there are some logics in jit/Lowering.cpp during visiting Int32ToIntPtr node that checks if a sign-extension is needed at all:

If the only use is as the index of the load then it is assumed that the value cannot be negative at all (as this could only result from a broken bounds check as in our case) and a simple zero-extension is performed instead of the usual sign extension. However, converting the value into a BigInt also uses the Int32ToIntPtr node as an intermediate leading to another use and disabling this optimization. Returning this BigInt using the out object prevents it from being optimized away.

Possibility of Related Bugs

Like mentioned above TryEliminateBoundsCheck is not the only place where ExtractLinearSum is used. Notably, it is also used in multiple places during the bounds check hoisting in jit/RangeAnalysis.cpp (sometimes also via the related function ExtractLinearInequality). Here, the function is again used with its default second argument of MathSpace::Unknown. Again, this choice seems incorrect. Consider a loop like for (let i = 0; i + 3 < 10 − 2; i = i+1) {...}. Here the loop analysis will basically conclude (by extracting various linear sums) that maximum 5 iterations will take place. This information is then used to hoist bounds checks which may depend linearly on some loop variables. However, if any of these additions are replaced by unchecked wrapping ones then these invariants could no longer hold. For example, the loop for (let i = 2^31− 5; i <= 2^31-1; i = (i+1)|0) {...} will run forever. There is one hurdle that however seems to make this harder (maybe impossible) to exploit and it is the compilation stage responsible for getting rid of the unneccessary bitwise OR happens after the bounds check hoisting (though before bounds check elimination). WebAssembly can also not be used as this optimization is disabled in that compilation mode.

Exploitation

As always, controlled out-of-bounds read and write primitives are quite powerful tools for further exploitation. The only slight difficulty is that the access is from a very large-typed array instead of the more usual smal heap object, meaning that it won’t be allocated in e.g. the nursery heap. Experimentally what works well is gaining access into large Map objects. Allocating a few of them will nearly always result in one map being right in front of the huge-typed array. This map object will contain tagged pointers to its values. Reading out such a pointer directly results in an addrOf primitive. Conversely overwriting a tagged pointer results in a fakeObj primitive. Once these two primitives are obtained exploitation becomes fairly standard. Some fake structures in the fixed inline storage of some (small) array buffers are crafted which are a fixed offset from the object location determined via addrOf. Using this a complete fake object crafted whose elements are also fake with a huge length. This object is not fully valid as there are some pointers to e.g. the object class that are hard to fake but it is good enough to temporarily get another out-of-bounds access this time into another overlapping ArrayBuffer. This can finally be used to overwrite the data address of this array buffer resulting in arbitrary read and write primitives. By embedding shellcode into float constants of a WASM function it would be possible to put the shellcode into executable memory. Finally all that remains is to overwrite the entry point offset of the WASM function to execute the shellcode. A demo of exploitation is available at https://www.youtube.com/watch?v=TG029NAGKs0

Final Notes

Despite fuzzing JavaScript engines at scale for a long time there are still high-quality bugs present yet to be found. It is notable that the bug described here could be challenging to be found using a fuzzer as it needs large allocations which may trigger performance penalties. This yet again proves the importance of source code review to find high quality bugs. You can also read more on what Mozilla has to say about this Pwn2Own entry in this post.

You can find me on Twitter at @hosselot and follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.

It’s the second Tuesday of the month, and as expected, Adobe and Microsoft have released their latest security patches. Take a break from your scheduled activities and join us as we review the details of their latest security alerts. If you’d rather watch the full video recap covering the entire release, you can check it out here:

Adobe Patches for July 2025

For July, Adobe (eventually) released 13 bulletins addressing 60 unique CVEs in Adobe ColdFusion, After Effects, Substance 3D Viewer, Audition, InCopy, InDesign, Connect, Dimension, Substance 3D Stager, Illustrator, FrameMaker, Experience Manager Forms, and Experience Manager Screens. The obvious place to start here is ColdFusion. It’s the only update listed as Priority 1 and addresses 13 CVEs, five of which are rated Critical. ColdFusion should probably be considered “legacy” at this point. If you’re still using it, you should think about migrating to something more modern. The patch for FrameMaker is also somewhat large. It fixes 15 CVEs – including 13 Critical bugs that could lead to code execution. The only other double-digit CVE bulletin is for Illustrator with 10 bugs. The most severe of these bugs could lead to code execution.

The remaining patches are much smaller. The After Effects patch fixes two Important severity bugs. The fix for Substance 3D Viewer addresses one Critical and two Important vulnerabilities. There’s a single denial-of-service (DoS) bug fixed in the Audition patch. The update for InCopy includes three Critical-rated bugs that could lead to code execution. The fixes for InDesign correct six similar Critical bugs. There’s just a single Critical bug in the patch for Connect. That’s the same for the Experience Manager Forms patch. The update for Substance 3D Stager corrects a single memory leak. The patch for Dimension also includes a memory leak fix and a Critical-rated code execution bug. Finally, the update for Experience Manager Screens addresses two cross-site scripting (XSS) bugs.

None of the bugs fixed by Adobe this month are listed as publicly known or under active attack at the time of release. Besides the patch for ColdFusion, all updates are listed as deployment priority 3.

Microsoft Patches for June 2025

This month, Microsoft released a whopping 130 new CVEs in Windows and Windows Components, Office and Office Components, .NET and Visual Studio, Azure, Teams, Hyper-V, Windows BitLocker, Microsoft Edge (Chromium-based), and the Windows Cryptographic Service. Eight of these bugs were reported through the Trend ZDI program. With the additional third-party CVEs being documented, it brings the combined total to 140 CVEs.

Of the patches released today, 10 are rated Critical, and the rest are rated Important in severity. July tends to be a heavier month for patches, though the reason is not clear. Perhaps Microsoft wants to patch as much as possible prior to the Black Hat and DEFECON conferences that take place in early August. Perhaps it’s related to their test cycles and is merely coincidental.

Microsoft lists one bug as being publicly known at the time of release, but nothing is noted as being under active attack. Let’s take a closer look at some of the more interesting updates for this month, starting with a bug many will be talking about:

-   CVE-2025-47981 - SPNEGO Extended Negotiation (NEGOEX) Security Mechanism Remote Code Execution Vulnerability
This heap-based buffer overflow impacts the Windows SPNEGO Extended Negotiation component and allows remote, unauthenticated attackers to execute code simply by sending a malicious message to an affected system. Since there’s no user interaction, and since the code executes with elevated privileges, this bug falls into the wormable class of bugs. Microsoft also gives this its highest exploitability index rating, which means they expect attacks within 30 days. Definitely test and deploy these patches quickly.

-  CVE-2025-49717 - Microsoft SQL Server Remote Code Execution Vulnerability
Speaking of heap-based buffer overflows, here’s one in SQL Server that could lead to code execution by an attacker executing a malicious query on an affected SQL Server system. They could also escape the context of the SQL Server and execute code on the host itself. Servicing this will not be easy. If you’re running your own application (or an affected third-party app) on an affected system, you will need to update your application to use Microsoft OLE DB Driver 18 or 19. The bulletin has full details, so be sure to read it carefully to ensure you have taken all steps needed to address this vulnerability fully.

-  CVE-2025-49704 - Microsoft SharePoint Remote Code Execution Vulnerability
This bug originates from Pwn2Own Berlin and was used as a part of a chain by the Viettel Cyber Security team to exploit SharePoint and win $100,000. This particular bug allowed code injection over the network. On its own, it requires some level of authentication. However, at the contest, the team paired it with an authentication bypass bug to evade this requirement. Their demonstration shows how authentication alone cannot be trusted to protect from attacks.

-  CVE-2025-49695 - Microsoft Office Remote Code Execution Vulnerability
This is one of four Critical-rated Office bugs in this release, and all of them have the Preview Pane listed as an attack vector. This is the third month in a row with Critical-rated Office bugs, which is a disturbing trend. There is either a wealth of these bugs to be found, or the patches can be easily bypassed. Either way, Mac users are out of luck since updates for Microsoft Office LTSC for Mac 2021 and 2024 are not available yet. Perhaps it’s time to consider disabling the Preview Pane until Microsoft sorts some of these problems out.

Here’s the full list of CVEs released by Microsoft for July 2025:

* Indicates this CVE had been released by a third party and is now being included in Microsoft releases.

† Indicates further administrative actions are required to fully address the vulnerability.

There are only three other Critical-rated bugs to discuss in this month’s release. The first in in Hyper-V and could allow an attacker to execute code on the local system if they can be tricked into importing an INF file. The bug in the Windows KDC Proxy Service could allow code execution if an attacker can leverage a cryptographic protocol vulnerability in Kerberos Key Distribution Center Proxy Service. While an enticing target, that’s a tall order for an attacker. Finally, there is a Critical-rated info disclosure bug in the Imaging Component, but it only leaks ream heap memory, so it’s not clear why it is listed as Critical.

Looking at the remaining code execution bugs, there are additional bugs in Office of the open-and-own variety where the Preview Pan is not an attack vector. There’s also our monthly dose of bugs in the RRAS service – 14 for July. There are a couple of bugs in MPEG2 that require authentication. That’s also a requirement for the SQL injection bug in Intune. The SharePoint bug also requires authentication, but anyone with the ability to create a site has the needed permissions. The bug in the Virtual Hard Drive requires a user to mount a specially crafted VHD, which seems unlikely. The bug in RDP Client requires connecting to a malicious RDP server – another unlikely scenario. The bug in Windows Server Setup and Boot Event Collection requires high privileges but could be used to maintain access after an initial intrusion. Speaking of unlikely, the vulnerability in Miracast requires a target user to connect to a malicious Miracast sink and have a non-default configuration. The bug in Windows Connected Devices Platform Service allows for code execution if an attacker sends specially crafted packets to TCP port 5040 on an affected system, but the user would need to restart the service to complete the attack. There’s a bug in the Python component of Visual Studio due to the Python extension allowing an unauthorized attacker to execute code locally. Finally, the bug in Azure Monitor Agent allows an unauthorized attacker to execute code over an adjacent network. Users who have disabled Automatic Extension Upgrades will need to perform a manual update of the agent.

There are more than 50 elevation of privilege (EoP) bugs in the July release. The vast majority of these bugs lead to SYSTEM-level code execution or administrative privileges if an authenticated user runs specially crafted code. The bugs in Virtual Hard Disk and Fast FAT require a target mount a virtual drive. There are a few bugs that allow local attackers to crash a system, which could be used as a part of a privilege escalation. Other bugs elevate to different levels depending on the product. The EoP is Office escapes the Protected View sandbox. Bugs in the Virtualization-Based Security allows attackers to gain Virtual Trust Level 1 (VTL1) privileges. The bugs in Input Method Editor (IME) allow attackers to go from low to medium integrity code execution. The bug in the Universal Print Management Service is a little bit different. In this case, an authenticated attacker could send a specially crafted file to a shared printer resulting in code execution on the system sharing that printer. Lastly, the bug in Azure Fabric Runtime leads to SYSTEM, but the attacker needs a few extra steps. You’ll also need to take additional action if you have disabled automatic updates. You will need to manually update your Server Fabric Cluster to be protected.

Moving on to the security feature bypass (SFB) patches in this month’s release, five are for BitLocker. The scenarios are different, but they all lead to an attacker being able to bypass BitLocker. The bug in SmartScreen allows attackers to bypass SmartScreen protections. While this bug is not under active attack, we’ve seen similar bugs used by ransomware in the wild. The bug in Remote Desktop Licensing requires a machine-in-the-middle (MitM) attack, but Microsoft doesn’t make it clear which specific security feature is being bypassed. The final SFB is in the Office Development Platform and allows attackers to bypass the Office Visual Basic for Applications (VBA) signature scheme.

The July release includes quite a few information disclosure patches. As usual, most of these are in the Windows Storage Management Provider and only result in info leaks consisting of unspecified memory contents. This is useful info to have when exploiting components on a system, but otherwise not quite riveting. That’s also true for the bugs in SQL Server. However, similar to the SQL RCE bug already mentioned, you may need to manually update to Microsoft OLE DB Driver 18 or 19. The bug in GDI could allow the leaking of the ever elusive “sensitive information”. That’s a bit more detailed than what is leaked by the Cryptographic Service. Microsoft simply states the bug allows an “attacker to disclose information over a network.” Neat.

There are five patches for Denial-of-Service (DoS) bugs in this release. However, Microsoft provides no actionable information about these bugs. Instead, they simply state that an attacker could deny service over a network to that component. The only exception is for the bug in Windows Performance Recorder. This vulnerability requires an authenticated attacker to create directories then have an administrator run wprui.exe for the first time. Somehow, I don’t see that one getting exploited in the wild.

Looking at the spoofing bugs receiving patches this month, the first that stands out is in SharePoint server. This is the bug that allowed Viettel to bypass authentication at Pwn2Own by spoofing an authenticated connection. The bug in Remote Desktop requires some social engineering, as it requires tricking a user into interacting with a spoofed WebAuthn prompt and entering their credentials. The spoofing bug in Storage could be used by an attacker to trick a user into connecting to an attacker-controlled network resource. Finally, the spoofing bug in SMB involves improper certificate validation, which implies certificates could be spoofed over the network.

The last patch for July is in the poorly defined “Tampering” category. It’s in the Windows StateRepository API Server and allows for an AppContaier escape to delete specific files on a system. I suppose that’s a good enough definition of tampering.

No new advisories are being released this month.

Looking Ahead

The next Patch Tuesday of 2025 will be on August 12, and, assuming I survive hacker summer camp, I’ll be back then with my analysis and thoughts about the release. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

Every complex modern device needs non-volatile storage to keep program and configuration data while unpowered. There are several competing options on the market available to today’s systems designers: serial Flash, raw NAND chips, (micro)SD, and Embedded MultiMediaCard (eMMC). eMMC is the topic of this discussion, and specifically how to interact with it without removing the chip from the system.

Such an approach is often desirable – after all, even when you are exceptionally skilled with BGA re-balling, there are only so many heating and cooling cycles the chip and the PCB can withstand before the probability of a failure gets too high. That is not to mention the exceptionally fine pitch of the most often encountered packages used by eMMC. The contact balls/pads are just 0.5mm (0.02in) apart, making the whole process rather fiddly and error-prone. Nobody really wants to bodge-wire this every time something needs to be changed!

Figure 1 - An eMMC chip in BGA153 bodged to a microSD-to-SD adapter. Source: @GetHypoxic onX/ Twitter

Thus, it’s desirable to avoid all that and still be able to read and write the chip’s data to. As to how to accomplish that, various bits and pieces of information have been floating around, a lot of it on phone repair forums, but I felt it could be beneficial to collect, process, and present the collective experience in a more structured way. Let’s explore this idea and how it can be made a reality.

PREREQUISITES

First, the basics. The following are necessary to be able to accomplish anything at all:

·      A device to be researched, obviously.
·      An interface device to interact with the eMMC chip. Options can vary, but you can pick anything that can speaks 1-bit MMC. I use a custom-made STM32-based adapter for that, which gives some additional hacking and debugging capabilities, while on the other hand being quite slow. Other options are also available, but I have not personally tested them (yet).
·      Some machine with a program to consume disk images. This depends on the actual interface device you will be using. Maybe a Linux laptop and “dd”?
·      Microsoldering equipment and skills to go with it. Unfortunately, there will still be some fiddly soldering involved as you will need to wire some things up. A pointy tip for your soldering iron that can tack things to passives smaller than size 0603, and some “magnet” wire of a reasonable diameter is a must. If you don’t feel confident enough, practice on some not-that-important equipment first.
·      Equipment to probe signals. A multimeter is obligatory, but you will also need a logic analyzer and an oscilloscope. Neither needs to be high-end, but they should be able to handle frequencies up to 100MHz at a minimum.
·      An adjustable bench power supply. This may be needed to power your device, either in whole or in part.

eMMC basics

Despite eMMC chips having a hundred and a half contact balls, only several actually do anything; the rest seem to be for mechanical stability and/or reserved for future use. While the full description of the eMMC protocol is provided in JESD84 [PDF], here is a short rundown of signals of particular interest and their properties:

·      The CLK line is provided by the host and synchronizes everything that happens on the bus.
·      The CMD line is for bidirectional communications between the host and eMMC devices on the bus. Host commands and device responses are sent via this line.
·      A set of bidirectional lines DAT0 through DAT7 for data exchange between the host and eMMC devices. These carry everything else apart from commands and responses.
·      The VDD and VDDQ lines, and corresponding VSS and VSSQ lines, supply power to eMMC devices. The eMMC standard defines several acceptable combinations of voltages, but in all cases VDDQ is less than or equal to VDD. Notably, VDDQ defines voltage levels on all external signals on the eMMC bus!

And that’s basically it. In fact, we will cut things down further and only deal with CLK, CMD, DAT0 and power lines, this being the so-called 1-bit bus width with the two other options being 4 and 8 bits.

Higher speeds often necessitate series resistors for all the signals of the eMMC bus. This results in eMMC devices being closely surrounded with 8 or more resistors, which make excellent points of contact. The eMMC standard also suggests all the lines to be pulled up to VDDQ via resistors to ensure signal levels are well defined.

The whole adventure presents a set of several interrelated problems, the solution to which is vital for successful communications to be established.

Problem #1: Locating eMMC signals on the board

Before we connect to anything, we need to understand what to connect to exactly. If you are lucky, the device PCB has silkscreen markings that note some or all of the eMMC signal locations.

Figure 2 - An example where we got lucky

More often than not, though, there is no such luck, and the PCB is devoid of any markings. How to proceed?

First of all, take note of traces around the eMMC device on your board. Some of them will likely come from under the device. Where do they go? To the SoC, perhaps? Is there a passive in series? Make sure to thoroughly inspect the other side of the board as well. While it is not impossible for eMMC signals to be routed on internal layers, if the board has enough of them, nonetheless in a 4 layer board it is more common for the internal layers to be power and ground while the top and bottom layers carry signals.

Figure 3 - An example where we did not get as lucky, but not too bad either

One could also overlay the package pinout on top of the board photo to approximately identify the location of signals of interest.

This investigative exercise should leave you with a set of potential candidates for eMMC signals. Now we need to weed them out. The easiest way around is probably to just tap all the candidates with some magnet wire and use a logic analyzer to watch the activity as the device under hack is powered up.

Figure 4 - The eMMC device is on the other side of the board at the top of this image, and the SoC is at the bottom

In Figure 4, several traces making their way top to bottom can be seen, all good candidates for probing.

At power up or system reset, the only active interaction on the bus will be via the CMD line: switching the bus to idle state, interrogating supported voltages, assigning device address, etc. You should see bursts of slow CLK signal with less regular activity on the CMD. Something like this:

Figure 5 - Sample bursts of slow CLK signals

Note that, as the eMMC standard allows bus operation using low voltages such as 1.8V, your logic analyzer may need to be configured appropriately.

The CMD line activity always begins with bit sequence 01; these are the start bit (always 0) and the direction bit (1 for host-to-device). Naturally, CMD transitions must be synchronized to the falling edge of potential CLK. At some point you will probably see the frequency of CLK change to a much higher one — something like 50MHz — with CMD also following. Using these clues, it should be possible to spot the CLK and CMD lines among your candidates. You can confirm the guesses by configuring a protocol analyzer in your logic analyzer software and seeing if it shows anything reasonable.

If there is something that looks like CMD but no CLK, you will have to find more candidates. Note that of all the signals, the CLK line is the least likely to have a series resistor close to the eMMC chip. The host is the only one driving that line, so the resistor will be placed closer to the host.

Now only the data lines are missing. These can be spotted once you spot your CMD and CLK and use a protocol analyzer. Look for the host issuing any command that will result in the device sending data over, for example, asking for the extended CSD contents or reading some sectors. The former typically occurs before a speed switch, and the latter after. High-speed devices are also likely to use the 8-bit mode; 8 lines going low and then showing activity can be a good clue too. Figuring out which of those 8 lines is DAT0 is easy if your device under hack performs any read-like operations before speed switch: there will be only one data line active at that time, whereas 8 of them will be active after the switch. You can also connect CMD and CLK to your 1-bit interface device and see what happens. Since there should be no bus width switch from 1 bit to higher width, only one line out of 8 candidates should show any activity. However, this requires being able to power the eMMC chip and keep the rest of the system out of the way.

Problem #2: Powering the eMMC chip

Of course, your eMMC chip needs to be powered before you can do anything with it. This power can be supplied by the device under hack itself, or it can be provided externally. Both approaches have their pros and cons.

The easiest approach is just letting the device do its thing. However, there can be trouble as you will have the whole system powered up and, to provide an example, there might be some kind of a watchdog circuit expecting a signal from the main SoC to show it has actually booted up. If this signal is not detected within a short amount of time, then the watchdog will power cycle the system. You will have then to find that circuit and bypass it, which may be more trouble than it’s worth.

On the other hand, you can provide your own power to only power the eMMC chip by connecting a power supply (or supplies, see below) across some capacitors under the chip. This circumvents the power-cycling problem but also requires connecting extra wires. The approach is not without its drawbacks: providing power in an uncontrolled manner may damage the board, so some form of current limiting is strongly advised—watch the current consumption and abort the exercise if it is too high to avoid permanent damage.

Whichever option is chosen, please be aware that there can be considerable current draw on those power lines, as more things will likely be connected to the VDD power rail than just the eMMC of interest. Using your bench supply to provide power is a good idea.

Before proceeding, we should figure out whether the system uses a single or separate supplies for VDD and VDDQ power rails, as well as the voltage required for each. In the case of separate supplies, we may not know what else is connected to the possibly lower-voltage VDDQ supply and whether it will tolerate the VDD supply should we decide to just use that by connecting VDD and VDDQ together; it might work fine, or it might force some magic smoke to escape from the $1000+ device under hack. Whether to accept this risk is up to personal judgment. The text below assumes the risk is too high, and we’ll want to supply two separate power rails.

Figure 6 - The opposite side, with many capacitors of varying sizes sprinkled around

As seen in Figure 6, there are several metal pour areas (light green area), with the larger ones being ground, and smaller ones VDD and VDDQ – in this case connected together.

As the VDDQ voltage can be easily determined by probing the CMD and CLK signals on system startup and noting the value shown, the only thing to do really is to probe the decoupling capacitors under the eMMC in an attempt to find a different, higher voltage there, which would then have to be VDD. Or, as in the case above, you can eyeball it and double check with your multimeter.

Split supplies and lower voltages raise another issue as well. Whatever interface device is used, it needs to be adapted to the hack that is underway. Specifically, your interface device may or may not support the lower signal voltage used in your device under hack. For example, the interface at my disposal is 3.3V only. All this means is that a bidirectional voltage level translator must be used.

There is some choice of devices on the market for that task. Unfortunately, the widespread TXB series of translators from TI cannot be used as they do not work when signals are pulled up at either side. Instead, the TXS series devices can be used; this was confirmed experimentally. They can be purchased in the hacker-friendly form of being mounted on a small PCB. Then it is just the matter of wiring the adapter PCB between your interface and the eMMC chip.

Figure 7 - An example of a breakout PCB for TXS0108E

Problem #3: Keeping the rest of the system quiet

Whichever way you choose to power the eMMC chip, the rest of the system may also want to kick into action, either in full or partially, and it may have to be pacified. This is especially important if whatever device is connected to the eMMC will become powered and active. This is naturally expected should you choose to power the whole system up instead of just the eMMC. Powering the eMMC only may or may not result in activity over the eMMC bus. This could be easily verified by powering the eMMC up and observing whether there is any activity on the CMD line; normally it should be pulled up to VDDQ and stay that way.

Should the system under hack be overly active, a couple options may be available to choose from depending on the design of said system.

·      If not already, try powering the eMMC only through its power connections below instead of the whole system.
·      If there are silkscreen signal labels, look for anything that resembles a reset signal for whatever wants to talk to the eMMC. Forcibly asserting that signal should keep the thing in reset—but some other part may become unhappy about that (see the text above concerning watchdogs). The reset a signal could also be found on a variety of debugging connectors or even a hardware reset button.
·      If the SoC talking to the eMMC has this eMMC as a secondary boot device in a chain with, for example, a serial Flash chip, see how that primary device could be “disabled” to make the system not boot and get stuck in a loop instead, not touching the eMMC interface.
·      Alternatively, one could try disabling the clock source by tampering with the crystal and e.g. removing it from the board or tying the SoC oscillator input to a power rail via a low-value resistor. Whether this works or not can be confirmed by probing with an oscilloscope.

Other options may also exist on your device under hack; do experiments and see what does the trick!

Once this problem is solved, you should search for DAT0, if it has not already been discovered, as everything is in place to facilitate that effort. And after that, well, depending on what kind of interface you are using, you should be able to freely interact with the eMMC as if it was part of your own machine: you can dump it, you can mount it, etc. The only downside here is, dumping non-user areas will likely be impossible if non-specialized interfaces are used as they do not provide means to switch areas. This can be overcome once initial access to the live device under hack is obtained through the research and analysis of whatever software is found in the user area of the eMMC.

Before we wrap up, some caveats should be mentioned. Above all else, remember that eMMC chips are high-speed devices, so wire lengths should be kept to a practical minimum. Even then, the device under hack may not work properly due to signal integrity issues. In that case, all the signal wires need to be removed after you are done tampering with the eMMC and you want to once more observe the operation of the device as a whole. Naturally, you will have to solder them back if more work needs to be done, but this is still much easier than removing and putting back the chip itself. Second, depending on your interface, boot and RPMB partitions may not be accessible. Fortunately, the boot partitions typically contain the bootloader—likely U-Boot—and are typically not that interesting if your research does not aim at, say, bypassing secure boot. Contents of these non-user partitions can be obtained later when access to the OS has been gained.

Conclusion

While this is by no means an exhaustive guide to interfacing with eMMC memory, I have tried to incorporate all the real-world cases encountered in work so far. Any questions, additions, corrections, and other feedback are always welcome, and who knows, maybe we will see the second iteration of this guide soon. In the meantime, I can offer good material for further reading about more invasive techniques.

You can reach me on Mastodon at @InfoSecDJ, and be sure to follow the team on Twitter, Mastodon, LinkedIn, or Bluesky for the latest in exploit techniques and security patches.