Samsung says they care about your privacy, but their smart home hub shipped with 20 security holes that let hackers unlock your doors, watch your cameras, and control every device in your home. One flaw scored 9.9 out of 10 in severity — nearly the worst possible. When the SmartThings Hub crashed, it secretly sent a memory dump — which could include your passwords and personal data — to a third-party service called backtrace.io, completely unencrypted. Anyone watching your network could read it. Samsung never told users this was happening.
What they claim: SmartThings app requests CALL_PHONE, READ_CONTACTS, READ_PHONE_NUMBERS, and MODIFY_PHONE_STATE permissions. The privacy notice does not explain why a smart home hub controller needs to make phone calls or read contact lists.
What we found: The SmartThings app (com.samsung.android.oneconnect v1.8.21.28) requests CALL_PHONE, READ_CONTACTS, READ_PHONE_NUMBERS, and MODIFY_PHONE_STATE. These are dangerous-level Android permissions that grant access to the user's phone functionality and personal contacts. The SmartThings U.S. Privacy Notice mentions collecting "interactions and inputs" but does not specifically disclose or justify access to phone call functionality, contact lists, or phone numbers for a smart home management app.
What they claim: SmartThings app requests RECORD_AUDIO and CAMERA permissions. The privacy notice mentions collecting voice commands and video but frames this as user-initiated.
What we found: The app requests RECORD_AUDIO and CAMERA permissions. The privacy notice states "If you use voice commands to control SmartThings, information about your conversations and voice commands will be relayed through SmartThings servers" — framing audio collection as only happening during voice commands. However, the RECORD_AUDIO permission allows continuous audio access at the app level, and the Exodus report confirms the app has 218 total permissions (including many Samsung-proprietary ones). The FOREGROUND_SERVICE_MEDIA_PLAYBACK permission also allows sustained background audio processing.
What they claim: The hub's hubCore service on port 39500 accepted unauthenticated messages (CVE-2018-3911), despite Samsung positioning SmartThings as a central home security controller.
What we found: CVE-2018-3911 (CVSS 8.6) documents that the hubCore process on port 39500 accepted unauthenticated messages from the local network and relayed them to remote servers without sanitization. This allowed HTTP header injection that could manipulate internal service communications. The SmartThings Hub is marketed as a security device that controls smart locks, alarm systems, and cameras. An unauthenticated network service on a security hub is a fundamental design contradiction.
What they claim: Samsung's privacy notice does not disclose that the SmartThings app includes Microsoft Visual Studio App Center tracking libraries.
What we found: Exodus Privacy analysis of SmartThings app v1.8.21.28 identifies two trackers: Microsoft Visual Studio App Center Analytics and Microsoft Visual Studio App Center Crashes. The SmartThings U.S. Privacy Notice mentions no specific analytics or advertising partners by name. The Samsung Privacy Policy references general "analytics services" but does not name Microsoft as a data recipient for SmartThings usage data.
What they claim: SmartThings privacy notice collects "information about your conversations and voice commands" relayed through SmartThings servers, but does not specify data retention or deletion timelines.
What we found: The SmartThings U.S. Privacy Notice (effective December 29, 2025) confirms voice commands are "relayed through SmartThings servers" and collects video/audio from connected devices. It also collects health data (medication schedules, symptoms, medical visits) via Family Care. However, no specific data retention periods are disclosed for any of these sensitive data categories. Samsung states data is shared with "business partners who control and manage your personal information" — an unusually broad category that gives partners control over user data.
What they claim: SmartThings U.S. Privacy Notice states Samsung "respects your concerns about privacy" and collects data through the Service, but makes no specific security commitments for the hub hardware or firmware.
What we found: Cisco Talos discovered 20 vulnerabilities in SmartThings Hub firmware 0.20.17, including CVE-2018-3902 (CVSS 9.9 buffer overflow enabling remote code execution), CVE-2018-3879 (SQL injection in video-core database), and CVE-2018-3856 (command injection via RTSP password). These vulnerabilities allowed attackers to unlock smart locks, spy via cameras, and control all connected devices. The hub was shipped with these critical flaws for an extended period before the July 2018 patch.
What they claim: SmartThings Hub firmware sent crash dumps (Google Breakpad minidumps) to backtrace.io over unencrypted HTTP (CVE-2018-3927).
What we found: CVE-2018-3927 documents that the hubCore process transmitted crash minidumps to backtrace.io without encryption. Crash dumps can contain sensitive memory contents including credentials, device state, and user data. Meanwhile, the SmartThings Privacy Notice does not disclose backtrace.io as a data recipient, and Samsung's privacy page makes no mention of unencrypted data transmission to third-party crash reporting services.
What they claim: Samsung's privacy policy does not disclose the scope of data sharing with subsidiaries in the context of the March 2022 Lapsus$ breach, which exposed SmartThings source code and secret keys.
What we found: The Lapsus$ group leaked 190GB of Samsung data in March 2022 including SmartThings app source code, secret keys, TrustZone trusted applet code, and bootloader source. SmartThings secret keys could be used to impersonate services or forge authentication. A second breach in July 2022 exposed customer PII. The privacy policy states data is shared with "subsidiaries and affiliates" and "service providers" but does not disclose the risk that centralized key management creates for all SmartThings users when breached.
What they claim: SmartThings markets itself as making homes "safer" (FCC quick-start guide tagline: "A safer, smarter home"). The hub's five wireless radios create the widest attack surface of any consumer smart home hub.
What we found: The SmartThings Hub v3 supports Wi-Fi (2.4GHz + 5GHz), Bluetooth LE, Zigbee, Z-Wave, and Thread — five distinct wireless protocols, each with its own attack surface. CVE-2018-3926 demonstrated that even the ZigBee firmware update process was vulnerable (integer underflow in CRC16 check). The hub communicates with at least 8 cloud endpoints. Marketing the device as making homes "safer" contradicts the reality that each additional radio protocol adds exploitable attack surface.
What they claim: SmartThings app requests QUERY_ALL_PACKAGES, WRITE_SECURE_SETTINGS, and WRITE_SETTINGS — system-level permissions that go far beyond controlling smart home devices.
What we found: QUERY_ALL_PACKAGES lets the app enumerate every app installed on your phone. WRITE_SECURE_SETTINGS and WRITE_SETTINGS allow modifying system configuration. These are system-level permissions rarely needed by consumer apps. Combined with the hub's five wireless radios (Wi-Fi, BLE, Zigbee, Z-Wave, Thread) and 8 hardcoded cloud endpoints, the SmartThings ecosystem has a uniquely wide attack surface. Fernandes et al. (IEEE S&P 2016) found 55% of SmartApps are overprivileged due to the coarse-grained capability model.
What they claim: Academic research found 55% of SmartApps overprivileged, yet Samsung's own companion app requests 46 Android permissions and 218 total permissions including Samsung-proprietary ones.
What we found: Fernandes et al. (IEEE S&P 2016) found that 55% of 499 SmartApps are overprivileged because the capability model is coarse-grained — an app requesting "lock" capability gets both lock and unlock. The SmartThings companion app itself exemplifies this: it requests ACTIVITY_RECOGNITION (physical activity tracking), HIGH_SAMPLING_RATE_SENSORS (high-frequency sensor data), ACCESS_BACKGROUND_LOCATION (continuous location tracking), and SCHEDULE_EXACT_ALARM — none of which are core to hub management.