Skip to content

2026-10 Release Notes (Advance Notice)#

This document is an advance summary of the official release scheduled for October 14, 2026. The contents, dates, and names are subject to change.

Scanner update required

This release includes feature improvements that require a scanner update. If your scanner version is outdated, some features may not work correctly, so please update your scanner regularly.

Target Scanner Version Scan Execution Script
For Linux [NEW] vuls v0.41.0 Version: 2025/10
For Windows [NEW] vuls v0.41.0 Version: 2025/04
Trivy [NEW] v0.74.0 [NEW] Version: 2026/09

To keep lists responsive even in large environments, this release makes the group set CVE page load significantly faster. It also introduces pagination for the task and software lists, on-demand generation of task CSV reports from the latest data, and features for efficiently retrieving large amounts of data through the list APIs. Some changes affect list operations, displayed columns, and existing workflows. Check "Actions and Impact at a Glance" for the features you use.

Actions and Impact at a Glance#

These links cover changes that affect existing workflows. [Action Required] marks items that require changes to your operations or workflows. For the applicable conditions and required actions, see the linked sections.

Who Is Affected Items to Review
Users of task and software lists Pagination / Patch availability criteria
Users of task CSV reports CSV report generation / Patch availability criteria
FutureVuls API users Changes by API
Users of bulk scans [Action Required] Bulk scan changes and alternatives
Users who register or update server SBOMs via the FutureVuls API or Paste Import First-update precautions for existing SBOMs / Queuing for scans and SBOM registration
SBOM users Application SBOM detection coverage / SBOM management screen
Users of Windows or CPEs Vulnerability detection logic
Users who manage Linux servers through SBOMs or the Amazon Inspector integration Handling of EOL risks for OS packages
EOL supply chain risk users EOL deadline evaluation and reopening
Audit log users Logging of operations via the MCP Server
Special alert tag users Input fields and due date corrections
Role users Removal of the security requirements and task count displays
Users who update Lockfiles automatically with GitHub Actions [Action Required] Move of the GitHub Action

FutureVuls API Users#

API You Use Items to Review
List endpoints Total count calculation / [Advance Notice] Default use of the cached total count
Task and software retrieval Differential sync API (v2) / Timestamps / Patch availability criteria
CPE deletion Restrictions on which CPEs can be deleted
Server scans and SBOM registration or updates Queuing for scans and SBOM registration
Role retrieval Task count field removal
Group set CVE detail retrieval (organizations using English) Response changes

Important Notices#

[Action Required] Organization-Wide Bulk Scans Have Been Discontinued#

We have discontinued "Manual Scan of All Servers" in Organization Settings. This is because scanning every server in an organization at once can delay the processing of other customers' scan results. Going forward, use "Manual Scan of All Servers" in Group Settings.

Bulk scans run from Group Settings are now subject to the following limits.

  • Each run can cover up to 500 servers. You cannot run a bulk scan on a group that has more than 500 servers, so split it into smaller groups.
  • If a run targets more than 100 servers, it may take longer than before for all scan results to become available.

We previously recommended organization-wide bulk scans as a way to immediately scan all servers during the emergency response to the Next.js vulnerability in December 2025. Going forward, if you need to scan many servers at once in an emergency, call the FutureVuls API server scan endpoint (POST /v1/server/scan/{serverID}) for each target server.

Note that if you run server-level manual scans, paste scans, or SBOM registrations and updates in quick succession, they may be queued per organization, which can slow down responses. This includes the server scan API described above. With the FutureVuls API, processing continues even if a call times out while waiting in this queue. Do not resend the same request.

[Advance Notice] The FutureVuls API List Endpoints Will Use the Cached Total Count by Default (Planned for December 2026)#

To improve performance, we will change the default value of allowCachedCount from false to true in the release planned for December 2026. After the change, if you do not specify the parameter, a cached total count calculated up to 30 minutes earlier will be used for the second and subsequent pages (except the last page).

For details on allowCachedCount and exactCount, see "You Can Now Choose How the FutureVuls API List Endpoints Calculate the Total Count (totalCount)".

Behavior After the Change#

