Smart Contract Audit Severity Levels Explained

Ranking findings into smart contract audit severity levels is one of the hardest problems in security. There is no deterministic process that tells you whether a bug is critical, high, medium or low.

It is harder still when you are starting out.

This guide shows how to weigh impact and likelihood, and what separates each level from the next.

It also covers centralization risks, and how to tell whether two findings are really one.

Four Severity Buckets

In our view there are four buckets: critical, high, medium and low. Most firms use some version of these.

Some split low into informational, QA, gas and low. We fold all of those into low to cut operational complexity. Nobody really cares whether something is informational or QA.

That simplicity matters most when you run several audits a month, or several at once as a team.

Why contest platforms use fewer buckets

At the time of this session (late 2023), the contest platforms did not use critical at all. Code4rena used high, medium and low, and Sherlock used only high and medium.

Fewer buckets means less operational drag. Contest platforms run audits at scale, so they aim for the most efficient processes possible.

Why keep critical separate from high

Removing critical would be simpler. But there is an important difference between a high and a critical finding.

If you charge per vulnerability, a separate critical tier also prices the truly critical findings higher. And they deserve greater emphasis either way.

Definitions and Severity Matrices

One approach is a written definition for each level, with examples. Here is one such set, as Guardian used it in 2023.

This is not a formula. It is subjective and leaves room for argument, because every codebase and every interesting finding is unique.

A high, for instance, may need a special type of address or a lot of capital.

If spending $10,000 lets me DoS a feature, I gain nothing, but the protocol and its users are clearly harmed.

A medium might be making a keeper spend a few extra cents or dollars per transaction without reimbursement, or rounding off 10 cents every time fees are distributed.

That is real, but not significant.

Likelihood and impact matrices

Other firms use a matrix of how likely something is against how bad it is. This is common in web2 security too.

One firm's version runs: protocol-breaking and very likely is critical, protocol-breaking and likely is high, protocol-breaking but unlikely is medium. It also keeps info and warning levels.

The version we like best is a simple three by three grid, from high impact and high likelihood down to low impact and low likelihood.

A medium likelihood of a high impact issue, for example, is probably a high.

A grid like this avoids extra levels, though it is still reductive if applied blindly.

It is still a judgment call

Even with a matrix, deciding likelihood and impact is subjective. You could try dollar thresholds, but some protocols hold billions and some hold thousands.

For now, severity is more of a sense you develop. The rules below are how we think it through.

Low Severity Issues

A low is anything worth noting that has no impact, or virtually unnoticeable impact.

Ask: if the team did not fix this, would it be fine?

If it would literally be fine, it is probably a low. If it would be kind of not fine, it is probably more.

Examples of lows:

• Floating pragma. You should be explicit about the Solidity version, since compiler vulnerabilities and behavior differ between versions.
• Missing zero address checks.
• Gas optimizations.
• Documentation typos, and general notes on test coverage.
• Anything with a trivial effect on the system or users, such as less than a cent for one user.
• Anything that relies on a user or trusted address making a mistake.

A floating pragma can occasionally be more.

At the time of the session, a project using the PUSH0 opcode could end up on a Solidity version incompatible with Arbitrum, where it was deploying.

User and admin mistakes

If a user inputs the zero address and loses funds, that deserves a finding.

If it requires the user's own mistake and only hurts that user, it is a good low.

A trusted address bricking the protocol through misconfiguration is also noteworthy. Generally, assume the team knows how to configure its own protocol, so it is usually a low.

Sometimes it can be a medium, depending on the scope of the change, what is at risk and who controls the address. Matrices do not capture this well.

If you charge per vulnerability, these are usually warnings rather than exploitable risks. List them as lows, or as mediums you do not charge for.

Medium Severity Issues

A medium has non-trivial impact that is still not significant: perhaps a few dollars of net effect on a user or the protocol.

Mediums can also be:

• Issues with more significant impact that are extremely rare.
• Potential risks an attacker could leverage later.
• Centralization risks.

Rounding in the attacker's favor

Rounding in the wrong direction may do nothing on its own. But an exploit of Raft (late 2023) came down to rounding in the user's benefit, and so the attacker's.

