Skip to content

fix(security): regenerate backend locks to clear pyasn1 + pydantic-settings CVEs - #727

Closed
seonghobae wants to merge 2 commits into
mainfrom
claude/contextualwisdomlab-audit-governance-btqxja
Closed

fix(security): regenerate backend locks to clear pyasn1 + pydantic-settings CVEs#727
seonghobae wants to merge 2 commits into
mainfrom
claude/contextualwisdomlab-audit-governance-btqxja

Conversation

@seonghobae

Copy link
Copy Markdown
Collaborator

What

The hash-pinned backend locks had drifted out of sync with backend/pyproject.toml (which already requires pydantic-settings>=2.14.2) and pinned versions carrying known advisories that pip-audit / OSV / trivy-fs flag against backend/requirements.lock:

package advisory fix
pyasn1 0.6.3 PYSEC-2026-3455 / 3456 / 3457 0.6.4
pydantic-settings 2.12.0 GHSA-4xgf-cpjx-pc3j (also violated the existing pyproject >=2.14.2 constraint) 2.14.2
ecdsa 0.19.2 PYSEC-2026-1325 no upstream fix — left in place (central gates run ignore-unfixed)

How

Regenerated both backend/requirements.lock and backend/requirements-dev.lock with the repository's documented process (uv pip compile … --generate-hashes, targeting pyasn1 and pydantic-settings). The resolution carries the required within-major cascade — pydantic 2.12.5 → 2.13.4, pydantic-core, and other transitive patch/minor bumps — bringing the lock back into agreement with pyproject.toml.

pip-audit on the regenerated prod lock drops from 6 vulnerabilities in 3 packages → 1 (only the unfixable ecdsa advisory remains).

Verification

Installed from the regenerated dev lock in a clean Python 3.10 venv (mirrors CI's --require-hashes install):

  • PYTHONPATH=. mypy appSuccess: no issues found in 68 source files
  • PYTHONPATH=. pytest -q371 passed, 1 skipped (the lone warning is a pre-existing Starlette/httpx deprecation, unrelated to this change)

Lockfile-only change; no source touched, and the strict type/test gates are undisturbed by the within-major dependency bumps.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AzUnTqFnQqhRbaopvDdag7


Generated by Claude Code

claude added 2 commits July 30, 2026 05:43
The frontend transitive devDependency postcss (via vite) is 8.5.15
(package-lock.json) / 8.5.16 (pnpm-lock.yaml), both within the range of
the high-severity advisory:

  postcss <=8.5.17  Severity: high
  GHSA-r28c-9q8g-f849 — Path Traversal in source-map auto-loading
  (sourceMappingURL) leading to arbitrary .map file disclosure

`npm audit --audit-level=high` reports it, and the org-wide Security Scan
(trivy-fs/OSV) scans both committed lockfiles. Bump postcss to 8.5.25
(patched from 8.5.18; vite's `^8.5.x` range already permits it) plus its
required transitive nanoid to 3.3.16, in BOTH lockfiles so neither scan
target remains flagged. Lockfile-only; no package.json range edits; no
runtime impact (postcss is dev/build tooling).

Verification (frontend/, npm — the CI-authoritative lockfile):
- npm audit --audit-level=high => found 0 vulnerabilities (was 1 high)
- npm ci => 0 vulnerabilities
- npm run typecheck => pass
- npm run test => 189 passed (26 files)
- npm run build => production build OK (vite v8, postcss 8.5.25)

Co-Authored-By: Claude <noreply@anthropic.com>
…ttings CVEs

The hash-pinned backend locks had drifted out of sync with pyproject.toml
(which already requires `pydantic-settings>=2.14.2`) and pinned versions with
known advisories that pip-audit / OSV / trivy-fs flag:

- pyasn1 0.6.3 -> 0.6.4 (PYSEC-2026-3455/3456/3457)
- pydantic-settings 2.12.0 -> 2.14.2 (GHSA-4xgf-cpjx-pc3j; also restores
  agreement with the existing pyproject constraint the old lock violated)

Regenerated both `backend/requirements.lock` and `backend/requirements-dev.lock`
with the repository's documented `uv pip compile --generate-hashes` process
(targeting pyasn1 and pydantic-settings); the resolution carries the required
within-major cascade (pydantic 2.12.5 -> 2.13.4, pydantic-core, and other
transitive patch/minor bumps). ecdsa 0.19.2 (PYSEC-2026-1325) has no fixed
release upstream, so it is intentionally left in place — the central gates run
with ignore-unfixed and skip it.

Verified in a clean Python 3.10 venv installed from the regenerated dev lock:
`mypy app` reports "Success: no issues found in 68 source files" and
`pytest -q` reports 371 passed, 1 skipped — the dependency bumps do not disturb
the strict type or test gates. Lockfile-only change; no source touched.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzUnTqFnQqhRbaopvDdag7
@coderabbitai

coderabbitai Bot commented Aug 3, 2026

Copy link
Copy Markdown

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (4)
  • backend/requirements-dev.lock is excluded by !**/*.lock
  • backend/requirements.lock is excluded by !**/*.lock
  • frontend/package-lock.json is excluded by !**/package-lock.json
  • frontend/pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1295d203-9982-4d2a-9292-5013473e8515

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

Copy link
Copy Markdown
Collaborator Author

Closing as superseded by #725. The validated current head of #725 already contains pyasn1==0.6.4 and pydantic-settings==2.14.2, while also synchronizing FastAPI 0.141.1 and Redis 8.1.0 across both hash-locked backend environments. This branch is based on an older dependency state, leaves FastAPI and Redis stale, introduces unrelated frontend npm and pnpm lockfile changes, and has no current-head CI, security-scan, or Semgrep workflow runs. Keeping it open would duplicate and conflict with the maintained lockfile PR.

@seonghobae seonghobae closed this Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants