Vulnerability-Lookup

UBUNTU-CVE-2026-65632 (CVE-2026-65632)

Vulnerability from osv_ubuntu – Published: 2026-10-27 00:00 – Updated: 2026-10-27 00:00 – Source website

Details

The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 §3.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes. As a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same (r, s) pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying (r, s) values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic. This issue affects jose: from 1.0.0 before 1.11.13.

Severity

5.1 (Medium)


                    
                      CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

N/A (UNKNOWN)


                    
                      medium

References

URL

Type

	https://ubuntu.com/security/CVE-2026-65632	REPORT
	https://www.cve.org/CVERecord?id=CVE-2026-65632	REPORT
	https://cna.erlef.org/cves/cve-2026-65632.html	REPORT
	https://github.com	REPORT
	https://github.com/potatosalad/erlang-jose	REPORT
	https://github.com/potatosalad/erlang-jose/commit…	REPORT
	https://github.com/potatosalad/erlang-jose/commit…	REPORT
	https://github.com/potatosalad/erlang-jose/securi…	REPORT
	https://hex.pm/packages/jose	REPORT
	https://repo.hex.pm	REPORT
	https://github.com/cveproject/cvelistv5/tree/main…	REPORT
	https://nvd.nist.gov/vuln/detail/cve-2026-65632	REPORT
	https://osv.dev/vulnerability/eef-cve-2026-65632	REPORT

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "jose",
            "binary_version": "10-2build1"
          },
          {
            "binary_name": "libjose0",
            "binary_version": "10-2build1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:18.04:LTS",
        "name": "jose",
        "purl": "pkg:deb/ubuntu/jose@10-2build1?arch=source\u0026distro=bionic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "10-2",
        "10-2build1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "jose",
            "binary_version": "10-2build2"
          },
          {
            "binary_name": "libjose0",
            "binary_version": "10-2build2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:20.04:LTS",
        "name": "jose",
        "purl": "pkg:deb/ubuntu/jose@10-2build2?arch=source\u0026distro=focal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "10-2build2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "jose",
            "binary_version": "11-2"
          },
          {
            "binary_name": "libjose0",
            "binary_version": "11-2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:22.04:LTS",
        "name": "jose",
        "purl": "pkg:deb/ubuntu/jose@11-2?arch=source\u0026distro=jammy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "10-3",
        "11-2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "jose",
            "binary_version": "13-1"
          },
          {
            "binary_name": "libjose0",
            "binary_version": "13-1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:24.04:LTS",
        "name": "jose",
        "purl": "pkg:deb/ubuntu/jose@13-1?arch=source\u0026distro=noble"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "11-2",
        "11-3",
        "11-3build1",
        "11-3build2",
        "13-1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "jose",
            "binary_version": "14-2build2"
          },
          {
            "binary_name": "libjose0",
            "binary_version": "14-2build2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:26.10",
        "name": "jose",
        "purl": "pkg:deb/ubuntu/jose@14-2build2?arch=source\u0026distro=stonking"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "14-2build1",
        "14-2build2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "jose",
            "binary_version": "14-2build1"
          },
          {
            "binary_name": "libjose0",
            "binary_version": "14-2build1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:26.04:LTS",
        "name": "jose",
        "purl": "pkg:deb/ubuntu/jose@14-2build1?arch=source\u0026distro=resolute"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "14-2build1"
      ]
    }
  ],
  "aliases": [],
  "details": "The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 \u00a73.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes. As a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same (r, s) pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying (r, s) values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic. This issue affects jose: from 1.0.0 before 1.11.13.",
  "id": "UBUNTU-CVE-2026-65632",
  "modified": "2026-10-27T00:00:00Z",
  "published": "2026-10-27T00:00:00Z",
  "references": [
    {
      "type": "REPORT",
      "url": "https://ubuntu.com/security/CVE-2026-65632"
    },
    {
      "type": "REPORT",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65632"
    },
    {
      "type": "REPORT",
      "url": "https://cna.erlef.org/cves/cve-2026-65632.html"
    },
    {
      "type": "REPORT",
      "url": "https://github.com"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/potatosalad/erlang-jose"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/potatosalad/erlang-jose/commit/72ce1866622b9329347dc52a94173ac0317bc9cf"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/potatosalad/erlang-jose/commit/a7746ecd4950f85a393136e449a91dac62b5c429"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/potatosalad/erlang-jose/security/advisories/ghsa-44hw-rpw9-mwg4"
    },
    {
      "type": "REPORT",
      "url": "https://hex.pm/packages/jose"
    },
    {
      "type": "REPORT",
      "url": "https://repo.hex.pm"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/cveproject/cvelistv5/tree/main/cves/2026/65xxx/cve-2026-65632.json"
    },
    {
      "type": "REPORT",
      "url": "https://nvd.nist.gov/vuln/detail/cve-2026-65632"
    },
    {
      "type": "REPORT",
      "url": "https://osv.dev/vulnerability/eef-cve-2026-65632"
    }
  ],
  "related": [],
  "schema_version": "1.7.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    },
    {
      "score": "medium",
      "type": "Ubuntu"
    }
  ],
  "upstream": [
    "CVE-2026-65632"
  ]
}

