Vulnerability Scoring Calculator — Vendor / PSIRT Security Engineer

Default is Critical. Each gate may reduce it; risk floors can veto the reduction. Every default can be overridden by the SE — the calculator proposes, the engineer decides and signs off.

1 · Behavior base

—

2 · Exploit level

—

3 · Auth context

—

4 · Risk floor

—

Vendor score

—

Behavior — what actions the exploit can do (CIA violation)

GATE 1 · BASE SEVERITY

Pick the demonstrated behavior. This sets the base severity and the publication impact row.

Compute Install / code execution default Critical Tamper with system / configs default Critical Read configs / system state default Critical

Data — CRUD @ data type CRUD on PII default Critical CRUD on system data default High CRUD on service data default High

Service Service down default Critical Random outage default High Elevated load default Medium

SE override:

Exploit level — what the testing proved

GATE 2 · MAY REDUCE

A PoC is proof of exploit — just not full CE — so by default it does not reduce the score. Theoretical: condition exists, behavior change not shown; still a potential vulnerability.

Exploit level CE — full code execution demonstrated no reduction PoC — behavior change proven, not full CE no reduction (default) Theoretical — condition exists, no behavior change shown reduce one level (default)

SE override:

Exploitation context — authentication × execution privileges

GATE 3 · MAY REDUCE / VETO

Unauthenticated remote keeps severity (KEV candidate). Authenticated attackers matter only for how far they can escalate. Logged in as root = not a vulnerability. Context unknown = no reduction.

Attacker authentication Unauthenticated — remote, over the web (RCE) Authenticated — low / medium privileges Authenticated — high privileges Authenticated — root

Vulnerability execution context Unknown no reduction Root privileges High privileges Medium / low privileges

SE override:

Risk floors — vendor system definition

GATE 4 · MAY RESTORE CRITICAL

Risk can veto the reduction: if any applies (per the vendor's own system definition), severity is restored to Critical. Cannot revive a "not a vul" result.

Risk dimensions Service is mission critical (vendor mission statement) Data is confidential (PII, secrets, or by system definition) Compute is publicly accessible — CE on data plane or control plane

SE override (final vendor score):

Result

VENDOR SCORE → PUBLICATION

Vendor score · fix decision

—

Public disclosure — impact table (consumer-visible)

Select a behavior to see the publication row.

The vendor score dictates the publication severity. Only the impact is published — never the condition, the manipulation technique, or the exploit mechanism.

Fix verification — sign-off sanity check

NO EFFECT ON SCORE

The vendor SE owns the vulnerability and signs off the fix. Verify that the fix addresses the condition (the manipulation), not just the observed behavior.

Manipulation source (cause) Input (user / system) — no sanitation or limits Handovers — between components / system-wide Design — wrong logic / flow, insecure design

Manipulation technique Concatenation — appending malicious logic Embedding — breaking parsing with malformed structure Replacing — substituting safe values / tokens / config

Sign-off checklist The fix addresses the condition, not only the behavior The manipulation technique no longer works after the fix Retested at the same exploit level as originally proven

Sign-off: incomplete — select source, technique, and confirm all checks.