The Key Ships With the Lock: CVE-2026-82876 — Phison S11 SSD Firmware Signature Bypass

The Phison PS3111-S11 is the controller inside tens of millions of budget SATA SSDs — the Kingston A400 alone passed 100 million units shipped. Its firmware-update path does everything right on paper: RSA-2048 signatures, SHA-256 hashes, a proper signature segment in every factory image. It just verifies those signatures against the public modulus embedded inside the firmware file being verified. Generate your own key pair, re-sign your backdoored firmware, embed your own modulus — the drive accepts it as genuine. A companion flaw (CVE-2026-84696) leaves the vendor command interface reading and writing raw flash with a CRC-based lock. No fix exists.

Overview

On August 31, 2026, NIST’s National Vulnerability Database published CVE-2026-82876, an improper-verification-of-cryptographic-signature vulnerability (CWE-347) in the firmware of the Phison PS3111-S11 — one of the most common SATA SSD controllers ever made. NVD scores it 8.2 High under CVSS 3.1; VulnCheck, which published its advisory the same day, scores it 9.3 Critical under CVSS 4.0. A day later came the companion advisory for CVE-2026-84696 (VulnCheck: September 1, NVD: September 2), covering the same controller’s wide-open vendor command interface. Both were credited to independent researcher Michael Herbert, whose “Drive Firmware Security” series is the primary source for everything in this article — and whose open-source tooling (psychite, disksec) makes every claim here reproducible.

The root cause of CVE-2026-82876 fits in one sentence: the RSA public modulus used to verify a firmware image is stored inside the firmware image. A signature scheme has meaning only if the verifying key is anchored somewhere the signed artifact cannot reach — mask ROM, eFuses, anything immutable. Phison put the key in the envelope with the letter. The consequence is that the S11’s firmware signature is not a security boundary at all: anyone who can already send an ATA command to the drive can install arbitrary controller firmware, properly signed, by the drive’s own logic, with keys they invented five minutes earlier.

That is not a subtle cryptographic attack. There is no padding oracle, no fault injection, no key recovery. The cryptography — RSA-2048 with SHA-256 — is implemented competently. It is simply pointed at the wrong anchor, which is the same as not being pointed at anything.

Worse, the research documents that the signature segment is optional (an unsigned image installs with no complaints), that the boot path never consults any signature — the mask-ROM bootloader validates firmware with a custom CRC-32-style checksum the attacker recomputes after tampering — and that the firmware header carries an interpreted init script facility that can write arbitrary memory before any code verification could occur. And for attackers who cannot be bothered with any of that, CVE-2026-84696 offers vendor ATA commands that read and write controller SRAM and raw NAND directly, guarded by a challenge-response “lock” built on a CRC-16-based stream cipher — or by nothing at all on builds that ship with no lock configured.

The result, in the researcher’s own conclusion: “Overall the security of the Phison S11 controller is poor, with no functional protections against malicious firmware modification or Vendor Unique Command (VUC) access.”

Vulnerability Classification

The companion flaw, CVE-2026-84696:

A note on the timeline: the CVEs are days old, but the research is not. Herbert’s S11 writeup carries a “last updated” date of June 8, 2026 — the full technical documentation, including the signature-segment layout and the working tooling, has been public for months. The advisories formalized what was already sitting in the open.

The Target: The Computer You Did Not Know You Owned

Every SSD is two products in one case: the NAND flash that stores your data, and a full computer that manages it. The S11 is that computer — a single-core Xtensa SoC (the instruction-set family you otherwise know from the ESP32), with 32 KB of mask ROM, 192 KB of instruction RAM, 33 MB of SRAM, and, notably, no MMU and no MPU: all code runs with read-write-execute access to the entire physical address space. There is no privilege separation to lose, because there is no privilege separation.

The firmware it runs is a real-time operating system — a 2014-era ThreadX, per the version string in the images:

Copyright (c) 1996-2014 Express Logic Inc. * ThreadX Xtensa Version
G5.6.5.8 SN: 3773-198-3201 *

Three threads share the single core: mainTask (ATA command handling), ftlTask (the flash translation layer), and flaTask (NAND operations). Everything a host writes, reads, TRIMs, or encrypts at the file-system level passes through this code.

Why does one controller matter? Because Phison’s business model is selling the whole platform. A drive brand can buy the S11 as an off-the-shelf reference design, add branding, a PCB, maybe some NAND and cosmetic firmware customizations — the controller silicon and core firmware stay the same. Herbert’s hardware table lists drives from Addlink, Gigabyte, Inland, KingMax, Kingston, Kioxia, Maxtor, MSI, Patriot, Pioneer, PNY, Seagate, Silicon Power, Team, and Toshiba/Kioxia. A sample:

One of those, the Kingston A400, passed 100 million units shipped — a figure Kingston itself announced. A capability developed against this one controller generalizes across dozens of product lines and millions of drives. From an attacker’s perspective, that is a superb return on investment.

Background: What Firmware Signing Is Supposed to Buy You

Drive-firmware implants are not a new idea. When the NSA’s ANT catalog leaked in 2013, it described IRATEMONK — a firmware implant for hard drives from major vendors, providing persistent surveillance below the operating system. The appeal is structural and has not changed since:

1. The drive sees everything. Every read, every write, every hibernation image, every LUKS/BitLocker ciphertext — all of it crosses controller firmware.
2. Persistence below the OS. Reinstalling the operating system, reformatting the partition table, even most “secure erase” flows do not touch controller firmware.
3. No host-side visibility. The host has no standard mechanism to read, let alone verify, what code the controller is executing.

The industry’s answer to that class of threat is a verified firmware chain: the vendor signs its firmware with a private key that never leaves the build farm, the device verifies signatures with a public key burned into immutable storage, and the device refuses to run code that does not verify — ideally at every boot, not just at update time. That last clause matters more than people think, as we will see.

The S11 has all the trappings of this design. Firmware files carry a 3,072-byte signature segment containing a 256-byte RSA signature over a SHA-256 hash, exactly the way a competent firmware-signing scheme looks. And then the implementation destroys the design in a single decision.

Technical Deep Dive

The Boot Chain, as the Mask ROM Sees It

On power-up, the Xtensa core starts executing at the reset vector 0x5C0D8000 — the 32 KB mask ROM bootloader (observed versions 2.0, 7.0, 9.0 and 9.2, with 2.0 by far the most common). The boot flow, reconstructed in the research:

power-on
   │
   ▼
mask ROM @ 0x5C0D8000            (immutable, per-controller-family)
   │  scan first page of every block (first CE of each flash channel)
   │  for OOB magic 0x31113111
   ▼
firmware header (4096 B) loaded to 0x5C0D4000
   │  header checksum: custom CRC-32, seed 0x31113111
   │  header magic: 'ID'
   ▼
load firmware sections to their addresses
   │  per-section checksum: custom CRC-32, seed 0x55AA55AA
   │  run header "init scripts" ──── arbitrary memory writes, pre-code
   ▼
copy IRAM sections into place at 0x5C0C8000
   │
   ▼
jump to entry point 0x5C0E0400 ── ThreadX RTOS starts

Read that flow again and look for the RSA. There isn’t any. The boot path validates firmware with a custom CRC-32-style checksum and nothing else. The firmware in flash carries no signature at all — signatures exist only in the distributable .BIN files, and are consulted only during the update procedure. Once firmware is installed, its provenance is permanently forgotten.

Two more details complete the picture. The firmware is stored as four redundant copies (two per flash channel) for reliability — all four equally unsigned. And the header’s init script facility — a small interpreted command sequence the bootloader executes while loading sections — includes opcodes that write arbitrary values to arbitrary memory addresses, before any firmware code is even in place. Even if Phison added a boot-time signature check tomorrow, the init scripts hand an attacker a code-execution primitive that runs before the check could happen.

The Firmware File and Its Signature Segment

Distributable S11 firmware (.BIN) files are dual-purpose: the same file can update a running drive through the standard ATA DOWNLOAD MICROCODE (0x92) command, or resurrect a blank/broken one via burner code loaded into memory in the bootloader’s safe mode. The layout:

┌───────────────────────────┐
│ 512-byte file header      │  signature flag 0x33 ⇒ signature segment present
├───────────────────────────┤
│ burner code               │  in-memory loader (manufacturing / repair)
├───────────────────────────┤
│ signature segment (3072B) │  ← if flag == 0x33 … entirely optional
├───────────────────────────┤
│ normal code               │  the firmware that gets installed to flash
└───────────────────────────┘

The signature segment is where the story lives. Its internal layout, with sizes exactly as documented:

Look at row three, then look at row two. The signature at +512 is verified using the modulus at +768 — of the same file. The verification anchor, the one quantity that must live outside the attacker’s reach, is shipped inside the attacker-controlled artifact. The signature is not a security boundary; it is a decorative self-attestation.

This is the anatomy of CVE-2026-82876, and everything else in the exploit follows mechanically:

1. Take a stock S11 firmware .BIN (any vendor build).
2. Modify the normal code — add your implant, alter the FTL, whatever you like.
3. Generate a fresh RSA-2048 key pair. Yours. Nobody else’s.
4. Compute SHA-256(opaque header ‖ modified normal code), sign it with your private key.
5. Write your signature at +512 and your modulus at +768.
6. Deliver the file to the drive with DOWNLOAD MICROCODE.

The drive recomputes the hash, performs the RSA verification with the modulus it just read from your file, and approves your firmware as authentic. The scheme is “working as designed” — the design just has the lock and the key in the same envelope.

Three Ways the Signature Fails You

What makes this worse than a single implementation slip is that the signature fails independently in three different ways:

The second failure deserves emphasis because it shows the signature was never load-bearing. The file header’s signature flag can simply say “no signature present,” and the update proceeds. A verification mechanism that can be declined is a suggestion, not a gate.

And the third failure closes the loop: even a perfectly forged update signature would be beside the point for an attacker who can write to the installed firmware in flash directly — which is exactly what the companion CVE provides.

The Companion: Vendor Unique Commands with a CRC-16 Lock (CVE-2026-84696)

The S11 has a second, older-style interface for what Phison’s own tools do: a Vendor Unique Command (VUC) system that smuggles vendor functionality into ordinary ATA commands with magic register values. The sequence is a two-step handshake: a STANDBY IMMEDIATE (0xE0) command with Count = 0x6F and LBA = 0xFAEFFE — Phison tools call this set AP key — arms a temporary VUC mode, and the next READ SECTOR(S) (0x21) or WRITE SECTOR(S) (0x31) is interpreted as a VUC, with the Feature register selecting the operation.

The operation list is a hardware hacker’s wish list. A selection:

Some firmware versions can optionally gate these behind a lock, with four documented states: Locked (only the read-only System Info command works), Engineering (unlock operations available — also the default state in protected mode / SATAFIRM, or when running burner firmware), Unlocked, and No lock (no key configured). A locked drive can be switched to Engineering mode by sending a DOWNLOAD MICROCODE command whose header carries byte 0x33 at offset +0x35 — the same “magic byte” family as the signature flag.

The unlock handshake itself is a challenge-response: read a challenge sector, “encrypt” it, send it back. The encryption is the S11’s house cipher — a stream cipher built on CRC-16 shift-register primitives, hardware-accelerated in the controller, keyed by a 32-bit seed corresponding to the drive’s configured unlock key. The drive even tells you, in its System Info response, which key it is configured to expect. This is not authentication in any cryptographic sense: it is an obfuscation handshake keyed from a factory key set, and — per the advisory — some builds ship with no VUC lock at all.

The NVD description of CVE-2026-84696 states the outcome plainly: attackers “can bypass the weak CRC-16 based unlock handshake or exploit builds with no VUC lock to read and write controller memory and raw flash, persisting implants across power cycles.”

Note the implication: with VUC access, an attacker does not need the firmware-update path, does not need to forge any signature, and does not need to touch the drive’s file-system-visible behavior. Write a modified firmware block to a spare flash region, or patch the installed copy directly — the boot path will validate it with a CRC-32 and run it happily, forever.

It is also worth noting what the research found at the hardware level: the controller’s UART and JTAG debug interfaces are typically left enabled at the eFuse level on production drives — they were found not usable in practice, but their presence underlines the design philosophy. The firmware was the security perimeter, and the firmware has no lock.

Exploitation Considerations

Threat Model — Being Honest About the Scores

Both CVSS vectors start AV:L/PR:H — local vector, high privileges required. That is accurate and worth dwelling on: to reach either flaw you must already be able to issue arbitrary ATA commands to the drive, which in practice means administrator/root on the host, physical access to the drive, or a position in the supply chain. Nobody is remotely hacking your SSD over the network.

