Oracle’s January 2026 CPU resolves roughly 230 unique vulnerabilities across more than 30 products.

The post Oracle’s First 2026 CPU Delivers 337 New Security Patches appeared first on SecurityWeek.

The two bugs, an arbitrary file read and an SSRF bug, can be exploited without user interaction to leak credentials, databases, and other data.

The post Chainlit Vulnerabilities May Leak Sensitive Information appeared first on SecurityWeek.

The researcher who discovered the vulnerability saw more than 2,500 internet-exposed devices.

The post TP-Link Patches Vulnerability Exposing VIGI Cameras to Remote Hacking appeared first on SecurityWeek.

Millions of IT systems — some of them industrial and IoT — may start behaving unpredictably on January 19. Potential failures include: glitches in processing card payments; false alarms from security systems; incorrect operation of medical equipment; failures in automated lighting, heating, and water supply systems; and many more or less serious types of errors. The catch is — it will happen on January 19, 2038. Not that that’s a reason to relax — the time left to prepare may already be insufficient. The cause of this mass of problems will be an overflow in the integers storing date and time. While the root cause of the error is simple and clear, fixing it will require extensive and systematic efforts on every level — from governments and international bodies and down to organizations and private individuals.

The unwritten standard of the Unix epoch

The Unix epoch is the timekeeping system adopted by Unix operating systems, which became popular across the entire IT industry. It counts the seconds from 00:00:00 UTC on January 1, 1970, which is considered the zero point. Any given moment in time is represented as the number of seconds that have passed since that date. For dates before 1970, negative values are used. This approach was chosen by Unix developers for its simplicity — instead of storing the year, month, day, and time separately, only a single number is needed. This facilitates operations like sorting or calculating the interval between dates. Today, the Unix epoch is used far beyond Unix systems: in databases, programming languages, network protocols, and in smartphones running iOS and Android.

The Y2K38 time bomb

Initially, when Unix was developed, a decision was made to store time as a 32-bit signed integer. This allowed for representing a date range from roughly 1901 to 2038. The problem is that on January 19, 2038, at 03:14:07 UTC, this number will reach its maximum value (2,147,483,647 seconds) and overflow, becoming negative, and causing computers to “teleport” from January 2038 back to December 13, 1901. In some cases, however, shorter “time travel” might happen — to point zero, which is the year 1970.

This event, known as the “year 2038 problem”, “Epochalypse”, or “Y2K38”, could lead to failures in systems that still use 32-bit time representation — from POS terminals, embedded systems, and routers, to automobiles and industrial equipment. Modern systems solve this problem by using 64 bits to store time. This extends the date range to hundreds of billions of years into the future. However, millions of devices with 32-bit dates are still in operation, and will require updating or replacement before “day Y” arrives.

In this context, 32 and 64 bits refer specifically to the date storage format. Just because an operating system or processor is 32-bit or 64-bit, it doesn’t automatically mean it stores the date in its “native” bit format. Furthermore, many applications store dates in completely different ways, and might be immune to the Y2K38 problem, regardless of their bitness.

In cases where there’s no need to handle dates before 1970, the date is stored as an unsigned 32-bit integer. This type of number can represent dates from 1970 to 2106, so the problem will arrive in the more distant future.

Differences from the year 2000 problem

The infamous year 2000 problem (Y2K) from the late 20^th century was similar in that systems storing the year as two digits could mistake the new date for the year 1900. Both experts and the media feared a digital apocalypse, but in the end there were just numerous isolated manifestations that didn’t lead to global catastrophic failures.

The key difference between Y2K38 and Y2K is the scale of digitization in our lives. The number of systems that will need updating is way higher than the number of computers in the 20^th century, and the count of daily tasks and processes managed by computers is beyond calculation. Meanwhile, the Y2K38 problem has already been, or will soon be, fixed in regular computers and operating systems with simple software updates. However, the microcomputers that manage air conditioners, elevators, pumps, door locks, and factory assembly lines could very well chug along for the next decade with outdated, Y2K38-vulnerable software versions.

Potential problems of the Epochalypse

