-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
in test, cannot search for CVE-2026-NNNN in late 2025 #3484
Comments
I'd still like to do a check for "reasonable-ness" of the date within the CVE ID. If I check for 1999 or after, and the current year plus 1 (2026) - is that a reasonable check to do? I want to catch obvious problems without preventing a valid CVE ID from being used in the search. It seems like if I use the following year, it should catch the "corner" cases and still provide a reasonable check for the date. |
We would have to track down where the requirement for reasonable-ness came from. The cve-website repository code is supposed to work for both the production and test servers. CVE IDs may exist on the test server that are not reasonable in production. In my view, the test.cve.org website needs to be able to render whatever CVE IDs happen to exist in the test server database, which currently includes https://cveawg-test.mitre.org/api/cve-id/CVE-0000-20001 |
I've removed the code looking at CVE ID; not pursuing this further. |
cve-website/src/components/cveRecordSearchModule.vue
Lines 167 to 176 in a96cce9
getFullYear() is the year in the local time zone of the client's web browser. There can realistically be published CVE-2026-NNNN CVE Records before the local year is 2026 in some relevant locations (e.g., Hawaii). Also, there can be reserved CVE-2026-NNNN CVE IDs as early as October 2025.
The text was updated successfully, but these errors were encountered: