Common Weakness Enumeration

CWE-682

Discouraged

Incorrect Calculation

Abstraction: Pillar · Status: Draft

API response cwe.mitre.org

The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

199 vulnerabilities reference this CWE, most recent first.

GHSA-4V7V-GQF9-WW2G

Vulnerability from github – Published: 2026-10-06 15:22 – Updated: 2026-10-06 15:22
VLAI
Summary
Vyper: Call stack corruption when passing complex type containing non-base type members as argument
Details

Impact

When we pass a multi-dimensional array (like [[1, 2], [3, 4]]) as an argument to internal/external functions we get incorrect output. This is due to a stack management issue, because it was assumed that the size of each subtype of an array/struct is 32, which is not always correct.

Example code:

@internal
def test_input(arr: int128[2][1], i: int128) -> (int128[2][1], int128):
    return arr, i

@external
def test_values(arr: int128[2][1], i: int128) -> (int128[2][1], int128):
    return self.test_input(arr, i)

Please see #2183 for further information

Patches

This problem was fixed in #2184, and released as a part of v0.2.6.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T15:22:23Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nWhen we pass a multi-dimensional array (like `[[1, 2], [3, 4]]`) as an argument to internal/external functions we get incorrect output. This is due to a stack management issue, because it was assumed that the size of each subtype of an array/struct is 32, which is not always correct.\n\nExample code:\n```python\n@internal\ndef test_input(arr: int128[2][1], i: int128) -\u003e (int128[2][1], int128):\n    return arr, i\n\n@external\ndef test_values(arr: int128[2][1], i: int128) -\u003e (int128[2][1], int128):\n    return self.test_input(arr, i)\n```\n\nPlease see #2183 for further information\n\n### Patches\nThis problem was fixed in #2184, and released as a part of [`v0.2.6`](https://github.com/vyperlang/vyper/releases/tag/v0.2.6).",
  "id": "GHSA-4v7v-gqf9-ww2g",
  "modified": "2026-10-06T15:22:23Z",
  "published": "2026-10-06T15:22:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-4v7v-gqf9-ww2g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/issues/2183"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/pull/2184"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/commit/0be02b7331e8febe79d5a4218829c72e30417a29"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/releases/tag/v0.2.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vyper: Call stack corruption when passing complex type containing non-base type members as argument"
}

GHSA-4VVP-2H3V-73FW

Vulnerability from github – Published: 2026-09-08 18:31 – Updated: 2026-09-08 18:31
VLAI
Details

snipe-it before 8.7.0 contains an incorrect calculation vulnerability in checkout request handling that allows authenticated users to corrupt the assets.requests_counter through duplicate submissions and cancellations without active requests. Attackers can repeatedly call cancel endpoints without active requests to drive the counter negative, or submit duplicate checkout requests to inflate the counter, misrepresenting pending demand in the admin queue.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-86736"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-08T16:18:36Z",
    "severity": "MODERATE"
  },
  "details": "snipe-it before 8.7.0 contains an incorrect calculation vulnerability in checkout request handling that allows authenticated users to corrupt the assets.requests_counter through duplicate submissions and cancellations without active requests. Attackers can repeatedly call cancel endpoints without active requests to drive the counter negative, or submit duplicate checkout requests to inflate the counter, misrepresenting pending demand in the admin queue.",
  "id": "GHSA-4vvp-2h3v-73fw",
  "modified": "2026-09-08T18:31:54Z",
  "published": "2026-09-08T18:31:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grokability/snipe-it/security/advisories/GHSA-hc9q-5x9h-9gxc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86736"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/snipe-it-before-8.7.0-checkout-request-counter-integrity-failure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-4XJF-FFMR-PJ4G

Vulnerability from github – Published: 2022-05-13 01:40 – Updated: 2022-05-13 01:40
VLAI
Details

