First, thanks for this library — we depend on it for the encrypted-store option in a .NET MAUI app, and it has been rock solid.
The gap: SQLitePCLRaw.lib.e_sqlcipher is still at 2.1.11 (Dec 2024), whose bundled SQLCipher predates the SQLite 3.50.2 fix for CVE-2025-6965. There is no 3.x line for the SQLCipher natives, so the remedy given in #636 does not reach consumers of this bundle.
In #636 the guidance was:
One of the main changes in SQLitePCLRaw 3.0 is that the version of the native SQLite library is no longer tied to the version of SQLitePCLRaw itself. So if you want to update to SQLite 3.X you just update SQLitePCLRaw.lib.e_sqlite to version 3.X.
That decoupling works well for plain SQLite, and we have watched lib.e_sqlite3 track upstream since. But the equivalent package for SQLCipher has no 3.x release, so there is no supported way to pick up a newer native. Current state on nuget.org:
| package |
latest |
SQLitePCLRaw.core |
3.0.5 |
SQLitePCLRaw.bundle_e_sqlite3 |
3.0.5 |
SQLitePCLRaw.provider.sqlcipher |
3.0.5 |
SQLitePCLRaw.lib.e_sqlcipher |
2.1.11 |
SQLitePCLRaw.bundle_e_sqlcipher |
2.1.11 |
The managed provider moved to 3.x; the native did not.
We also noticed that v2.1.12 (2026-07-19) was described as "a maintenance release to update 2.1.11 to reference SQLitePCLRaw.lib.e_sqlite3 3.53.3" — so the 2.1 line did get a native bump, but the SQLCipher variant was not included in it. That is what suggests this is an oversight rather than a deliberate hold, which is why we are raising it rather than assuming.
Upstream appears ready. SQLCipher has been rebasing steadily and is past the fix by a wide margin:
| SQLCipher |
date |
SQLite baseline |
| v4.18.0 |
2026-08-18 |
3.53.4 |
| v4.17.0 |
2026-07-08 |
3.53.3 |
| v4.13.0 |
2026-01-20 |
3.51.2 |
So a rebuild against a current SQLCipher tag looks like it would resolve this, rather than needing anything from Zetetic.
Why it matters a little more than it might appear: with bundle_e_sqlcipher, the same native serves all database access, not only encrypted stores. Applications that offer encryption as an opt-in — ours defaults to off — still run every query through this native, so the exposure is not limited to the subset of users who turned encryption on.
The ask: is a 3.x line for lib.e_sqlcipher planned, or is there an intended path we have missed? Either answer is genuinely useful — we are choosing between waiting, building the natives ourselves, and dropping SQLCipher, and knowing which of those is realistic would settle it.
Happy to test a prerelease on Windows, Android and iOS if that would help.
First, thanks for this library — we depend on it for the encrypted-store option in a .NET MAUI app, and it has been rock solid.
The gap:
SQLitePCLRaw.lib.e_sqlcipheris still at 2.1.11 (Dec 2024), whose bundled SQLCipher predates the SQLite 3.50.2 fix for CVE-2025-6965. There is no 3.x line for the SQLCipher natives, so the remedy given in #636 does not reach consumers of this bundle.In #636 the guidance was:
That decoupling works well for plain SQLite, and we have watched
lib.e_sqlite3track upstream since. But the equivalent package for SQLCipher has no 3.x release, so there is no supported way to pick up a newer native. Current state on nuget.org:SQLitePCLRaw.coreSQLitePCLRaw.bundle_e_sqlite3SQLitePCLRaw.provider.sqlcipherSQLitePCLRaw.lib.e_sqlcipherSQLitePCLRaw.bundle_e_sqlcipherThe managed provider moved to 3.x; the native did not.
We also noticed that v2.1.12 (2026-07-19) was described as "a maintenance release to update 2.1.11 to reference SQLitePCLRaw.lib.e_sqlite3 3.53.3" — so the 2.1 line did get a native bump, but the SQLCipher variant was not included in it. That is what suggests this is an oversight rather than a deliberate hold, which is why we are raising it rather than assuming.
Upstream appears ready. SQLCipher has been rebasing steadily and is past the fix by a wide margin:
So a rebuild against a current SQLCipher tag looks like it would resolve this, rather than needing anything from Zetetic.
Why it matters a little more than it might appear: with
bundle_e_sqlcipher, the same native serves all database access, not only encrypted stores. Applications that offer encryption as an opt-in — ours defaults to off — still run every query through this native, so the exposure is not limited to the subset of users who turned encryption on.The ask: is a 3.x line for
lib.e_sqlcipherplanned, or is there an intended path we have missed? Either answer is genuinely useful — we are choosing between waiting, building the natives ourselves, and dropping SQLCipher, and knowing which of those is realistic would settle it.Happy to test a prerelease on Windows, Android and iOS if that would help.