CVE-2023-50096 is a high severity (CVSS 7.5) buffer overflow in the STMicroelectronics STSAFE-A1xx middleware before version 3.3.7. It can allow code execution on the host microcontroller if an attacker can read from and write to the I2C bus. Update to middleware 3.3.7 or later and rebuild any firmware derived from the samples.
What's affected
- STSAFE-A1xx middleware before 3.3.7, per the NVD description.
- The flaw sits in the X-CUBE-SAFEA1 Software Package for STSAFE-A, sample applications version 1.2.0. The write-up referenced by the record says the vulnerable middleware is 3.3.6 and below.
- User written code that was copied or derived from a published sample application can carry the same bug, even if you never installed the package.
- The attack vector is adjacent and the complexity is high (AV:A/AC:H), reflecting the need for physical or board level access to the bus.
- KEV status: the record shows kev as false.
How to check if you're exposed
This is firmware, so there is no package manager query. Search your source tree, including vendored and copied sample code, for the vulnerable function named in the write-up.
grep -rn "StSafeA_ReceiveBytes" .
If the function appears, find the middleware version it came from and compare with 3.3.7. Check any board support package or example project you started from, since the risk is in copied code. We did not fetch an ST advisory, so confirm the exact fixed package release with STMicroelectronics.
What to do now
- Inventory every product that uses an STSAFE-A secure element and note which middleware or sample code it was built from.
- Update to STSAFE-A1xx middleware 3.3.7 or later and rebuild the firmware.
- If you copied code from a sample application, diff it against the fixed version and apply the length check yourself.
- Plan the firmware update for deployed devices. Where field updates are hard, assess whether the bus is physically accessible.
- Add a build time check that flags this function so a stale copy does not come back.
Why it matters
The weakness is CWE-120, a buffer copy without checking the size of the input. According to the public write-up, the receive routine reads a length value from the data coming back over I2C and uses it to copy bytes into a buffer, without enough validation of that length. A device or an interposer on the bus that supplies a bad length can overflow the buffer.
The CVSS score is held down by the access needed: the attacker must sit on the I2C bus between the microcontroller and the secure element. That makes the risk physical and supply chain related more than remote. It is still worth fixing because sample code spreads. Reference code gets copied into many products, and the write-up makes that point directly.
Quick check
Do I need the X-CUBE-SAFEA1 package installed to be affected?
No. The record says user written code derived from a published sample application can be affected as well, so search your own source.
Can this be exploited over the network?
Not according to the record. The vector is adjacent and the attacker needs read and write access to the I2C bus.
Sources
- NVD record for CVE-2023-50096
- elttam write-up for CVE-2023-50096
Last reviewed: 19 October 2026.
