[FIX] Upgrade snowflake-connector-python to 4.x to unblock cryptography 48.0.0 (CVE fixes)

[jaseemjaskp]

What

Upgrades snowflake-connector-python ~=3.14.0 → ~=4.6.0 and re-locks every module to cryptography 48.0.0 / cffi 2.0.0, eliminating cryptography version divergence across the repo and clearing three CVEs in the modules that were stuck below the fix.

Fixes #2016 (follow-up to the review on the merged #2011).

Why

snowflake-connector-python ~=3.14.0 pins cffi>=1.9,<2.0.0, while cryptography 46.0.1+ requires cffi>=2.0.0. These are mutually exclusive, so every module pulling unstract-connectors (→ snowflake) — backend, workers, unstract/connectors, and the root project — was hard-capped at cryptography 46.0.0, the only 46.x still compatible with cffi 1.x. That left them below the security fixes shipped in:

cryptography	CVE
46.0.5	CVE-2026-26007 — binary elliptic-curve private-key leak
46.0.6	CVE-2026-34073 — name-constraint bypass with wildcard DNS SAN
46.0.7	CVE-2026-39892 — buffer overflow on non-contiguous buffers

Attempting to set backend/pyproject.toml to cryptography>=46.0.7 made the project unresolvable (uv lock failed) because of the snowflake cffi pin.

How

• unstract/connectors/pyproject.toml: snowflake-connector-python[pandas] ~=3.14.0 → ~=4.6.0. Snowflake 4.x drops the cffi dependency entirely and itself requires cryptography>=46.0.5, so the cap is lifted.
• backend/pyproject.toml: cryptography floor >=41.0.7 → >=48.0.0 (genuinely aligns with platform-service, which is already >=48.0.0).
• unstract/flags/pyproject.toml: protobuf floor >=6.33.5 → >=4.25.0. See "protobuf conflict" below.
• Re-locked all tracked lock files. cryptography is now uniformly 48.0.0 (latest secure release, supersedes 46.0.7) with cffi 2.0.0 everywhere; snowflake 4.6.0 in the snowflake-bound modules.

protobuf conflict (surfaced after merging main)

Merging main pulled in #2017 (a dependabot bump), which had raised unstract-flags' floor to protobuf>=6.33.5. That conflicts with google-cloud-bigquery==3.11.4 (caps protobuf<5, via unstract-connectors), making uv lock unsatisfiable in every module pulling both packages (root, backend, workers) — this is what made the Update UV lock, build, and test checks fail.

The protobuf>=6.33.5 floor was over-aggressive: the flipt gRPC stubs (flipt_simple_pb2.py) use the protobuf-4.x+ _builder API, the package's egg-info declares protobuf>=4.25.0, and no code in the repo requires protobuf>=5.26 (no runtime_version checks). Reverting the floor to >=4.25.0 resolves the conflict with zero resolved-package-version changes — it avoids forcing protobuf 6, which would otherwise have required bumping google-cloud-bigquery/google-cloud-secret-manager and downgraded opentelemetry 1.34 → 1.11.

Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

Low risk, but it is a two-major-version snowflake jump and a cryptography major bump, so worth a smoke test:

• Snowflake connector — our code uses only the stable core API (connect(user, password, account, database, schema, warehouse, role), cursor(), execute(), commit(), errors.ProgrammingError.msg/.errno). All verified present/unchanged in 4.6.0 and SnowflakeDB imports cleanly. The live integration test needs real credentials, so a manual smoke test against a real Snowflake account is recommended before merge.
• cryptography 48.0.0 — backend's only direct use is Fernet/InvalidToken (adapter credential encryption); verified an encrypt/decrypt + InvalidToken roundtrip on 48.0.0. 48.0.0 drops Python 3.8 support (all modules pin >=3.12,<3.13, so unaffected).
• Snowflake 4.6.0's pandas extra (pandas<3.0.0,>=1.0.0) is compatible with the existing numpy<2.0.0, pandas<2.2.0 constraint; all modules pass uv lock --check.
• protobuf/flags — the floor revert causes no resolved-version changes (lock diffs are specifier-metadata only); the flipt stubs import cleanly under both protobuf 4.25.x (connectors-bound modules) and protobuf 6.33.5 (flags standalone), and opentelemetry stays at 1.34.

Database Migrations

None.

Env Config

None.

Relevant Docs

Related Issues or PRs

• Fixes Upgrade snowflake-connector-python to 4.x to unblock cryptography 46.0.7 (CVE fixes) #2016
• Follow-up to Bump the uv group across 10 directories with 5 updates #2011

Dependencies Versions

• snowflake-connector-python 3.14.x → 4.6.0
• cryptography → 48.0.0 (was 46.0.0 / 45.0.7 / 41.0.7 in lagging modules)
• cffi → 2.0.0 (was 1.17.1)
• pyOpenSSL → 26.2.0 (transitive)