The date’s rolling over to 1901 or 1970 will impact different systems in different ways. In some cases, like a lighting system programmed to turn on every day at 7pm, it might go completely unnoticed. In other systems that rely on complete and accurate timestamps, a full failure could occur — for example, in the year 2000, payment terminals and public transport turnstiles stopped working. Comical cases are also possible, like issuing a birth certificate with a date in 1901. Far worse would be the failure of critical systems, such as a complete shutdown of a heating system, or the failure of a bone marrow analysis system in a hospital.

Cryptography holds a special place in the Epochalypse. Another crucial difference between 2038 and 2000 is the ubiquitous use of encryption and digital signatures to protect all communications. Security certificates generally fail verification if the device’s date is incorrect. This means a vulnerable device would be cut off from most communications — even if its core business applications don’t have any code that incorrectly handles the date.

Unfortunately, the full spectrum of consequences can only be determined through controlled testing of all systems, with separate analysis of a potential cascade of failures.

The malicious exploitation of Y2K38

IT and InfoSec teams should treat Y2K38 not as a simple software bug, but as a vulnerability that can lead to various failures, including denial of service. In some cases, it can even be exploited by malicious actors. To do this, they need the ability to manipulate the time on the targeted system. This is possible in at least two scenarios:

• Interfering with NTP protocol data by feeding the attacked system a fake time server
• Spoofing the GPS signal — if the system relies on satellite time

Exploitation of this error is most likely in OT and IoT systems, where vulnerabilities are traditionally slow to be patched, and the consequences of a failure can be far more substantial.

An example of an easily exploitable vulnerability related to time counting is CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) in Dover ProGauge MagLink LX4 automatic fuel-tank gauge consoles. Time manipulation can cause a denial of service at the gas station, and block access to the device’s web management panel. This defect earned its own CISA advisory.

The current status of Y2K38 mitigation

The foundation for solving the Y2K38 problem has been successfully laid in major operating systems. The Linux kernel added support for 64-bit time even on 32-bit architectures starting with version 5.6 in 2020, and 64-bit Linux was always protected from this issue. The BSD family, macOS, and iOS use 64-bit time on all modern devices. All versions of Windows released in the 21^st century aren’t susceptible to Y2K38.

The situation at the data storage and application level is far more complex. Modern file systems like ZFS, F2FS, NTFS, and ReFS were designed with 64-bit timestamps, while older systems like ext2 and ext3 remain vulnerable. Ext4 and XFS require specific flags to be enabled (extended inode for ext4, and bigtime for XFS), and might need offline conversion of existing filesystems. In the NFSv2 and NFSv3 protocols, the outdated time storage format persists. It’s a similar patchwork landscape in databases: the TIMESTAMP type in MySQL is fundamentally limited to the year 2038, and requires migration to DATETIME, while the standard timestamp types in PostgreSQL are safe. For applications written in C, pathways have been created to use 64-bit time on 32-bit architectures, but all projects require recompilation. Languages like Java, Python, and Go typically use types that avoid the overflow, but the safety of compiled projects depends on whether they interact with vulnerable libraries written in C.

A massive number of 32-bit systems, embedded devices, and applications remain vulnerable until they’re rebuilt and tested, and then have updates installed by all their users.

Various organizations and enthusiasts are trying to systematize information on this, but their efforts are fragmented. Consequently, there’s no “common Y2K38 vulnerability database” out there (1, 2, 3, 4, 5).

Approaches to fixing Y2K38

The methodologies created for prioritizing and fixing vulnerabilities are directly applicable to the year 2038 problem. The key challenge will be that no tool today can create an exhaustive list of vulnerable software and hardware. Therefore, it’s essential to update inventory of corporate IT assets, ensure that inventory is enriched with detailed information on firmware and installed software, and then systematically investigate the vulnerability question.

The list can be prioritized based on the criticality of business systems and the data on the technology stack each system is built on. The next steps are: studying the vendor’s support portal, making direct inquiries to hardware and software manufacturers about their Y2K38 status, and, as a last resort, verification through testing.

When testing corporate systems, it’s critical to take special precautions:

• Never test production systems.
• Create a data backup immediately before the test.
• Isolate the system being tested from communications so it can’t confuse other systems in the organization.
• If changing the date uses NTP or GPS, ensure the 2038 test signals cannot reach other systems.
• After testing, set the systems back to the correct time, and thoroughly document all observed system behaviors.

If a system is found to be vulnerable to Y2K38, a fixing timeline should be requested from the vendor. If a fix is impossible, plan a migration; fortunately, the time we have left still allows for updating even fairly complex and expensive systems.

The most important thing in tackling Y2K38 is not to think of it as a distant future problem whose solution can easily wait another five to eight years. It’s highly likely that we already have insufficient time to completely eradicate the defect. However, within an organization and its technology fleet, careful planning and a systematic approach to solving the problem will allow to actually make it in time.

Other noteworthy stories that might have slipped under the radar: BodySnatcher agentic AI hijacking, Telegram IP exposure, shipping systems hacked by researcher.

The post In Other News: FortiSIEM Flaw Exploited, Sean Plankey Renominated, Russia’s Polish Grid Attack appeared first on SecurityWeek.

UAT-9686 exploited the bug to deploy the AquaShell backdoor on Cisco appliances with certain ports open to the internet.

The post Cisco Patches Vulnerability Exploited by Chinese Hackers appeared first on SecurityWeek.

Researchers have disclosed technical details on a new AMD processor attack that allows remote code execution inside confidential VMs.

The post New ‘StackWarp’ Attack Threatens Confidential VMs on AMD Processors appeared first on SecurityWeek.

This isn’t good:

We discovered a critical vulnerability (CVE-2026-21858, CVSS 10.0) in n8n that enables attackers to take over locally deployed instances, impacting an estimated 100,000 servers globally. No official workarounds are available for this vulnerability. Users should upgrade to version 1.121.0 or later to remediate the vulnerability.

Three technical links and two news links.

Only a dozen new advisories have been published this Patch Tuesday by industrial giants. 

The post ICS Patch Tuesday: Vulnerabilities Fixed by Siemens, Schneider, Aveva, Phoenix Contact appeared first on SecurityWeek.

Exploitable without authentication, the two security defects could lead to configuration leak and code execution.

The post Fortinet Patches Critical Vulnerabilities in FortiFone, FortiSIEM appeared first on SecurityWeek.

The two browser updates resolve 26 security defects, including bugs that could be exploited for code execution.

The post Chrome 144, Firefox 147 Patch High-Severity Vulnerabilities appeared first on SecurityWeek.

Database platform MongoDB disclosed CVE-2025-14847, called MongoBleed. This is an unauthenticated memory disclosure vulnerability with a CVSS score of 8.7.

The post Threat Brief: MongoDB Vulnerability (CVE-2025-14847) appeared first on Unit 42.

Adobe has released patches for 25 vulnerabilities across its products, including a critical Apache Tika flaw in ColdFusion.

The post Adobe Patches Critical Apache Tika Bug in ColdFusion appeared first on SecurityWeek.

Two vulnerabilities patched this month by Microsoft were disclosed publicly before fixes were released.

The post Microsoft Patches Exploited Windows Zero-Day, 111 Other Vulnerabilities appeared first on SecurityWeek.

SAP has released 17 security notes, including four that address critical SQL injection, RCE, and code injection vulnerabilities.

The post SAP’s January 2026 Security Updates Patch Critical Vulnerabilities appeared first on SecurityWeek.

We identified remote code execution vulnerabilities in open-source AI/ML libraries published by Apple, Salesforce and NVIDIA.

The post Remote Code Execution With Modern AI/ML Formats and Libraries appeared first on Unit 42.

Introduction

Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.

The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.

Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.

To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.

During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.

Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.

Acquiring the modem firmware

The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.

Circuit board of the head unit

Description of the circuit board components:

Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.

Remote access to the modem (CVE-2024-39431)

The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).

We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.

3G protocol stack

The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).

Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.

As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.

In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).

Gaining persistence in the system

The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.

We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.

Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.

Stack overflow in the context of the operating system

Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!

Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.

The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.

All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.

As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.

However, being able to execute our own code on the modem does not give us access to user data. Or does it?

