Remove the nltk GHSA-8mgp-746c-j5xp dependency-review allowlist entry once nltk ships a fix
- Dominant language
- Python
- Stars
- 46.9k
- Forks
- 17.8k
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 472
Description
### What the workaround is
`.github/workflows/java-sdk-dependency-security.yml` now passes `allow-ghsas: GHSA-8mgp-746c-j5xp`
to `actions/dependency-review-action`, suppressing that one advisory.
### Why
[GHSA-8mgp-746c-j5xp](https://github.com/advisories/GHSA-8mgp-746c-j5xp) / CVE-2026-81726 (high,
CVSS 7.0) is a path-traversal in nltk's model-artifact APIs. **Every published nltk version is
affected** — the advisory range is `<= 3.10.3` and 3.10.3 is the newest release on PyPI, with no
patched version recorded. Upstream has fixes on `main` (nltk/nltk#3757, nltk/nltk#3759,
nltk/nltk#3813) but has not cut a release carrying them, so there is nothing to upgrade to.
nltk is not a dependency of Airflow. It arrives transitively through `llama-index-core`, which is
an optional `llamaindex` extra and a dev dependency of `providers/common/ai`. None of the affected
APIs (`TransitionParser.train` / `.parse`, `AveragedPerceptron.save` / `.load`,
`PerceptronTagger.save_to_json`, `save_maxent_params`) is reachable from Airflow code.
The job fires on any PR touching `java-sdk/**`, but `dependency-review-action` reviews the whole
repository dependency graph, so it also sees `uv.lock`. That is how a Python transitive dependency
ends up blocking the Java SDK check — most visibly on the 3.3.2rc1 sync PR (#72946), where
`uv.lock` moves nltk 3.10.0 → 3.10.3 and both versions are inside the advisory range.
### Follow-up work
- Watch for an nltk release above 3.10.3 that carries the fix.
- Bump nltk in `uv.lock` (it will come along with the next `llama-index-core` resolution) and drop
the `allow-ghsas` line plus the comment above it.
- Consider separately whether `java-sdk-dependency-security.yml` should review only the Java SDK's
dependency graph rather than the whole repository's — a Python lockfile change failing the Java
SDK gate is surprising, but the action has no path scoping today.
### Acceptance criteria
The `allow-ghsas` entry and its explanatory comment are removed from
`.github/workflows/java-sdk-dependency-security.yml`, and the "Reject vulnerable dependency changes"
job passes on a PR that touches both `java-sdk/**` and `uv.lock`.
---
Drafted-by: Claude Opus 5 (1M context) (no human review before posting)
Contributor guide
Research direction
Start by reading .github/workflows/java-sdk-dependency-security.yml and the nltk entries in uv.lock, then check whether nltk has released a version containing the referenced upstream fixes. Once the lockfile resolves above 3.10.3, remove the allow-ghsas entry and its comment, and verify the “Reject vulnerable dependency changes” job on a PR changing both java-sdk/** and uv.lock.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, python
- Domain
- ci-cd, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100