Rounding is a common attacker knob. If a trader's profit is rounded up, in the trader's favor, that is a decent medium to report in case it can be exploited.

This is the "inherent risk of future exploits" idea. If leaving it would make you sweat, it should be changed, and it should be at least a medium.

Centralization as a medium

Centralization risks should rarely be more than a medium. Consider combining all of a protocol's centralization risks into one finding.

Otherwise the report reads as one long list of everything the team could do wrong. That is not why they hired you.

Some protocols care deeply about centralization because they aim to be fully decentralized.

Most do not: in practice, most protocols are a SaaS app deployed onchain and controlled by a team.

Examples of mediums

• Minor gas griefing. Making a keeper spend a few extra dollars per transaction, unpaid, adds up over time.
• Rounding errors an attacker could leverage.
• A missing sequencer uptime check. On a layer 2 like Arbitrum, if the sequencer is down, an oracle feed may not update for a long time. Chainlink offers a sequencer uptime feed so you can reject potentially stale prices.
• An owner who can re-enter withdrawFees and drain the contract. The owner is trusted, so this is limited to a medium.

Medium or low?

• If users behave correctly, does it impact them in a noticeable way (gas optimizations aside)? If yes, it is at least a medium. If no, probably a low.
• Does it pose a risk of a non-trivial exploit or mishap in the future? If yes, lean medium, because you want it fixed. If trusted addresses enter the right parameters and nothing can go wrong, it is a low.

High Severity Issues

Highs are attacks that are not straightforward and may be somewhat unlikely, but have large consequences. They have more impact and likelihood than mediums, without being a guaranteed protocol-ending hack.

Attacks that need real capital

Attacks requiring significant capital that cannot be flash loaned are often highs. A flash loan needs zero capital, so the capital requirement is what limits likelihood.

• TWAP manipulation. You cannot manipulate a TWAP with a flash loan, because the moved price must be recorded in a block. You cannot repay the loan and undo it in one transaction.
• Reference exchange manipulation. The attacker moves the price on a centralized exchange, then uses it to exploit a protocol onchain.
• Abusing protocol logic with large amounts of value, case by case.

Suppose TWAP manipulation can trigger a wave of errant liquidations that the attacker profits from.

The stars have to align, the market can move in between, and it takes capital. That is a high.

GMX V1 was hit this way about a year before the session.

Someone manipulated the price on Binance, and because GMX used oracles with no slippage, the attacker arbitraged the system for roughly $500,000.

It needed a lot of capital and was not guaranteed, but it was probable and had significant impact. That is a textbook high.

Griefing attacks

Griefing attacks harm users or the protocol but bring no obvious benefit to the attacker. Sometimes the attacker even pays to cause them.

They can have almost as much impact as a solid critical. What they lack is the attacker's profit.

• Causing a protocol to spend around $500 a day in extra gas is a solid high.
• Causing a user to lose funds without gaining anything yourself is usually a high.
• Causing every user to lose all their funds is critical, even with no gain. The Parity wallet hack destroyed the multisig and locked the funds; the attacker got nothing.

Denial of service is often a form of griefing: a transaction reverts when it needs to go through.

If it shuts down a non-critical but important feature, such as updating referral codes, that is a solid high.

If the DoS has wide effects on the protocol, or stops users withdrawing, it is critical.

High or medium?

• If the protocol did not fix it, is it imperative that users know? Should the team be actively monitoring it? If yes, it is probably a high. If no, probably a medium.
• Rare with huge consequences: probably still a high.
• Rare with decent consequences: probably a medium.
• Probable with huge or decent consequences: a high, or even critical.

Critical Severity Issues

Criticals are the most cut and dry. Lows and criticals are the easiest to recognize; you know a critical when you see one.

A critical is anything a malicious actor can do to take a significant amount of value out of the protocol.

In our view that means something like 20% or more of the protocol's value.

Griefing can be critical too. If I can make the vault send all its funds to the zero address, I gain nothing, but it is still terrible.

Common examples:

• Reentrancy that steals all the funds in the protocol.
• A denial of service that traps all user funds. That is a huge loss of assets, and the protocol's reputation is all but destroyed.
• Any attack that gives the attacker a risk-free trade.
• Accounting issues that break the protocol or let the attacker profit.