The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.

Introduction

Imagine you’re cruising down the highway in your brand-new electric car. All of a sudden, the massive multimedia display fills with Doom, the iconic 3D shooter game. It completely replaces the navigation map or the controls menu, and you realize someone is playing it remotely right now. This is not a dream or an overactive imagination – we’ve demonstrated that it’s a perfectly realistic scenario in today’s world.

The internet of things now plays a significant role in the modern world. Not only are smartphones and laptops connected to the network, but also factories, cars, trains, and even airplanes. Most of the time, connectivity is provided via 3G/4G/5G mobile data networks using modems installed in these vehicles and devices. These modems are increasingly integrated into a System-on-Chip (SoC), which uses a Communication Processor (CP) and an Application Processor (AP) to perform multiple functions simultaneously. A general-purpose operating system such as Android can run on the AP, while the CP, which handles communication with the mobile network, typically runs on a dedicated OS. The interaction between the AP, CP, and RAM within the SoC at the microarchitecture level is a “black box” known only to the manufacturer – even though the security of the entire SoC depends on it.

Bypassing 3G/LTE security mechanisms is generally considered a purely academic challenge because a secure communication channel is established when a user device (User Equipment, UE) connects to a cellular base station (Evolved Node B, eNB). Even if someone can bypass its security mechanisms, discover a vulnerability in the modem, and execute their own code on it, this is unlikely to compromise the device’s business logic. This logic (for example, user applications, browser history, calls, and SMS on a smartphone) resides on the AP and is presumably not accessible from the modem.

To find out, if that is true, we conducted a security assessment of a modern SoC, Unisoc UIS7862A, which features an integrated 2G/3G/4G modem. This SoC can be found in various mobile devices by multiple vendors or, more interestingly, in the head units of modern Chinese vehicles, which are becoming increasingly common on the roads. The head unit is one of a car’s key components, and a breach of its information security poses a threat to road safety, as well as the confidentiality of user data.

During our research, we identified several critical vulnerabilities at various levels of the Unisoc UIS7862A modem’s cellular protocol stack. This article discusses a stack-based buffer overflow vulnerability in the 3G RLC protocol implementation (CVE-2024-39432). The vulnerability can be exploited to achieve remote code execution at the early stages of connection, before any protection mechanisms are activated.

Importantly, gaining the ability to execute code on the modem is only the entry point for a complete remote compromise of the entire SoC. Our subsequent efforts were focused on gaining access to the AP. We discovered several ways to do so, including leveraging a hardware vulnerability in the form of a hidden peripheral Direct Memory Access (DMA) device to perform lateral movement within the SoC. This enabled us to install our own patch into the running Android kernel and execute arbitrary code on the AP with the highest privileges. Details are provided in the relevant sections.

Acquiring the modem firmware

The modem at the center of our research was found on the circuit board of the head unit in a Chinese car.

Circuit board of the head unit

Description of the circuit board components:

Using information about the modem’s hardware, we desoldered and read the embedded multimedia memory card, which contained a complete image of its operating system. We then analyzed the image obtained.

Remote access to the modem (CVE-2024-39431)

The modem under investigation, like any modern modem, implements several protocol stacks: 2G, 3G, and LTE. Clearly, the more protocols a device supports, the more potential entry points (attack vectors) it has. Moreover, the lower in the OSI network model stack a vulnerability sits, the more severe the consequences of its exploitation can be. Therefore, we decided to analyze the data packet fragmentation mechanisms at the data link layer (RLC protocol).

We focused on this protocol because it is used to establish a secure encrypted data transmission channel between the base station and the modem, and, in particular, it is used to transmit higher-layer NAS (Non-Access Stratum) protocol data. NAS represents the functional level of the 3G/UMTS protocol stack. Located between the user equipment (UE) and core network, it is responsible for signaling between them. This means that a remote code execution (RCE) vulnerability in RLC would allow an attacker to execute their own code on the modem, bypassing all existing 3G communication protection mechanisms.

3G protocol stack

