Results are sorted by CVE ID as text and capped at 10,000, so the newest records can't be reached; please add a sort option #178

Every page has to fall within the first 10,000 results, and the only sort order is cveMetadata.cveId.keyword ascending (searchQueryBuilder.js#L63-L69). Put those together and any query with more than 10,000 matches can't reach its highest IDs, which are usually the newest records.

An example

On 2026-10-12, cvssV3_1Metrics: "AV:N/AC:L/PR:N/UI:N" had 44,311 matches (checked against cvelistV5). The last record you can page to is CVE-2023-33871. That leaves 34,311 matches (77%) unreachable, including every CVE-2024-* through CVE-2026-* ID.

PR #156 will fix the totals for semantic searches, but it keeps this sort and the 10,000 window, so the same records stay out of reach. Ordinary searches have the same problem: cvssV3_1Severity: CRITICAL has 19,197 matches, and only the lowest 10,000 IDs can be paged to.

The sort is alphabetical by text, not numeric

curl -s -X POST https://search.cve.org/search -H 'Content-Type: application/json' \
  -d '{"cveIds":"CVE-2024-9999,CVE-2024-2000,CVE-2024-100000,CVE-2024-10000"}' | jq -r '.records[].cveMetadata.cveId'
# CVE-2024-10000
# CVE-2024-2000
# CVE-2024-9999

CVE-2024-100000 doesn't exist, so it's not returned. Four- and five-digit sequence numbers have been mixed every year since 2014, and six-digit ones exist now (for example, CVE-2026-109425). So most result sets come back in this order.

Suggestions

1. The most useful fix: a sort option (cveId, datePublished, dateUpdated, ascending or descending), or a public search_after cursor. dateUpdated descending is what people keeping a local copy in sync will want, and it keeps the newest records within reach.
2. Sort CVE IDs numerically by year and then sequence number, using numeric sub-fields or a zero-padded sort key.
3. Document the default order and how it interacts with the 10,000-result window.