CVE-2026-65632 (GCVE-0-2026-65632)

Vulnerability from cvelistv5 – Published: 2026-10-26 19:53 – Updated: 2026-10-26 19:53

Title

ECDSA signature length is not validated in jose, allowing signature malleability

Summary

Severity

5.1 (Medium)


                        
                          CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

CWE

CWE-347 - Improper Verification of Cryptographic Signature

Assigner

EEF CNA under the mitre root

CNA scorecard A 97/100 over 345 records in the last 180 days details

References

5 references

URL	Tags
https://github.com/potatosalad/erlang-jose/securi…	vendor-advisoryrelated
https://cna.erlef.org/cves/CVE-2026-65632.html	related
https://osv.dev/vulnerability/EEF-CVE-2026-65632	related
https://github.com/potatosalad/erlang-jose/commit…	related
https://github.com/potatosalad/erlang-jose/commit…	patch

Impacted products

2 products

Vendor	Product	Version
potatosalad	jose	Affected: 1.0.0 , < 1.11.13 (semver) cpe:2.3:a:potatosalad:jose::::::::
potatosalad	jose	Affected: a7746ecd4950f85a393136e449a91dac62b5c429 , < 72ce1866622b9329347dc52a94173ac0317bc9cf (git) cpe:2.3:a:potatosalad:jose::::::::

Credits

