Skip to content
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

Open
ElectricNroff opened this issue Mar 3, 2025 · 3 comments
Open

in test, cannot search for CVE-2026-NNNN in late 2025 #3484

ElectricNroff opened this issue Mar 3, 2025 · 3 comments

Comments

@ElectricNroff
Copy link

const currentYear = new Date().getFullYear();
if (cveStartYear <= year && year <= currentYear) {
const normalizedCveId = `CVE-${year}-${id}`;
if (isSearch)
queryString.value = normalizedCveId;
else
cveId = normalizedCveId;
} else {
showHelpMessage(`CVE ID year must be within ${cveStartYear}-${currentYear}`);

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.

@rlxdev
Copy link
Collaborator

rlxdev commented Mar 3, 2025

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.

@ElectricNroff
Copy link
Author

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

@rlxdev
Copy link
Collaborator

rlxdev commented Mar 5, 2025

I've removed the code looking at CVE ID; not pursuing this further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Needs Triage
Development

No branches or pull requests

2 participants