What is GHSA-5V93-9MQW-P9MH?

GHSA-5V93-9MQW-P9MH is a high-severity security vulnerability in orml-rewards (rust), affecting versions < 1.2.1. It is fixed in 1.2.1.

Which versions of orml-rewards are affected by GHSA-5V93-9MQW-P9MH?

orml-rewards (rust) versions < 1.2.1 is affected.

Is there a fix for GHSA-5V93-9MQW-P9MH?

Yes. GHSA-5V93-9MQW-P9MH is fixed in 1.2.1. Upgrade to this version or later.

Is GHSA-5V93-9MQW-P9MH exploitable, and should I be worried?

Whether GHSA-5V93-9MQW-P9MH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk.

What actually determines whether GHSA-5V93-9MQW-P9MH is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

How do I fix GHSA-5V93-9MQW-P9MH?

Upgrade orml-rewards to 1.2.1 or later.

GHSA-5V93-9MQW-P9MH in orml-rewards

Q: Which versions of orml-rewards are affected by GHSA-5V93-9MQW-P9MH?

orml-rewards (rust) versions < 1.2.1 is affected.

Q: Is there a fix for GHSA-5V93-9MQW-P9MH?

Yes. GHSA-5V93-9MQW-P9MH is fixed in 1.2.1. Upgrade to this version or later.

Q: Is GHSA-5V93-9MQW-P9MH exploitable, and should I be worried?

Whether GHSA-5V93-9MQW-P9MH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk.

Q: What actually determines whether GHSA-5V93-9MQW-P9MH is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

Q: How do I fix GHSA-5V93-9MQW-P9MH?

Upgrade orml-rewards to 1.2.1 or later.

Summary

Uncaught Panic in ORML Rewards Pallet

A vulnerability in the add_share function of the Rewards pallet (part of the ORML repository) can lead to an uncaught Rust panic when handling user-provided input exceeding the u128 range.

Affected Components

ORML Rewards pallet (rewards/src/lib.rs)
Any Substrate-based chain using ORML Rewards with add_share accepting unvalidated large u128 inputs

Technical Details

add_share performs arithmetic on user-supplied values (add_amount) of type T::Share (mapped to u128 in Acala).
If add_amount is large enough (e.g., i128::MAX), the intermediate result may overflow and panic on the cast to u128.
Validation occurs only after arithmetic, enabling a crafted input to trigger an overflow.

Likelihood

This issue is exploitable in production if there exists at least one rewards pool where reward tokens exceed twice the collateral tokens, allowing sufficiently large multiplication to exceed u128 bounds.

Backport

The patch have been backported to following release branches:

polkadot-stable2407
polkadot-stable2409

A 1.0.1 patch release is made with this fix.

Impact

A malicious user submitting a specially crafted extrinsic can cause a panic in the runtime:

Denial of Service by crashing the node process.
Potential for invalid blocks produced by validators.

Affected versions

orml-rewards (< 1.2.1)

Security releases

orml-rewards → 1.2.1 (rust)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environment New to Kodem? Get a demo →

Remediation advice

This issue is fixed in https://github.com/open-web3-stack/open-runtime-module-library/pull/1016

Frequently Asked Questions

What is GHSA-5V93-9MQW-P9MH? GHSA-5V93-9MQW-P9MH is a high-severity security vulnerability in orml-rewards (rust), affecting versions < 1.2.1. It is fixed in 1.2.1.
Which versions of orml-rewards are affected by GHSA-5V93-9MQW-P9MH? orml-rewards (rust) versions < 1.2.1 is affected.
Is there a fix for GHSA-5V93-9MQW-P9MH? Yes. GHSA-5V93-9MQW-P9MH is fixed in 1.2.1. Upgrade to this version or later.
Is GHSA-5V93-9MQW-P9MH exploitable, and should I be worried? Whether GHSA-5V93-9MQW-P9MH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
What actually determines whether GHSA-5V93-9MQW-P9MH is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
How do I fix GHSA-5V93-9MQW-P9MH? Upgrade orml-rewards to 1.2.1 or later.