So why does VulnCheck score both 9.3 Critical under CVSS 4.0? Because of what happens after compromise — the v4 vector’s SC:H/SI:H/SA:H: the compromise propagates to everything the drive touches. A controller implant is not “one more rootkit.” It is above the host’s security stack in a way nothing else on a normal system is:

• It persists below the OS. Reinstalling Windows, wiping to ZFS, reformatting — none of it rewrites controller firmware.
• It sees all data, encrypted or not — the drive handles the sectors underneath every disk-encryption layer.
• It can lie about everything. An implanted controller controls what every diagnostic reads back: firmware version strings, SMART data, the results of READ FLASH to its own code regions. There is no host-side attestation of S11 firmware to contradict it.
• It survives drive “formatting” and most secure-erase flows, which operate through the very firmware you would be trying to erase.

The realistic attackers, in rough order of likelihood:

1. Host-level malware escalating to permanent persistence. The moment malware has host admin rights — for any window of time — it can push a signed-by-anyone implant and clean up after itself. The persistence then survives every remediation short of drive replacement, including re-imaging from known-good media.
2. Supply-chain interdiction. Drives that pass through hostile hands between the factory and the rack (or the laptop bag) can be pre-implanted with firmware that verifies perfectly by the drive’s own logic.
3. Physical access. Minutes with a drive and a SATA cable — no case-opening, no chip clip, no JTAG rig required.

Detection is the bleakest part. There is no standard host mechanism to hash and verify S11 controller firmware; the strongest honest statement is that a Phison drive reporting the SATAFIRM identity string is in bootloader safe mode — evidence of firmware trouble, not proof of an implant. For a suspect drive in a high-value system, the dependable remediation is replacement (or destruction), not cleaning.

Why Not Just Backdoor One Drive?

Because the controller is shared across the industry’s entire budget-SATA lineup, and the core firmware is the same across vendors. An implant built for one S11 drive model works, with minor adaptation, across the family — Kingston, PNY, Toshiba, Seagate branding on the outside, the same ThreadX on Xtensa on the inside. This fleet-wide property is precisely what made IRATEMONK-style tooling valuable, and the S11 is the modern bargain-basement edition of that attack surface: at 100M+ units for a single drive model, this is among the widest-shared firmware trust flaws in current consumer hardware.

Affected Products

• All drives using the Phison PS3111-S11 controller with firmware ≤ SBFQT1.3 — the entire documented version history of the platform. No fixed version is listed in either advisory, and the researcher’s conclusion leaves no room for an optimistic reading of older releases.
• The drive’s brand is irrelevant: the controller and core firmware are Phison’s; vendors customize around them. Known S11-based models include the Kingston A400 and Q500, PNY CS900/CS2040/Elite, Toshiba/Kioxia TR200, Seagate BarraCuda Q1, Silicon Power A58/Bolt B75 Pro, Patriot Burst, MSI S270, Team GX1/L3 EVO, Maxtor Z1, Addlink S22, Pioneer APS-SL3, Gigabyte SSD, Inland Professional, and KingMax SMV — among others. If a budget SATA SSD shipped in the last several years, checking whether it is S11-based (the researcher’s hardware table and psychite’s drive-info tooling both do this) is cheap; assuming it is vulnerable unless proven otherwise is prudent for threat modeling.

Remediation

There is no patch, and there cannot be one in firmware: the flaw is where the verification anchor lives, and the S11 has no immutable anchor for a correct one. Any “fix” that keeps the modulus in updatable storage is the same bug with a new version number.

What defenders can actually do

1. Audit your fleet’s controllers. Run the researcher’s read-only assessment tool, disksec (see the PoC section) against drives you own — it reports VUC lock posture and command accessibility without modifying anything.
2. Treat S11 drives in high-value systems as un-fixable risk. If the threat model includes supply-chain interdiction or persistence-hardened adversaries, the only dependable answer is procurement: drives from vendors who document a verified boot chain, with firmware attestation, and a security posture that survives questions like “where is your verification key anchored?”
3. Assume persistence. After any host compromise on a machine with an S11 drive, re-imaging does not restore the endpoint to a trustworthy state. Plan for hardware replacement in incident response playbooks.
4. Buy through trusted channels. Interdiction beats zero-days on cost; shorten and monitor the logistics chain for sensitive deployments.

