docs(ci): regroup CVE-2025-15366 from Group B to Group A — the imaplib backport landed on 3.14 - #100

Summary

Group B's waiver rationale — upstream declined the backport to 3.10–3.14, so these are fixed only
in 3.15+ — is no longer true of CVE-2025-15366. The imaplib fix is on the 3.14 and 3.13
maintenance branches. It moves to Group A with the 3.14.7 trigger; Group B becomes CVE-2025-15367
(poplib) alone.

No CVE is un-waived. The list stays at four entries — three in Group A, one in Group B.

Configuration and documentation only.

Stacked on #99. This PR is based on claude/group-a-cve-waivers-3.14-uw1xh1, not dev,
because it edits the same Group A comment block #99 rewrites — a dev-based branch would either
conflict on merge or duplicate #99's diff. Retarget this PR to dev as soon as #99 merges,
per CLAUDE.md § Git & PR conventions. #99 itself is untouched.

Evidence

Checked at the source per CLAUDE.md § Dependency hygiene — Lib/imaplib.py and Lib/poplib.py
fetched from four refs and compared:

imaplib (CVE-2025-15366) — 3.14 defines _control_chars = re.compile(b'[\x00\r\n]') and
raises ValueError("NUL, CR and LF not allowed in commands") in IMAP4._command(). Upstream
gh-143921; 3.14 backport python/cpython#153137, commit 2981822, merged 2026-07-07; 3.13
backport python/cpython#153287, commit 71926d9. The NEWS entry
Misc/NEWS.d/next/Security/2026-01-16-11-41-06.gh-issue-143921.AeCOor.rst is present on 3.14/3.13
and 404s on v3.14.6 — still under next/, so it ships in 3.14.7 and has shipped in nothing.

poplib (CVE-2025-15367) — guard on main only; gh-143923 lists one PR (python/cpython#143924,
b234a2b, 2026-01-20) and no backport against any maintenance branch. Unchanged.

Why the companion fixes diverged. The original imaplib fix (python/cpython#143922) rejected
all control characters, and that breadth is what drew the regression concern behind the original
no-backport decision. python/cpython#153067 narrowed the check to NUL/CR/LF — other control
characters are legal in quoted strings and are sent quoted — and it is the narrowed version that
was backported. poplib's fix still rejects the full [\x00-\x1F\x7F] range with no equivalent
narrowing. They were never going to move together, despite the identical stated reasoning in our own
record.

On the 2026-07-25 §14 entry

Superseded for CVE-2025-15366 only, and left unedited. Its reading was correct and is not
retracted — it verified 3.14.6, and 3.14.6 genuinely lacks both guards; still true. What does
not survive is the generalisation drawn from it ("no 3.14.x point release will ever clear them").
The honest chronology: the imaplib backport merged 2026-07-07, 18 days before that entry was
written — the claim was already stale when recorded, not overtaken afterwards. The check read the
released tag and concluded something about the maintenance branch, which a tag cannot answer.

That is the narrow lesson, since "verify at the source" was already the rule and was followed:
a claim that a fix will never arrive on a line is a claim about the branch; only a claim about
what ships today can be settled from a tag.

What changed

ci/grype.yaml

• CVE-2025-15366 moved into the Group A list; the imaplib backport added to Group A's
  source-verification block.
• Group B rewritten for poplib alone, with its own source-verification lines, the divergence
  explanation, and CVE-2025-15367 (poplib) — accepted risk on any interpreter below 3.15 #52 as its tracker.
• Group B's standing-acceptance framing, annual review date (2027-07-25), and the explicit
  "do not scope a 3.15 move as a reaction to this" instruction are carried over unchanged — the
  acceptance was not re-opened, only its membership.

docs/ARCHIVE.md

• Dated §14 entry (2026-07-26) carrying the full evidence above.

Related

• docs(ci): re-verify Group A interpreter CVEs on 3.14 and re-point waivers at #98 #99 — Group A re-verification (parent of this PR).
• Group A CPython interpreter CVEs on 3.14 — accepted risk until the next 3.14.x point release #98 — Group A tracker; updated to cover CVE-2025-15366 as a third entry.
• CVE-2025-15367 (poplib) — accepted risk on any interpreter below 3.15 #52 — re-scoped to CVE-2025-15367 only; its follow-up checkboxes are ticked by this PR.