FirstNet Compliance Failures: Security Flags for raised for Android Meeting SDK

Hi Zoom Support Team,
Subject - FirstNet Compliance Failures: Security Flags for SharedPreferences, Legacy Crypto (SHA-1), and WebView Debugging in Android Meeting SDK v6.5.1.31081

We prepared our production application for a highly secure deployment on the FirstNet Network. Our application integrates the Android Meeting SDK version 6.5.1.31081.

Following a mandatory automated and static security assessment by FirstNet, our build was flagged with three compliance issues arising entirely within the core binary modules of the Zoom SDK.

We require your guidance, verification of a programmatic workaround, and information on whether these blocks will be addressed in an upcoming release cycle.

Issue 1: Insecure Storage (World-Readable SharedPreferences)

  • Finding: The security scan flagged potential utilisation of deprecated file permission MODE_WORLD_READABLE / MODE_WORLD_WRITEABLE within ZoomApplication.java or linked internal configuration components.
  • Question: Is this block maintaining active legacy hooks, or is this dead code lingering within the mobilertc.aar package? How can we guarantee to the auditors that no application data is exposed to third-party app packages at runtime?

Issue 2: Use of Broken Cryptographic Algorithms (SHA-1 / MD5)

  • Finding: The static analysis engine detected hardcoded cryptographic string matching signatures for “SHA-1” and “MD5” within core compiled packages (us.zoom. / com.zipow.).
  • Question: We assume these signatures exist for backward-compatibility handshakes with legacy telepresence infrastructure or internal non-cryptographic checksums. Can you officially confirm that real-time streaming components (video/audio data packets) natively use AES-256-GCM transport encryption exclusively in this version, isolating the flagged algorithms from the user attack surface?

Issue 3: Remote WebView Debugging Enabled

  • Finding: The SDK explicitly invokes WebView.setWebContentsDebuggingEnabled(true) in production release binaries, presenting an arbitrary code execution risk if an attacker bridges physical access to the device.
  • Reference: This exact issue has been brought up on the Zoom Developer Forum: Ticket - WebView.setWebContentsDebuggingEnabled(true) found in release build — Zoom Meeting SDK Android 6.3.10
  • Workaround Check: To satisfy our security gate immediately, we intend to force-disable this flag dynamically directly after the SDK initialization completes:
override fun onZoomSDKInitializeResult(errorCode: Int, internalErrorCode: Int) {
    // Force override the flag globally to pass the FirstNet security scan
    android.webkit.WebView.setWebContentsDebuggingEnabled(false)
}

Question: Is this specific initialisation override fully compatible with the SDK’s lifecycle, or will it disrupt internal components or web-based UI fragments during an active meeting session?

Summary & Resolution Paths

We have audited Android Zoom Meeting SDK release change logs through version 7.0.5 and have found no mentions of these specific security vulnerabilities or hardening implementations.

Does Zoom provide a secure-baseline configuration API to switch off debugging behaviours globally, or are there internal patch targets scheduled to clear these legacy code blocks in a future SDK update?

As this is currently a hard blocker for our FirstNet network authorization, please look into this ASAP.

Which Android Meeting SDK version?
Android Meeting SDK v6.5.1.31081

Thanks!

Hi @xcube , thanks for reaching out to us. Please kinldy see our response below for Android Meeting SDK 6.5.1 or newer version:

Issue 1: After checking the source code, we confirmed no usage in Zoom source code. We believe it’s a false positive from the scanner.

Issue 2: It’s present for non-cryptographic purposes only. Not in the media transport path.

HA-1 and MD5 string signatures appear in any large Android binary because of legitimate non-security uses: HTTP ETag/cache keys, content fingerprints, file dedup hashes, certificate parsing for legacy server compat, third-party library internals (OkHttp, Glide, protobuf, Firebase, etc.).

Issue 3: We have included setWebContentsDebuggingEnabled(false) as build default config since MSDK Android 6.5.1. The only way to enable it is to enable the log (init SDK with enableLog = true).

Thank you!