For silicon and firmware vendors — the checklist this platform failed

• Anchor the public key in immutable storage (mask ROM or eFuses). A verification key that ships in the artifact it verifies is not an anchor.
• Verify at every boot, not just at update. A signature that stops being checked after installation protects the installer, not the system.
• Make the signature mandatory. An optional verification is documentation, not enforcement.
• No pre-verification code execution. Init-script memory-write primitives before code verification (like the S11’s) are a universal bypass.
• Real authentication for vendor commands. A CRC-16-based cipher keyed from a factory key set — announced by key ID over the same interface — is obfuscation, not authentication.

Proof of Concept

https://github.com/Hunt-Benito/the-key-ships-with-the-lock-cve-2026-82876-phison-s11-ssd-firmware-signature-bypass

The PoC (forge_signature.py, pure Python 3 standard library, no hardware needed) demonstrates the bypass at the logic level with real cryptography: it builds a synthetic image mirroring the documented S11 layout, implements the drive’s verification exactly as the research describes it — including reading the RSA modulus from offset +768 of the image under verification — and then defeats it. Two honest caveats: the exact RSA padding scheme is not documented in the research, so the PoC uses standard PKCS#1 v1.5 (the anchoring flaw is padding-independent); and key material is random per run, so your modulus values will differ from the transcript below.

The script’s seven steps tell the whole story — genuine signature verifies; tampering without re-signing correctly fails (proving the math is fine); the signature turns out to be optional; and the forged image with the attacker’s own modulus sails through:

$ python3 forge_signature.py
========================================================================
CVE-2026-82876 — Phison S11 SSD firmware signature bypass (logic PoC)
========================================================================

