Software vuln detected dates do not match between screens

[RachelElysia]

Fleet version:

Web browser and operating system:

---

💥  Actual behavior

https://github.com/user-attachments/assets/2927ea40-4477-4a09-a393-e1583a85cb75

🧑‍💻  Steps to reproduce

1. Go to dogfood CVE details page https://dogfood.fleetdm.com/software/vulnerabilities/CVE-2025-24162 and note the detected date
2. Go to dogfood vulnerabilities table page https://dogfood.fleetdm.com/software/vulnerabilities?exploit=false&query=CVE-2025-24162&order_direction=desc&order_key=hosts_count&page=0 and note the detected date

🕯️ More info (optional)

N/A

Detected date on software vuln table should match detected date in details

[mostlikelee]

Hey team! Please add your planning poker estimate with Zenhub @iansltx @jahzielv @ksykulev

[iansltx]

I'm not able to repro this (wanted to check what was going on prior to throwing an estimate on). Both places have the same timestamp returned from the API (Jan 28 ~6:40a UTC), and both show the expected "one month ago" in the UI.

Maybe we close this and if anyone sees this again we reopen?

[mostlikelee]

Maybe we close this and if anyone sees this again we reopen?

i'm onboard with this, unless @RachelElysia has any other info that may get us into this state

[iansltx]

Per Slack, @jmwatts has a repro.

[iansltx]

@jmwatts Can you grab your vulnerabilities table and confirm which created_at timestamp is the correct one? This feels like a join is propagating things across a bunch of columns where it shouldn't be, so I'm assuming that the individual CVE page is correct and the list is wrong, but want to make sure.

[jmwatts]

There's a lot in that table :D so here's one example but let me know if you need more than this

[iansltx]

This is useful; thanks!

Looks like we may have at least two bugs here. In the case you showed, the list view is correct but the individual vuln view shows detected as the current timestamp (though this seems to vary from vuln to vuln). In Rachel's example though both places have different values, both of which aren't the current timestamp. So we might need to scope this as "fix the bugs that we can repro", which won't necessarily be the original bug.

[RachelElysia]

Here's one example that is showing detected as a minute ago, but the table view of vulns shows another time:

details view https://dogfood.fleetdm.com/software/vulnerabilities/CVE-2025-0938 table view of vulns https://dogfood.fleetdm.com/software/vulnerabilities?exploit=false&query=CVE-2025-0938&order_direction=desc&order_key=hosts_count&page=0

[rachaelshaw]

I haven't seen this issue exactly, but was about to report a similar issue: currently, every CVE detail page is saying detected "less than a minute ago"; In the API response, created_at always seems to be set to the current time. (List view is fine, only seeing this w/ GET /vulnerabilities/:cve).

@RachelElysia do you think this is related, or should I report that bug seperately?

[iansltx]

@rachaelshaw The one you're seeing is the one I mentioned. Thinking we'll resolve that one with this ticket and see if we can repro the other one afterward.

[jmwatts]

QA Notes

Go to CVE details page (ex: /software/vulnerabilities/CVE-2025-24162) and note the detected date Go to vulnerabilities table page (ex: /software/vulnerabilities?exploit=false&query=CVE-2025-24162&order_direction=desc&order_key=hosts_count&page=0) and note the detected date

• [x] Detected date on software vuln table should match detected date in details
• [x] Check multiple CVEs

[fleet-release]

Mismatched dates sow doubt, Synced, trust in Fleet sprouts out. Cloud city stands stout.