This change applies to requests to the CVE list, task list, software list, and deleted software list APIs that do not specify exactCount=false.

  • In responses for the second and subsequent pages (page of 2 or more, or offset of 1 or more), totalCount and totalPage may be values from up to 30 minutes earlier.
  • For the first page (page=1 and offset=0) and the last page, totalCount and totalPage remain the latest values, as before.
  • The retrieved data (the list contents) remains the latest, as before.

Required Actions#

Take the following actions depending on how you use the APIs.

Your Usage Required Action
You use totalCount or totalPage from responses for the second and subsequent pages as the latest count (for example, to aggregate or monitor counts, or to detect increases or decreases in the count while paging through results) Explicitly specify allowCachedCount=false before the change
You periodically retrieve all data with the v1 list APIs to replicate tasks and software to an external system Also consider using the "differential sync API (v2)". It does not use page numbers or the total count and continues from where the previous retrieval left off by using cursor, so it is not affected by how the total count is calculated
Other cases No action is required

Main Change: Faster List Screens and List APIs#

To keep lists responsive even in large environments, the CVE pages now load faster, and the task and software lists now use pagination. Pagination affects some displayed columns and how you use these lists. We have also changed task CSV reports to be generated on demand, and added features to the FutureVuls API for retrieving large amounts of data efficiently. In December 2026, we plan to make the list APIs use cached total counts by default. For details, see "The FutureVuls API List Endpoints Will Use the Cached Total Count by Default (Planned for December 2026)".

The Group Set CVE Page Now Loads Faster (Greater Gains for Larger Group Sets)#

We have addressed the slow loading of the CVE page for large group sets. The more tasks and CVEs a group set has, the greater the improvement.

As an example, see the following video comparing how the CVE page loads for a group set with about 500,000 tasks and about 60,000 CVEs (the top shows before the improvement, and the bottom shows after).

You can see that before the improvement, only about a quarter of all CVEs were loaded in 30 seconds, whereas after the improvement, all CVEs are loaded in about 30 seconds.

In addition, for even larger group sets, the approximate time to load all CVEs after the improvement is as follows.

Group set size (approx. number of servers) Time to load all CVEs (after the improvement)
About 1.5 million tasks and about 150,000 CVEs (about 1,000 servers) About 50 seconds
About 7.6 million tasks and about 170,000 CVEs (about 5,000 servers) About 1 minute 10 seconds

Note: These values were measured in our test environment. Actual times vary depending on the number of tasks and CVEs in the group set, and on your device and network.

The Group CVE Page Now Loads Faster#

We have addressed the slow loading of the CVE page for large groups. For example, for a group with about 1,000 servers, the time to load all CVEs has dropped from about 5 minutes to about 1 minute.

Note: These values were measured in our test environment. Actual times vary depending on the number of CVEs in the group.

Task and Software Lists Are Now Paginated#

To keep lists responsive even in large environments, the task lists and software lists for groups and group sets now display results page by page. The software list, which previously displayed only search results, now lists software as soon as you open the screen. You can export all software in a group at once with the "CSV Report".

  • Lists are loaded one page at a time, and clicking the next page button loads additional rows.
  • You can choose to display 30 to 1,000 rows per page.
  • Filters are applied to all rows, and only the matching rows are displayed.
  • You can bulk update all rows that match your filter conditions (up to 10,000 rows) at once.
  • You can sort by only one column at a time, and the available sort and filter conditions now vary by column.
  • The "Software Name" search box and "Conditions to Watch" at the top of the software list have been removed. Use the filter on each column instead.

Columns removed from the software list and other lists

The "Open Tasks", "Ongoing Tasks", "Completed Tasks", "All Tasks", and "Latest Detection Time" (shown as "Last Update" for groups) columns have been removed from the software list. The "OSS License Type" column has been merged into the filter for the "OSS License" column. The task count columns and the "Last Update" column have also been removed from the software lists in Server Details and CVE Details. For the task count columns in the role list, see "Removal of the role displays".

Task CSV Reports Are Now Generated On Demand from the Latest Data#

Task CSV reports, which previously provided data generated around 8:00 AM daily, are now generated on demand from the latest data.

