ENG-3022: Bump ujson to ~=5.12.0

[erosselli]

Ticket ENG-3022

Description Of Changes

Adds an explicit ujson~=5.12.0 floor pin to address CVE-2026-32874 (memory leak DoS via large integers) and CVE-2026-32875 (integer overflow in dumps). ujson is a transitive dependency via fastapi[all] — not imported directly by fides or fidesplus.

Code Changes

• Added ujson~=5.12.0 pin in pyproject.toml
• Regenerated uv.lock

Steps to Confirm

1. CI passes — no direct ujson imports in fides or fidesplus

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • No UX review needed
• Followup issues:
  • No followup issues
• Database migrations:
  • No migrations
• Documentation:
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Mar 23, 2026 2:31pm
fides-privacy-center	Ignored		Mar 23, 2026 2:31pm

[greptile-apps]

Greptile Summary

This PR adds an explicit ujson~=5.12.0 floor pin to pyproject.toml to address two security vulnerabilities (CVE-2026-32874: memory leak DoS via large integers, CVE-2026-32875: integer overflow in dumps) in the transitive ujson dependency pulled in via fastapi[all], and regenerates uv.lock accordingly.

• ujson is confirmed to not be directly imported anywhere in the fides or fidesplus codebase, so the pin is purely a supply-chain / transitive dependency constraint.
• The uv.lock correctly reflects the upgrade from 5.11.0 → 5.12.0 with updated wheel URLs and hashes.
• The changelog entry is properly typed as Security and references both CVEs.
• types-ujson is still pinned at ==5.4.0 in dev dependencies, but because ujson is not directly imported anywhere in the project, there is no practical impact on type-checking.

Confidence Score: 5/5

• This PR is safe to merge — it is a minimal, targeted security bump of a transitive dependency with no direct usage in the codebase.
• The change is a single dependency version bump addressing two CVEs. ujson is not imported directly anywhere in fides or fidesplus, so there is zero risk of API breakage. The lock file hashes have been properly regenerated, and the changelog entry is correct.
• No files require special attention.

Important Files Changed

Filename	Overview
pyproject.toml	Adds explicit ujson~=5.12.0 floor pin to address CVE-2026-32874 and CVE-2026-32875; change is minimal and correct.
uv.lock	Lock file regenerated to pin ujson from 5.11.0 to 5.12.0, with updated sdist/wheel URLs and hashes; looks correct.
changelog/7727-bump-ujson.yaml	Changelog entry properly categorized as Security and references both CVEs.

_{Reviews (1): Last reviewed commit: "Use ~=5.12.0 pin for ujson upper bound" | Re-trigger Greptile}

[claude]

Code Review: ENG-3022 — Bump ujson to ~=5.12.0

This is a clean, minimal security dependency bump. No issues found.

What was verified:

• Version specifier — ~=5.12.0 (compatible release: >=5.12.0, <5.13.0) is the correct constraint for a security floor pin, consistent with other dependency pins in pyproject.toml.
• Lock file — uv.lock is properly regenerated with verified hashes for all target platforms (cp313/cp314 across macOS, manylinux, musllinux, win32/win64/arm64). Wheel count and platform coverage are consistent with the previous 5.11.0 entry.
• Direct usage — No Python files in the repo import ujson directly, confirming this is purely a transitive dependency (via fastapi[all]) being explicitly floored for security reasons.
• Changelog — changelog/7727-bump-ujson.yaml uses type: Security and matches the format of other recent security bump entries (e.g., 7718-bump-pyjwt.yaml, 7716-bump-tornado.yaml).
• CVE scope — Both CVEs (memory leak DoS via large integers, integer overflow in dumps) are addressed by 5.12.0 per the upstream release.

LGTM. ✓

[adamsachs]

👍 (as long as CI passes). this one should be low risk because i believe this is only a dev requirement, doesn't even impact app behavior at all