A elevation of privilege vulnerability in the Android framework. Product: Android. Versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2. Android ID: A-37285689.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-0666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-06T20:29:00Z",
    "severity": "HIGH"
  },
  "details": "A elevation of privilege vulnerability in the Android framework. Product: Android. Versions: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2. Android ID: A-37285689.",
  "id": "GHSA-4xjf-ffmr-pj4g",
  "modified": "2022-05-13T01:40:25Z",
  "published": "2022-05-13T01:40:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0666"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2017-07-01"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99470"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-52RW-WPQ3-W67J

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34
VLAI
Details

A vulnerability in certain IPv4 fragment-processing functions of Cisco Remote PHY Software could allow an unauthenticated, remote attacker to impact traffic passing through a device, potentially causing a denial of service (DoS) condition. The vulnerability is due to the affected software not validating and calculating certain numerical values in IPv4 packets that are sent to an affected device. An attacker could exploit this vulnerability by sending malformed IPv4 traffic to an affected device. A successful exploit could allow the attacker to disrupt the flow of certain IPv4 traffic passing through an affected device, which could result in a DoS condition.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-15391"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-05T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in certain IPv4 fragment-processing functions of Cisco Remote PHY Software could allow an unauthenticated, remote attacker to impact traffic passing through a device, potentially causing a denial of service (DoS) condition. The vulnerability is due to the affected software not validating and calculating certain numerical values in IPv4 packets that are sent to an affected device. An attacker could exploit this vulnerability by sending malformed IPv4 traffic to an affected device. A successful exploit could allow the attacker to disrupt the flow of certain IPv4 traffic passing through an affected device, which could result in a DoS condition.",
  "id": "GHSA-52rw-wpq3-w67j",
  "modified": "2022-05-13T01:34:21Z",
  "published": "2022-05-13T01:34:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15391"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-phy-ipv4-dos"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-55V6-VVQW-J3QQ

Vulnerability from github – Published: 2022-05-24 17:08 – Updated: 2024-02-02 15:30
VLAI
Details

In reassemble_and_dispatch of packet_fragmenter.cc, there is possible out of bounds write due to an incorrect bounds calculation. This could lead to remote code execution over Bluetooth with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10Android ID: A-143894715

Severity
8.8 (High)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-0022"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-13T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "In reassemble_and_dispatch of packet_fragmenter.cc, there is possible out of bounds write due to an incorrect bounds calculation. This could lead to remote code execution over Bluetooth with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-8.0 Android-8.1 Android-9 Android-10Android ID: A-143894715",
  "id": "GHSA-55v6-vvqw-j3qq",
  "modified": "2024-02-02T15:30:27Z",
  "published": "2022-05-24T17:08:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0022"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2020-02-01"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/156891/Android-Bluetooth-Remote-Denial-Of-Service.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2020/Feb/10"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200513-03-smartphone-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-59W5-J22F-H3RV

Vulnerability from github – Published: 2025-07-04 06:30 – Updated: 2026-06-15 03:30
VLAI
Details

A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success—the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions' confidentiality, integrity, and availability.

Severity
5.0 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-5372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-04T06:15:24Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in libssh versions built with OpenSSL versions older than 3.0, specifically in the ssh_kdf() function responsible for key derivation. Due to inconsistent interpretation of return values where OpenSSL uses 0 to indicate failure and libssh uses 0 for success\u2014the function may mistakenly return a success status even when key derivation fails. This results in uninitialized cryptographic key buffers being used in subsequent communication, potentially compromising SSH sessions\u0027 confidentiality, integrity, and availability.",
  "id": "GHSA-59w5-j22f-h3rv",
  "modified": "2026-06-15T03:30:31Z",
  "published": "2025-07-04T06:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5372"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21977"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:23024"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:20610"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:24349"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:25911"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-5372"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2369388"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5GQV-PHJ4-9RWG

Vulnerability from github – Published: 2022-05-14 02:59 – Updated: 2022-05-14 02:59
VLAI
Details

