Immunefi - Severity test

At Immunefi, we classify bugs on a simplified 5-level scale:

Critical
High
Medium
Low
None

This scale encompasses all the aspects of a bug, from the consequence of a successful exploit, to the level of access required to exploit it, to the probability that an exploitation attempt will be successful.

For example:

A bug that results in loss of contract funds is more severe than a bug that temporarily prevents token holders from transferring their tokens.
A bug that can be triggered by any token holder is more severe than a bug that requires a pricing oracle to go rogue.
A bug that can be triggered by a third party invoking a particular function/method is more severe than a bug that requires the affected token holder to invoke that same function/method.

The table below is mostly concerned with the consequence of a successful exploit. Keep in mind that if the exploit requires elevated privileges or uncommon user interaction, the level of the bug may be downgraded to reflect that.

Smart Contracts/Blockchain

Feature	Support
CommonMark	100%
GFM	100% w/ `remark-gfm`

  <td>
    <ul>
      <li>
        Empty or freeze the contract’s holdings
        <br />
        (e.g. economic attacks, flash loans, reentrancy, logic errors,
        integer over-/under-flow)
      </li>
      <li>Cryptographic flaws</li>
    </ul>
  </td>
</tr>

<tr>
  <td>4. High</td>

  <td>
    <ul>
      <li>Token holders temporarily unable to transfer holdings</li>
      <li>Users spoof each other</li>
      <li>
        Trusting trust/composability bugs may be Critical, High, or Medium
        depending on the outcome
      </li>
      <li>Transient consensus failures</li>
    </ul>
  </td>
</tr>

<tr>
  <td>3. Medium</td>

  <td>
    <ul>
      <li>Contract out of gas</li>
      <li>Contract consumes unbounded gas</li>
      <li>Block stuffing</li>
      <li>Denial of service (e.g. spamming block space)</li>
    </ul>
  </td>
</tr>

<tr>
  <td>2. Low</td>

  <td>
    <ul>
      <li>
        Contract fails to deliver promised returns, but doesn't lose value
      </li>
    </ul>
  </td>
</tr>

<tr>
  <td>1. None</td>

  <td>
    <ul>
      <li>Not following best practices</li>
    </ul>
  </td>
</tr>

Level	Examples
5. Critical

Websites and Apps

  <td>
    <ul>
      <li>Deletion of site data</li>
      <li>XSS/CSRF</li>
      <li>Arbitrary code execution</li>
      <li>Shell access on the server</li>
      <li>SQL injection</li>
    </ul>
  </td>
</tr>

<tr>
  <td>4. High</td>

  <td>
    <ul>
      <li>Users spoof each other</li>
      <li>Leaking user data</li>
      <li>Insufficient validation before viewing sensitive pages</li>
      <li>Dumping, but not modifying database</li>
    </ul>
  </td>
</tr>

<tr>
  <td>3. Medium</td>

  <td>
    <ul>
      <li>Denial of service</li>
      <li>Site goes down</li>
      <li>DNS zone transfer misconfiguration</li>
    </ul>
  </td>
</tr>

<tr>
  <td>2. Low</td>

  <td>
    <ul>
      <li>DoS amplification</li>
      <li>Unsecured recursive DNS resolver</li>
      <li>Open SMTP relay</li>
      <li>Bad SSL settings</li>
      <li>Missing security headers (with impact)</li>
    </ul>
  </td>
</tr>

<tr>
  <td>1. None</td>

  <td>
    <ul>
      <li>Using RSA1024</li>
      <li>No ASLR</li>
      <li>No verification email</li>
      <li>Not using argon2 for password hashing</li>
      <li>Missing captcha</li>
      <li>Bad password policy</li>
      <li>Missing DMARC/DKIM/SPF on a mailserver</li>
      <li>Not following best practices</li>
    </ul>
  </td>
</tr>

Level	Examples
5. Critical