NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

CVE-2020-11090 — indy-node

HIGH

CVE-2020-11090 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in indy-node. A fix is available for indy-node — see the affected versions and patch details below.

Uncontrolled Resource Consumption in Indy Node

Also known asGHSA-3gw4-m5w7-v89cPYSEC-2020-47
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 29, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
2.2%probability of exploitation in next 30 days
Lower Risk+0.07%
Lower risk than most CVEs82th percentile — riskier than 82% of all scored CVEsHighest risk
0.00%0.91%1.82%2.73%0.4%2.2%Apr 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐍indy-node

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Indy Node has a bug in TAA handling code. The current primary can be crashed with a malformed transaction from a client, which leads to a view change. Repeated rapid view changes have the potential of bringing down the network.

Discovery

On May 18, Evernym's monitoring of Sovrin StagingNet showed a report of StagingNet losing sufficient consensus to validate write transactions. The problem resolved itself within a few minutes. On May 20th we saw the alert multiple times, and we began analyzing the logs of our steward node. On May 21st we continued to see the alerts with increasing frequency.

It appears that someone is unknowingly sending a malformed transaction, and retrying when the transaction fails. The cause of the errors appear to be the TAA acceptance.

Proposed actions

  • Reproduce problem in integration tests and create a fix
  • Do a hotfix release branching from last stable (current master have some things merged that are too risky)
  • Upgrade BuilderNet, StagingNet and MainNet as soon as possible
  • Improve testing strategy on Indy Node to reduce probability of such bugs

Notes

  • The journalctl logs also show an out-of-memory problem on the Australia node. We need to evaluate if this should be raised as a separate issue.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIindy-node≥ 1.12.2&&< 1.12.31.12.3pip install --upgrade 'indy-node==1.12.3'

Affected Products

1 product · 1 configurations
Application
indy-nodelinuxfoundation
1 version
1.12.2

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for indy-node, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update indy-node to 1.12.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2020-11090 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

# Summary Indy Node has a bug in TAA handling code. The current primary can be crashed with a malformed transaction from a client, which leads to a view change. Repeated rapid view changes have the potential of bringing down the network. # Discovery On May 18, Evernym's monitoring of Sovrin StagingNet showed a report of StagingNet losing sufficient consensus to validate write transactions. The problem resolved itself within a few minutes. On May 20th we saw the alert multiple times, and we began analyzing the logs of our steward node. On May 21st we continued to see the alerts with increasing
O3 Security · Impact-Aware SCA

Is CVE-2020-11090 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
CVE-2020-11090: indy-node — Fixed in 1.12.3