CVE-2025-52883

Executive Summary

CVE-2025-52883 is a medium-severity vulnerability in the Meshtastic-Android application (version < 2.5.21) that allows an attacker to send an unencrypted direct message to a victim while impersonating any other node on the mesh network. The message appears in the victim’s chat interface as if it came from the legitimate node and falsely displays a green padlock icon, indicating Public Key Cryptography (PKC) protection, even though the message is sent using the shared channel key (unencrypted). This creates a false sense of security and enables effective social engineering or phishing attacks within the mesh network.

The vulnerability stems from insufficient verification of whether a message was actually encrypted with PKC or the shared channel key. The client application trusts the message metadata without validating the cryptographic origin. The patch in version 2.5.21 introduces stricter control on message encryption verification and recommends using a yellow half-open padlock icon for non-PKC messages to provide clear visual feedback.

Supply Chain & Package Security

This vulnerability affects the Meshtastic-Android application, which is distributed via the Google Play Store and F-Droid. The application is built on the Meshtastic firmware and uses the Android platform’s cryptographic libraries. No supply chain compromise is indicated, but users should verify the integrity of the APK file before installation.

CVSS Breakdown & Threat Level

CVSS Score: 5.3 (Medium) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

• Attack Vector (AV): Network – The attacker sends the malicious message over the mesh network.
• Attack Complexity (AC): Low – No special conditions required; the attacker only needs to be on the same mesh network.
• Privileges Required (PR): None – No authentication needed.
• User Interaction (UI): Required – The victim must read the message and trust the false padlock.
• Scope (S): Unchanged – The vulnerability affects only the client application.
• Confidentiality (C): None – No data is disclosed.
• Integrity (I): Low – The attacker can inject false messages that appear legitimate.
• Availability (A): None – No denial of service.

Threat Level: Medium. The attack requires user interaction but can be used for targeted phishing or misinformation within a mesh network.

Deep Dive & Mechanics

The Meshtastic-Android application uses two encryption modes:

1. Public Key Cryptography (PKC): Messages are encrypted with the recipient’s public key, ensuring end-to-end encryption.
2. Shared Channel Key: Messages are encrypted with a shared key known to all nodes on the channel, providing only group-level encryption.

The vulnerability lies in the client’s UI logic. When a message is received, the application checks a flag in the message metadata to determine if PKC was used. If the flag is set, it displays a green padlock icon. However, an attacker can craft a message with the PKC flag set to true while actually encrypting it with the shared channel key. The victim’s client then displays the green padlock, misleading the victim into believing the message is end-to-end encrypted.

The attacker can also spoof the source node ID, making the message appear to come from any other node on the mesh. This allows the attacker to impersonate a trusted contact and send malicious content (e.g., a phishing link) that the victim is more likely to trust.

The root cause is a lack of cryptographic verification on the client side. The client should verify that the message was actually encrypted with the claimed key before displaying the padlock. The patch in version 2.5.21 addresses this by implementing stricter checks and recommends using a yellow half-open padlock for non-PKC messages.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-2.5.21):

// In MessageAdapter.kt or similar
fun bind(message: Message) {
    if (message.isPkc) {
        padlockIcon.setImageResource(R.drawable.ic_padlock_green)
    } else {
        padlockIcon.setImageResource(R.drawable.ic_padlock_grey)
    }
}

The isPkc flag is set based on the message metadata without verifying the actual encryption method.

Patched Code (2.5.21+):

// In MessageAdapter.kt or similar
fun bind(message: Message) {
    when {
        message.isPkcVerified -> {
            padlockIcon.setImageResource(R.drawable.ic_padlock_green)
        }
        message.isChannelEncrypted -> {
            padlockIcon.setImageResource(R.drawable.ic_padlock_yellow_half_open)
        }
        else -> {
            padlockIcon.setImageResource(R.drawable.ic_padlock_grey)
        }
    }
}

The patched code introduces isPkcVerified which is set only after cryptographic verification of the message’s encryption origin. It also adds a distinct yellow half-open padlock for channel-encrypted messages.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Meshtastic mesh network with at least two nodes (attacker and victim).
• Attacker node running Meshtastic firmware with ability to send raw packets.
• Victim node running Meshtastic-Android version < 2.5.21.

Exploitation Steps:

1. Identify the victim’s node ID and the node ID of a trusted contact (e.g., “Alice”).
2. Craft a direct message packet with:
   • Source: Alice’s node ID
   • Destination: Victim’s node ID
   • Payload: Malicious content (e.g., “Click here: http://malicious.link”)
   • PKC flag: Set to true
   • Encryption: Use the shared channel key (not Alice’s public key)
3. Send the packet over the mesh network.
4. The victim receives the message, sees the green padlock, and reads the content, believing it came from Alice with end-to-end encryption.

Example Packet Crafting (Python with meshtastic library):

import meshtastic
import meshtastic.serial_interface

interface = meshtastic.serial_interface.SerialInterface()
# Craft a direct message with spoofed source and PKC flag
packet = {
    "to": victim_node_id,
    "from": alice_node_id,
    "type": "PKC",
    "payload": b"Click here: http://malicious.link",
    "encryption": "channel"  # Actually use channel key
}
interface.sendData(packet)

Blue Team

Detection Steps:

1. Monitor mesh network traffic for messages where the PKC flag is set but the encryption method is channel-based.
2. Implement client-side verification: Check the actual encryption key used against the claimed PKC flag.
3. Educate users to verify the padlock icon type (green vs. yellow half-open) after patching.
4. Use network monitoring tools to detect anomalous message patterns (e.g., messages from a node that is offline).

Honeypot Setup:

• Deploy a Meshtastic node with a modified client that logs all received messages and their encryption metadata.
• Alert when a message has a PKC flag but is encrypted with the channel key.

Indicators of Compromise (IOCs)

• Network: Meshtastic packets with type: PKC but encrypted with the shared channel key.
• Client: Messages displaying a green padlock but originating from a node that is not using PKC.
• Logs: Client logs showing isPkc=true but encryptionMethod=channel.
• File: Modified Meshtastic-Android APK with tampered cryptographic verification logic.

Detection Engineering

YARA Rule

rule CVE_2025_52883_Meshtastic_PKC_Spoof {
    meta:
        description = "Detects Meshtastic-Android APK files vulnerable to CVE-2025-52883"
        author = "Valters IT"
        date = "2025-04-10"
        hash = "sha256:target_apk_hash"
    strings:
        $s1 = "isPkc" ascii wide
        $s2 = "ic_padlock_green" ascii wide
        $s3 = "ic_padlock_grey" ascii wide
        $s4 = "setImageResource" ascii wide
    condition:
        all of ($s*) and filesize < 100MB
}

Sigma Rule

title: CVE-2025-52883 - Meshtastic PKC Spoofing Detection
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects Meshtastic network packets with PKC flag but channel encryption
author: Valters IT
date: 2025-04-10
logsource:
    category: network
    product: meshtastic
detection:
    selection:
        packet.type: "PKC"
        packet.encryption: "channel"
    condition: selection
falsepositives:
    - Legitimate misconfigured nodes
level: medium

Suricata Rule

alert tcp any any -> any any (msg:"CVE-2025-52883 Meshtastic PKC Spoofing"; content:"|00|"; depth:1; content:"|01|"; within:2; content:"PKC"; nocase; content:"channel"; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Meshtastic-Android to version 2.5.21 or later.
2. If upgrade is not possible, disable PKC display or manually verify encryption with trusted contacts.

Long-term Fixes:

• Implement cryptographic verification of message encryption origin on the client side.
• Use distinct padlock icons for different encryption levels (green for PKC, yellow half-open for channel, grey for none).
• Add a warning message when a PKC-flagged message is received but cannot be verified.

Compensating Controls:

• Educate users to verify the padlock icon type after patching.
• Monitor mesh network for anomalous messages.
• Use out-of-band verification (e.g., voice call) for sensitive communications.

Valters IT