From the "CSV Report" button menu in the group task list, select "Generate CSV Report (All Tasks in Group)" and start generation in the confirmation dialog; we notify you by email when the report is ready. You can then get the report from "Download Generated CSV Report" in the same menu.

Generate a report on first use and whenever you need the latest data

CSV reports generated daily before this release are not carried over. When you use the feature for the first time after the release, generate a report. "Download Generated CSV Report" does not regenerate the report; it contains the data as of the last generation. If you need the latest data, generate the report again.

You Can Now Export the Software List as CSV#

We have added a "CSV Report" button to the group "Software" tab. Now that the software list is paginated, use this button when you want to get all software in a group at once.

As with task CSV reports, select "Generate CSV Report (All Software in Group)" from the button menu to start generation; we notify you by email when the report is ready. You can then get the report from "Download Generated CSV Report" in the same menu. Filters and selections on the screen are not applied to the CSV report.

You Can Now Choose How the FutureVuls API List Endpoints Calculate the Total Count (totalCount)#

We have added the exactCount and allowCachedCount parameters to the FutureVuls API list endpoints, which let you choose how the total count (totalCount) in the response is calculated. When you retrieve large amounts of data page by page, you can speed up responses.

exactCount allowCachedCount Returned Total Count (totalCount) Recommended Use
true (default) false (default) The latest count, calculated every time When you always need the latest total count
true (default) true First page and last page: the latest count, calculated every time
Second and subsequent pages (except the last page): a count calculated up to 30 minutes earlier		 When you want to page through large amounts of data quickly
false (Ignored if specified) A count calculated every time, but capped at 100,000 When a rough total count is enough and you do not retrieve all data
  • You can specify exactCount in the task list, software list, and deleted software list APIs.
  • You can specify allowCachedCount in the CVE list APIs in addition to the above. Because the CVE list APIs do not have exactCount, they behave the same as the rows in the table where exactCount is true.

Added a Differential Sync API (v2) for Tasks and Software to the FutureVuls API#

We have added a differential sync API that lets you retrieve only the tasks and software that have changed since your last retrieval. Use it to replicate FutureVuls data to an external system and keep it in sync periodically.

  • Lists: GET /v2/tasks and GET /v2/softwares (Group API), GET /v2/groupSetTasks and GET /v2/groupSetSoftwares (Group Set API)
  • Counts: /count for each of the above (for example, GET /v2/tasks/count)

If you specify the nextCursor from a response as the cursor of your next request, retrieval continues from where the previous one left off.

Keep the following points in mind:

  • Deleted software is returned with deletedAt (except software deleted through some paths).
  • Deleted tasks and tasks that no longer match the filterStatus condition are not returned. Periodically retrieve all data again and reconcile it to keep your replica consistent.
  • If the group set configuration or the filter conditions change, 409 (sync_reset_required) is returned. Discard the cursor and retrieve everything again from the beginning.

In the FutureVuls API, Software and Task Timestamps Are Now Updated Only When Something Changes#

With the addition of the "differential sync API (v2)", we changed when the timestamps returned by the FutureVuls API (v1) are updated.

  • Scans and SBOM re-uploads that contain no changes no longer update the last updated time (updatedAt) of software and tasks. If you retrieve changes based on the last updated time, you may retrieve fewer items than before.
  • The CPE assignment time of software (cpeAssignedAt) is now updated only when the vendor or product of the assigned CPE changes, and is no longer updated by a version change alone.

New Features and Improvements#

You Can Now Manage Oracle Solaris Servers with Paste Scan (Beta)#

You can now register Oracle Solaris 10 / 11 (11.0 to 11.4) servers with paste scan. When you run commands on the server to obtain information such as the package list and paste the output into the FutureVuls console, FutureVuls detects vulnerabilities based on the vulnerability information published by Oracle.

  • For Solaris 11, FutureVuls determines whether a vulnerability has been fixed from the update level (such as an SRU) or the build date included in the version of the entire package (Java 8 and MySQL are evaluated by the version of each package)
  • For Solaris 10, FutureVuls detects vulnerabilities that may affect the installed packages. Because it does not determine whether they have been fixed, detection results remain even after you apply patches

Added the "Vulnerability Detection" Column to the Software List#

We have added the "Vulnerability Detection" column to the software lists of groups and group sets. It shows whether vulnerabilities in each piece of software can be detected, and you can also filter by this column. Use it to find software that needs a CPE assignment or review, or software in which vulnerabilities cannot be detected.

Display Description
CPE required Not detectable because the suggested CPE is not assigned
Review CPE The assigned CPE is deprecated or differs from the verified CPE, so the CPE needs to be reviewed
CPE required (Trivy) A package that Trivy excludes from detection. Assigning a CPE enables detection (shown only when scanned with trivy-to-vuls v0.41.0 or later)
No CVEs registered No CVEs are registered in the vulnerability database for the product of the assigned CPE
Not detectable There is no way to detect vulnerabilities (no suggested CPE either)
Detectable Vulnerabilities can be detected
Not evaluated The status has not been determined yet (it is determined at the next scan, SBOM import, or CPE change)

In addition, the "Assign CPE/PURL" tab of the software details now displays a warning according to the vulnerability detection status.

We have also added vulnDetectionStatus to the responses of the FutureVuls API software list endpoints (GET /v1/pkgCpes, GET /v1/deletedPkgCpes, GET /v1/groupSet/pkgCpes, and GET /v1/groupSet/deletedPkgCpes). Existing software is displayed as "Not evaluated" until its status is determined by a scan after this release (including scheduled scans), a CPE assignment, or a similar operation.

Superseded Windows KBs Are Now Consolidated Under the Latest KB#

In Windows, a newer update (KB) may supersede older KBs. The Advisory tab now displays only the latest KB in a supersedence chain, and you can check the superseded KBs under "Merged KBs" in Advisory Details. The update commands also target only the latest KB. For existing servers, this change is reflected after the next scan.

Windows KBs Not Listed in the Microsoft Update Catalog Are Now Displayed Separately#

For KBs that are not listed in the Microsoft Update Catalog, such as KBs delivered through hotpatching, we now display the support page URL instead of the catalog search URL and indicate that the KB may be a hotpatch. The update commands also display KBs not listed in the catalog separately.

Vulnerabilities in OS Packages Included in Application SBOMs Are Now Detected#

OS packages (rpm / deb / apk, etc.) included in Application SBOMs that you add to an SBOM server are now subject to vulnerability detection. In addition, you can now import Application SBOMs that do not specify an OS; their OS packages are imported as packages of the destination server's OS (previously, this resulted in an error). You can use this, for example, to register packages added later to a base device's SBOM as a separate SBOM. This applies only to SBOM servers whose OS has been identified.

A server can have only one version of each OS package with a given name. If you import or update an SBOM that contains an OS package with the same name as, but a different version from, an OS package in another SBOM on the server, an error occurs, and the conflicting package and the name of the other SBOM are displayed.

Imported contents are reflected in the detection results after the next day's scheduled scan or after a manual scan. On SBOM servers that already have Application SBOMs containing OS packages, more vulnerabilities may be detected in scans after this release.

You Can Now Export SBOMs Without Vulnerability Information#

We have added "Exclude vulnerabilities" to the "Download SBOM file" menu in Server Details and to the SBOM download menu that appears when you select multiple servers in the server list. In line with the approach of BSI TR-03183 and the CRA, you can create an SBOM for submission that contains no vulnerability information, without editing it by hand.

Vulnerability information (vulnerabilities in CycloneDX and advisory references in SPDX) and unapplied Windows KBs are excluded, while components, dependencies, CPEs / PURLs, and license information are output as before. -components-only is appended to the end of the file name. You can produce the same output with the FutureVuls API (GET /v1/server/{serverID}/sbom) by specifying excludeVulnerabilities=true.

You Can Now Import Manually Created SBOMs with the Tool Name "manual"#

If you specify manual in the SBOM's creation tool information, the tool name is now imported as "manual" instead of "Unknown". This lets you manage manually created SBOMs separately from SBOMs generated by tools.

You Can Now Import SBOMs Exported from OWASP Dependency-Track as an Officially Supported Tool#

Dependency-Track is an OWASP open source platform that centrally manages SBOMs generated by various tools.

