CVE-2025-54808: MinKNOW Auth Bypass Vulnerability

CVE-2025-54808 Overview

Oxford Nanopore Technologies' MinKNOW software at or prior to version 24.11 stores authentication tokens in the world-readable /tmp directory on the host machine. Any local user or process can read these tokens and reuse them to authenticate against the sequencer. When remote access is enabled, an attacker who obtains a leaked token can establish unauthorized remote connections to the device. The flaw maps to CWE-522: Insufficiently Protected Credentials and was catalogued in the CISA ICS Medical Advisory ICSMA-25-294-01.

Critical Impact
An attacker who steals a MinKNOW authentication token can chain it with remote access to generate developer tokens with arbitrary expiration dates, providing persistent access to the sequencer while bypassing standard authentication.

Affected Products

Oxford Nanopore Technologies MinKNOW software version 24.11
Oxford Nanopore Technologies MinKNOW software versions prior to 24.11
Nanopore sequencer host systems running vulnerable MinKNOW releases

Discovery Timeline

2025-10-23 - CVE-2025-54808 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-54808

Vulnerability Analysis

MinKNOW writes authentication tokens to a file inside the operating system temporary directory (/tmp). On typical Linux hosts, /tmp is world-readable, so any local account or process running on the sequencer host can read the token file. The tokens are the same credentials MinKNOW itself uses to authorize API operations against the sequencer control plane.

The issue becomes remotely exploitable when the MinKNOW remote access feature is enabled. Remote access may be turned on intentionally by an operator or silently by malware with sudo privileges. Once remote access is active and a token is exfiltrated, the attacker can authenticate to the sequencer from outside the host without additional credentials.

The most consequential secondary effect is developer token issuance. A valid session token can be used to mint developer tokens with attacker-defined expiration dates, giving long-lived, out-of-band access that bypasses normal authentication flows and survives password or session resets.

Root Cause

The root cause is insecure credential storage. Sensitive authentication material is placed in a shared, world-readable directory instead of a per-user location with restrictive file mode bits (for example, 0600 under the service account's home directory) or an operating system keystore. No access control is enforced on the token file at rest.

Attack Vector

Exploitation requires local access to the MinKNOW host to read the token file, plus remote access enabled on the sequencer to abuse the token from a remote system. Malware, low-privileged local users, or shared multi-tenant workflows on the sequencer host all satisfy the local read requirement. The vulnerability described in the CISA advisory does not require exploitation of a memory corruption bug or a network-facing zero day; it relies on filesystem permissions and normal MinKNOW API calls.

The vulnerability manifests through predictable file placement in /tmp combined with default OS permissions. See the CISA ICS Medical Advisory ICSMA-25-294-01 and the associated CSAF advisory JSON for the authoritative technical description.

Detection Methods for CVE-2025-54808

Indicators of Compromise

Presence of MinKNOW authentication token files under /tmp with world-readable permissions on the sequencer host.
Non-MinKNOW processes (shells, scripting interpreters, unknown binaries) reading files inside /tmp that belong to the MinKNOW service account.
Unexpected developer tokens issued by MinKNOW with unusually long or arbitrary expiration dates.
Successful remote MinKNOW API sessions originating from IP addresses not associated with authorized operator workstations.

Detection Strategies

Monitor file access telemetry on the sequencer host for read operations against MinKNOW token files in /tmp by any process other than the MinKNOW service itself.
Audit MinKNOW configuration for the remote access setting and alert on state changes, especially those made by processes with elevated privileges.
Review MinKNOW server logs for developer token creation events and correlate against a known-good baseline of administrative activity.

Monitoring Recommendations

Enable and forward host and application logs from every MinKNOW sequencer to a centralized log store for retention and query.
Baseline the expected set of remote clients and alert on new source addresses connecting to MinKNOW APIs.
Track privilege escalations (sudo, su, capability changes) on the sequencer host, since malware needs elevated rights to enable remote access silently.

How to Mitigate CVE-2025-54808

Immediate Actions Required

Upgrade MinKNOW to a release later than 24.11 once Oxford Nanopore Technologies publishes a fixed version; consult Oxford Nanopore Technologies or ONT contact channels for release details.
Disable the MinKNOW remote access feature on any sequencer where remote control is not operationally required.
Rotate any existing developer tokens and audit their expiration dates, revoking tokens that cannot be attributed to a legitimate administrator.
Restrict interactive and remote logon rights on sequencer hosts to the minimum set of trusted operators.

Patch Information

Oxford Nanopore Technologies has not published a fixed version identifier in the referenced advisory content. Refer to the CISA ICS Medical Advisory ICSMA-25-294-01 and the Oxford Nanopore software page for current update guidance and to confirm whether a patched MinKNOW build is available for your instrument.

Workarounds

Keep MinKNOW remote access disabled and operate the sequencer only through the local console until a patched release is deployed.
Segment sequencer hosts on an isolated management network that blocks inbound access from user endpoints and the internet.
Harden /tmp where feasible (for example, per-user /tmp namespaces, noexec mounts, or restrictive umask for the MinKNOW service account) to reduce exposure of transient credential files.
Restrict the local user population on sequencer hosts and remove unnecessary shell accounts and third-party agents.

bash

# Configuration example: restrict access to MinKNOW token files and audit reads
# 1. Locate MinKNOW-created files under /tmp owned by the MinKNOW service account
sudo find /tmp -user minknow -type f -exec ls -l {} \;

# 2. Tighten permissions so only the service account can read the token
sudo chmod 600 /tmp/<minknow_token_file>
sudo chown minknow:minknow /tmp/<minknow_token_file>

# 3. Add an auditd rule to log any read of the token file
sudo auditctl -w /tmp/<minknow_token_file> -p r -k minknow_token_access

# 4. Verify remote access is disabled in the MinKNOW configuration
#    (refer to Oxford Nanopore documentation for the exact config key)