Notes on Testing

• uv lock --check passes for all 10 modules.
• Verified snowflake 4.6.0 API surface, SnowflakeDB import, and Fernet roundtrip on cryptography 48.0.0.
• Recommend a manual Snowflake read/write smoke test against a live account before merge.

Screenshots

Checklist

I have read and understood the Contribution Guidelines.

[coderabbitai]

Walkthrough

Bumps unstract/connectors Snowflake connector to ~=4.6.0 and raises backend's cryptography minimum to >=48.0.0.

Changes

Dependency Upgrades

Layer / File(s)	Summary
Snowflake connector upgrade unstract/connectors/pyproject.toml	snowflake-connector-python[pandas] constraint changed from ~=3.14.0 to ~=4.6.0.
Backend cryptography floor backend/pyproject.toml	cryptography dependency changed from >=41.0.7 to >=48.0.0.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and clearly describes the primary change: upgrading snowflake-connector-python to 4.x to unblock cryptography 48.0.0 and address CVE fixes.
Linked Issues check	✅ Passed	The PR successfully addresses issue #2016 by upgrading snowflake-connector-python to 4.x, removing the cffi constraint, enabling cryptography upgrade to 48.0.0 with all three CVE fixes, and verifying Snowflake API compatibility.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to resolving the dependency conflict: snowflake-connector-python upgrade, cryptography floor bump, cffi version alignment, and lock file updates to support these changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The pull request description comprehensively addresses all required template sections with detailed technical justification, risk assessment, and testing strategy.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/snowflake-4x-cryptography-46-0-7

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR upgrades snowflake-connector-python from ~=3.14.0 to ~=4.6.0 and re-locks all 10 tracked modules to cryptography 48.0.0 / cffi 2.0.0, clearing three cryptography CVEs that were blocked by the old Snowflake connector's cffi<2.0.0 pin.

• unstract/connectors/pyproject.toml: Snowflake connector bumped to ~=4.6.0, which drops the cffi<2.0.0 dependency entirely and itself requires cryptography>=46.0.5, unblocking the crypto upgrade.
• backend/pyproject.toml: cryptography floor raised from >=41.0.7 to >=48.0.0, picking up fixes for CVE-2026-26007, CVE-2026-34073, and CVE-2026-39892.
• unstract/flags/pyproject.toml: protobuf minimum was silently lowered from >=6.33.5 to >=4.25.0 — this change is not mentioned in the PR description and the rationale is unclear.

Confidence Score: 4/5

The cryptography and Snowflake connector upgrades are well-reasoned and the lock files are consistent, but the unexplained protobuf floor downgrade in unstract/flags needs clarification before merge.

The core dependency upgrades (Snowflake 4.6.0, cryptography 48.0.0, cffi 2.0.0) are straightforward and internally consistent across all 10 lock files. The one concern is the silent lowering of the protobuf minimum in unstract/flags/pyproject.toml from >=6.33.5 to >=4.25.0 — this change is absent from the PR description, is unrelated to the stated goal, and leaves the root workspace resolved at 4.25.9, below the previous floor. Whether intentional or a locking side-effect, it deserves an explicit explanation before the PR lands.

unstract/flags/pyproject.toml — the protobuf constraint change is unexplained and unrelated to the Snowflake/cryptography goal of this PR.

Important Files Changed

Filename	Overview
unstract/connectors/pyproject.toml	Upgrades snowflake-connector-python from ~=3.14.0 to ~=4.6.0, which drops the cffi<2.0.0 cap and enables cryptography 48.0.0 across the codebase.
backend/pyproject.toml	Raises cryptography floor from >=41.0.7 to >=48.0.0, aligning with platform-service and pulling in three CVE fixes (CVE-2026-26007, CVE-2026-34073, CVE-2026-39892).
unstract/flags/pyproject.toml	Lowers protobuf minimum from >=6.33.5 to >=4.25.0 — change is undocumented in the PR; the root workspace lock resolves to 4.25.9, which is below the previous floor.
unstract/connectors/uv.lock	Locks snowflake-connector-python to 4.6.0, cryptography to 48.0.0, and cffi to 2.0.0 — consistent with pyproject.toml changes.
backend/uv.lock	Re-locks cryptography to 48.0.0 and cffi to 2.0.0, consistent with the raised floor in pyproject.toml.
uv.lock	Root workspace lock updated to cryptography 48.0.0 and cffi 2.0.0 uniformly across all member packages.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["snowflake-connector-python 3.14.x\ncffi < 2.0.0 (hard cap)"] -->|"blocks"| B["cryptography capped at 46.0.0\n(CVE-2026-26007, CVE-2026-34073, CVE-2026-39892 unpatched)"]
    C["snowflake-connector-python 4.6.0\nno cffi dependency"] -->|"unblocks"| D["cryptography 48.0.0\ncffi 2.0.0\n(all three CVEs patched)"]
    D --> E["backend\ncryptography floor ≥48.0.0"]
    D --> F["unstract/connectors\ncryptography 48.0.0 locked"]
    D --> G["all 10 modules\nuniform 48.0.0"]
    H["unstract/flags/pyproject.toml\nprotobuf ≥6.33.5 → ≥4.25.0\n⚠️ undocumented change"] -.->|"root workspace resolves\nto 4.25.9"| G

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
unstract/flags/pyproject.toml:8
**Unexplained protobuf floor downgrade**