espritblock eos4j, an unofficial SDK for EOS, through 2018-07-12 mishandles floating-point numbers with more than four digits after the decimal point, which might allow attackers to trigger currency transfers of unintended amounts.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-14439"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-20T00:29:00Z",
    "severity": "HIGH"
  },
  "details": "espritblock eos4j, an unofficial SDK for EOS, through 2018-07-12 mishandles floating-point numbers with more than four digits after the decimal point, which might allow attackers to trigger currency transfers of unintended amounts.",
  "id": "GHSA-5gqv-phj4-9rwg",
  "modified": "2022-05-14T02:59:17Z",
  "published": "2022-05-14T02:59:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14439"
    },
    {
      "type": "WEB",
      "url": "https://github.com/espritblock/eos4j/issues/6"
    },
    {
      "type": "WEB",
      "url": "http://www.bishijie.com/kuaixun_80841"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5X79-WFVW-985R

Vulnerability from github – Published: 2022-05-13 01:08 – Updated: 2025-04-20 03:31
VLAI
Details

NTP before 4.2.8p9 does not properly perform the initial sync calculations, which allows remote attackers to unspecified impact via unknown vectors, related to a "root distance that did not include the peer dispersion."

Severity
5.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2016-7433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-01-13T16:59:00Z",
    "severity": "MODERATE"
  },
  "details": "NTP before 4.2.8p9 does not properly perform the initial sync calculations, which allows remote attackers to unspecified impact via unknown vectors, related to a \"root distance that did not include the peer dispersion.\"",
  "id": "GHSA-5x79-wfvw-985r",
  "modified": "2025-04-20T03:31:11Z",
  "published": "2022-05-13T01:08:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7433"
    },
    {
      "type": "WEB",
      "url": "https://bto.bluecoat.com/security-advisory/sa139"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-211752.pdf"
    },
    {
      "type": "WEB",
      "url": "https://h20566.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03706en_us"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ILMSYVQMMF37MANYEO7KBHOPSC74EKGN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PABKEYX6ABBFJZGMXKH57X756EJUDS3C"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/U5E3XBBCK5IXOLDAH2E4M3QKIYIHUMMP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ILMSYVQMMF37MANYEO7KBHOPSC74EKGN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PABKEYX6ABBFJZGMXKH57X756EJUDS3C"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U5E3XBBCK5IXOLDAH2E4M3QKIYIHUMMP"
    },
    {
      "type": "WEB",
      "url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-16:39.ntp.asc"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsa-21-159-11"
    },
    {
      "type": "WEB",
      "url": "https://www.broadcom.com/support/fibre-channel-networking/security-advisories/brocade-security-advisory-2017-227"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/633847"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2016-12/msg00153.html"
    },
    {
      "type": "WEB",
      "url": "http://nwtime.org/ntp428p9_release"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2017-0252.html"
    },
    {
      "type": "WEB",
      "url": "http://support.ntp.org/bin/view/Main/NtpBug3067"
    },
    {
      "type": "WEB",
      "url": "http://support.ntp.org/bin/view/Main/SecurityNotice#Recent_Vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171129-01-ntpd-en"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2017-3236626.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/539955/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/540254/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/archive/1/539955/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/archive/1/540254/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94455"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037354"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-3349-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-687G-22H4-J4W4

Vulnerability from github – Published: 2026-10-08 22:02 – Updated: 2026-10-08 22:02
VLAI
Summary
fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)
Details

Summary

createVerifier({ clockTolerance: Infinity }) silently bypasses both exp (expiry) AND nbf (not-before) validation. Any expired or not-yet-active token is accepted as valid. The same primitive also corrupts the verifier's internal cache so cached entries inherit infinite validity — they remain valid past a later developer-removed Infinity config until LRU eviction.

Vulnerable code

src/verifier.js:531-533 — option validation only rejects negative values, not Infinity:

if (clockTolerance && (typeof clockTolerance !== 'number' || clockTolerance < 0)) {
  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a positive number.')
}

