Amazon Inspector v2 findings not closing after confirmed remediation and confirmed successful rescans (CVE-2026-45490, CVE-2026-45591) — reproducible across two separate accounts

Question 1: Why is it not being re-evaluated?

Amazon Inspector’s logic for closing findings works by cross-referencing the "list of currently installed packages" (collected via SSM Inventory scans) with the "vulnerable package name and version" associated with the finding; it automatically closes the finding once the specific vulnerable version is no longer detected. If the package identifier (vulnerablePackages) associated with the finding is empty from the start, there is no reference point for comparison. Consequently, even if subsequent scan cycles complete successfully, the system may be unable to determine that the issue has been "resolved," leaving it in a state where it can never be closed.

The fact that these are CVEs related to the .NET SDK or ASP.NET Core is also concerning. If these runtimes were installed via self-contained deployment or as binaries placed directly in the application directory—rather than through the OS package manager (e.g., yum, apt, or MSI)—a discrepancy may arise. While Inspector’s file-based signature detection might successfully identify the vulnerability, the SSM Inventory package management system might fail to correctly track version changes. This results in the finding being generated with an empty vulnerablePackages field.

Question 2: An empty vulnerablePackages array is abnormal.

Typically, findings of the PACKAGE_VULNERABILITY type include detailed information—such as the affected package name, version, and fixedInVersion (the version containing the fix)—within the packageVulnerabilityDetails.vulnerablePackages field. Looking at actual documentation examples, a log4j-core vulnerability would include specific details like name: "log4j-core", version: "2.14.1", and fixedInVersion: "2.15.0".

In short, the fact that vulnerablePackages is empty in your case represents a clearly abnormal data state. As you suspected, this empty array indicates that Inspector lacks the necessary reference point (i.e., the package version identifier) ​​to verify the remediation; this is highly likely the direct technical reason why the finding is not being closed. Response to Question 3: Suppression is not recommended, and there is no mechanism to force a re-evaluation.

Manual suppression is intended for "accepted risks" or "risks being addressed via other means"; using it for cases where an issue has actually been remediated but fails to close due to a system glitch is an inappropriate use of the feature. Furthermore, Inspector provides no official API or console operation to force the re-evaluation of a finding. The only way to trigger a closure determination is to wait for the results of the next scan cycle; the current situation is that the issue remains open despite the fact that the scan itself has already successfully completed.

Recommended Action

This issue should be escalated to AWS Support. Since the problem has been reproduced across two independent accounts and you have concrete technical evidence—specifically, that vulnerablePackages is showing an anomalous empty array—you have sufficient grounds to report a potential platform-level defect. Please include the following information in your support case:

• The relevant Finding ARNs for both accounts
• A list of affected instances, including i-0c4313cee1c233aa1
• The output of list-findings (specifically highlighting the empty vulnerablePackages field)
• The timestamp of the remediation and the timestamp confirming the subsequent successful re-scan
• The specific CVE IDs: CVE-2026-45490 and CVE-2026-45591