In the FutureVuls SBOM import, SBOMs exported from Dependency-Track are now registered with the tool name "dependency-track".

Added the "SBOM" Sub-Tab to Server Details#

We have added the "SBOM" sub-tab to Server Details. You can view the SBOMs registered to the server as a list, and on each SBOM's details screen, you can check the type (Server SBOM / Application SBOM), SBOM specification, SBOM file format, SBOM tool, registration method, and included applications. Accordingly, "Registered SBOM File" on the "Details" sub-tab has been removed. Add SBOMs (with the "Add SBOM" button), download, update, and rename them from the "SBOM" sub-tab. Application SBOMs can also be deleted; Server SBOMs cannot.

Removed UUIDs from Application Names Derived from SBOMs and Added the "SBOM file name" Column#

The names of applications imported from SBOMs included the SBOM UUID, as in OS Application | ea36c8d1-…, but the UUID is no longer displayed. This applies to the application list and details, the software list and details, and the "Related Software" list in task details.

Instead of the UUID, you can now check which SBOM an item was imported from by its SBOM file name.

  • Application list: Added the "SBOM file name" column. Application details now include the "SBOM file name" field.
  • Software list: Added the "SBOM file name" column. In the group software list, you can filter by SBOM file name (partial match).
  • Software details (libraries): Added the "SBOM file name" field.

In the FutureVuls API, the values of the existing fields (location / path / name) do not change. In responses that include these fields, the API additionally returns, for data derived from SBOMs only, the name without the UUID (sbomAppName), the SBOM file name (sbomName), and the SBOM UUID (sbomUuid). In addition, when retrieving the lockfile list (GET /v1/lockfiles), you can now specify filterSbomUuid to filter by SBOM.

In the CSV report of the software list, location for rows derived from SBOMs is output as the name without the UUID, and the sbomName and sbomUuid columns are output at the end.

The Default SBOM File Name Is Now the Uploaded File Name#

When you upload an SBOM file from the screen to register a new SBOM, the default SBOM file name is now the name of the uploaded file instead of the <tool name>-<UUID> format. This applies to adding an application SBOM and to creating an SBOM server by uploading a file. If the file name exceeds 50 characters, the first 50 characters are used as the SBOM file name.

For SBOMs registered by pasting text or through AWS Inspector integration, the default SBOM file name remains unchanged. The names of already registered SBOMs do not change either.

We also fixed an issue where updating an SBOM by uploading a file reverted the SBOM file name to the <tool name>-<UUID> format, discarding a name you had changed. The SBOM file name no longer changes when you update an SBOM file. To use the new file name as the SBOM file name, change it with the rename button in SBOM Details.

SBOM Import Error Messages Now Indicate the Cause#

Errors that were uniformly displayed as "Failed to decode SBOM" when an SBOM import failed are now displayed as messages specific to the cause, such as missing generator tool information, an OS that cannot be identified, multiple OSes, an unsupported OS, an unsupported format, or a file that cannot be parsed. The messages also describe how to resolve the issue.

You Can Now Import SBOMs Whose OS Cannot Be Determined by Excluding OS Packages#

We have added the "Ignore OS information" checkbox to the SBOM import dialogs. When enabled, you can import an SBOM that contains OS packages (rpm / deb / apk, etc.) but no OS information, or an SBOM for an OS that FutureVuls does not support, by importing only the components other than OS packages. Previously, these SBOMs resulted in an error and could not be imported.

  • The checkbox is disabled by default. If you import with it disabled and the OS cannot be determined, an error occurs as before, and the error message guides you to this option
  • It takes effect only when the OS cannot be determined. For SBOMs whose OS can be determined, OS packages are imported as before even if the checkbox is enabled
  • OS packages that were not imported are not subject to vulnerability detection
  • If you import the SBOM as a Server SBOM, the server's OS becomes "Pseudo"

In the FutureVuls API, we have added ignoreOS to POST /v1/server/sbom, POST /v1/sbom, and PUT /v1/sbom/{sbomID}.

SSVC Priority Is Now Displayed at the Top of Task Details#

