Security: idna 3.11 vulnerable to DoS (GHSA-65pc-fj4g-8rjx) #33

New issue

Closed

opened 2026-05-23 21:28:14 +00:00 by coding-agent-marvin8 · 1 comment

coding-agent-marvin8 commented

2026-05-23 21:28:14 +00:00

(Migrated from codeberg.org)

The installed version of idna (3.11, transitive via httpx and anyio) is affected by GHSA-65pc-fj4g-8rjx, an incomplete fix for CVE-2024-3651.

Specially crafted inputs such as "٠" * N cause idna.encode() to consume significant CPU resources before the length check fires, leading to a denial-of-service condition. The fix is available in idna 3.15, which rejects long inputs as early as possible.

Detected by nox -s pysentry.

The installed version of `idna` (3.11, transitive via `httpx` and `anyio`) is affected by GHSA-65pc-fj4g-8rjx, an incomplete fix for CVE-2024-3651. Specially crafted inputs such as `"٠" * N` cause `idna.encode()` to consume significant CPU resources before the length check fires, leading to a denial-of-service condition. The fix is available in `idna` 3.15, which rejects long inputs as early as possible. Detected by `nox -s pysentry`.

coding-agent-marvin8 commented

2026-05-23 21:56:49 +00:00

(Migrated from codeberg.org)

Findings:

`idna` 3.11 is pulled in transitively by both `httpx 0.28.1` and `anyio 4.13.0`; neither places an upper bound on `idna`, so bumping is safe.
No direct usage of `idna` in fedinesia source — this is a pure transitive dep bump.
`httpx~=0.28.1` (pinned in `pyproject.toml`) is compatible with `idna>=3.15`.

Plan of attack:

Add a `[tool.uv]` section to `pyproject.toml` with `constraint-dependencies = ["idna>=3.15"]` — forces the resolver to pick `idna>=3.15` without adding it as a direct project dependency.
Regenerate `uv.lock` via `uv lock`.
Verify with `nox -s pysentry` (expect clean scan).
Commit, push, open PR targeting `main`.

Branch: `fix/idna-ghsa-65pc-fj4g-8rjx`

**Findings:** - \`idna\` 3.11 is pulled in transitively by both \`httpx 0.28.1\` and \`anyio 4.13.0\`; neither places an upper bound on \`idna\`, so bumping is safe. - No direct usage of \`idna\` in fedinesia source — this is a pure transitive dep bump. - \`httpx~=0.28.1\` (pinned in \`pyproject.toml\`) is compatible with \`idna>=3.15\`. **Plan of attack:** 1. Add a \`[tool.uv]\` section to \`pyproject.toml\` with \`constraint-dependencies = ["idna>=3.15"]\` — forces the resolver to pick \`idna>=3.15\` without adding it as a direct project dependency. 2. Regenerate \`uv.lock\` via \`uv lock\`. 3. Verify with \`nox -s pysentry\` (expect clean scan). 4. Commit, push, open PR targeting \`main\`. Branch: \`fix/idna-ghsa-65pc-fj4g-8rjx\`