GHSA-h5x4-m2qf-r4f2
Diesel's SQLite backend has possible UTF-8 corruption
Diesel uses the sqlite3_value_text function to receive strings from SQLite while deserializing query results. We misinterpreted the corresponding SQLite documentation that this function always returns a UTF-8 encoded string values as *const c_char. Based on that we used str::from_utf8_unchecked to construct a Rust string slice without any additional UTF-8 checks in place. It turned out that this function doesn't always return correct UTF-8 strings. For field of the SQLite side storage type BLOB this pointer can contain arbitrary bytes, which makes the usage of str::from_utf8_unchecked unsound as this violates the safety contract of str to only contain valid UTF-8 encoded Strings.
Mitigation
The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.
Resolution
Diesel now correctly checks whether the provides byte buffer is actually valid UTF-8, instead of relying on SQLite's documentation. This fix is included in the 2.3.8 release.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- High
- Availability
- None
What each source reports
GitHub Advisories Score used
Diesel's SQLite backend has possible UTF-8 corruption
Diesel uses the sqlite3_value_text function to receive strings from SQLite while deserializing query results. We misinterpreted the corresponding SQLite documentation that this function always returns a UTF-8 encoded string values as *const c_char. Based on that we used str::from_utf8_unchecked to construct a Rust string slice without any additional UTF-8 checks in place. It turned out that this function doesn't always return correct UTF-8 strings. For field of the SQLite side storage type BLOB this pointer can contain arbitrary bytes, which makes the usage of str::from_utf8_unchecked unsound as this violates the safety contract of str to only contain valid UTF-8 encoded Strings.
Mitigation
The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.
Resolution
Diesel now correctly checks whether the provides byte buffer is actually valid UTF-8, instead of relying on SQLite's documentation. This fix is included in the 2.3.8 release.
- Record
GHSA-h5x4-m2qf-r4f2- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-20
- Updated
- 2026-11-02
OSV
Diesel's SQLite backend has possible UTF-8 corruption
Diesel uses the sqlite3_value_text function to receive strings from SQLite while deserializing query results. We misinterpreted the corresponding SQLite documentation that this function always returns a UTF-8 encoded string values as *const c_char. Based on that we used str::from_utf8_unchecked to construct a Rust string slice without any additional UTF-8 checks in place. It turned out that this function doesn't always return correct UTF-8 strings. For field of the SQLite side storage type BLOB this pointer can contain arbitrary bytes, which makes the usage of str::from_utf8_unchecked unsound as this violates the safety contract of str to only contain valid UTF-8 encoded Strings.
Mitigation
The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.
Resolution
Diesel now correctly checks whether the provides byte buffer is actually valid UTF-8, instead of relying on SQLite's documentation. This fix is included in the 2.3.8 release.
- Record
GHSA-h5x4-m2qf-r4f2- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N - Weakness
- CWE-20
- Updated
- 2026-11-02
OSVRUSTSEC-2026-0111No score
Possible UTF-8 corruption in Diesels SQLite backend
Diesel uses the sqlite3_value_text function to receive strings from SQLite while deserializing query results. We misinterpreted the corresponding SQLite documentation that this function always returns a UTF-8 encoded string values as *const c_char. Based on that we used str::from_utf8_unchecked to construct a Rust string slice without any additional UTF-8 checks in place. It turned out that this function doesn't always return correct UTF-8 strings. For field of the SQLite side storage type BLOB this pointer can contain arbitrary bytes, which makes the usage of str::from_utf8_unchecked unsound as this violates the safety contract of str to only contain valid UTF-8 encoded Strings.
Mitigation
The preferred mitigation to the outlined problem is to update to a Diesel version 2.3.8 or newer, which includes fixes for the problem.
Resolution
Diesel now correctly checks whether the provides byte buffer is actually valid UTF-8, instead of relying on SQLite's documentation. This fix is included in the 2.3.8 release.
- Record
RUSTSEC-2026-0111- Updated
- 2026-11-02
Affected packages
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-h5x4-m2qf-r4f2 is a high vulnerability (CVSS 8.7) in diesel, published April 24, 2026. No source lists public exploit code. Fixed in diesel 2.3.8.