GHSA-h5x4-m2qf-r4f2
Suggest an improvement- Source
- https://github.com/advisories/GHSA-h5x4-m2qf-r4f2
- Import Source
- https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-h5x4-m2qf-r4f2/GHSA-h5x4-m2qf-r4f2.json
- JSON Data
- https://api.osv.dev/v1/vulns/GHSA-h5x4-m2qf-r4f2
- Aliases
- Published
- 2026-05-05T18:08:05Z
- Modified
- 2026-05-06T06:56:25.944415855Z
- Severity
-
- 8.7 (High) CVSS_V4 - 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 CVSS Calculator
- Summary
- Diesel's SQLite backend has possible UTF-8 corruption
- Details
-
Diesel uses the
sqlite3_value_textfunction 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 usedstr::from_utf8_uncheckedto 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 typeBLOBthis pointer can contain arbitrary bytes, which makes the usage ofstr::from_utf8_uncheckedunsound as this violates the safety contract ofstrto 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.8release. - Database specific
{ "cwe_ids": [ "CWE-89" ], "github_reviewed_at": "2026-05-05T18:08:05Z", "github_reviewed": true, "severity": "HIGH", "nvd_published_at": null }- References
Affected packages
crates.io / diesel
Package
- Name
- diesel
- View open source insights on deps.dev
- Purl
- pkg:cargo/diesel