The Mobile Healthcare Security Gap: What 3,000+ App Scans Reveal

Quokka analyzed 3,000+ healthcare and medical mobile applications spanning a broad range of healthcare-related categories and found critical mobile app security risks. Read more on the vulnerabilities and how to secure healthcare apps.

By

Key Takeaways:

  • Sensitive Data Leakage Risk: 9.81% of the 3,000+ analyzed apps risk leaking personally identifiable information (PII) outside the secure app environment.
  • Flawed Intent Handling: Over 8% of apps contain input vulnerabilitiesโ€”7.69% via external local input and 1.06% via remote controlโ€”making them prime targets for injection attacks.
  • Severe Third-Party Risk: 57.05% of apps have dangerous software bill of materials (SBOM) flaws, with 14.6% flagged as critical and 42.4% as high severity.
  • High-Stakes Targets: Telehealth, e-prescribing, remote monitoring, and auth apps carry the highest risk, directly threatening patient safety and electronic protected health information (ePHI).
  • The Solution: Organizations must enforce continuous testing, strict input validation, secure component handling, and rigorous app vetting before deployment.

Scope of Analysis

Quokka analyzed 3,000+ healthcare and medical mobile applications spanning a broad range of healthcare-related categories, including:

  • Telehealth applications
  • Health tracking applications
  • Pharmacy and prescription platforms
  • Remote patient monitoring platforms
  • Wellness and fitness applications

Each app was analyzed with Quokkaโ€™s proprietary engines for indicators of insecure coding practices, insecure data handling, improper inter-process communication, credential exposure risks, insecure storage mechanisms, and unsafe component interactions.

Key Findings

Security FindingPercentage of Apps
Personally Identifiable Information (PII) potentially leaks outside the app9.81%
Externally-controlled local input used to set Intent fields7.69%
Cryptographic plaintext potentially leaks outside the app6.81%
Credentials potentially leak outside the app4.54%
Deserialization of externally-controlled objects3.01%
External local input used to construct Intent messages2.15%
External camera invocation components1.65%
External local input used in SQL statement construction1.38%
Remotely-controlled input used to set Intent fields1.06%

Risk Implications for Healthcare Organizations

The vulnerabilities identified in this analysis are not merely technical concerns. They also carry direct regulatory, legal, and patient safety implications for healthcare organizations that deploy or recommend these applications.

  • HIPAA Security Rule (45 CFR ยง164.312): PII and credential leakage findings directly implicate requirements for ePHI (Electronic Protected Health Information) integrity and transmission security. Organizations whose apps exhibit these patterns may face breach notification obligations and enforcement exposure.
  • Patient Safety: Apps used for medication management, chronic disease monitoring, or telehealth that contain SQL injection or unsafe deserialization vulnerabilities could have their data corrupted or tampered with, with direct clinical consequences.
  • Reputation: Healthcare organizations that recommend or integrate third-party apps into their care delivery workflows inherit reputational risk when those apps have unaddressed security vulnerabilities.

Detailed Explanations of Findings

1. PII Potentially Leaks Outside the App – 9.81% of analyzed apps

Healthcare applications routinely process highly sensitive information including patient names, dates of birth, Social Security numbers, insurance information, medical record identifiers, appointment details, and contact information. This data can leak outside the app through debug logs, shared device storage, unencrypted caches, third-party SDKs, insecure network communications, clipboard usage, and analytics platforms. A common and easily overlooked vector is third-party SDK integration โ€” SDKs may transmit conversation content, usage data, or other sensitive information to vendor-controlled servers by default, outside the healthcare provider’s compliance controls. Unlike many industries, healthcare data breaches frequently involve both financial and medical identity theft risks.

2. Externally-Controlled Local Input Used to Set Intent Fields – 7.69%

Intent fields facilitate communication between applications and components, and improper validation of Intent input can allow malicious actors to manipulate how a healthcare application behaves. When an app reads external input โ€” such as a QR code, deep link, or NFC tag โ€” and uses it directly to populate Intent fields without validating it against permitted values, an attacker can craft a payload that redirects the Intent to privileged internal components. This may enable launching hidden activities, triggering sensitive workflows, bypassing security boundaries, or manipulating application state, all within the context of the patient’s authenticated session.

3. Cryptographic Plaintext Potentially Leaks Outside the App – 6.81%

Encryption is commonly used to protect healthcare data both in transit and at rest, but once decrypted within the application, sensitive information can still escape through logging mechanisms, temporary cache files, memory dumps, shared storage, clipboard access, and third-party integrations. A particular risk arises when plaintext data is passed as a raw string through implicit Intents or system share sheets. The OS may capture this content as recent activity, and device backup services can then automatically sync it to personal cloud accounts governed by consumer-grade security rather than healthcare compliance standards.

