{"uuid": "457dfe40-ba18-4206-a063-2af6c60aa244", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2025-70873", "type": "seen", "source": "https://gist.github.com/ViveliDuCh/8e2e119fe688800e3c84e4b17424af4e", "content": "# Backport PR (8.0) \u2014 recommended title &amp; description for dotnet/efcore#38402\n\nReady-to-paste **title** and **description** for opening the servicing backport of [dotnet/efcore#38402](https://github.com/dotnet/efcore/pull/38402) (\"Switch Microsoft.Data.Sqlite and EFCore.Sqlite to SQLite3MC.PCLRaw.bundle\") onto **`release/8.0`**.\n\nFollows the repo's `.agents/skills/servicing-pr/SKILL.md` template and mirrors the prose style of recent merged servicing PRs (e.g. [#38373](https://github.com/dotnet/efcore/pull/38373), [#38134](https://github.com/dotnet/efcore/pull/38134)).\n\n- **Base branch:** `release/8.0`\n- **Source PR:** #38402 (merged to `main`)\n- **Issue:** [#38257](https://github.com/dotnet/efcore/issues/38257) \u2014 *SQLite vulnerabilities*\n\n&gt; **Verified against the real branches** (not just the source PR):\n&gt; `upstream/release/8.0` has **no Central Package Management** and references `SQLitePCLRaw.bundle_e_sqlite3` `2.1.6` inline; the prepared `dev-release-8.0` branch swaps both to `SQLite3MC.PCLRaw.bundle` `2.3.5` inline. `git diff` is exactly **2 files, 1 line each**. No SQLitePCLRaw 3.x prerequisite is needed (that's a 9.0/10.0 concern driven by CPM).\n\n## Recommended title\n\n```\n[release/8.0] Switch Microsoft.Data.Sqlite and EFCore.Sqlite to SQLite3MC.PCLRaw.bundle\n```\n\n## Recommended description\n\n````\nFixes #38257\nBackports #38402\n\n**Description**\nOn 8.0, `Microsoft.Data.Sqlite` and `Microsoft.EntityFrameworkCore.Sqlite` reference\n`SQLitePCLRaw.bundle_e_sqlite3` (2.1.6), whose native `e_sqlite3` builds are no longer\npublished to NuGet.org promptly. As a result, shipped EF Core SQLite consumers stay on\na native SQLite build that lags upstream, delaying SQLite security fixes\n(e.g. CVE-2025-6965, CVE-2025-70873) from reaching them. This backports #38402 by\nswitching both packages to `SQLite3MC.PCLRaw.bundle` 2.3.5, which provides the\n`e_sqlite3mc` native build (SQLite3 Multiple Ciphers), an actively maintained project\nthat tracks upstream SQLite and ships updated builds promptly.\n\nUnlike the 9.0 and 10.0 backports, no SQLitePCLRaw 3.x prerequisite migration is required\non 8.0: this branch does not use Central Package Management, so the transitive\n`SQLitePCLRaw.core` 3.0.2 brought in by the new bundle flows in cleanly alongside the\nunchanged 2.1.6 references in the test projects, with no central pin to violate. The\nchange is therefore two inline `.csproj` edits.\n\n**Customer impact**\nEF Core SQLite users on 8.0 are pinned to a native SQLite build that lags upstream,\nleaving them exposed to known SQLite CVEs until the bundle catches up. After the swap,\nthe default native build receives timely security updates, and encryption (including\nsetting a password) works out of the box. Behavior for unencrypted databases is\nunchanged \u2014 SQLite3 Multiple Ciphers is a superset that only applies encryption when a\nkey/password is explicitly supplied, so existing unencrypted databases open and work as\nbefore. Two documented compatibility notes: the native asset is renamed\n`e_sqlite3` -&gt; `e_sqlite3mc` (matters for trimming/AOT/single-file references), and\n`e_sqlite3mc` doesn't support legacy double-quoted string literals (use single quotes for\nstring values). Apps that need the standard build can opt out by referencing\n`Microsoft.Data.Sqlite.Core` / `Microsoft.EntityFrameworkCore.Sqlite.Core` plus\n`SQLitePCLRaw.bundle_e_sqlite3` 2.1.6. The breaking change is documented with mitigations\nin EntityFramework.Docs#5385.\n\n**How found**\nUser reported on 8.0 in dotnet/efcore#38257 (*SQLite vulnerabilities*), which has 50\ncomments and 13 \ud83d\udc4d across multiple users, including multiple security (MSRC) reports.\n\n**Regression**\nNo. This is a long-standing maintenance gap in the upstream `e_sqlite3` bundle, not a\nregression from an earlier EF Core version.\n\n**Testing**\nNo new tests. Covered by the existing Microsoft.Data.Sqlite and EFCore.Sqlite suites,\nincluding the dedicated `Microsoft.Data.Sqlite.sqlite3mc.Tests` project that already\nexercises the `SQLite3MC.PCLRaw.bundle` provider. The branch builds clean and related\ntests pass with the two-file edit.\n\n**Risk**\nLow-to-medium. Two-file, two-line `.csproj` change that swaps the native SQLite engine in\na servicing release. No quirk added: native SQLite bundle selection is a build/restore-time\nNuGet decision, not a runtime managed branch, so an AppContext switch can't gate it \u2014 the\nservicing-pr skill explicitly exempts cases where a quirk couldn't be used. An opt-out\nremains available at the packaging level via the existing `.Core` packages, and the change\nis documented with mitigations in EntityFramework.Docs#5385.\n````\n\n## How this maps to the servicing-pr template &amp; current patterns\n\n| Template / pattern element | Applied here |\n| --- | --- |\n| Title `[release/XX.0] ` | `[release/8.0] Switch Microsoft.Data.Sqlite and EFCore.Sqlite to SQLite3MC.PCLRaw.bundle` |\n| `Fixes #` / `Backports #` header | `Fixes #38257`, `Backports #38402` |\n| All seven sections present | Description, Customer impact, How found, Regression, Testing, Risk |\n| Quirk (AppContext switch) | **Skipped** \u2014 bundle selection is build-time, not runtime; skill exempts \"quirk couldn't be used\" cases. Called out in **Risk**. |\n| Risk ranked + code-size note | \"Low-to-medium \u2026 two-file, two-line change\" |\n| Mirrors real servicing PR prose (#38373 etc.) | Concise per-section paragraphs, customer-facing language, explicit CVE + opt-out |\n\n### Suggested labels\n\n`area-adonet-sqlite`, `breaking-change`\n\n&gt; Replace the CVE identifiers / comment counts with the latest figures at PR-open time if they've moved, and confirm `release/8.0` is the intended servicing target before opening.\n", "creation_timestamp": "2026-06-27T01:33:56.251565Z"}