Risk-free trades

In a perpetuals protocol, suppose an attacker has a strategy that guarantees a position, or a set of positions, will be profitable.

The protocol has become a money printer for the attacker.

In a CDP protocol, the equivalent is borrowing more stablecoin than your collateral is worth. Deposit $10 of collateral, borrow $12, and walk away with $12.

Most criticals are edge cases

Today, most critical root causes are not reentrancy or another named class. They are tiny edge cases exploited in a very niche way.

There is no single vulnerability type you can learn to find them. It takes understanding the protocol deeply enough to see how to twist the knife.

The KyberSwap exploit (late 2023) is a perfect example. It was not reentrancy or denial of service, but a niche edge case in swap accounting at tick boundaries.

That is why you need to learn protocols from first principles. Critical findings live in the complex, hard parts, not in patterns you can drill on CTFs.

Our breakdown of how to find critical vulnerabilities goes further.

Critical or high?

• How guaranteed is it? If it relies on front-running on a network with no public mempool, such as Arbitrum, it is not guaranteed. That is a high, or even a medium.
• Is the profit certain? If the attacker profits 100% of the time, lean critical. If it is more like 70%, probably a high.
• How many users does it hit? If it affects all users significantly, it is probably critical. If it drains one user but can be repeated against every user, it is definitely critical. If it only applies to one special user, probably a high.
• How long does it take? If it plays out over weeks or months, and the team could step in if they noticed, probably a high. Days or less, down to a single transaction, is probably critical.

Centralization Risks

Centralization risks are almost always a medium at most.

If a finding relies on a trusted party acting maliciously or making a mistake, cap it at medium, and consider not charging for it.

Front-running and back-running can raise the real risk of a centralized update above medium. Two examples:

Removing a collateral token

In an options protocol audit, a portfolio held supported collateral tokens. The owner could remove a token from being counted as collateral.

An attacker front-runs the removal and deposits a lot of that token. They borrow against it, or use it however the protocol allows.

Once the token is removed, that collateral no longer counts for their position, including when it is liquidated.

We rated this a high, even though it hinged on a centralized update.

Changing a note's underlying asset

In another audit, the owner could update a note's underlying asset.

An attacker who sees the update front-runs it, depositing a lot of ether while the note is backed by ether.

The owner switches the note to wrapped staked ether. The attacker back-runs the update and withdraws wrapped staked ether, possibly draining the contract's entire balance.

Every other holder of those notes is now unbacked. The owner may have assumed nobody held the note, but the attacker turned the update into an exploit.

A finding on the border between medium and high becomes clearly high. See front-running in smart contracts for more.

One Finding or Two?

Often several findings share a root cause, or sit in the same area. Ask one question:

Does the most straightforward fix to either finding fix both? If yes, they are one finding. If no, they are two.

Sometimes a clever fix solves both at once. If it is not the most straightforward fix, the two likely do not share the exact same root cause.

Severity Levels at a Glance

For worked examples of findings at each level, see smart contract audit findings explained.

How Guardian Helps

In a Guardian smart contract audit, two independent teams review the same scope and cross-check each other's findings.

Senior researchers deliver exploit narratives and reproduction paths with what they find.

Frequently Asked Questions

What makes a finding critical rather than high?

A critical is guaranteed, certainly profitable, hits all users or repeats against each one, and plays out fast. If it depends on luck, capital, one special user or weeks of time, it is probably a high.

Are centralization risks ever high severity?

Rarely. If a finding needs a trusted party to act maliciously or make a mistake, cap it at medium. It can rise to high when an attacker can front-run or back-run the centralized update to exploit it.

Is a griefing attack high or critical?

Griefing harms others without benefiting the attacker. Making one user lose funds, or burning the protocol's gas, is usually a high. Making every user lose their funds, or trapping all deposits, is critical.

How do you tell if two findings are the same?

Ask whether the most straightforward fix to either finding fixes both. If yes, they are one finding. If no, they are two separate findings.

Sources

• Owen Thurm (YouTube): Is This A Critical? How To Rank Vulnerability Severity (December 2023)