[1] Generating the 'factory' RSA-2048 key pair (stands in for
    Phison's signing key, which never leaves their build farm)...
    vendor modulus N = ba68593684370cda...

[2] Building a stock firmware image with a genuine signature segment
    (512-byte header | burner | 3072-byte signature | normal code)...
    image: 4072 bytes, signature flag = 0x33

[3] Drive-side verification of the untampered image:
    [drive] RSA-2048 verify, N = image[+768] = ba68593684370cda... accepted
    result: PASS (as expected)

[4] Tamper with the normal code (implant) but keep the old signature:
    normal code modified at +100, signature segment untouched
    [drive] RSA-2048 verify, N = image[+768] = ba68593684370cda... REJECTED
    result: FAIL — the RSA math itself works fine

[5] Same tampered code, signature segment simply DELETED (flag 0x00):
    [drive] signature flag = 0x00 -> no signature present ... accepted
    result: PASS — the signature is optional (documented behavior)

[6] THE BYPASS — forge with our own key pair:
    6a. generating attacker RSA-2048 key pair...
        attacker modulus N = f656a1f9cbce98fc...
    6b. signing the IMPLANTED normal code with the attacker key...
    6c. drive-side verification of the forged image:
    [drive] RSA-2048 verify, N = image[+768] = f656a1f9cbce98fc... accepted
    result: PASS — tampered firmware accepted as genuine

[7] Post-install reality — what the boot path actually checks:
    stock code boot-checksum valid:      True
    implanted code boot-checksum valid:  True
    (the attacker recomputes the CRC-32 trailer; no RSA at boot —
     the signature segment is never read again after installation)

========================================================================
Conclusion: RSA-2048 + SHA-256, correctly implemented, defeated by
anchoring the public key inside the attacker-controlled artifact.
The lock came with its own key in the same envelope.
========================================================================

Step 4 is the one worth pausing on: the RSA implementation itself rejects a tampered image when the signature belongs to someone else’s key. The scheme is defeated only because the drive will happily consider the attacker’s key equally trustworthy — the modulus came from the same file, so the drive has no way to tell “Phison’s key” from “yours.” That is the entire vulnerability, and no amount of cryptographic quality fixes it.

Against Real Hardware (Your Own Drives Only)

To reproduce against an actual S11 drive you own, the researcher’s psychite implements the full read/modify/install pipeline:

$ git clone https://github.com/trulycrisp/psychite
$ cd psychite && python3 -m pip install -e .
$ example/drive_info.py /dev/sg0                    # identify drive & firmware
$ example/read_firmware.py /dev/sg0 firmware.bin    # dump installed firmware
$ example/firmware_tool.py unpack firmware.bin fw/  # unpack for modification
$ example/firmware_tool.py pack fw/ firmware.bin    # repack
$ example/update_firmware.py firmware.bin /dev/sg0  # install — will brick on error

And to audit the VUC lock posture of drives you manage — read-only, no writes — use disksec:

$ disksec list
$ disksec run /dev/sg0 -vv -o report.txt

Attention! Flashing modified firmware will likely destroy the drive if anything is wrong, may void warranties, and installing implants on hardware you do not own is a criminal offense in most jurisdictions. Everything in this section is for authorised research on your own devices.

The Bigger Picture: Trust That Ships With the Artifact

We keep meeting this bug in different costumes. Last month it was Cudy’s mesh routers authenticating their whole fleet with a JWT key shipped inside the public firmware image — trust anchored to material everyone can download. Before that, baseband silicon with trust assumptions that dissolved under a debugger. The S11 is the purest form yet: a cryptographically correct signature scheme whose anchor is inside the artifact being verified. RSA-2048 did its job. SHA-256 did its job. The one decision that mattered — where does the public key live? — was answered with “in the same file as the signature,” and that answer converts the whole apparatus into decoration.

There is a simple test for any secure-boot design, and it fits in one question: can the artifact under verification supply, influence, or replace any input to its own verification? If yes, you do not have a trust boundary — you have a ceremony. The S11 fails that test in three independent ways (embedded modulus, optional segment, no boot-time check), and then adds a vendor command interface behind a checksum-shaped lock for anyone who finds ceremonies too slow.

The uncomfortable ending: there is nothing exotic here. This is the budget controller in an enormous fraction of the consumer SATA drives sold for years, in servers, desktops, and laptops that their owners consider “wiped” the moment the OS is reinstalled. The lock was fine. The key just shipped in the same envelope — and with CVE-2026-82876, we finally have CVE numbers saying so out loud.

SOURCES

• NIST NVD — CVE-2026-82876: https://nvd.nist.gov/vuln/detail/CVE-2026-82876
• NIST NVD — CVE-2026-84696: https://nvd.nist.gov/vuln/detail/CVE-2026-84696
• VulnCheck Advisory — Phison PS3111-S11 Controller Firmware Signature Verification Bypass: https://www.vulncheck.com/advisories/phison-ps3111-s11-controller-firmware-signature-verification-bypass
• VulnCheck Advisory — Phison PS3111-S11 Controller Firmware Missing Authentication on Vendor Unique Commands: https://www.vulncheck.com/advisories/phison-ps3111-s11-controller-firmware-missing-authentication-on-vendor-unique-commands
• Michael Herbert — Drive Firmware Security: Phison S11 (primary research): https://trulycrisp.github.io/drivefirmware/phison_s11/
• Michael Herbert — Drive Firmware Security series: https://trulycrisp.github.io/drivefirmware/
• psychite — Phison S11/PS3111 firmware tools: https://github.com/trulycrisp/psychite
• disksec — storage drive firmware security assessment tool: https://github.com/trulycrisp/disksec
• MITRE CWE-347 — Improper Verification of Cryptographic Signature: https://cwe.mitre.org/data/definitions/347.html
• MITRE CWE-306 — Missing Authentication for Critical Function: https://cwe.mitre.org/data/definitions/306.html
• PC Gamer — Kingston announces 100 million A400 SSDs shipped: https://www.pcgamer.com/hardware/ssds/sata-drives-are-still-going-strong-as-kingston-announces-it-has-shipped-100-million-a400-ssds
• Phison — SSD solutions (S11 platform context): https://www.phison.com/en/solutions/ssd
• Hunt-Benito — The Same Key Opens Every Box (related fleet-wide trust failure): https://www.hunt-benito.com/blog/the-same-key-opens-every-box-cve-2026-71960-hard-coded-jwt-secret-in-cudy-wr3000-mesh-mqtt/
• Hunt-Benito — Samsung Exynos baseband stack overflow (related silicon trust surface): https://www.hunt-benito.com/blog/samsung-exynos-sms-stack-overflow-cve-2025-54328-critical-zero-click-baseband-rce/