The ZOLL ePCR iOS mobile application contains a WebView-based input‑sanitization flaw (tracked as CVE‑2025‑12699) that can be triggered by attacker‑controlled strings in patient care report (PCR) fields, allowing injected HTML/JavaScript to read local application files that may contain device telemetry and protected health information (PHI). This is a serious privacy and operational concern for emergency medical services that relied on the app, even though the vulnerability is not remotely exploitable and the vendor has since decommissioned the application.
Background
ZOLL’s ePCR family has been a component in many EMS documentation workflows, used to capture scene and patient data on mobile devices and to synchronize that data with back‑end systems. The recently disclosed vulnerability affects version 2.6.7 of the ZOLL ePCR iOS mobile application and is categorized as an
insertion of sensitive information into externally‑accessible file or directory issue, with a CVSS v3.1 base score of 5.5 in vendor reporting. The weakness results from reflecting unsanitized user input into a WebView rendering context; when the app renders or prints PCR fields such as run number, incident name, call sign or notes, those strings are interpreted as HTML/JS. In proof‑of‑concept testing, injected scripts were able to read local filesexposing device and user data contained inside the ePCR runtime.
CISA added this issue to its ICS medical advisories cycle and issued mitigations and general defensive guidance aimed at reducing exposure of control‑system devices and medical applications. The agency’s published vulnerability summaries and ICS advisory rollups have repeatedly emphasized segmentation, minimization of network exposure, and careful remote‑access controls for medical and ICS assets.
ZOLL has communicated that the ePCR iOS application was decommissioned in May 2025 and the company currently does not plan to provide a direct replacement; customers are directed to contact ZOLL Support for migration or transition guidance. This vendor‑level decommissioning materially changes the risk profile for operators who still have the application installed on devices.
What the vulnerability is and how it works
The technical root cause: reflected content in a WebView
At a high level, the vulnerability is a
reflected content issue inside a mobile WebView. The ePCR app takes text that originates from PCR fields—fields that are routinely filled by clinicians and dispatch systems—and inserts that text into aer neutralization. When HTML or JavaScript is embedded in those fields by an attacker or malicious data feed, the WebView interprets and executes it. Executing scripts inside the app’s runtime permits access to resources available in that context, including local files.
What an attacker needs to succeed
This is not a trivial, purely remote exploit. The vulnerability requires the attacker to be able to place crafted strings into PCR fields that the target device will later render. In practice, that means:
- Local access or proximity to a data entry channel (for example, typing malicious strings on a device used by an EMT), or
- An upstream data feed or synchronization channel that accepts external data into PCR fields (for example, imported incident data or a compromised integration), or
- Social engineering that convinces a user to paste or open a maliciously crafted field.
Because the proof‑of‑concept uses the WebView context to fetch localdel is
local‑context escalation of information disclosure rather than unauthenticated remote code execution across the network. The advisory explicitly notes that there were no reports of public in‑the‑wild exploitation at the time of publication.
What an attacker can access
The immediate risk demonstrated by the POC is
arbitrary local file reads from the app’s runtime context. Files stored by ePCR apps typically contain:
- Patient identifiers and incident metadata,
- Time stamps and device telemetry,
- Local cached copies of chart data and attachments,
- Potentially device‑specific identifiers and logs that tie data to a
Exfiltrating these files yields PHI and telemetry that are sensitive under healthcare privacy regimes; it also provides forensic artifacts an attacker could use to escalate follow‑on attacks or to reconstruct patient histories.
Why this matters: health, privacy and operational impact
PHI exposure and compliance risk
Protected Health Information is tightly regulated. Unauthorized reading or exfiltration of PHI triggers not only reputational harm but also regulatory obligations under frameworks such as HIPAA in the United States and equivalent privacy regimes worldwide. Even if the exploit is non‑remote, the existence of allows PHI to be read from app files can create breach reporting obligations if exploitation is confirmed. Healthcare organizations must therefore treat demonstrated local‑context vulnerabilities seriously.
Operational risk to EMS workflows
EMS agencies often rely on the continuity of their ePCR toolchain during emergency response. A decommissioned application that still exists on devices creates a dual problem: operators must quickly remediate vulnerable endpoints to avoid data exposure, but they also must ensure there is an operationally acceptable replacement to avoid interrupting patient documentation. The vendor’s decision to decommission the app reduces the likelihood of a vendor patch, forcing agencies to focus on mitigations and replacement strategies.
Forensic and supply‑chain implications
Because the vulnerability revolves around files produced and read by the app, any historical cache retained by the device could be accessed if an attacker obtains control of a device or persuades a clinician to open a crafted field. That raises data retention concerns and suggests that device‑level hygiene (full disk encryption, secure wipe, MDM controls) is as important as the application fix would have been. CISA advisories consistently recommend isolating control‑system devices and medical applications behind segmented networks and minimizing their exposure to the internet; those mitigations apply here as well.
Strengths of the disclosure and vendor response
- Responsible disclosure and public advisory: The vulnerability was reported, assigned a CVE, and the issue was made public through established advisory channels so operators could act. Public disclosure matters because it allows defenders to assess exposure and respond with network and device controls.
- Vendor decommissioning reduces forward risk surface: By decommissioning the application, ZOLL removed the prospect of future uncoordinated updates and signaled operators to transition away from the legacy client. For organizations unable to patch an app they control, decommissioning limits the window of active support complexity.
- Practical mitigations already recommended by authorities: CISA’s guidance on segmentation, limiting network exposure, and avoiding internet‑facing clinical systems provides clear, immediately actionable steps that reduce attacker opportunities.
Key weaknesses, unresolved risks and unanswered questitch for the vulnerable release:** Decommissioning is not the same as issuing a code fix. Operators still using the app must rely on mitigations instead of a vendor patch. That leaves environments where the app is embedded in workflows exposed until transitions complete.
- Data persisted on devices remains exposed: Even any local files—or backups—that were created while the app was active remain at risk if devices are not fully sanitized or encrypted. Attackers with device access or the ability to trick clinicians into rendering crafted fields could still extract PHI.
- Integration attack surface is unclear: Thhow attacker‑controlled strings placed into PCR fields trigger the vulnerability, but operators should investigate how those fields are populated in their environment—whether via manual entry, integrated dispatch feeds, or third‑party imports—and close upstream ingestion vectors. The degree to which external integrations were protected is not fully addressed in the vendor notice.
- Limited public detail about exploitability in the wild: At advisory publication there were no known reported public exploitations, but the absence of evidence is not proof of absence. Organizations should assume that any widely deployed vulnerability affecting PHI is attractive to attackers.
Immediate, practical guidance for IT, security and EMS managers
Below are prioritized actions for organizations that used or still host ZOLL ePCR iOS 2.6.7 on devices.
1. Inventory and assess
- Identify all devices that have ZOLL ePCR installed (including backups and shared tablets). Use Mobile Device Management (MDM) and endpoint management tools to enumerate installations and installed versions.
- Tag devices that remain in service with the vulnerable application and schedule them for remediation or removal.
- Map data flows to discover how PCR fields are populated—manual input, dispatch integrations, or external feeds—so you can determine likely attack paths.
2. Quarantine and isolate
- Immediately isolate devices still running vulnerable versions from networks that carry PHI or highly sensitive telemetry data. Place those devices on a dedicated management VLAN or offline workflows until they are cleaned or replaced.
- Enforce segmentation between clinical devices and enterprise systems; avoid cross‑pollination of trust. CISA guidance specifically recommends minimizing network exposure and placing control system devices behind firewalls.
3. Remove or replace the app
- Uninstall the decommissioned application from managed devices and require that users stop using unmanaged copies. If immediate uninstallation is operationally infeasible, restrict the app via MDM controls and remove permissions that permit file access.
- Plan a migration path to a supported ePCR client; coordinate with your billing and hospital interfaces to ensure continuity of care documentation. Contact ZOLL Support for vendor guidance and records of decommissioning procedures.
4. Secure sensitive files and backups
- Wipe any device‑level caches associated with the ePCR app and fully encrypt device storage; if devices cannot be scrubbed immediately, remove them from service.
- Purge old backups (device backups and cloud backups) that may contain cached reports, and ensure backup retention policies align with your risk posture and regulatory needs.
5. Harden ingestion and display vectors
- Sanitize upstream data: validate and neutralize any text that could be rendered as HTML/JS before it is stored in PCR fields or forwarded to devices.
- Enforce safe rendering practices: future ePCR clients and integrations should never render untrusted text into WebView contexts without strict CSP rules and HTML escaping.
6. Audit, detect and report
- Search logs and telemetry for suspicious writes or unusual PCR field contents that could flag attempted exploitation.
- Report incidents to your security incident response team and meet any breach notification obligations if you confirm PHI exposure. Follow the internal procedures recommended by national cybersecurity agencies.
Longer‑term recommendations: building resilient ePCR ecosystems
- Adopt secure coding and review for medical apps: Mobile medical applications that render user content must adopt secure templates, disable or sandbox WebView contexts, and implement input output neutralization to prevent reflected XSS and similar issues.
- Require vendor lifecycle commitments: Healthcare IT procurement should insist on documented patch and end‑of‑life policies; decommissioning without replacement can leave critical workflows in limbo. Vendors should guarantee a migration path or supported upgrade path with sufficient notice.
- Operationalize segmentation and least privilege: Place mobile clinical devices in restricted network contexts and avoid exposing them to general internet or broad enterprise resources. Use MDM to enforce app whitelisting and remove unapproved third‑party software.
- Continuous integration of security testing: Medical device and app ecosystems need continuous fuzzing, ing, and third‑party code reviews because patient safety depends on both safety and security.
What operators and clinicians should tell patients and staff
- Be transparent but measured: tell patients that a legacy app used for documentation contained a local file‑access vulnerability and that you are taking steps to secure any affected devices or data.
- Reassure patients that immediate risk is limited by the lack of remote exploitability, but also commit to timely remediation and breach notification if investigations find evidence of exposure.
- Train clinical staff to treat any unexpected or unusual text in PCR templates or incident fields as suspicious and to avoid copying data from untrusted sources into patient records.
Critical takeaways and final assessment
- The ZOLL ePCR iOS vulnerability (CVE‑2025‑12699) is an important example of how seemingly innocuous UI behavior—rendering PCR fields in a WebView—can elevate to a data‑exfiltration weakness when input is not neutralized. The proof‑of‑conce file reads that could expose PHI and telemetry.
- The vendor’s decision to decommission the application in May 2025 removes the option of a vendor patch and forces operators to rely on mitigations, uninstallations, or migration to supported platforms; this is operationally disruptive and increases short‑term security burden.
- Defenders should prioritize inventorying affected endpoints, isolating and sanitizing device caches, and hardening upstream data ingestion. These steps mirror long‑standing CISA recommendations for control‑system and clinical device security: minimize network exposure, segment networks, and use secure remote access where needed.
- Finally, this disclosure reinforces a durable lesson for healthcare IT: when software that handles PHI uses HTML rendering primitives, it must treat all rendered text as untrusted and adopt defense‑in‑depth controls—including escaping, content security policies, and runtime isolation—to prevent local context vulnerabilities from becoming regulatory and patient‑safety incidents.
If your organization used ZOLL ePCR iOS 2.6.7, prioritize the inventory and isolation steps in this article immediately, coordinate with ZOLL Support to record decommissioning and migration actions, and follow the CISA guidance on segmentation and mitigation for ICS and medical device ecosystems to reduce exposure.
Source: CISA
ZOLL ePCR IOS Mobile Application | CISA