The minimum `protobuf` version was lowered from `>=6.33.5` to `>=4.25.0`, but this change is not mentioned anywhere in the PR description. The previous floor of `6.33.5` presumably existed for a reason (it was set deliberately). Dropping it to `4.25.0` allows protobuf versions that pre-date `6.x` fixes to satisfy the constraint. The flags-package lock file still resolves to `6.33.5` in isolation, but any downstream environment that resolves this package against the root workspace (which locks to `4.25.9`) will now install the older version without a version-floor guard. Please clarify whether this change was intentional or a side-effect of the locking run.

_{Reviews (3): Last reviewed commit: "Fix protobuf conflict blocking lock reso..." | Re-trigger Greptile}

[jaseemjaskp]

Automated dependency-correctness review (PR is lock-file + version-bump only; no application code changed, so the code/type/test/comment review agents have no in-scope surface). Verified: (1) cryptography is uniformly 48.0.0, cffi 2.0.0, snowflake 4.6.0, pyOpenSSL 26.2.0 across all 9 changed locks; (2) no other repo module pins a vulnerable cryptography — every uv.lock that has cryptography is at 48.0.0 (platform-service already was), and the 6 locks without it genuinely have no cryptography dep; (3) snowflake 4.6.0 drops cffi from its dep tree (confirmed in the lock) and the connector code uses only the stable DB-API surface (connect/cursor/execute/commit/errors.ProgrammingError.msg/.errno); (4) pandas 2.1.4 (<2.2.0) and numpy 1.26.4 (<2.0.0) satisfy existing constraints; (5) backend's only direct cryptography use is Fernet/InvalidToken (stable in 48.0.0). Two minor notes inline. Note: the 2026 CVE IDs are past my knowledge cutoff and were not independently verified — but the remediation logic (48.0.0 > 46.0.7 supersedes all three fixes) is sound regardless.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Unstract test results

Per-group results

Status	Group	Tier	Passed	Failed	Errors	Skipped	Duration (s)
❌	unit-connectors	unit	64	12	0	3	17.0
❌	unit-core	unit	0	0	2	0	1.3
❌	unit-platform-service	unit	9	0	1	0	1.5
✅	unit-prompt-service	unit	15	0	0	0	20.9
✅	unit-rig	unit	53	0	0	0	3.4
✅	unit-runner	unit	11	0	0	0	3.2
✅	unit-sdk1	unit	381	0	0	0	21.1
❌	unit-tool-registry	unit	0	0	1	0	1.4
⚪	unit-workers	unit	0	0	0	0	18.1
	TOTAL		533	12	4	3	87.7

Critical paths

⚠️ Critical paths not yet covered

• auth-login — User can log in and obtain a session cookie. (entry: POST /api/v1/auth/login; declared coverage: no groups declared)
• adapter-register-llm — Register and validate an LLM adapter. (entry: POST /api/v1/adapter/; declared coverage: no groups declared)
• workflow-create-execute — Create a workflow, configure source+destination, execute, poll, fetch result. (entry: POST /api/v1/workflow/{id}/execute/; declared coverage: e2e-workflow)
• api-deployment-run — Deploy a workflow as an API, POST a document, receive structured JSON. (entry: POST /deployment/api/{org}/{name}/; declared coverage: e2e-api-deployment)
• prompt-studio-fetch-response — Prompt Studio: create project, add prompt, run single-pass, get response. (entry: POST /api/v1/prompt-studio/prompt-studio-tool/{id}/fetch_response/; declared coverage: e2e-prompt-studio)
• pipeline-etl-execute — Run an ETL pipeline from source connector to destination. (entry: POST /api/v1/pipeline/{id}/execute/; declared coverage: no groups declared)
• usage-token-tracking — Per-execution token usage is recorded and retrievable. (entry: GET /api/v1/usage/get_token_usage/; declared coverage: no groups declared)
• workflow-execution-fan-out — Multi-file workflow execution fans out to file-processing workers and rejoins. (entry: internal: backend → rabbitmq → workers/file_processing; declared coverage: no groups declared)
• callback-result-delivery — Async results are posted back via the callback worker. (entry: internal: workers/callback → backend /internal endpoints; declared coverage: no groups declared)

✅ Covered critical paths

• tool-sandbox-exec — covered by unit-runner