STMicroelectronics STM32F1 flash read-out protection bypass exposes firmware

STMicroelectronics STM32F1 devices have Incorrect Access Control.

• The record marks st:stm32f1_firmware as affected but provides no version range, specific version or default-status qualifier.
• The technical source applies to the STMicroelectronics STM32F1 series and demonstrates impact on multiple variants in that series, but it does not define a complete list of affected devices.
• No fixed release, patch or branch boundary is confirmed in the supplied evidence.

STMicroelectronics STM32F1 has an access-control flaw in its flash read-out protection (RDP). RDP blocks flash data reads through the debug interface, but the CPU exception-handling process can still read flash through the ICode bus. An attacker with physical access to the debug interface can cause or activate exceptions so that the CPU loads values from the vector table into the program counter, exposing flash contents through the debug state. Relocating the vector table with VTOR allows the technique to reach multiple flash regions rather than only the default location. Public research demonstrated extraction of substantial portions of flash from multiple STM32F1 variants in practical time. The implementation details of a fix and the complete boundary for all STM32F1 variants remain unknown.

The concrete exploitation condition established by the technical source is physical access to the debug interface, such as SWD, rather than an application user account. The technical source describes a non-invasive attack and states that research source code was published; the supplied record also marks a public exploit as available. No application-level user interaction is described, and no application authentication requirement is stated. The record's scoring metadata describes a network attack path, but the technical article establishes only the physical debug-interface precondition; a network-only path is not demonstrated by that technical source. The supplied record does not establish exploitation in deployed environments.

The primary technical outcome is unauthorized reading of a substantial portion of RDP-protected flash through the debug interface and the CPU's vector-fetch behavior. The exact amount exposed depends on the STM32F1 variant and the available vector or interrupt entries. Disclosure can result in loss of firmware confidentiality, exposure of intellectual property or cryptographic material, and possible support for product cloning or analysis. Modification of firmware, integrity compromise or direct availability impact is not established by the record or technical source. The physical-access requirement limits exposure compared with a remote application vulnerability, but remains material for devices in the field or with exposed debug pads.

Flash disclosure can expose firmware, intellectual property, cryptographic material or credentials stored in the device. Those assets could support product cloning, reverse engineering or compromise of controls that depend on secrets stored in firmware, but the record does not confirm a specific breach.

• Practical exposure is concentrated in devices whose debug interface can be reached, making enclosure design, deployment location and maintenance procedures important control points.
• The documented impact is primarily information disclosure. The record and technical source do not establish direct firmware modification or service disruption.

1. Prevent physical access to the debug interface. The technical source identifies this as the known way to keep the entire flash content confidential when RDP cannot be trusted.
2. Do not use STM32F1 RDP as the sole confidentiality control for firmware or secrets. Address SWD pins, headers and test points in the hardware design, enclosure and maintenance process so unauthorized parties cannot reach them.
3. Review deployed devices that may be accessible during transport, servicing or recovery. Where physical control cannot be guaranteed, prioritize a design change or replacement protection mechanism.
4. No specific fixed release or patch is confirmed for this record. Do not assume that another STM32F1 release branch is safe without separate authoritative confirmation.

1. Inventory deployed devices and boards using STMicroelectronics STM32F1, together with firmware that relies on RDP to protect sensitive assets.
2. Inspect hardware designs and physical units for accessible debug-interface pins, headers, test points or connectors, especially SWD access.
3. Verify whether the deployed design relies on flash read-out protection to protect firmware, cryptographic keys or other sensitive data.
4. Classify the contents that could be exposed from flash, including intellectual property, firmware and cryptographic material. This is an impact assessment, not evidence that a device has been read.
5. In an authorized assessment, review debug-interface behavior and CPU state when exception handling reads vector-table entries. Do not treat the absence of application or network logs as proof of safety because the documented path uses a physical debug interface.
6. Record devices that cannot be directly inspected as having an unknown status. Enabling RDP in configuration records is not proof that all flash contents remain confidential.