We have moved the SSVC Priority on the Task Details screen to the top of the screen, so you can see the response priority at a glance.

The Layout of Detail Pages Has Been Updated#

We have updated the layout of detail pages, such as the task, CVE, and server detail pages, to organize information more clearly.

You Can Now Retrieve the Last Comment via the Supply Chain Risk API#

The FutureVuls API endpoints that retrieve supply chain risks (GET /v1/supplyChainRisks and GET /v1/groupSet/supplyChainRisks) now return the body, author, and posting date and time of the last comment. The field names are lastUserCommentBody, lastUserCommentBy, lastUserCommentByName, and lastUserCommentedAt. These fields are not returned for supply chain risks that have no comments.

We also fixed an issue where a deleted comment continued to appear as the "Last Comment" on the supply chain risk screen and in the API after you deleted the latest comment.

MCP Server Access Is Now Distinguishable in the Audit Log#

FutureVuls API calls made via the MCP Server are now recorded in the audit log with the MCP: prefix on the endpoint name (for example, MCP:サーバ一覧), so they can be distinguished from normal API usage (for example, API:サーバ一覧). Entries for MCP Server access recorded before this release remain as API: and are not changed.

AI Summaries Are Now Also Displayed in English#

Vulnerability Summaries and Threat Information Summaries (AI summaries) are now generated in both Japanese and English. English summaries are displayed in the following cases.

  • Screen: when the display language is English
  • FutureVuls API: when the organization's language setting is English
  • Email notifications for Immediate task detection: when the recipient user views FutureVuls in English
  • Slack App notifications for Immediate task detection: when the organization's language setting is English

Summaries that have not been translated yet are displayed in Japanese. English translations will also be added to existing AI summaries on the day of the release.

Changes and Discontinuations of Existing Features#

This section covers changes to detection results, API responses, and displayed information, as well as discontinued features and services. Depending on how you use these features, you may need to take action, so please review the conditions and changes in each item.

We Have Revised the Vulnerability Detection Logic for Windows and CPE#

To improve detection accuracy, we have revised the vulnerability detection logic for Windows and CPE. As a result, detection results may change for some vulnerabilities.

Windows#

A vulnerability is now detected when it cannot be confirmed that the KB that fixes it has been applied. Previously, only vulnerabilities corresponding to KBs confirmed as not applied were detected. In addition, vulnerabilities that were not previously detected may now be detected in Microsoft Edge (now evaluated against the installed version) and in Microsoft products other than the OS, such as Teams and Visual Studio Code. On the other hand, vulnerabilities that have already been fixed by an applied cumulative update, and false positives caused by evaluating Microsoft Edge without considering its version, may no longer be detected.

CPE#

We discontinued approximate matching (fuzzy matching) that was performed when versions could not be compared strictly, reducing false positives. We also made it possible to correctly match versions that contain letters, such as OpenSSL 1.1.1n.

The FutureVuls API CPE Deletion Endpoints Can Now Delete Only Manually Registered CPEs#

We fixed an issue where specifying the ID of an OS package, library, or other software registered from a scan or an SBOM in the FutureVuls API CPE deletion endpoints (DELETE /v1/pkgCpe/cpe/{cpeID} and the deprecated DELETE /v1/pkgCpe/cpe) deleted that software along with its related tasks. From now on, specifying the ID of anything other than a manually registered CPE (software whose software type is Private Package) results in an error. You can still delete CPEs from the screen as before.

For Organizations Using English, the Group Set CVE Detail API Response Now Matches the Group CVE Detail API#

When the organization's language setting is English, the response of the FutureVuls API endpoint that retrieves group set CVE details (GET /v1/groupSet/cve/{cveID}) is now handled in the same way as that of the group CVE detail endpoint (GET /v1/cve/{cveID}).

  • For CVEs that have an English translation, the AI summaries (cveSummary and exploitationSummary) are returned in English.
  • JVN information (Japanese titles and descriptions) and JPCERT alerts are no longer included.
  • JVN scores are no longer considered for the maximum CVSS (cvss), so the value changes for CVEs whose highest score came from JVN.

Removed the "Target System Security Requirements" Setting and Task Count Columns from Roles#

