apache / apache/airflow

Remove the nltk GHSA-8mgp-746c-j5xp dependency-review allowlist entry once nltk ships a fix

Open
#73,049 1 comment 0 reactions 0 assignees View on GitHub
area:dev-tools kind:meta
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.