Infinity passes (it's a number, not less than 0, truthy).

src/verifier.js:583-602 — clockTolerance flows into the date-claim validators:

if (!ignoreNotBefore) {
  validators.push({ ..., modifier: -clockTolerance })   // → -Infinity
}
if (!ignoreExpiration) {
  validators.push({ ..., modifier: +clockTolerance })   // → Infinity
}

src/verifier.js:198-205 — applies modifier additively, producing always-pass comparisons:

function validateClaimDateValue(value, modifier, now, greater, errorCode, errorVerb) {
  const adjusted = value * 1000 + (modifier || 0)   // → ±Infinity
  const valid = greater ? now >= adjusted : now <= adjusted   // → always true
  ...
}

Empirical PoC

const { createSigner, createVerifier } = require('fast-jwt')
const secret = 'test-secret-with-enough-length-to-pass'

const sign = createSigner({ key: secret, algorithm: 'HS256' })
const expiredToken = sign({
  sub: 'alice',
  iat: Math.floor(Date.now()/1000) - 3600,
  exp: Math.floor(Date.now()/1000) - 1800,  // expired 30 min ago
})

const v1 = createVerifier({ key: secret })
try { v1(expiredToken) } catch (e) { console.log('baseline rejects:', e.message) }
// → "The token has expired at ..."

const v2 = createVerifier({ key: secret, clockTolerance: Infinity })
console.log('bypass:', v2(expiredToken))
// → { sub: 'alice', iat: ..., exp: ... }  ← expired token accepted as valid

// Not-yet-active token (nbf in 1 day) — same bypass
const futureToken = sign({
  sub: 'bob',
  iat: Math.floor(Date.now()/1000),
  nbf: Math.floor(Date.now()/1000) + 86400,
})
console.log('bypass nbf:', v2(futureToken))
// → { sub: 'bob', ... }  ← not-yet-active token accepted as valid

Verified against fast-jwt@HEAD on 2026-06-03 (commit pulled today).

Cache side-effect

The verifier's LRU cache uses clockTolerance to compute the cache entry's expiry window:

src/verifier.js:121-134:

cacheValue[1] = ... payload.nbf * 1000 - clockTolerance : 0                   // → -Infinity
cacheValue[2] = payload.exp * 1000 + clockTolerance                            // → Infinity
const maxTTL = clockTimestamp + clockTolerance + cacheTTL                      // → Infinity

With clockTolerance: Infinity, cache entries are stored with [min=-Infinity, max=Infinity]. The cache-hit check (min === 0 || now < min || now <= max) always passes for cached tokens.

Consequence: a developer who briefly sets clockTolerance: Infinity (e.g., during debug) and then removes it will find that any verifications performed during the debug window remain cached as valid until LRU eviction (default 1000 entries).

Asymmetric hardening — the smoking-gun shape

src/signer.js:98, 104 CORRECTLY uses Number.isFinite() to reject Infinity for expiresIn and notBefore:

expiresIn != null && Number.isFinite(expiresIn)
  ? Math.floor((iat + expiresIn) / 1000)
  : ...

The verifier's clockTolerance validation doesn't apply the same guard. The same < 0 check pattern is also applied to clockTimestamp (line 527-529) and cacheTTL (line 535-537) — both also accept Infinity.

This is the kind of asymmetry that often indicates a missed hardening pass: the sign-side was hardened against Infinity but the verify-side wasn't.

Threat model

The bug requires the developer to (mis)configure clockTolerance: Infinity. Realistic ways this happens:

  1. Developer using Infinity as a sentinel for "disable expiry": common JS idiom; many libraries accept Infinity as "no limit." fast-jwt's signer treats Infinity as invalid (Number.isFinite false) but the verifier silently accepts it.
  2. JSON / env-var misconfig: config file or env var sets clockTolerance to "Infinity" (string); Number("Infinity") === Infinity. Surprising via JSON.parse + Number cast or even JSON.parse('{"clockTolerance": null}') if the codec accepts null → Infinity.
  3. Test config bleed: integration tests use Infinity to make tokens never expire during long-running tests; the config bleeds into production.

For a JWT library, silently disabling token expiry on a "looks like a non-negative number" input is a security boundary failure.

Suggested fix

Single-line addition: use Number.isFinite() consistent with signer.js:

if (clockTolerance && (typeof clockTolerance !== 'number' || !Number.isFinite(clockTolerance) || clockTolerance < 0)) {
  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a finite, non-negative number.')
}

Same fix for clockTimestamp (line 527-529) and cacheTTL (line 535-537) for consistency.

Optional defense-in-depth: cap clockTolerance to a reasonable upper bound (e.g., 5 minutes = 300000 ms) with a process.emitWarning above that. Most legitimate use cases need <60s tolerance.

Affected versions

All versions since clockTolerance was first introduced in PR #193 (v1.5.1). Current main HEAD on 2026-06-03 is affected.

Reporter

Andrew Ridings (independent security researcher). Happy to coordinate disclosure timing and follow up with any clarifications. Email: ridingsa@gmail.com

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.2.4"
      },
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107721"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613",
      "CWE-682"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T22:02:02Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`createVerifier({ clockTolerance: Infinity })` silently bypasses both `exp` (expiry) AND `nbf` (not-before) validation. Any expired or not-yet-active token is accepted as valid. The same primitive also corrupts the verifier\u0027s internal cache so cached entries inherit infinite validity \u2014 they remain valid past a later developer-removed Infinity config until LRU eviction.\n\n## Vulnerable code\n\n`src/verifier.js:531-533` \u2014 option validation only rejects negative values, not Infinity:\n\n```js\nif (clockTolerance \u0026\u0026 (typeof clockTolerance !== \u0027number\u0027 || clockTolerance \u003c 0)) {\n  throw new TokenError(TokenError.codes.invalidOption, \u0027The clockTolerance option must be a positive number.\u0027)\n}\n```\n\n`Infinity` passes (it\u0027s a number, not less than 0, truthy).\n\n`src/verifier.js:583-602` \u2014 clockTolerance flows into the date-claim validators:\n\n```js\nif (!ignoreNotBefore) {\n  validators.push({ ..., modifier: -clockTolerance })   // \u2192 -Infinity\n}\nif (!ignoreExpiration) {\n  validators.push({ ..., modifier: +clockTolerance })   // \u2192 Infinity\n}\n```\n\n`src/verifier.js:198-205` \u2014 applies modifier additively, producing always-pass comparisons:\n\n```js\nfunction validateClaimDateValue(value, modifier, now, greater, errorCode, errorVerb) {\n  const adjusted = value * 1000 + (modifier || 0)   // \u2192 \u00b1Infinity\n  const valid = greater ? now \u003e= adjusted : now \u003c= adjusted   // \u2192 always true\n  ...\n}\n```\n\n## Empirical PoC\n\n```js\nconst { createSigner, createVerifier } = require(\u0027fast-jwt\u0027)\nconst secret = \u0027test-secret-with-enough-length-to-pass\u0027\n\nconst sign = createSigner({ key: secret, algorithm: \u0027HS256\u0027 })\nconst expiredToken = sign({\n  sub: \u0027alice\u0027,\n  iat: Math.floor(Date.now()/1000) - 3600,\n  exp: Math.floor(Date.now()/1000) - 1800,  // expired 30 min ago\n})\n\nconst v1 = createVerifier({ key: secret })\ntry { v1(expiredToken) } catch (e) { console.log(\u0027baseline rejects:\u0027, e.message) }\n// \u2192 \"The token has expired at ...\"\n\nconst v2 = createVerifier({ key: secret, clockTolerance: Infinity })\nconsole.log(\u0027bypass:\u0027, v2(expiredToken))\n// \u2192 { sub: \u0027alice\u0027, iat: ..., exp: ... }  \u2190 expired token accepted as valid\n\n// Not-yet-active token (nbf in 1 day) \u2014 same bypass\nconst futureToken = sign({\n  sub: \u0027bob\u0027,\n  iat: Math.floor(Date.now()/1000),\n  nbf: Math.floor(Date.now()/1000) + 86400,\n})\nconsole.log(\u0027bypass nbf:\u0027, v2(futureToken))\n// \u2192 { sub: \u0027bob\u0027, ... }  \u2190 not-yet-active token accepted as valid\n```\n\nVerified against `fast-jwt@HEAD` on 2026-06-03 (commit pulled today).\n\n## Cache side-effect\n\nThe verifier\u0027s LRU cache uses `clockTolerance` to compute the cache entry\u0027s expiry window:\n\n`src/verifier.js:121-134`:\n```js\ncacheValue[1] = ... payload.nbf * 1000 - clockTolerance : 0                   // \u2192 -Infinity\ncacheValue[2] = payload.exp * 1000 + clockTolerance                            // \u2192 Infinity\nconst maxTTL = clockTimestamp + clockTolerance + cacheTTL                      // \u2192 Infinity\n```\n\nWith `clockTolerance: Infinity`, cache entries are stored with `[min=-Infinity, max=Infinity]`. The cache-hit check (`min === 0 || now \u003c min || now \u003c= max`) always passes for cached tokens.\n\n**Consequence**: a developer who briefly sets `clockTolerance: Infinity` (e.g., during debug) and then removes it will find that any verifications performed during the debug window remain cached as valid until LRU eviction (default 1000 entries).\n\n## Asymmetric hardening \u2014 the smoking-gun shape\n\n`src/signer.js:98, 104` CORRECTLY uses `Number.isFinite()` to reject Infinity for `expiresIn` and `notBefore`:\n\n```js\nexpiresIn != null \u0026\u0026 Number.isFinite(expiresIn)\n  ? Math.floor((iat + expiresIn) / 1000)\n  : ...\n```\n\nThe verifier\u0027s `clockTolerance` validation doesn\u0027t apply the same guard. The same `\u003c 0` check pattern is also applied to `clockTimestamp` (line 527-529) and `cacheTTL` (line 535-537) \u2014 both also accept `Infinity`.\n\nThis is the kind of asymmetry that often indicates a missed hardening pass: the sign-side was hardened against Infinity but the verify-side wasn\u0027t.\n\n## Threat model\n\nThe bug requires the developer to (mis)configure `clockTolerance: Infinity`. Realistic ways this happens:\n\n1. **Developer using Infinity as a sentinel** for \"disable expiry\": common JS idiom; many libraries accept Infinity as \"no limit.\" fast-jwt\u0027s signer treats Infinity as invalid (Number.isFinite false) but the verifier silently accepts it.\n2. **JSON / env-var misconfig**: config file or env var sets `clockTolerance` to `\"Infinity\"` (string); `Number(\"Infinity\") === Infinity`. Surprising via JSON.parse + Number cast or even `JSON.parse(\u0027{\"clockTolerance\": null}\u0027)` if the codec accepts null \u2192 Infinity.\n3. **Test config bleed**: integration tests use Infinity to make tokens never expire during long-running tests; the config bleeds into production.\n\nFor a JWT library, silently disabling token expiry on a \"looks like a non-negative number\" input is a security boundary failure.\n\n## Suggested fix\n\nSingle-line addition: use `Number.isFinite()` consistent with signer.js:\n\n```js\nif (clockTolerance \u0026\u0026 (typeof clockTolerance !== \u0027number\u0027 || !Number.isFinite(clockTolerance) || clockTolerance \u003c 0)) {\n  throw new TokenError(TokenError.codes.invalidOption, \u0027The clockTolerance option must be a finite, non-negative number.\u0027)\n}\n```\n\nSame fix for `clockTimestamp` (line 527-529) and `cacheTTL` (line 535-537) for consistency.\n\nOptional defense-in-depth: cap `clockTolerance` to a reasonable upper bound (e.g., 5 minutes = 300000 ms) with a `process.emitWarning` above that. Most legitimate use cases need \u003c60s tolerance.\n\n## Affected versions\n\nAll versions since clockTolerance was first introduced in PR #193 (v1.5.1). Current `main` HEAD on 2026-06-03 is affected.\n\n## Reporter\n\nAndrew Ridings (independent security researcher). Happy to coordinate disclosure timing and follow up with any clarifications. Email: ridingsa@gmail.com",
  "id": "GHSA-687g-22h4-j4w4",
  "modified": "2026-10-08T22:02:03Z",
  "published": "2026-10-08T22:02:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-687g-22h4-j4w4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/commit/c0fb5b88b4c88ff2bdd194ca2c713599ad9e38b6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/fast-jwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)"
}

