Oxford Nanopore’s MinKNOW platform has been placed squarely under the security microscope after coordinated disclosures identified multiple high‑risk vulnerabilities that can be triggered over local networks, expose long‑lived authentication tokens, and even produce denial‑of‑service conditions that stop sequencing runs. Security researchers reported missing authentication and unsafe token handling in MinKNOW releases prior to 24.06 and 24.11, CISA republished guidance to operators, and Oxford Nanopore has since shipped later MinKNOW releases containing targeted security fixes and changes to developer APIs.
MinKNOW is the control and data‑acquisition application used to run Oxford Nanopore sequencing devices (MinION, GridION, PromethION, P2i, etc.. It handles device configuration, run control, live basecalling orchestration, and the storage/forwarding of raw signals and basecalled reads. Because MinKNOW often runs on workstation or server OSes that are shared with other lab tools, its security posture directly affects patient‑sensitive research, clinical pipelines, and public‑health sequencing deployments.
The recently disclosed issues fall into three related classes:
This attack does not necessarily grant access to the sequencer, but it reliably causes operational outage — a meaningful safety and availability concern in labs performing time‑sensitive sequencing.
The broader lesson for lab administrators and Windows teams is unchanged: operational convenience must be balanced against the integrity and availability of critical scientific workflows. Sequencers are now networked instruments that sit between the physical and digital domains — and their software deserves the same rigorous security posture applied to any enterprise‑grade system.
Source: CISA Oxford Nanopore Technologies MinKNOW | CISA
Background / Overview
MinKNOW is the control and data‑acquisition application used to run Oxford Nanopore sequencing devices (MinION, GridION, PromethION, P2i, etc.. It handles device configuration, run control, live basecalling orchestration, and the storage/forwarding of raw signals and basecalled reads. Because MinKNOW often runs on workstation or server OSes that are shared with other lab tools, its security posture directly affects patient‑sensitive research, clinical pipelines, and public‑health sequencing deployments.The recently disclosed issues fall into three related classes:
- Missing authentication / weak network gating that exposes control APIs to reachable hosts.
- Insufficient protection of authentication tokens, including temporary files written to universally readable locations.
- Race / file‑lock conditions that cause token generation to fail and lock MinKNOW out of device control, producing DoS.
What the disclosures say (executive summary)
- Vulnerability classes: Missing Authentication for Critical Function, Insufficiently Protected Credentials, and Improper Check for Unusual or Exceptional Conditions.
- Practical results of successful attacks: an unauthenticated or network‑adjacent attacker can discover MinKNOW endpoints, obtain or reuse tokens, observe sequencing, pause/stop runs, redirect output, and — in some chains — create developer tokens that persist indefinitely.
- Assigned identifiers: the set of findings were assigned CVEs and scored in the high range under CVSS. Vendor guidance recommends upgrading to MinKNOW versions later than 24.11 and applying network‑level compensations if patching cannot be completed immediately.
Technical deep dive
Missing or weak authentication on exposed APIs
MinKNOW historically allowed remote control interfaces to be enabled, and in some configurations, enabled remote access by default or tied authentication decisions too closely to the origin IP address or the existence of a registered account. An attacker on the same network can enumerate device IPs (for example, with simple network scans), register a Nanopore account (including temporary accounts), and connect to MinKNOW if remote access is enabled. Once connected, an adversary can:- Observe live sequencing metrics and progress.
- Pause or stop sequencing runs, causing data loss or wasted reagents.
- Redirect output or change destination storage for raw and processed reads.
- Potentially alter protocol parameters or start new runs with malicious input.
Token handling: temporary file exposure and /tmp storage
A critical cause of persistent remote takeover in the reports is insecure handling of MinKNOW authentication tokens. MinKNOW up to certain versions wrote authentication tokens to the host system’s temporary directory (commonly /tmp on Linux), which is commonly world‑readable on many distributions. This opens multiple attack vectors:- Any local process or user (including malware and containerized apps running without strict isolation) can read the token file and then use it to establish a remote session to the sequencer.
- If remote access is enabled or can be toggled by local processes, a stolen token becomes a remote access key with immediate impact.
- Token leakage becomes a persistent threat when developer tokens can be minted with arbitrary expiration dates, creating durable backdoors if an attacker chains local token theft with remote token creation.
File‑lock race causing DoS
During startup, MinKNOW reportedly creates temporary files in world‑accessible directories while generating local authentication tokens. An unprivileged local user or process can use flock or similar file‑locking APIs to hold locks on those temporary files, preventing the main process from completing token generation. The end result is a denial‑of‑service (DoS) for sequencing operations: no valid token is created, and the software refuses to control the sequencer.This attack does not necessarily grant access to the sequencer, but it reliably causes operational outage — a meaningful safety and availability concern in labs performing time‑sensitive sequencing.
Realistic attack scenarios and threat models
- Opportunistic local network attacker (adjacent‑network compromise)
- Attacker performs network discovery, finds MinKNOW host, and attempts to register/attach through exposed remote connect. If remote access is enabled and the MinKNOW instance uses IP‑based or weak authentication, the attacker can take control of runs.
- Malware or lateral movement on a compromised host
- A standard Windows or Linux workstation used to launch MinKNOW becomes infected. Local malware reads /tmp token files or places locks on temp files; it can then either exfiltrate tokens or cause run failures. Because typical sequencing workstations can also run Windows-based data analysis and lab management tools, this vector is highly plausible in mixed‑OS labs.
- Persistent access via developer token creation
- An attacker with local access exploits token generation behaviors to create developer tokens with long or no expiration, enabling remote, persistent control that bypasses operator authentication.
- Supply‑chain or insider abuse
- A contractor or rouge employee with network access and knowledge of lab workflows could exploit exposed APIs for sabotage or industrial espionage.
Who should worry most
- Clinical sequencing labs and public‑health teams running near‑real‑time sequencing for surveillance or diagnostics.
- Biomanufacturing and regulated facilities where sequencing informs product release or contamination testing.
- Research groups that share sequencing workstations or run MinKNOW on general‑purpose Windows/Linux hosts accessible by multiple users.
- IT/OT teams responsible for lab device fleets and remote vendor access programs.
What Oxford Nanopore and the community have done
Oxford Nanopore’s release notes for recent MinKNOW builds (25.x releases) document security‑oriented changes, notably the disabling of Developer API tokens in at least one 25.05.x release and other improvements to token handling and run recovery. These vendor changes materially reduce the attack surface discussed in the disclosures. Community projects and repositories associated with the MinKNOW ecosystem (for example, Dorado basecaller releases) also track versioning and compatibility changes that often coincide with MinKNOW updates; these repositories provide an independent confirmation path for when key dependencies and behaviors changed. CISA and other national‑level advisories have republished guidance and recommended mitigations for MinKNOW operators — specifically, upgrade where possible, disable remote access unless required, isolate devices behind firewalls, and apply endpoint protection. These are standard but essential compensations for environments that cannot patch immediately.Cross‑validation and verification notes
- Oxford Nanopore release notes explicitly show security fixes in the 25.x series (for example, disabling developer tokens). This is a primary vendor confirmation that MinKNOW behavior around developer tokens has been changed in later releases.
- The CISA‑style advisory text reproduced in coordinated disclosure summaries confirms the attacks’ mechanics (token files in /tmp, token‑generation race, missing authentication for remote control). Public republishing of these advisory summaries in community advisories and incident threads aligns with the vendor’s release messaging and researcher reports.
Practical mitigation checklist (prioritized, Windows‑focused)
- Immediate (0–24 hours)
- Disable MinKNOW “Remote Connect” or any remote control interface unless absolutely required for operation. If remote access is required, restrict access to a tightly controlled maintenance VLAN or trusted jump host.
- If you manage sequencing workstations via Windows systems, immediately review local permissions: ensure user accounts that do not need to run MinKNOW cannot read temporary directories used by the MinKNOW process.
- Near term (1–7 days)
- Upgrade MinKNOW to the latest vendor‑recommended release for your device family. Oxford Nanopore’s own release pages list security changes and are the canonical place for safe downloads; ensure you obtain releases via the Nanopore Community channel and validate hashes where provided.
- Harden the host OS where MinKNOW runs:
- On Linux: ensure /tmp and other temporary paths use secure mount options (noexec, nodev where viable) and limit world‑readable files; consider a dedicated tmpfs with stricter permissions for MinKNOW runtime.
- On Windows: restrict access to the MinKNOW working directories and run MinKNOW under a dedicated service account with least privilege.
- Install and maintain endpoint protection (EDR/antivirus) on MinKNOW hosts to reduce risk of local token‑theft malware.
- Operational / network controls (1–30 days)
- Place sequencer hosts and MinKNOW workstations on a segmented VLAN with a deny‑by‑default firewall policy that only permits required management flows (and only from known jump hosts or VPN endpoints).
- Require MFA and recorded, just‑in‑time vendor remote access processes for any third‑party maintenance that requires connectivity to MinKNOW.
- Restrict the ability to enable remote access to physical console or to privileged admin accounts only; log and alert on any remote‑access configuration changes.
- Detection and monitoring (ongoing)
- Monitor host file activity for reads of MinKNOW token files or unusual file‑locking behavior targeting MinKNOW temp paths.
- Alert on unexpected MinKNOW administrative actions (run pause/stop/start) outside scheduled maintenance windows.
- Correlate EDR telemetry and network logs for suspicious outbound connections from MinKNOW hosts to unknown endpoints.
- If you cannot patch immediately
- Contact Oxford Nanopore Support for tailored guidance and follow their interim hardening steps.
- Treat any device reachable from the internet as high risk; remove internet routing or NAT rules immediately and rely on vendor‑mediated downloads/patch servers only from inside trusted networks.
Operational and supply‑chain risks — a critical analysis
Strengths- The vulnerability cluster is well‑scoped and fixable: vendor release notes indicate the vendor can and did change token handling and developer API policies.
- The research and disclosure process produced CVE assignments and advisory text that allow operators to implement prioritized mitigations.
- Default/networked exposure: Many labs enable remote access for convenience (remote monitoring of long runs, vendor support). When operational convenience conflicts with security, risk increases dramatically.
- Token persistence and local file exposure: The practice of writing sensitive tokens to world‑readable temp directories is a systemic security smell. It assumes trusted local environments and is brittle in modern, mixed‑use lab hosts where containerized apps, third‑party analysis tools, and other users may coexist.
- Patch cadence and operational constraints: Labs often run production experiments and cannot always patch immediately. The need to validate sequencing behavior across pipeline stages can delay uptake of security releases — leaving a window of exposure.
- Detection gaps: Because these are largely operational/availability and token‑management problems (rather than high‑visibility RCEs), active exploitation may be silent and slow to detect. Operators must assume compromise may be subtle.
- Some public CVE records or central vulnerability trackers may not reflect every vendor build or fix mapping at the time of reading. Confirm the exact MinKNOW build that contains the fixes for your device model before you change production images. If authoritative CVE/NVD entries remain sparse, treat vendor release notes as the most reliable indicator.
Recommendations for WindowsForum readers and administrators
- Treat MinKNOW workstations as high‑value endpoints: these machines run experimental pipelines, hold sensitive data, and often have access to lab instruments. Apply Windows hardening best practices: least privilege, application control (WDAC/AppLocker where practical), Credential Guard where supported, and centralized EDR monitoring.
- Build a dedicated sequencing management VLAN and enforce strict ACLs; never expose MinKNOW or device control ports to the Internet.
- Add sequencing orchestration hosts to patch rings and maintenance schedules; treat MinKNOW releases as high‑priority vendor updates and test them in isolated staging lanes before moving to production.
- Document vendor remote access processes: require recorded sessions, vendor just‑in‑time access, and per‑session logging.
Final assessment
The MinKNOW vulnerabilities represent a pragmatic but serious risk to sequencing operations: they combine network‑accessible control paths with insecure local token handling and a race‑condition DoS that can disrupt operations or enable persistent attacker access. The situation is remediable — Oxford Nanopore’s later MinKNOW releases show deliberate security changes — but operators must act quickly to reduce exposure through a combination of vendor updates, host hardening, and network segmentation. Immediate actions are straightforward and effective: disable remote access unless needed, upgrade to vendor‑recommended MinKNOW releases when feasible, restrict token file access on hosts, and enforce strict network boundaries around sequencing equipment. For teams unable to update immediately, the combination of endpoint protection, ACLs, and operational process changes (for example, vendor session controls) will materially reduce risk while a full patch plan is executed.The broader lesson for lab administrators and Windows teams is unchanged: operational convenience must be balanced against the integrity and availability of critical scientific workflows. Sequencers are now networked instruments that sit between the physical and digital domains — and their software deserves the same rigorous security posture applied to any enterprise‑grade system.
Source: CISA Oxford Nanopore Technologies MinKNOW | CISA