Peter Ullrich Andrew Bennett Jonatan Männchen / EEF

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:potatosalad:jose:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "jose_jwk_kty_ec"
          ],
          "packageName": "jose",
          "packageURL": "pkg:hex/jose",
          "product": "jose",
          "programFiles": [
            "src/jwk/jose_jwk_kty_ec.erl"
          ],
          "programRoutines": [
            {
              "name": "jose_jwk_kty_ec:verify/4"
            }
          ],
          "repo": "https://github.com/potatosalad/erlang-jose",
          "vendor": "potatosalad",
          "versions": [
            {
              "lessThan": "1.11.13",
              "status": "affected",
              "version": "1.0.0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:potatosalad:jose:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "jose_jwk_kty_ec"
          ],
          "packageName": "potatosalad/erlang-jose",
          "packageURL": "pkg:github/potatosalad/erlang-jose",
          "product": "jose",
          "programFiles": [
            "src/jwk/jose_jwk_kty_ec.erl"
          ],
          "programRoutines": [
            {
              "name": "jose_jwk_kty_ec:verify/4"
            }
          ],
          "repo": "https://github.com/potatosalad/erlang-jose",
          "vendor": "potatosalad",
          "versions": [
            {
              "lessThan": "72ce1866622b9329347dc52a94173ac0317bc9cf",
              "status": "affected",
              "version": "a7746ecd4950f85a393136e449a91dac62b5c429",
              "versionType": "git"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:potatosalad:jose:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "1.11.13",
                  "versionStartIncluding": "1.0.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Peter Ullrich"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Andrew Bennett"
        },
        {
          "lang": "en",
          "type": "analyst",
          "value": "Jonatan M\u00e4nnchen / EEF"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe \u003ccode\u003ejose\u003c/code\u003e library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, \u003ccode\u003ejose_jwk_kty_ec:verify/4\u003c/code\u003e in \u003ccode\u003esrc/jwk/jose_jwk_kty_ec.erl\u003c/code\u003e splits the raw signature in half by its actual byte length (\u003ccode\u003esplit_binary(Signature, byte_size(Signature) div 2)\u003c/code\u003e) instead of enforcing the fixed length required by RFC 7518 \u00a73.4, and then decodes each half with \u003ccode\u003ecrypto:bytes_to_integer/1\u003c/code\u003e, which ignores leading zero bytes.\u003c/p\u003e\n\u003cp\u003eAs a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same \u003ccode\u003e(r, s)\u003c/code\u003e pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying \u003ccode\u003e(r, s)\u003c/code\u003e values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic.\u003c/p\u003e\n\u003cp\u003eThis issue affects jose: from 1.0.0 before 1.11.13.\u003c/p\u003e"
            },
            {
              "base64": false,
              "type": "text/markdown",
              "value": "The `jose` library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, `jose_jwk_kty_ec:verify/4` in `src/jwk/jose_jwk_kty_ec.erl` splits the raw signature in half by its actual byte length (`split_binary(Signature, byte_size(Signature) div 2)`) instead of enforcing the fixed length required by RFC 7518 \u00a73.4, and then decodes each half with `crypto:bytes_to_integer/1`, which ignores leading zero bytes.\n\nAs a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same `(r, s)` pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying `(r, s)` values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic.\n\nThis issue affects jose: from 1.0.0 before 1.11.13."
            }
          ],
          "value": "The jose library accepts ECDSA (ES256, ES256K, ES384, and ES512) JWS signatures of a non-canonical length. When verifying an ECDSA signature, jose_jwk_kty_ec:verify/4 in src/jwk/jose_jwk_kty_ec.erl splits the raw signature in half by its actual byte length (split_binary(Signature, byte_size(Signature) div 2)) instead of enforcing the fixed length required by RFC 7518 \u00a73.4, and then decodes each half with crypto:bytes_to_integer/1, which ignores leading zero bytes.\n\nAs a result, an attacker who holds one valid token can prepend leading zero bytes to each of the R and S halves to produce longer signatures that still split evenly and decode to the same (r, s) pair, so many distinct signature byte strings all verify against the same key (signature malleability). This does not allow forging new payloads or impersonating a signer, because the underlying (r, s) values are unchanged. It does defeat any security control that assumes a valid token or its signature is unique, such as token-revocation-by-hash, replay or idempotency caches, and deduplication logic.\n\nThis issue affects jose: from 1.0.0 before 1.11.13."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-475",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-475 Signature Spoofing by Improper Validation"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "LOCAL",
            "baseScore": 5.1,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "LOW",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-347",
              "description": "CWE-347 Improper Verification of Cryptographic Signature",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-26T19:53:56.649Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/potatosalad/erlang-jose/security/advisories/GHSA-44hw-rpw9-mwg4"
        },
        {
          "name": "EEF CNA record for CVE-2026-65632",
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-65632.html"
        },
        {
          "name": "OSV record EEF-CVE-2026-65632",
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-65632"
        },
        {
          "name": "Introducing commit a7746ec in potatosalad/erlang-jose",
          "tags": [
            "related"
          ],
          "url": "https://github.com/potatosalad/erlang-jose/commit/a7746ecd4950f85a393136e449a91dac62b5c429"
        },
        {
          "name": "Fix commit 72ce186 in potatosalad/erlang-jose",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/potatosalad/erlang-jose/commit/72ce1866622b9329347dc52a94173ac0317bc9cf"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "ECDSA signature length is not validated in jose, allowing signature malleability"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-65632",
    "datePublished": "2026-10-26T19:53:56.649Z",
    "dateReserved": "2026-07-22T13:58:26.233Z",
    "dateUpdated": "2026-10-26T19:53:56.649Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted