Request a CVE for GHSA-rggj-c47j-46v9

[indigo423]

GHSA-rggj-c47j-46v9 is published and its patched_versions is set to 0.8.0, so the disclosure itself is complete. No CVE has been requested: the advisory still reports cve: none.

GitHub can assign one as a CNA from the advisory page ("Request CVE"), which makes the issue citable outside GitHub and picks it up in downstream vulnerability databases and SCA tooling.

Worth deciding rather than leaving implicit. Either request it, or note on the advisory that a CVE is deliberately not being sought.

Filed while archiving the bound-flow-session-state change, whose task 7.3 covered coordinating this. That change lives under openspec/, which is gitignored, so the task would not have survived the archive.

Related: #480.

[indigo423]

CVE requested. POST /repos/Riptide-Labs/riptide/security-advisories/GHSA-rggj-c47j-46v9/cve accepted; assignment is asynchronous, so cve_id is still null and nothing has changed on the advisory yet.

The decision was more consequential than "citability"

Looking into it turned up something that changes why this matters. The advisory is not in the global GitHub Advisory Database:

$ gh api /advisories/GHSA-rggj-c47j-46v9
404 Not Found

$ curl https://api.osv.dev/v1/vulns/GHSA-rggj-c47j-46v9
{"code": 5, "message": "Vulnerability not found"}

It is published, but repository-local. The chain that makes a disclosure reach anyone:

repo advisory, published          <- riptide was here
        |
        |  requires GitHub review to promote
        v
global GitHub Advisory Database   <- 404
        |
        v
OSV.dev                           <- not found
        |
        v
Dependabot / Trivy / Grype / SCA  <- nothing

So for a year this has been a page on the security tab that no tooling could see. Requesting a CVE routes it through GitHub's CNA review, and that review is what promotes it — the CVE and the reach are the same action, not two.

A hypothesis that turned out wrong, recorded so it is not retried

The advisory names maven / org.riptide.flows:riptide-flows, and that coordinate does not exist on Maven Central (numFound=0). The obvious guess is that the bad coordinate is why OSV is empty. It is not — the cause is that the advisory was never globally reviewed. Correcting the coordinate would have changed nothing.

The coordinate is still slightly wrong: riptide is a daemon shipped as a container image, DEB, RPM and jar, not a library anyone depends on. But GitHub's advisory ecosystems have no OCI, deb or rpm option, and other propagates worse than maven. Leaving it as-is is the least-wrong choice GitHub offers, and after promotion the realistic reach is CVE-in-NVD picked up by container scanners, which does not depend on the Maven match.

Closing condition

Not done yet. Close this when:

gh api /advisories/GHSA-rggj-c47j-46v9 --jq '{cve_id, type}'

returns a cve_id and type: reviewed rather than 404. GitHub's CNA review can take weeks.

If the request is declined, the honest follow-up is a note on the advisory saying so, since otherwise it reads as a complete disclosure while reaching nobody.

[indigo423]

Status: CVE requested, awaiting assignment.

Recording the state so the next person to look does not re-derive it. Nothing is blocked on us; this is waiting on CNA review.

Worth remembering while it waits: a repository advisory published with cve: none is not in the global advisory database or in OSV. It is visible on the repo's Security tab and nowhere a scanner looks. Consumers running osv-scanner, Dependabot or Scorecard against riptide will not see this advisory until review promotes it and an identifier is assigned.

[indigo423]

Status re-checked; postponed is still correct and there is no maintainer action available.

The advisory is state: published with cve_id: null, and GET /advisories/GHSA-rggj-c47j-46v9 still returns 404 — so it is not in the global database, OSV, or any scanner that reads them. A published repository advisory is not a published global one until CNA review promotes it. Requested 2026-08-25; assignment is asynchronous and the blocker is entirely on GitHub's side.

Worth adding: GHSA-pp6f-jcpf-7v73 sits in the identical state — published, no CVE, 404 globally — and this issue does not mention it. Whatever happens to the request here should cover both, or the second one gets forgotten.