4. Credentials Potentially Leak Outside the App – 4.54%

Healthcare mobile applications frequently integrate with EHR systems, SSO platforms, insurance platforms, prescription systems, and identity providers, making credential handling a high-value target. API keys, OAuth tokens, session tokens, and usernames and passwords can be exposed when credentials are injected into WebViews that load live web content โ€” any third-party script running on that page, including supply-chain-compromised accessibility or analytics widgets, can read and exfiltrate those values before the patient has interacted with the screen at all.

5. Deserialization of Externally-Controlled Objects – 3.01%

Unsafe deserialization is a well-known attack vector capable of introducing denial-of-service conditions, application crashes, memory exhaustion, and in severe cases arbitrary code execution. Healthcare applications that cache structured data โ€” care plans, imaging files, medication schedules, synchronized records โ€” are particularly exposed when that data originates from a backend that could itself be compromised. A tampered serialized payload delivered through a routine sync operation can execute within the app’s process, which typically holds the patient’s authenticated session, local health records, and device permissions.

6. External Local Input Used to Construct Intent Messages – 2.51%

Applications that dynamically build Intent messages from untrusted external input, such as redirect parameters in deep links, may unintentionally expose privileged internal functionality, effectively turning a trusted healthcare application into a proxy for unauthorized actions. When the destination is not validated against a whitelist of permitted screens, an attacker can craft a link that routes a patient through a legitimate flow, such as identity verification, and then fires an Intent to a sensitive screen with the verified authentication context attached, bypassing protections that screen would normally enforce.

7. External Camera Invocation Components – 1.65%

Healthcare applications commonly use camera functionality for insurance card scanning, prescription uploads, telehealth documentation, barcode scanning, and clinical imaging workflows. When a camera-invoking Activity is exported without proper caller authentication โ€” particularly one registered with an intent filter or publicly documented deep link โ€” any third-party application or malicious link can launch it directly. This means an attacker can trigger image capture without the user’s informed consent, and if the upload destination is not validated, captured images can be silently routed to an attacker-controlled endpoint rather than the intended backend.

8. External Local Input Used in SQL Statement Construction – 1.38%

Unsafe SQL construction introduces local injection risks that can allow attackers to read, modify, delete, or corrupt data in locally cached databases. In healthcare applications, these databases often contain medication histories, appointment records, and cached authentication tokens. When user-supplied input is concatenated directly into a query without sanitization, a crafted search term can extract data well beyond the intended scope, including configuration entries and credentials stored in the same local database.

9. Remotely-Controlled Input Used to Set Intent Fields – 1.06%

When an application uses fields from remote sources โ€” such as push notification payloads โ€” to directly construct and fire Intents, it creates a remote channel through which application behavior can be manipulated. If the backend delivering those payloads is compromised, an attacker can send a crafted notification that silently triggers internal functionality, such as a document-export Activity, when the end user taps what appears to be a routine alert. This can establish effective remote command-and-control over sensitive app functions without any visible indication.

SBOM Findings

The SBOM (Software Bill of Materials) analysis surfaced a significant concentration of high- and critical-severity vulnerabilities in third-party components embedded within the analyzed apps. 57.05% of apps contained a critical- or high-severity finding, underscoring the supply chain risk inherent in healthcare mobile software.

SeverityPercentage of Apps
Critical14.6%
High42.4%
Medium38.3%
Low23.0%

Recommendations to Secure the Mobile Attack Surface

For Application Developers

  • Enforce HTTPS for all data transmissions and remove any HTTP fallback pathways.
  • Implement strict input validation and sanitization on all external inputs used in Intent construction, SQL queries, and object deserialization routines.
  • Strip all debug logging statements that capture user data before release builds. Conduct automated checks in CI/CD pipelines to enforce this.
  • Apply component-level permissions (signature protection level) to all internal Android components accessible via Intent.
  • Replace direct object deserialization with explicit data mapping or use the Parcelable interface with class allowlisting.

Q-mast is Quokkaโ€™s automated mobile application security testing solution purpose-built for development teams that need to detect and address vulnerabilities like those identified in this analysis โ€” including Intent injection, PII leakage, unsafe deserialization, and credential exposure โ€” before apps reach users. Q-mast performs full-spectrum testing across the mobile software development lifecycle, covering static, dynamic, and interactive analysis, even in obfuscated or binary-only builds. It generates a complete, version-specific SBOM including embedded libraries, enabling precise identification of the third-party component vulnerabilities that contributed to 14.6% critical and 42.4% high-severity findings in this dataset. 

