The Fix Signs New Files, Not Your Archive

The people who found this were reading the output

Nathan Adams is a systems engineer at Forensic Bioinformatics Services in Ohio, and his working life is spent reviewing DNA analyses used in criminal cases in the United States, the United Kingdom and Australia. Thermo Fisher's security bulletin credits him, together with Kevin Dyer and Laura Gaydosh Combs and the Cybersecurity and Infrastructure Security Agency, for identifying the issue and coordinating its disclosure. That list of names tells you how this was found. Nobody was scanning the internet for exposed instruments. Somebody who reads result files for a living looked hard at the file.

What they established is now recorded in Thermo Fisher's own bulletin, published on 31 July 2026. The company describes a risk of nearly undetectable modification of the .fsa and .hid file types generated by selected Applied Biosystems Human Identification software. The identifier is CVE-2026-17583, the severity is High, and the CVSS v4.0 score is 8.2. The bulletin is precise about where in the workflow the risk sits: the modification could occur before the file is loaded into analysis software, if laboratory controls are circumvented.

What the remedy actually concedes

The solution paragraph is worth reading at half speed. The security updates, Thermo Fisher writes, implement the use of digital signatures to add an extra layer of protection that, moving forward, will help customers verify that data files have not been modified. Moving forward is doing an enormous amount of work in that sentence, and it is not a hedge. It is an accurate description of what a signature can do.

A digital signature proves that a file has not changed since the moment it was signed. It cannot reach backwards. Files produced last week were produced by software that did not sign anything, so there is no signature to compare them against and no way for the update to give them one honestly. The patch closes the future. The archive stays exactly as it was, and its size is a function of how long the instrument has been running.

Five products get a patch, three get a sentence

The bulletin's table is short and worth reading in full. The 3500 and 3500xL Series Data Collection Software at version 4.0.2 and earlier moves to 4.0.3. The 3730 and 3730xL Series at 5.0.2 and earlier moves to 5.0.3. SeqStudio Genetic Analyzer Data Collection Software at 1.2.5 and earlier moves to 1.2.6. SeqStudio Flex Series Instrument Software at 1.2.0 and earlier moves to 1.2.1, and if you run the Flex with SAE enabled there is an order of operations: install the latest SAE profile on the SAE Admin Console first, then the instrument update. GeneMapper ID-X at 1.7.3 and earlier moves to 1.7.4.

Then three rows say something different. The 3130 Series Data Collection Software at 4.1 and earlier, ABI PRISM 3100 and 3100-Avant at 2.0 and earlier, and ABI PRISM 310 at 3.1 and earlier have reached end of life, are no longer supported, and no update will be provided. Those instruments still switch on. They still produce files that somebody downstream will rely on. The vendor has simply stopped writing code for them, which means the end-of-life date was a security decision about your evidence, and somebody else made it.

Your instruments write evidence too

Most European owners do not operate a genetic analyzer, and it would be easy to file this under other people's problems. That misreads what the finding is about. Plenty of ordinary businesses run something that writes a proprietary result file which later settles an argument: a coordinate measuring machine, a materials tester, a calibration rig, an emissions bench, an environmental logger, a batch record system. In an ISO/IEC 17025 accredited testing environment that unbroken record is not paperwork around the product. It is the product. Under NIS2 a large share of European manufacturers and testing entities are in scope, and the obligation attaches to the operator rather than to the instrument vendor.

Look again at the measures Thermo Fisher recommends for customers who cannot install the updates. Maintain a secure chain of custody for files throughout the analysis workflow. Store generated files on encrypted, password-protected media. Restrict access to authorized personnel. Apply least privilege on the systems operating the instrumentation and hosting the analysis software. Use firewall rules and network access control lists to restrict internet connectivity to trusted sources. Every one of those is sound advice, and every one of them is procedural. They constrain who can reach a file. Not one of them tells you whether the bytes inside it changed.

Three questions to put in writing this week

Start with the estate rather than the vulnerability. Which of our instruments sign their output at the moment of creation, and which merely write a file into a folder we have agreed to be careful with? For the ones that do not sign, what is the oldest file we would still rely on in a dispute, and what exactly would we be able to say about it if the other side asked how we know it is unaltered? And which of our instruments are already past vendor end of life, because that answer belongs in the replacement budget rather than in the risk register.

For anyone running the Applied Biosystems estate the immediate path is published and specific, and the release notes matter more than usual here. This is not a patch that closes a port or removes a remote code path. It changes how files are trusted from the day it lands, which makes the install date itself a meaningful boundary in your records. Note that date somewhere durable. In two years it will be the line that separates files you can demonstrate are intact from files you can only vouch for.

Read next: Siemens and Schneider Joined the Advisory on 22 July  |  141,006 Test Runs Held Three Real Breaches