As announced in the 2026-06 release, we have removed the "Target System Security Requirements" (CR, IR, and AR) setting from Role Details. This setting was not reflected in CVSS score, CVE Priority, or SSVC calculations, or in notifications.

We have also removed the CR, IR, and AR columns and the task count columns from the role list. The role list now shows the Role ID, Role Name, and Total Servers. For the FutureVuls API changes, see "Role endpoint field removal".

Removed the Task Count Fields from the FutureVuls API Role Endpoints#

We have removed the task count fields (newTaskCount and allTaskCount) from the responses of the FutureVuls API endpoints that retrieve the role list and role details (GET /v1/roles and GET /v1/role/{roleID}). If you reference these fields, specify filterRoleID in the task list API (GET /v1/tasks) and use the total count (totalCount) retrieved with the following conditions instead.

  • Instead of newTaskCount: set filterStatus to new and filterIgnore to true
  • Instead of allTaskCount: set filterStatus to all statuses (by default, filterStatus includes only new, investigating, and ongoing)

VulsDB Has Been Discontinued#

Due to low usage, we have discontinued "VulsDB" (https://cve.vuls.biz/), the website that summarized the detection conditions for each vulnerability.

[Action Required] The GitHub Action fvuls-lockfile-uploader Has Moved#

We have discontinued futurevuls/fvuls-lockfile-uploader, which automatically updates Lockfiles from GitHub Actions, and moved it to vuls-saas/fvuls-lockfile-uploader.

We Have Revised the Scope and Content of Vulnerability Summaries#

Vulnerability Summaries are no longer generated for CVEs for which NVD and vendors have not published a vulnerability description, such as rejected CVEs.

In addition, Vulnerability Summaries no longer include information that changes over time, such as EPSS and exploitation status. For the latest information, check "Threats & Exploitation" in the CVE Details.

These changes do not apply to summaries that have already been generated.

Bug Fixes#

Fixes that may affect existing data or statuses are listed first. Review the precautions for any fixes that apply to you.

Fixed an Issue Where the EOL Deadline Was Incorrectly Determined for Software Matching Multiple Support Cycles#

We fixed an issue where, when matching against EOL information from endoflife.date, the EOL deadline of a broader cycle was applied if the software version matched multiple support cycles. For example, .NET Framework 4.6.2 was evaluated with the EOL deadline of the 4.6 cycle (2022-04-26) instead of that of the 4.6.2 cycle (2027-01-12). The EOL deadline of the cycle that matches the version most specifically is now applied. The fix takes effect from the next scan (including SBOM updates). Servers that are not scanned and whose SBOMs are not updated keep the previous evaluation.

EOL supply chain risks are reopened when their evaluation changes

When the fix takes effect, the EOL supply chain risks of software whose evaluation changed are reopened with the new evaluation, and their status returns to NEW. Statuses you had changed, such as RISK_ACCEPTED, and the Primary Assignee, Scheduled Date, and Due Date settings are not carried over (the Primary Assignee is reset to the server assignee). Notifications for newly created risks are also sent. Risks are also reopened when only the matched cycle changes and the EOL deadline stays the same. Set the response policy for the affected risks again.

Fixed an Issue Where OS Package Detection Results Differed Depending on How the SBOM Was Registered#

We fixed an issue where, unlike SBOMs uploaded from the screen, CPEs / PURLs were not assigned to OS packages in SBOMs registered via the FutureVuls API or Paste Import. As a result, more vulnerabilities may be detected in SBOMs registered through these methods.

Precautions for the first update of affected existing SBOMs

For server SBOMs registered or updated through the FutureVuls API or Paste Import before this release, the fix takes effect on the first update after this release. OS packages are re-registered during this first update, so CPEs and tags manually assigned to OS packages are not carried over. Vulnerabilities are detected again during the same update. From the second update onward, information for unchanged OS packages is retained.

Fixed an Issue Where Due Dates of Special Alert Tags and Private CVEs Were Displayed as "1970-01-01", and Other Issues#

"Decision Date" is now a required field when you register or edit a special alert tag.

We fixed an issue where saving a special alert tag or a private CVE with an empty due date stored the due date as 1970-01-01, which was then displayed as "1970-01-01" on the screen, in notifications, and in daily reports. From now on, saving with an empty due date means no due date.

Correcting existing 1970-01-01 due dates

For special alert tags that already show 1970-01-01, the due date appears empty on the edit screen. If you change the decision date or another field and save the tag again, the due date is removed, including the due dates of the linked tasks.

We also fixed the following issues:

  • Simply saving a special alert tag again without changing its due date overwrote the due dates of tasks in the organization that have the same CVE (including manually set due dates) and added system comments
  • Deleting the milestone or due date of a PSIRT response did not add a history comment indicating the deletion

Fixed an Issue Where Linux OS Packages Were Detected as EOL Supply Chain Risks on Their Own#

We fixed an issue where, on Linux servers registered through SBOM import or the Amazon Inspector integration, OS packages (for example, python 2.7.18 on Amazon Linux 2) were detected as EOL supply chain risks separately from the OS itself. Because the support period of Linux OS packages follows the lifecycle of the OS itself, they are no longer detected individually. Affected risks that were already detected are automatically changed to CLOSED when the SBOM is updated (re-imported) or vuls scan results are uploaded for that server (including risks you had changed to RISK_ACCEPTED or another status), and a system comment explaining the reason is added. Servers integrated with Amazon Inspector are updated automatically by periodic synchronization, but for servers whose SBOM was uploaded manually, the risks remain OPEN until you update the SBOM. In that case, update the SBOM. Software registered as private EOL information and RHEL Application Streams are still detected as before.

Fixed an Issue Where the "Patch Availability" of Tasks Differed Depending on the Screen or Retrieval Method#

We unified the criteria for determining the "Patch Availability" of tasks across the screen, CSV reports, and the FutureVuls API. As a result, the display changes for some tasks. For example, tasks from the Amazon Inspector integration that were shown as "✓" even though no fixed version information was available are now shown as "❔".

Fixed an Issue Where Detection Results and Tags Temporarily Disappeared When Updating an SBOM#

We fixed an issue where, when an SBOM was updated via Paste Import or the FutureVuls API (PUT /v1/sbom/{sbomID}), the detection results, tags, and manually assigned CPEs of unchanged software temporarily disappeared. The information for unchanged software is now retained after the update.

For the first update of affected existing server SBOMs, review the "first-update precautions".

Fixed an Issue Where Registering a Large SBOM Resulted in a Timeout Error#

We fixed an issue where registering a large SBOM of tens of megabytes or more resulted in a timeout error (504).

Fixed an Issue Where Software with an Assigned CPE Was Displayed as "Auto" After Enabling "CPE Auto Assignment" Individually#

We fixed an issue where, when you enabled "CPE Auto Assignment" individually for software to which a CPE had been assigned manually, the CPE Assignment Type was displayed as "Auto". Software to which a CPE is already assigned is now excluded from automatic assignment, even if you enable it individually. We have restored existing data in this state to the manually assigned state.

Fixed an Issue Where the "Last Comment" in the Task List Did Not Match the Actual Comments#

We fixed an issue where the "Last Comment" column in the task list did not match the actual latest comment after a bulk update of tasks with a comment, a comment deletion, or a task copy to another group. Entries that were already out of sync have also been corrected. Tasks that still showed a "Last Comment" even though all of their comments had been deleted now show a blank "Last Comment".

Fixed an Issue Where the Operation Names of Some FutureVuls API Calls Were Recorded as Empty in the Audit Log#

We fixed an issue where the operation name was recorded as empty in the audit log for calls to 17 FutureVuls API endpoints, such as adding and deleting server tags, creating SBOM servers, running server scans, bulk updating tasks, and updating groups. Starting with calls made after this release, operation names such as API:サーバタグ追加 (add server tag) are recorded. Audit log entries that have already been recorded are not changed.

Fixed an Issue Where Slack / Teams Notifications Were Sent in Japanese Regardless of the Language Setting#

We fixed an issue where Slack / Teams notifications were sent in Japanese even when the organization's language setting was English. Slack / Teams notifications follow the organization's language setting, not each user's language setting.

If you have any questions, please contact our support team.