A forensic systems engineer sat down with a public data set and a mainstream AI coding assistant. Forty-five minutes later, he had taken the digital DNA scans of two different people, merged them into a single file, and stamped it so it appeared to have sat untouched since 2015. He then opened that file in the analysis software used by crime laboratories around the world.
It raised no warning. Not a flag, not a prompt, not a note in a log. The file looked exactly like every other file the machine had ever produced.
The vendor, Thermo Fisher Scientific, published a security bulletin on 31 July confirming the underlying issue in select Applied Biosystems human identification software, rating it High, and shipping updates for five product lines that add digital signatures to the files. Researchers who found it — working with the U.S. Cybersecurity and Infrastructure Security Agency on coordinated disclosure — told reporters they believe the weakness has existed in files produced by crime-lab equipment since 1995, and that they could not find a way to tell whether any past file had been altered.
Before anyone panics: there is no public evidence that this was ever used against a real case, and the researchers say an attacker would need access to a laboratory’s servers plus genuine expertise in how DNA testing works. This is not a story about convictions being overturned tomorrow. It is a story about something much more ordinary, and much more widely applicable — a file that everybody trusted, that nothing was checking. Your business is full of those.
What was found, at a glance
| The affected files | The raw data files produced by widely used genetic analysis instruments — the digital output that laboratories later load into analysis software to build a DNA profile |
| The weakness | Those files could be modified before the analysis software loaded them, with changes the vendor describes as nearly undetectable, if laboratory controls were circumvented |
| Severity | Rated High by the vendor, with a score of 8.2 out of 10 |
| The demonstration | A researcher at a forensic consulting firm merged scans from two individuals’ DNA profiles into one file that appeared untouched since 2015; the analysis software opened it without complaint. His first successful modification took about 45 minutes with AI assistance |
| The historical scope | Researchers believe affected files have been produced since 1995 and say they found no way to detect earlier tampering. The vendor’s bulletin does not confirm that historical scope |
| The fix | Updates for five product lines add digital signatures to the files, which the analysis software then verifies on opening |
| The gap in the fix | Three end-of-life products will receive no update at all. For those, the vendor recommends controls around file custody, access, and network access instead |
| Real-world abuse | No public primary source ties any altered casework to this issue. It affects the digital records, not the physical DNA samples themselves |
Nothing was checking the file
Strip the science out and the flaw is almost embarrassingly simple. An instrument measures a sample and writes a file. Later, different software opens that file and produces the analysis that becomes a report. Between those two moments, nothing verified that the file was still the file the instrument wrote. There was no seal to break, so there was no broken seal to notice.
The researchers made this point with an image worth stealing: the physical world already solved this problem. Evidence gets sealed in a bag with tamper-evident tape, signed across the seam, logged at every handoff. Anyone can tell at a glance whether the bag has been opened. The digital file carrying the same evidence had less tamper-evidence than the paper bag it was collected in.
The lesson in one line: a file that looks fine is not evidence that the file is fine. “It opened normally” and “it hasn’t been changed” are two completely different claims — and almost every business treats the first as proof of the second, every single day.
The 45 minutes are the real headline
Here is the part we would circle in red. This weakness reportedly sat in these files for three decades. It is not new. What changed is that an expert — who is not a professional exploit developer — went from idea to working file modification in forty-five minutes, using an ordinary AI coding assistant to bridge the gaps in his own toolkit.
That is the same lesson we drew from the rogue AI agent story a few days ago, arriving from the opposite direction. There, an AI stumbled into real credentials that people had left exposed. Here, a human used AI to collapse the effort required to act on a weakness that had gone unexploited for thirty years. Same underlying shift, stated plainly:
Things that were theoretically possible but practically too much trouble are becoming quick. Every business has a pile of risks it has been implicitly protected from by nothing more than the effort required to exploit them. That protection is evaporating, quietly, across the board. Not because attackers got smarter — because the work got cheaper.
The fix is honest, and it has limits worth naming
Credit where it is due: the vendor worked with the federal cybersecurity agency, credited the researchers, and shipped a real fix rather than a reassurance. The instruments now sign the files they produce, and the analysis software checks that signature when opening them. That is exactly the right answer — it puts the tamper-evident tape on the digital bag.
But read the fine print, because it contains three lessons that apply directly to your business:
- The protection works “moving forward.” Signatures verify files created from now on. The bulletin does not explain whether files generated before the update can be validated retroactively, and the researchers say they found no way to detect prior tampering. You can start a chain of custody today; you cannot retroactively create one for yesterday.
- Three end-of-life products get nothing. Not a delayed fix — no fix, ever. Labs running those are told to compensate with physical and network controls instead. When a vendor stops supporting equipment, the risk does not retire with the product; it simply transfers to you.
- The paperwork lagged the fix. Days after publication, the vulnerability identifier still had no entry in the public vulnerability databases, and the notice was not listed in the vendor’s own public bulletin index. That is not scandalous — these things catch up — but it is a useful reminder that “we would have heard about it” is a weak security strategy. Plenty of fixes ship quietly.
Being careful with the facts: the vendor’s bulletin does not confirm the 1995 historical scope — that comes from the researchers. There is no public evidence of any real case being altered. And exploitation reportedly requires access to a laboratory’s systems plus real domain expertise, which is a meaningful barrier. We are not telling you DNA evidence is broken. We are telling you what the researchers demonstrated, what the vendor fixed, and what it means for the files your own business relies on.
Your business runs on files nobody verifies either
Now bring it home. A crime lab has a chain of custody, accreditation, audits, and procedures — and it still had a thirty-year gap where nothing checked the file. Ask yourself honestly what checks the files your business makes decisions and money on:
| The file you trust | What would happen if it were quietly altered |
|---|---|
| The invoice or quote you emailed a customer | A changed bank detail or total, and a dispute where both sides hold a “genuine” document |
| The signed contract or agreement PDF in your files | A term nobody agreed to, discovered at exactly the worst moment |
| Financial exports, payroll files, timesheets | Numbers that flow into accounts and tax filings with no independent check that they match the source |
| Inspection photos, job-site documentation, appraisals | Evidence in a claim or dispute that cannot prove it is what it says it is |
| Your backups themselves | The one copy you would rely on to prove what was true — which is why backups an attacker can reach are barely backups at all |
For most small businesses the honest answer to all five rows is: nothing checks them. A file sits in a folder or an inbox, it opens when double-clicked, and that is the entire verification process. Which is fine right up until the moment it matters — a dispute, an audit, an insurance claim, a legal demand — and someone asks the question this whole story turns on: how do you know this is the original?
What to actually do about it
- Give your records a real chain of custody. Systems with version history and audit logs — who opened it, who changed it, when — turn “I think that’s the original” into something you can demonstrate. Most businesses already pay for tools that do this and simply have not turned the feature on.
- Protect the copy that proves things. Backups that live where a person or an attacker can alter them are convenience, not proof. Snapshots that cannot be quietly rewritten are what let you say with confidence what a file looked like on a specific day — one reason we run private cloud backup with up to hourly snapshots for the businesses we manage.
- Verify the important things out of band. The digital equivalent of the tamper-evident bag, for a small business, is a phone call: confirm changed bank details, unusual payment instructions, and altered contract terms by voice, on a number you already had. This is the same rule that beats supplier and invoice fraud, and it works here for the same reason.
- Know what runs on unsupported gear. Somewhere in most small businesses is a machine, a program, or a piece of equipment past its support life — still working, still important, and permanently frozen at its last known set of flaws. That is exactly the position of the three lab products getting no fix. Working is not the same as supported.
- Make updates somebody’s actual job. This fix only helps laboratories that install it. Every fix is like that. In a business without an IT department, “make sure every machine and program is current” is a job that belongs to no one — which is precisely why outdated software keeps showing up at the center of these stories.
The uncomfortable question
The reason this story is worth your attention is not that DNA evidence is suddenly unreliable — it is not, and the responsible reporting has been careful about that. It is that one of the most rigorously controlled data environments humans have ever built turned out to have a thirty-year gap where a file could be changed and nothing would notice. Not through negligence, but because at the time it was designed, nobody thought to ask the question.
So ask it about your own business, where the controls are considerably lighter: which of your files would you be able to prove had not been altered? Our managed IT service exists to answer questions like that one properly — an inventory of every machine and program, updates applied everywhere, unsupported equipment identified before it becomes a liability, and records protected and backed up so that when someone asks you to prove what was true, you can. The laboratories in this story got thirty years of quiet luck and one very good researcher. That is not a security plan. Knowing what you have, and keeping it current and provable, is.
Sources: Thermo Fisher Scientific security bulletin, 31 July 2026 (tracked as CVE-2026-17583, CVSS v4.0 8.2); The Wall Street Journal; The Hacker News; TechRadar Pro; researcher disclosures coordinated with CISA. Historical-scope and detection claims are as reported by the researchers and are not confirmed in the vendor bulletin.