The RLC protocol uses three different transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). We are only interested in UM, because in this mode the 3G standard allows both the segmentation of data and the concatenation of several small higher-layer data fragments (Protocol Data Units, PDU) into a single data link layer frame. This is done to maximize channel utilization. At the RLC level, packets are referred to as Service Data Units (SDU).

Among the approximately 75,000 different functions in the firmware, we found the function for handling an incoming SDU packet. When handling a received SDU packet, its header fields are parsed. The packet itself consists of a mandatory header, optional headers, and data. The number of optional headers is not limited. The end of the optional headers is indicated by the least significant bit (E bit) being equal to 0. The algorithm processes each header field sequentially, while their E-bits equal 1. During processing, data is written to a variable located on the stack of the calling function. The stack depth is 0xB4 bytes. The size of the packet that can be parsed (i.e., the number of headers, each header being a 2-byte entry on the stack) is limited by the SDU packet size of 0x5F0 bytes.

As a result, exploitation can be achieved using just one packet in which the number of headers exceeds the stack depth (90 headers). It is important to note that this particular function lacks a stack canary, and when the stack overflows, it is possible to overwrite the return address and some non-volatile register values in this function. However, overwriting is only possible with a value ending in one in binary (i.e., a value in which the least significant bit equals 1). Notably, execution takes place on ARM in Thumb mode, so all return addresses must have the least significant bit equal to 1. Coincidence? Perhaps.

In any case, sending the very first dummy SDU packet with the appropriate number of “correct” headers caused the device to reboot. However, at that moment, we had no way to obtain information on where and why the crash occurred (although we suspect the cause was an attempt to transfer control to the address 0xAABBCCDD, taken from our packet).

Gaining persistence in the system

The first and most important observation is that we know the pointer to the newly received SDU packet is stored in register R2. Return Oriented Programming (ROP) techniques can be used to execute our own code, but first we need to make sure it is actually possible.

We utilized the available AT command handler to move the data to RAM areas. Among the available AT commands, we found a suitable function – SPSERVICETYPE.

Next, we used ROP gadgets to overwrite the address 0x8CE56218 without disrupting the subsequent operation of the incoming SDU packet handling algorithm. To achieve this, it was sufficient to return to the function from which the SDU packet handler was called, because it was invoked as a callback, meaning there is no data linkage on the stack. Given that this function only added 0x2C bytes to the stack, we needed to fit within this size.

Stack overflow in the context of the operating system

Having found a suitable ROP chain, we launched an SDU packet containing it as a payload. As a result, we saw the output 0xAABBCCDD in the AT command console for SPSERVICETYPE. Our code worked!

Next, by analogy, we input the address of the stack frame where our data was located, but it turned out not to be executable. We then faced the task of figuring out the MPU settings on the modem. Once again, using the ROP chain method, we generated code that read the MPU table, one DWORD at a time. After many iterations, we obtained the following table.

The table shows what we suspected – the code section is only mapped for execution. An attempt to change the configuration resulted in another ROP chain, but this same section was now mapped with write permissions in an unused slot in the table. Because of MPU programming features, specifically the presence of the overlap mechanism and the fact that a region with a higher ID has higher priority, we were able to write to this section.

All that remained was to use the pointer to our data (still stored in R2) and patch the code section that had just been unlocked for writing. The question was what exactly to patch. The simplest method was to patch the NAS protocol handler by adding our code to it. To do this, we used one of the NAS protocol commands – MM information. This allowed us to send a large amount of data at once and, in response, receive a single byte of data using the MM status command, which confirmed the patching success.

As a result, we not only successfully executed our own code on the modem side but also established full two-way communication with the modem, using the high-level NAS protocol as a means of message delivery. In this case, it was an MM Status packet with the cause field equaling 0xAA.

However, being able to execute our own code on the modem does not give us access to user data. Or does it?

The full version of the article with a detailed description of the development of an AR exploit that led to Doom being run on the head unit is available on ICS CERT website.

We discuss the CVSS 10.0-rated RCE vulnerability in the Flight protocol used by React Server Components. This is tracked as CVE-2025-55182.

The post Exploitation of Critical Vulnerability in React Server Components (Updated December 12) appeared first on Unit 42.