GHSA-69V6-XC2J-R2JF

Vulnerability from github – Published: 2021-06-29 21:13 – Updated: 2025-01-30 14:37
VLAI
Summary
Shallow copy bug in geth
Details

Impact

This is a Consensus vulnerability, which can be used to cause a chain-split where vulnerable nodes reject the canonical chain.

Geth’s pre-compiled dataCopy (at 0x00...04) contract did a shallow copy on invocation. An attacker could deploy a contract that

  • writes X to an EVM memory region R,
  • calls 0x00..04 with R as an argument,
  • overwrites R to Y,
  • and finally invokes the RETURNDATACOPY opcode.

When this contract is invoked, a consensus-compliant node would push X on the EVM stack, whereas Geth would push Y.

Patches

No standalone patches have been made.

Workarounds

Upgrade to 1.9.17 or higher.

References

https://blog.ethereum.org/2020/11/12/geth_security_release/

For more information

If you have any questions or comments about this advisory: * Open an issue in go-ethereum * Email us at security@ethereum.org

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ethereum/go-ethereum"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.9.7"
            },
            {
              "fixed": "1.9.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-26241"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-682"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-21T21:51:49Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nThis is a Consensus vulnerability, which can be used to cause a chain-split where vulnerable nodes reject the canonical chain. \n\nGeth\u2019s pre-compiled `dataCopy` (at `0x00...04`) contract did a shallow copy on invocation. An attacker could deploy a contract that \n\n- writes `X` to an EVM memory region `R`,\n- calls `0x00..04` with `R` as an argument,\n- overwrites `R` to `Y`,\n- and finally invokes the `RETURNDATACOPY` opcode.\n\nWhen this contract is invoked, a consensus-compliant node would push `X` on the EVM stack, whereas Geth would push `Y`.\n\n\n### Patches\n\nNo standalone patches have been made. \n\n### Workarounds\n\nUpgrade to `1.9.17` or higher.\n\n### References\n\nhttps://blog.ethereum.org/2020/11/12/geth_security_release/\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [go-ethereum](https://github.com/ethereum/go-ethereum)\n* Email us at [security@ethereum.org](mailto:security@ethereum.org)\n",
  "id": "GHSA-69v6-xc2j-r2jf",
  "modified": "2025-01-30T14:37:49Z",
  "published": "2021-06-29T21:13:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ethereum/go-ethereum/security/advisories/GHSA-69v6-xc2j-r2jf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26241"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ethereum/go-ethereum/commit/295693759e5ded05fec0b2fb39359965b60da785"
    },
    {
      "type": "WEB",
      "url": "https://blog.ethereum.org/2020/11/12/geth_security_release"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ethereum/go-ethereum"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shallow copy bug in geth"
}
Mitigation
Implementation

Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.

Mitigation MIT-8
Implementation

Strategy: Input Validation

Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Mitigation
Implementation

Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.

Mitigation
Architecture and Design

Strategy: Language Selection

  • Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.
  • Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

  • Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.
  • Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).
Mitigation MIT-26
Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

CAPEC-128: Integer Attacks

An attacker takes advantage of the structure of integer variables to cause these variables to assume values that are not expected by an application. For example, adding one to the largest positive integer in a signed integer variable results in a negative number. Negative numbers may be illegal in an application and the application may prevent an attacker from providing them directly, but the application may not consider that adding two positive numbers can create a negative number do to the structure of integer storage formats.

CAPEC-129: Pointer Manipulation

This attack pattern involves an adversary manipulating a pointer within a target application resulting in the application accessing an unintended memory location. This can result in the crashing of the application or, for certain pointer values, access to data that would not normally be possible or the execution of arbitrary code. Since pointers are simply integer variables, Integer Attacks may often be used in Pointer Attacks.

← Back to the CWE list