We’re pleased to announce the availability of SQLCipher 4.19.0. This is a maintenance release that addresses two low-risk security issues in the core library, fixes several non-critical bugs, and updates cryptographic providers.
hexkey URI parametersqlcipher_export()cipher_settings if allocation failsSQLCipher Commercial and Enterprise packages include the following enhancements:
This update includes fixes for two potential security issues affecting SQLCipher 4.18.0 and earlier:
sqlcipher_export convenience function can be used to copy the contents of one attached database into another. The function validates that source and target schema names reference attached databases, but constructed the internal SQL without quoting them. Thus a valid attached database alias containing SQL tokens could alter generated statements. SQLCipher now additionally quotes schema names before they are used in the generated SQL, ensuring they remain pure SQL identifiers. This issue is assigned a CVSS 4.0 base score of 2.1 / Low (CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:L). In order to practically exploit this issue, an application must already have an existing SQL injection vulnerability or allow unrestricted SQL access that reaches sqlcipher_export with attacker-controlled schema aliases. Cryptographic integrity of the database is unaffected and data remains encrypted under the application-controlled key at all times, all per-page HMAC and underlying integrity protections continue to function, and there is no leakage of data.hexkey parameter in URI connection strings for providing a hex-encoded key. An issue with parameter handling meant that using a non-empty but syntactically invalid hex value would not raise an error. Opening a new database in this manner would continue without a codec and write a plaintext SQLite database. SQLCipher now reports an error for a hexkey value containing no valid key material. Note that the hexkey URI parameter is not part of our official API documentation or any recommended example code, and is unlikely to be widely used. The same 2.1 / Low vector applies here as well.Both issues were reported privately. No credit responses were received, so these are unattributed out of respect for the original confidentiality request. We sincerely thank the reporter for their responsible and coordinated disclosure.
The table below summarizes the cryptographic providers used across SQLCipher packages and platforms:
| Edition | Platform | Cryptographic Provider |
|---|---|---|
| Community (non-FIPS) | Android | based on LibTomCrypt 1.18.2 |
| Community (non-FIPS) | Apple | Common Crypto (version varies by OS) |
| Commercial & Enterprise (non-FIPS) | Apple | Common Crypto (version varies by OS) |
| Commercial & Enterprise (non-FIPS) | Other Platforms | OpenSSL 3.5.8 LTS |
| Enterprise FIPS | All Platforms | SQLCipher Cryptographic Module Based on OpenSSL 3.5.7 LTS |
SQLCipher 4.19.0 is available for download now. We recommend that all applications upgrade to incorporate the security fixes and the other improvements in this release. As always, test your applications thoroughly with the new version before deploying to production.
Commercial and Enterprise - On-demand access to new releases of SQLCipher packages are available to all licensees with an active subscription from the Customer Downloads fulfillment site. Subscribers will also receive a separate email notification regarding the update and can contact us at any time for private support directly from the SQLCipher development team. Commercial and Enterprise edition upgrades require a new license code from the SQLCipher fulfillment site for each version. Don’t forget to change the license code in your application(s) when you upgrade.
Community Edition - SQLCipher Community Edition source code is available on GitHub, via AAR packaging for Android, and Swift Package Manager for Apple platforms.
For feedback and questions, please visit our Community Forum or private support channels. Thank you for using SQLCipher!