fix: bump pyjwt for security advisories

[johnnygreco]

📋 Summary

This PR addresses the scanner-reported PyJWT vulnerability by ensuring DataDesigner resolves PyJWT to the fixed 2.13.0 release. mcp pulls in pyjwt[crypto], so the engine package now declares an explicit security floor to prevent the vulnerable 2.12.0 resolution from returning.

🔗 Related Issue

N/A

🔄 Changes

• Added a direct pyjwt[crypto]>=2.13.0,<3 dependency constraint in packages/data-designer-engine/pyproject.toml.
• Regenerated uv.lock so pyjwt resolves to 2.13.0 instead of 2.12.0.

🔍 Attention Areas

⚠️ Reviewers: Please pay special attention to the following:

• packages/data-designer-engine/pyproject.toml — this intentionally promotes pyjwt[crypto] from transitive dependency to direct security floor because it is pulled in through mcp.

🧪 Testing

• make test passes (not run; dependency-only security update)
• uv lock --check
• uv run --package data-designer-engine python -c "import jwt; print(jwt.__version__)" → 2.13.0
• uv run --package data-designer-engine pytest packages/data-designer-engine/tests/engine/mcp -q → 119 passed
• Unit tests added/updated (N/A — no new code path)
• E2E tests added/updated (N/A — no workflow change)

✅ Checklist

• Follows commit message conventions
• Commits are signed off (DCO)
• Architecture docs updated (N/A — dependency-only security update)

[greptile-apps]

Greptile Summary

This PR fixes a transitive PyJWT vulnerability by pinning pyjwt[crypto]>=2.13.0,<3 as a direct dependency in data-designer-engine, overriding the vulnerable 2.12.0 that mcp would otherwise pull in. The lock file is regenerated to confirm resolution at 2.13.0.

• packages/data-designer-engine/pyproject.toml — adds the security floor using the same pattern already established for cryptography and python-multipart in this file.
• uv.lock — pyjwt bumped from 2.12.0 → 2.13.0; the [crypto] optional-dependencies entry correctly references the existing cryptography direct dependency, and a new typing-extensions marker is included for Python < 3.11.

Confidence Score: 5/5

This is a dependency-only security bump with no code changes; the lock file correctly resolves pyjwt to 2.13.0 and the other two packages in the monorepo do not depend on mcp and are unaffected.

The change follows a well-established pattern in this file, the crypto extra correctly wires up to the already-pinned cryptography dependency, the lock file hashes match the published 2.13.0 release on PyPI, and the PR author verified the resolved version and ran the MCP test suite.

No files require special attention.

Important Files Changed

Filename	Overview
packages/data-designer-engine/pyproject.toml	Adds pyjwt[crypto]>=2.13.0,<3 as an explicit direct dependency to enforce the security floor; follows the same pattern already used for cryptography and python-multipart in this file.
uv.lock	Lock file regenerated correctly: pyjwt bumped from 2.12.0 to 2.13.0, [crypto] extra wired up, new typing-extensions marker added for Python < 3.11, and hashes updated.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[data-designer-engine] -->|direct dep| B[mcp >=1.26.0,<2]
    B -->|transitive dep| C[pyjwt]
    A -->|new security floor| D["pyjwt[crypto] >=2.13.0,<3"]
    D -->|pins to| E[pyjwt 2.13.0]
    C -.->|without floor resolves to| F[pyjwt 2.12.0 vulnerable]
    A -->|existing dep| G[cryptography >=46.0.7,<47]
    D -->|crypto extra requires| G

Loading

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into johnny/fix-pyjw..." | Re-trigger Greptile}

[github-actions]

Code Review: PR #751 — fix: bump pyjwt for security advisories

Summary

Pins pyjwt[crypto]>=2.13.0,<3 as a direct dependency in data-designer-engine so the transitive resolution from mcp cannot fall back to the vulnerable 2.12.0 release. uv.lock is regenerated to reflect 2.13.0. Total churn: 2 files, +9/-3.

This follows the exact pattern used at line 55 for python-multipart>=0.0.29,<1, which was also promoted to a direct security floor for an mcp-introduced advisory. Promoting a transitive package to a direct dependency purely as a security floor is the standard fix for this kind of issue.

Findings

Correctness

• Specifier shape is correct. >=2.13.0,<3 matches the project's >=X,<MAJOR+1 convention used throughout pyproject.toml (e.g., mcp>=1.26.0,<2, numpy>=1.23.5,<3).
• [crypto] extra preserved. mcp pulls pyjwt[crypto], and the new direct dependency also requests [crypto], so the cryptographic backend (cryptography) stays installed. If only pyjwt were declared without the extra, uv would still resolve the extra via mcp's requirement, but explicitly requesting it here makes the intent self-documenting and resilient to mcp changing its declaration.
• Lock file consistent. uv.lock shows pyjwt at 2.13.0 with the new typing-extensions marker dependency for python_full_version < '3.11', matching upstream's 2.13.0 metadata.
• No code paths use jwt directly. Confirmed via grep — pyjwt is purely transitive through mcp. Bumping the version cannot regress DataDesigner code.

Conventions

• Comment style on line 54 mirrors the adjacent python-multipart line 55: short, ends with the rationale ("…security advisories pulled in by mcp"). Good consistency.
• Alphabetical ordering of dependencies is preserved (pyjwt before python-multipart).

Risk / Blast Radius

• Low. This is a dependency-only patch with no source changes. The only consumers of pyjwt are inside mcp's own auth flow; pyjwt 2.13.0 is a security patch release with no breaking API changes (verify against the PyJWT changelog — the bump is a minor version with backward-compatible additions).
• mcp test suite passed. PR description shows pytest packages/data-designer-engine/tests/engine/mcp -q → 119 passed, which is the relevant integration surface.

Test Coverage

• No tests added — appropriate. Dependency floors don't require new test logic; the lock file + the existing mcp test suite are the right gates.

Security

• This is the security fix. The CVE addressed by pyjwt 2.13.0 was tracked as a scanner advisory against pyjwt 2.12.0 (the version mcp pulls in transitively). Without this floor, a fresh uv lock could reintroduce 2.12.0 if mcp's bounds permit it.
• One thing worth noting (not blocking): when the upstream advisories rotate again, this floor will need to be bumped or removed. A short comment referencing the specific advisory ID (e.g. GHSA / CVE) would make future cleanup easier — but the existing python-multipart neighbor doesn't do this either, so it's a project-wide nit, not specific to this PR.

Performance

• N/A — dependency-only change.

Suggestions (Optional)

1. Consider adding the GHSA/CVE identifier in the trailing comment on line 54 (and retroactively for python-multipart on line 55) so it's obvious when the floor can be removed. Pattern: # pyjwt[crypto]>=2.13.0,<3 — security floor for GHSA-XXXX-XXXX-XXXX (transitively via mcp). Non-blocking.
2. Once mcp's own bounds move past 2.12.x, this direct dependency should be reverted to keep the dependency graph minimal. Worth tracking in a follow-up issue if one doesn't exist.

Verdict

Approve. Minimal, targeted security fix that matches an established in-repo pattern. The PyPI metadata, lock file, and mcp test suite all align. No code changes, no test changes needed. Ship it.