00 / Current status
Classification and evidence method
Methodology version: 2026-10-16.
Offline shadow evaluator: implemented. It checks saved candidates and evidence without publishing records or sending alerts. Missing or contradictory evidence keeps a candidate isolated.
Production automatic release: not enabled. A passing shadow result is a simulation, not permission to publish. The new five-gate workflow has not been retroactively applied to every existing public record. Read each record's sources and verification dates; this page is not a verification badge for that record.
01 / Prioritization
AIVirusDB Risk Score v1
The score is a 0–100 prioritization aid, not a prediction and not a substitute for environment-specific risk assessment. It combines severity, observed exploitation, evidence confidence, disclosure recency, patch availability, and ecosystem scope.
Critical, high, medium, low, or informational.
Confirmed, credible activity, no known activity, or unknown. Unknown means in-the-wild exploitation has not been confirmed; it does not mean no known activity.
How directly and independently the evidence supports the claim.
More recent disclosures receive greater response priority.
Unpatched exposure receives greater weight.
Signals spanning multiple ecosystems receive greater weight.
Scores are capped at 100. Equal scores are ordered by the latest verified update and then by stable record ID. Formula changes require a new score version.
Unknown confidence and unknown exploitation each contribute zero points. Missing evidence does not imply safety or independent reproduction.
02 / Classification
Classify the behavior, not just the name
Product and ecosystem labels identify context; vulnerability types and attack techniques describe the reported behavior. A mention of MCP alone does not establish an MCP attack. A normal tool capability is not, by itself, a vulnerability.
Records can carry multiple supported classifications. Missing evidence remains unknown, and unsupported model suggestions are not confirmed findings. A shared tag does not prove that two incidents are the same vulnerability or form an attack chain.
The current classification dictionary includes legacy product-specific categories. The new review policy separates product identity from attack claims; those legacy labels are not proof that an ecosystem caused an attack.
OWASP and MITRE ATLAS references are versioned analytical mappings, not certifications or guarantees of compliance. See the standards crosswalk.
03 / Evidence
Confidence levels
- Confirmed
- An official advisory, primary maintainer statement, or independently reproducible public evidence supports the record.
- High
- Multiple credible sources agree and the key technical facts are consistent.
- Medium
- A credible source exists, but important details still need confirmation.
- Low
- An early signal worth monitoring. It must not be presented as a confirmed incident.
- Unknown
- Confidence has not been assessed. This is not a low-confidence assessment or confirmation of the source's claims.
What the evidence establishes
- Source-reported
- An identified advisory or report makes the claim. This does not mean AIVirusDB reproduced the attack.
- Model-inferred
- A classification or relationship proposed by a model. It remains a candidate until supporting evidence is reviewed; confidence alone cannot confirm it.
- Independently reproduced
- AIVirusDB has a documented, authorized test with an environment, component version, trace and observable result. Do not infer this status from a score or a source's own test.
These evidence bases are distinct from the confidence labels above. Suspicious content, a reproduced boundary breach and demonstrated impact are different findings. A malicious-looking instruction does not prove an agent executed it.
Our new review policy requires support for each important field and relationship, tied to a source version and applicable package or environment. The offline evaluator checks a limited subset; semantic and graph claims without adequate support remain unknown. Complete field-by-field evidence views are not yet available for every public record.
04 / Scanner evidence
Independent signals, not automatic verdicts
AIVirusDB uses NVIDIA SkillSpector in static-only mode to produce bounded candidate evidence for public AI Agent and MCP skill repositories. Scanner scores and rule matches help prioritize review; they do not establish successful exploitation. Behavior, provenance and classification need separate supporting evidence.
A SkillSpector result never publishes a threat record or creates a defensive signature by itself. Raw source excerpts remain isolated from the public index, and standards mappings remain candidates until the underlying evidence is reviewed.
05 / Review policy
Five checks, no compensating scores
- Identity and freshness: match the advisory, package and applicable versions; distinguish successful source checks from failures and explicit withdrawal.
- Evidence and classification: check whether evidence supports each required claim in its stated scope.
- Safety and format: validate the candidate structure and check for sensitive or unsafe output. Source instructions are data, not commands to execute.
- Rights: require an applicable permission record for the source, intended use, content scope and distribution channel.
- Approval and scope: bind the decision to the reviewed version and the separately authorized action.
Each check returns pass, fail or unknown. Unknown is not a pass, and one strong score cannot compensate for another failed check. The offline evaluator can consult saved evidence in a bounded pass; it does not fetch new evidence or ask models to vote. Unresolved candidates stay unpublished.
This is the review policy and its limited offline implementation, not an active automatic publishing service. Production authorization and release-time checks still need completion. Publication, member alerts and security testing require separate authorization. Historical archive-only records do not trigger member alerts.
06 / Safety
Public disclosure boundary
AIVirusDB publishes defensive summaries, affected versions, remediation, classification, and source links. It does not publish live credentials, complete weaponized payloads, or actionable details for an unpatched issue when disclosure would create disproportionate risk.
Credential masking, safe rendering and not executing source content are separate controls. Defanging does not guarantee that every prompt is harmless or that all sensitive data has been detected.
07 / Accountability
Corrections and provenance
Every public record needs at least one HTTPS source and a verification timestamp. Corrections preserve the stable record ID, update the public timeline, and identify the evidence that changed the assessment.
Source publication, source updates, retrieval and successful verification are different dates. An old advisory can still apply; a failed lookup or 404 does not establish that an advisory was withdrawn. New evidence can change a classification or require a correction or withdrawal review.
The homepage's latest record verification is the most recent verification timestamp among published records, not a full-database recheck. Citation retrieval dates are separate from the collection pipeline's last successful check. Where no collection-run evidence is connected to the public page, collection check time and health remain Unknown; this does not assert a failure or a successful run.
Report an unsupported classification, incorrect version, rights concern or withdrawal request to security@aivirusdb.com. Include the public record URL and supporting source links. Do not send credentials, personal data or live exploit payloads. A report starts a review; it does not automatically change the public record.