AIfrontier home

Security information centre

Find the vulnerabilities. Read the trend. Decide what to patch.

Japanese edition: セキュリティ情報センター

Data basis: 2026年11月9日14:15:00 JST. Web v98 and the 26th edition use the same dataset and the same charts. NVD retrieved 2026-11-09T05:29:57.864Z – 2026-11-09T05:33:05.453Z (UTC). KEV catalog retrieved 2026-11-09T05:25:36.091Z.

High-severity CVE list

8,615 CVEs are searchable. 1,607 rated CVSS 9.0 or above; 17 are on CISA KEV inside the window. These are not counts of vulnerabilities in this site.

Open the CVE list, search and CSV export (Japanese UI)

Published inside the window and rated 7.0 or above on the maximum of CVSS v3.x / v4.0. Scoring versions and sources are mixed. These are not occurrence dates, nor a count of what affects your own environment.

The data in charts

Severity distribution of the listed CVEs

Open the chart full size

Fix information: machine classification

Open the chart full size

Monthly series cover January 2024 to November 2026 by UTC calendar month. Total CVEs exclude Rejected; KEV is grouped by the addition date in the current catalog. November 2026 is a partial month (white marker). The monthly high-severity series is unavailable for all 35 months — missing, not zero, and omitted from the charts. Past months are recomputed as of today, not saved snapshots.

KEV additions over time

KEV additions, 2024-01 to 2026-11
Same image and numbers as the PDF. Partial months and missing series are distinguished from complete ones.

Open the chart full size

CVE publications over time

CVE publications, 2024-01 to 2026-11
Same image and numbers as the PDF. Partial months and missing series are distinguished from complete ones.

Open the chart full size

Incident statistics

Ransomware reports
Same image and numbers as the PDF. Partial months and missing series are distinguished from complete ones.

Open the chart full size

Reports

Site check tool

Checks the response headers and HTML traces of a public page. It is an outside view only and does not guarantee internal configuration or the absence of compromise.

Open the site check tool (Japanese) →

AI incidents, breaches and attacks

Incidents, data leaks and attacks involving AI are tracked on a separate page.

Open the AI incident watch →

From fearing AI to reducing harm

Separate attacker from defender, and learn conditionally from the measures that actually reduced harm.

Why it feels so loud

Real damage exists; disclosures are increasing and arriving sooner; attackers using AI have appeared. Overlapping does not mean one cause. Evaluate AI use and the root cause of the damage separately, and do not equate more disclosure or more discovery with deterioration.

Do not stop at "be careful" — spread safe defaults

Instead of relying on warnings, make authentication, updates and recovery easier on the service side. That also reduces the burden of telling good from bad on the user.

Share what worked, with conditions

Learn from cases where harm was reduced, together with the scope, period and measures. The fall in fraudulent securities-account trades cited in the source material is not attributed to AI or passkeys alone.

Change the measure to harm and recovery

Weight actual loss, downtime and time to recovery. Do not score more disclosure or more discovery as deterioration.

This section follows the source paper "From fearing AI to reducing harm" (research date 31 October 2026). The cases and sources it cites have not been independently re-verified for this edition. Read the source PDF (Japanese)

There is no need to speak of the danger as small. Do not speak of our capacity to respond as small either.

Rather than blame AI, reduce the conditions that let an attack succeed.