Overview
This blog post will discuss a critical vulnerability discovered in COROS PACE 3 devices, specifically affecting versions up to 3.0808.0. This vulnerability, designated as CVE-2025-32878, presents a significant risk due to its potential to compromise systems and leak sensitive data. As COROS PACE 3 devices are widely used in various sectors, the impact of this vulnerability is widespread, affecting individual users, organizations, and even industries at large. The severity of this issue necessitates immediate attention and mitigation.
Vulnerability Summary
CVE ID: CVE-2025-32878
Severity: Critical (9.8 CVSS Score)
Attack Vector: Network
Privileges Required: None
User Interaction: None
Impact: Potential system compromise or data leakage
Affected Products
Share secrets securely
Ameeba is private infrastructure for communication and sensitive work built on encrypted identity instead of exposed corporate identity systems.
Passwords, credentials, confidential files, screenshots, internal discussions, sensitive AI context, and private coordination should not become exposed across ordinary communication platforms.
- • Encrypted identity
- • Private Spaces for organizations and teams
- • End-to-end encrypted chat, calls, files, and notes
- • Sensitive AI work and protected collaboration
- • Built for information that cannot leak
Our mission is to secure human work alongside AI.
Product | Affected Versions
COROS PACE 3 | Up to 3.0808.0
How the Exploit Works
The vulnerability arises from the COROS PACE 3 devices’ firmware download function, which connects the watch to a WLAN. Before downloading firmware files, the watch requests information about the firmware via HTTPS from the back-end API. However, the X.509 server certificate within the TLS handshake is not validated by the device. This leaves room for an attacker, who is in an active machine-in-the-middle position using a TLS proxy and a self-signed certificate, to eavesdrop and manipulate the HTTPS communication. Consequently, the attacker can potentially steal the API access token of the assigned user account.
Conceptual Example Code
In essence, the attacker intercepts the communication between the device and server. A conceptual example could be depicted by the following pseudocode:
// Interception of communication
ATTACKER_MACHINE -> DEVICE:
START TLS HANDSHAKE
DEVICE -> ATTACKER_MACHINE:
SEND CLIENT HELLO
ATTACKER_MACHINE -> DEVICE:
SEND SERVER HELLO, CERTIFICATE (Self-Signed), SERVER HELLO DONE
DEVICE -> ATTACKER_MACHINE:
CLIENT KEY EXCHANGE, CHANGE CIPHER SPEC, ENCRYPTED HANDSHAKE MESSAGE
ATTACKER_MACHINE -> DEVICE:
CHANGE CIPHER SPEC, ENCRYPTED HANDSHAKE MESSAGE
// Communication manipulation
ATTACKER_MACHINE -> BACKEND_API:
GET /firmware/info HTTP/1.1
Authorization: Bearer <API access token>
BACKEND_API -> ATTACKER_MACHINE:
{ "firmware": { "version": "3.0808.0", "url": "..." } }
ATTACKER_MACHINE -> DEVICE:
{ "firmware": { "version": "3.0808.0", "url": "<malicious URL>" } }
This pseudocode demonstrates how the attacker intercepts the TLS handshake, manipulates the HTTPS communication, steals the API token, and potentially redirects the device to download malicious firmware.
