Published repository advisories not appearing in the Advisory Database after 10-13 days

Open
#9,152 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Tech stack
github

Research direction

Start with the listed GET /advisories API queries and the corresponding web UI searches, then compare the four repository advisories with the control advisories and the behavior described in #9025. Determine whether the missing entries are caused by curation timing, package mappings, CVE requests, or another indexing step; done means the cause and expected maintainer action are established.

Written by the indexing model from the issue text.

Description

A question about how published repository advisories reach this database, with four concrete examples. I may well be misunderstanding the intended flow — happy to be told this is expected.

Four repository advisories I am credited on were published by their maintainers between 4 and 13 August. All four are live and public on their repos. None appear in the Advisory Database.

advisory package ecosystem published
GHSA-x6wm-3hvg-6pqh webdav-server npm 2026-08-04
GHSA-6gvx-vjgp-49x3 url-sheriff npm 2026-08-07
GHSA-pv2m-3wr7-9vp8 is-local-address npm 2026-08-13
GHSA-58r7-5cr4-4ffr tarsafe pip 2026-08-13

All four queries come back empty:

GET /advisories?ecosystem=npm&affects=webdav-server      -> []
GET /advisories?ecosystem=npm&affects=url-sheriff        -> []
GET /advisories?ecosystem=npm&affects=is-local-address   -> []
GET /advisories?ecosystem=pip&affects=tarsafe            -> []

Two controls, to show the query itself is fine:

GET /advisories?ecosystem=npm&affects=extract-zip  -> GHSA-jmr9-qjv8-65gv
GET /advisories?ecosystem=npm&affects=ssrfcheck    -> 3 advisories

Searching the web UI directly (/advisories?query=webdav-server, ?query=tarsafe) also returns only unrelated keyword matches, no advisory for those packages.

It also does not look like a general backlog — repository-sourced advisories published between 14 and 17 August are already present, e.g. GHSA-m44r-7c5h-m6mj, GHSA-ggr8-5vv4-36mx, GHSA-76pc-mqxp-3rq5. The four above are 4 to 13 days older than those.

On each of the four, the advisory form has the package name, ecosystem, affected version range and patched version filled in, so as far as I can tell there is nothing missing that would prevent a package mapping.

Questions
  1. Is there a step the maintainer or reporter needs to take beyond publishing the repository advisory?
  2. Is 10-13 days inside the normal curation window? The docs say every repository advisory is reviewed "for consideration" as a global advisory, which I read as meaning promotion is not automatic — I would just like to understand what makes the difference.
  3. Does requesting a CVE affect whether or when an advisory is curated? Three of the four have a CVE request lodged; GHSA-58r7-5cr4-4ffr (tarsafe) does not, and I would like to know whether that matters so I can advise the maintainer correctly.
Why it matters

Until an advisory is in this database, npm audit, pip audit and Dependabot do not surface it, so people running the affected versions get no signal even though the advisory is fully public. tarsafe alone is around 376k downloads/month and webdav-server around 27k/week.

This is the same shape as an issue I contributed a fix for in #9025, where an advisory existed with an empty affected array and therefore mapped to no package, leaving everything keyed on package mappings silent. I am not claiming that is the cause here — the mappings look populated — but the user-visible effect is identical.

Happy to open separate per-advisory issues instead if that is the preferred format, or to provide anything else useful. Thanks for maintaining this.

Dominant language
No language data
Stars
2.5k
Forks
772
Avg merge
3d 18h
Merged PRs (30d)
48

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/advisory-database

All issues in github/advisory-database

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.