Skip to content

← Public intelligence

Go package

github.com/babylonlabs-io/babylon

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.2GoPublished

    Babylon Integer Overflow in Distribution Module CumulativeRewardRatio Calculation Leading to Chain Halt

    GHSA-869w-47c6-fq8q

    Affected
    • Go github.com/babylonlabs-io/babylon < 1.1.0
    Fixed in
    1.1.0· Vendor fix available
    Issue
    Minting large amount of tokens through ibc transfer and then depositing them in validator rewards pool (via DepositValidatorRewardsPool message) can lead to integer overflow panic when calculating cumulativerewardratio for the validator. This calculation happens in x/epoching module EndBlocker, thus the panic will halt the chain. Impact Denial of Service - Due to panic in the EndBlocker Babylon Genesis will halt

    Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 8.9GoPublished

    Babylon Finality Provider MsgCommitPubRandList replay attack

    GHSA-7mm3-vfg8-7rg6

    Affected
    • Go github.com/babylonlabs-io/babylon < 1.1.0
    Fixed in
    1.1.0· Vendor fix available
    Issue
    A high vulnerability exists in the Babylon protocol's x/finality module due to a lack of domain separation in signed messages, combined with insufficient validation in the MsgCommitPubRandList handler. Specifically, the handler does not enforce that the submitted Commitment field is 32 bytes long. This allows an attacker to replay a signature originally generated for a different message (e.g., a Proof-of-Possession in MsgCreateFinalityProvider) as a MsgCommitPubRandList. By crafting the message parameters, an attacker can use the typically 20-byte address bytes (from the PoP context) to form the StartHeight, NumPubRand, and a shorter-than-expected Commitment (e.g., 4 bytes). The replayed signature will pass verification for this crafted message, leading to the injection of an invalid PubRand commitment. Impact Successful exploitation of this vulnerability, specifically via the PoP signature replay, allows an attacker to store an invalid PubRand commitment (with a non-standard…

    Recommended action: Upgrade to 1.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →