# CVEs that pip-audit reports but which we have explicitly accepted as
# risk-managed. Each entry must include a justification and a tracking link.
# Remove an entry once the upstream cause is resolved and a fresh
# `uv lock --upgrade` no longer reports it.
#
# Format: one vulnerability ID per line, using a pip-audit-supported prefix
# such as CVE-, GHSA-, or PYSEC-. Lines starting with `#` and blank lines are
# ignored. Inline `#` comments after the ID are allowed and encouraged.
#
# To re-verify this list, run `uv run pip-audit` with no ignore flags and
# compare the reported IDs against the entries below. Anything listed here
# that pip-audit no longer reports is stale and should be deleted.

# --- Blocked by zenml's `click<=8.2.1` cap. --------------------------------
# zenml declares `click>=8.0.1,<=8.2.1`. The ceiling is inclusive and sits on
# the vulnerable version itself, so no lockfile refresh can reach the 8.3.3
# fix while we depend on zenml.
#
# Not exploitable here: the advisory is a command injection in `click.edit()`,
# the helper that shells out to `$EDITOR`. Kitaru never calls it (our only
# click usage is `click.get_app_dir()` and catching `click.ClickException`),
# and neither does zenml. The CVSS vector is local-only and already requires
# high privileges (AV:L/AC:H/PR:H/UI:R).
# Tracked upstream: https://github.com/zenml-io/zenml/issues/5077
PYSEC-2026-2132  # click 8.2.1 -> 8.3.3 (CVE-2026-7246, `click.edit()` injection)

# --- Blocked by our own cap in the shipped `kitaru[mcp]` extra. ------------
# `pyproject.toml` declares `mcp>=1.19.0,<1.20.0`, so this is not merely a
# stale lock: every `pip install kitaru[mcp]` resolves to a vulnerable 1.19.x,
# and no version of the extra gets a user to the 1.23.0 fix.
#
# The cap was correct when written (`mcp>=1.20` needs `pyjwt>=2.10.1`, and
# zenml used to hard-pin `pyjwt==2.7.*`), but that reason is gone: zenml now
# requires `pyjwt[crypto]>=2.13.0`. Only our ceiling remains. Widening it
# changes a published extra and needs the MCP server re-verified against the
# newer SDK, so it is tracked separately rather than bundled into a bump.
# Delete this entry once that lands.
# Tracked: https://github.com/zenml-io/kitaru/issues/546
CVE-2025-66416  # mcp 1.19 -> 1.23; blocked by our `mcp<1.20.0` pin, not upstream

# --- Blocked by the fastapi pin in zenml's [server] extra. -----------------
# zenml pins `fastapi>=0.120.1,<0.121.0`, and fastapi 0.120.x in turn requires
# `starlette<0.50.0`. The fixes below all land in starlette 1.x, so they are
# unreachable until zenml widens its server-stack constraints.
PYSEC-2026-161  # starlette -> 1.0.1 (above fastapi's <0.50.0 ceiling)
CVE-2026-48817  # starlette -> 1.1.0 (above fastapi's <0.50.0 ceiling)
CVE-2026-48818  # starlette -> 1.1.0 (above fastapi's <0.50.0 ceiling)
CVE-2026-54282  # starlette -> 1.3.0 (above fastapi's <0.50.0 ceiling)
CVE-2026-54283  # starlette -> 1.3.1 (above fastapi's <0.50.0 ceiling)

# --- Reachable today; suppressed only until the starlette bump lands. ------
# Unlike the five above, these two are fixed *below* fastapi's <0.50.0 ceiling,
# so nothing upstream is blocking them: our lock is just stale at starlette
# 0.45.3. `uv lock --upgrade-package starlette` resolves to 0.49.3 and clears
# both. Delete these two entries as part of that bump.
CVE-2025-54121  # starlette 0.45 -> 0.47.2 (reachable; pending lock refresh)
CVE-2025-62727  # starlette 0.45 -> 0.49.1 (reachable; pending lock refresh)