For Healthcare Organizations

  • Establish a mobile app vetting process that includes security risk assessment as a prerequisite for endorsement or integration.
  • Prioritize remediation of apps used in clinical workflows, especially those handling ePHI, prescribing data, or authentication credentials.
  • Require third-party app vendors to provide evidence of security testing as part of vendor due diligence and contractual obligations.
  • Monitor app portfolios on an ongoing basis โ€” conduct rescans at each major version update, not just at initial procurement.

Q-scout enables security teams to vet mobile apps while substantiating their decisions with data-driven insights, directly supporting the app vetting, vendor due diligence, and continuous monitoring practices recommended above. It provides the evidence needed to confidently approve or block apps, ensuring compliance, safeguarding patient privacy, and protecting organizational assets from mobile app threats.

Q-scout integrates with MDM/ UEM platforms, giving security teams real-time visibility into mobile apps installed across managed devices. App inventories are automatically ingested and continuously refreshed, so each app is analyzed for risks as soon as it is added or updated. This provides administrators with an accurate, actionable view of mobile app exposure across the enterprise without manual effort.

Partner Perspective

Rachana Vijayan, EVP, Global Go-To-Market & CMO at Hexnode shares their thoughts on protecting mobile devices in healthcare spaces.

At Hexnode, we help organizations manage and secure mobile devices across a wide range of industries, including highly-regulated sectors. Mobile Device Management (MDM) provides IT teams with the tools to enroll, configure, and manage the devices employees rely on every day. However, while device management is a critical part of a security strategy, visibility into the applications running on those devices is equally important for understanding and addressing mobile risk.

This is where the integration between Hexnode UEM and Quokkaโ€™s Q-scout adds value. When a Hexnode UEM instance is integrated with Q-scout, the platform retrieves the app inventory from managed devices and delivers app-level threat analysis. The solution continuously evaluates Android and iOS store applications for factors such as security vulnerabilities, privacy concerns, supply chain risks, and unusual behaviors. Because this process is automated and agentless, organizations can gain additional visibility into their mobile environment without impacting end users or introducing additional administrative overhead.

The findings in this report reflect what we hear directly from customers: the risk is not hypothetical, and it is not limited to apps developed by malicious actors. Legitimate apps with insecure coding practices, leaky SDKs, or improperly exposed components are already on managed devices across healthcare organizations. By combining Hexnodeโ€™s device management capabilities with Q-scoutโ€™s app-level insights, security teams can better understand the risk associated with applications in their environment and take appropriate action when necessary. For organizations operating under HIPAA requirements or adopting Zero Trust security approaches, having greater visibility into application risk alongside device management can support a more informed and proactive mobile security strategy.

The Secure Path Forward for Healthcare Mobile Apps

The findings from this analysis of 3,000+ healthcare-related mobile applications reveal an industry with meaningful and largely addressable security gaps. PHI leakage, Intent injection, and cryptographic plaintext exposure together affect roughly one in four apps, and the presence of remote command-and-control indicators in a subset of apps underscores that threats to this sector are not hypothetical.

Given the sensitivity of health data and the regulatory environment surrounding it, healthcare organizations and developers alike should treat mobile application security not as a checkbox exercise, but as a continuous operational discipline integrated into the software development lifecycle and third-party risk management programs.

Request a demo to see how Quokka delivers proactive discovery, analysis, and remediation of mobile app risks to healthcare organizations, including hospitals and medical centers, mHealth, medical device companies, and clinical research organizations.

FAQs

  • What did Quokka find in the 3,000+ app scan?
    • We found a mix of data exposure, Intent injection, unsafe deserialization, and SBOM-related third-party risk across the sample. The most common issue was PII potentially leaking outside the app at 9.81%, followed by externally controlled input used to set Intent fields at 7.69%. The SBOM analysis also found that 57.05% of apps had Critical or High severity component findings.
  • Why does the SBOM finding matter?
    • The SBOM result shows that mobile app risk is not limited to app code alone. Third-party libraries and embedded components are a large part of the problem, and that is why component-level visibility matters for healthcare procurement and ongoing monitoring.
  • How should healthcare organizations vet third-party apps used by employees or recommended to patients?
    • Healthcare organizations should require security assessment before approval, prioritize apps used in clinical workflows, and rescan apps at every major version update. Vendor due diligence should include evidence of security testing, not just a product description or trust statement. That gives security teams a clear basis for approval, restriction, or removal.

Related content