Scan results

Recommendation: Solid

CITT rates this Solid (78/100). Login information and device keys are stored in the iOS Keychain, and cloud connections to Meross servers carry additional server identity verification on top of standard transport security. The provisioning flow for adding new devices to a home network uses a static encryption key, creating a window where a local network observer could potentially recover the Wi-Fi password entered during pairing. Firmware updates for connected devices may be delivered over unencrypted connections in some code paths.

Key Findings

Data Security - 0 findings

Network Security - 1 finding (1 medium)

Code Safety - 2 findings (1 medium, 1 low)

Privacy - 1 finding (1 medium)

Privacy Concerns

What Leaves the Device

• Usage and session data: the binary links the Firebase Analytics SDK, which is designed to share device identifiers and behavioral data with Google for analytics purposes.
• Crash reports: the binary links Firebase Crashlytics, which may share diagnostic information with Google when the app encounters an error.
• Device IP address: the binary contains an unencrypted URL path for ipinfo.io alongside a secure path. If the unencrypted path is exercised, the device's public IP is sent to ipinfo.io, which can infer approximate city, region, and coordinates from that IP without an iOS location permission being requested. This was not observed at runtime.

What Stays on the Device

Smart home commands issued through Matter or HomeKit are handled on the local network or within Apple's end-to-end encrypted infrastructure and do not pass through Meross cloud servers. This means the state of connected devices remains outside Meross's visibility when using HomeKit or Matter control paths.

Third-Party Data Sharing

Third parties that may receive data from the app:

• Firebase Analytics (Google) - usage analytics and device identifiers
• Firebase Crashlytics (Google) - crash and error reporting
• Firebase Messaging (Google) - push notifications
• AWS (Amazon) - cloud authentication, backend services, and file storage
• OpenWeatherMap - weather data for home automations
• ipinfo.io - IP-based location lookup
• Kookong SDK - Bluetooth and IoT device communication
• OpenTelemetry Swift - application telemetry

Understanding the Scores

Security: 75/100
Privacy: 86/100

Security Breakdown

• Data Security: 82/100. Login information, device keys, and session keys are stored in the iOS Keychain, hardware-backed storage that other apps cannot access. The Wi-Fi provisioning path uses a static encryption key that a local network observer may be able to use to recover the home Wi-Fi password during device pairing.
• Network Security: 82/100. Cloud connections to Meross infrastructure carry additional server identity verification layered on top of standard transport security. The MQTT connection between the app and local smart home devices on the home network may be configured to accept unverified server identities, based on static analysis - this was not observed at runtime and the scope appears limited to local-network connections.
• Code Safety: 90/100. Memory protection is active throughout the binary. External web content is opened in a sandboxed browser with no interface between web content and native device controls.

Privacy Breakdown

• Data Collection: 85/100. The binary links Firebase Analytics and Crashlytics, which are designed to share usage and diagnostic data with Google. No advertising SDK is present and no data broker SDK was identified.
• Data Sharing: 90/100. Data sharing is limited to the developer's own infrastructure and the analytics and cloud services listed under Third-Party Data Sharing. No advertising network or data broker SDK was identified in this build.
• User Control: 87/100. Smart home device control via HomeKit and Matter keeps activity within Apple's encrypted infrastructure. Standard iOS controls govern notification access.

Positive Security Features

• Smart home commands issued through Matter or HomeKit stay on the local network or within Apple's end-to-end encrypted infrastructure and do not pass through Meross cloud servers.
• Cloud connections to Meross servers carry additional server identity verification layered on top of standard transport security, making it harder for a local observer to impersonate the Meross backend.
• Login information, session keys, and device keys are stored in the iOS Keychain, hardware-backed storage that is inaccessible to other apps.
• Shared data storage is restricted to the developer's own first-party app extensions under a single developer Team ID; no third-party developer can access it.
• External web pages are opened in a sandboxed browser view with no access to the app's own storage or session data.
• The embedded browser has no interface between web content and native smart home controls, so web content cannot reach device APIs.
• Memory protection is active throughout the binary, providing defense against memory corruption.
• No advertising SDK is present; no broad-reach ad network has access to usage data.

Areas for Improvement

Disclosure observations

Observations about disclosure, each stated against the published guidance so a reader can compare:

1. Analytics SDK disclosure
   Apple's App Store privacy label guidelines require developers to declare data types collected by third-party SDKs integrated into the app. The build links Firebase Analytics (Google), which is designed to collect device identifiers and behavioral data. The app's privacy manifest declares no collected data types. Readers can compare Firebase's published data practices against the current App Store privacy label to assess whether the disclosure is complete.

2. IP-based location lookup disclosure
   The binary contains an unencrypted URL path for ipinfo.io that, if exercised, would send the device's IP address to a third-party service that returns approximate geographic location derived from that IP. This flow does not require an iOS location permission. Whether this path is exercised in production could not be determined from static analysis alone, and it is not reflected in the current privacy manifest.

Security Enhancements

1. Wi-Fi provisioning key hardening
   The device provisioning path uses a static encryption key to protect the home Wi-Fi password during setup. Generating a unique key per pairing session would eliminate the window in which a local network observer could potentially recover that password.

2. Firmware update transport security
   Ensuring firmware update downloads for connected devices always use encrypted connections, with integrity verification that cannot be substituted by a local network observer, would reduce the risk of malicious firmware being delivered on the home network.

3. URL scheme input validation
   The custom URL scheme registered in the build can be invoked by any other installed app without a permission prompt. Verifying that inbound URL scheme requests occur within an authenticated session before executing any device control actions would reduce the risk of unauthorized device actuation by other apps.

Technical Context

App Type: IoT smart home controller, cloud and local network
Classes Analyzed: 180,206
Third-Party Services: 10
Context Tags: iot, smart_home, location, camera, bluetooth

About This Analysis

This security analysis was conducted by CITT (Can I Trust That), an independent security analysis service. The analysis is static code review of iOS applications, intended to help people make informed decisions about app security and privacy.

App Details

Developer: Meross
Version: 3.42.0 (Build 698)
Analysis Date: 2026-08-22
Package: com.meross.Meross

Analysis Limitations

• Static analysis only (code review without running the app)
• Based on iOS build 3.42.0 (Build 698) analyzed on 2026-08-22
• May not reflect server-side security controls
• Cannot detect all runtime behaviors