Common Weakness Enumeration

CWE-522

Allowed-with-Review

Insufficiently Protected Credentials

Abstraction: Class · Status: Incomplete

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

1811 vulnerabilities reference this CWE, most recent first.

GHSA-VF4C-CMQM-2C6V

Vulnerability from github – Published: 2022-05-13 01:14 – Updated: 2022-05-13 01:14
VLAI
Details

Users with Site-level permissions can access files containing the username-encrypted passwords of Security Console Global Administrators and clear-text passwords for restoring backups, as well as the salt for those passwords. Valid credentials are required to access these files and malicious users would still need to perform additional work to decrypt the credentials and escalate privileges. This issue affects: Rapid7 InsightVM versions 6.5.11 through 6.5.49.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-5615"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-09T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Users with Site-level permissions can access files containing the username-encrypted passwords of Security Console Global Administrators and clear-text passwords for restoring backups, as well as the salt for those passwords. Valid credentials are required to access these files and malicious users would still need to perform additional work to decrypt the credentials and escalate privileges. This issue affects: Rapid7 InsightVM versions 6.5.11 through 6.5.49.",
  "id": "GHSA-vf4c-cmqm-2c6v",
  "modified": "2022-05-13T01:14:31Z",
  "published": "2022-05-13T01:14:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5615"
    },
    {
      "type": "WEB",
      "url": "https://help.rapid7.com/insightvm/en-us/release-notes/#6.5.50"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VFFP-XX76-RFQC

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

An issue was discovered in Epikur before 20.1.1. It stores the secret passwords of the users as MD5 hashes in the database. MD5 can be brute-forced efficiently and should not be used for such purposes. Additionally, since no salt is used, rainbow tables can speed up the attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-10538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-05T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Epikur before 20.1.1. It stores the secret passwords of the users as MD5 hashes in the database. MD5 can be brute-forced efficiently and should not be used for such purposes. Additionally, since no salt is used, rainbow tables can speed up the attack.",
  "id": "GHSA-vffp-xx76-rfqc",
  "modified": "2022-05-24T17:41:09Z",
  "published": "2022-05-24T17:41:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10538"
    },
    {
      "type": "WEB",
      "url": "https://www.x41-dsec.de/lab/advisories/x41-2020-003-epikur"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VFG9-HGRQ-RJHQ

Vulnerability from github – Published: 2024-06-10 18:31 – Updated: 2024-07-05 18:34
VLAI
Details

GitHub access token could be exposed to third-party sites in JetBrains IDEs after version 2023.1 and less than: IntelliJ IDEA 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; Aqua 2024.1.2; CLion 2023.1.7, 2023.2.4, 2023.3.5, 2024.1.3, 2024.2 EAP2; DataGrip 2023.1.3, 2023.2.4, 2023.3.5, 2024.1.4; DataSpell 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.2, 2024.2 EAP1; GoLand 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; MPS 2023.2.1, 2023.3.1, 2024.1 EAP2; PhpStorm 2023.1.6, 2023.2.6, 2023.3.7, 2024.1.3, 2024.2 EAP3; PyCharm 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.3, 2024.2 EAP2; Rider 2023.1.7, 2023.2.5, 2023.3.6, 2024.1.3; RubyMine 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP4; RustRover 2024.1.1; WebStorm 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.4

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-37051"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-10T16:15:16Z",
    "severity": "CRITICAL"
  },
  "details": "GitHub access token could be exposed to third-party sites in JetBrains IDEs after version 2023.1 and less than: IntelliJ IDEA 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; Aqua 2024.1.2; CLion 2023.1.7, 2023.2.4, 2023.3.5, 2024.1.3, 2024.2 EAP2; DataGrip 2023.1.3, 2023.2.4, 2023.3.5, 2024.1.4; DataSpell 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.2, 2024.2 EAP1; GoLand 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP3; MPS 2023.2.1, 2023.3.1, 2024.1 EAP2; PhpStorm 2023.1.6, 2023.2.6, 2023.3.7, 2024.1.3, 2024.2 EAP3; PyCharm 2023.1.6, 2023.2.7, 2023.3.6, 2024.1.3, 2024.2 EAP2; Rider 2023.1.7, 2023.2.5, 2023.3.6, 2024.1.3; RubyMine 2023.1.7, 2023.2.7, 2023.3.7, 2024.1.3, 2024.2 EAP4; RustRover 2024.1.1; WebStorm 2023.1.6, 2023.2.7, 2023.3.7, 2024.1.4",
  "id": "GHSA-vfg9-hgrq-rjhq",
  "modified": "2024-07-05T18:34:13Z",
  "published": "2024-06-10T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37051"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240705-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VFHW-75MR-PG52

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2022-05-24 16:56
VLAI
Details

An issue was discovered in Grafana 5.4.0. Passwords for data sources used by Grafana (e.g., MySQL) are not encrypted. An admin user can reveal passwords for any data source by pressing the "Save and test" button within a data source's settings menu. When watching the transaction with Burp Proxy, the password for the data source is revealed and sent to the server. From a browser, a prompt to save the credentials is generated, and the password can be revealed by simply checking the "Show password" box.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-15635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-319",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-23T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Grafana 5.4.0. Passwords for data sources used by Grafana (e.g., MySQL) are not encrypted. An admin user can reveal passwords for any data source by pressing the \"Save and test\" button within a data source\u0027s settings menu. When watching the transaction with Burp Proxy, the password for the data source is revealed and sent to the server. From a browser, a prompt to save the credentials is generated, and the password can be revealed by simply checking the \"Show password\" box.",
  "id": "GHSA-vfhw-75mr-pg52",
  "modified": "2022-05-24T16:56:40Z",
  "published": "2022-05-24T16:56:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15635"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/167244"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20191009-0002"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VFPJ-RCWJ-86VM

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

An issue was discovered in certain configurations of GNOME gnome-shell through 3.36.4. When logging out of an account, the password box from the login dialog reappears with the password still visible. If the user had decided to have the password shown in cleartext at login time, it is then visible for a brief moment upon a logout. (If the password were never shown in cleartext, only the password length is revealed.)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-17489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-11T21:15:00Z",
    "severity": "LOW"
  },
  "details": "An issue was discovered in certain configurations of GNOME gnome-shell through 3.36.4. When logging out of an account, the password box from the login dialog reappears with the password still visible. If the user had decided to have the password shown in cleartext at login time, it is then visible for a brief moment upon a logout. (If the password were never shown in cleartext, only the password length is revealed.)",
  "id": "GHSA-vfpj-rcwj-86vm",
  "modified": "2022-05-24T17:25:20Z",
  "published": "2022-05-24T17:25:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-17489"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2997"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202009-08"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4464-1"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-11/msg00028.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VFQ4-W7V4-7PF6

Vulnerability from github – Published: 2025-11-07 00:30 – Updated: 2025-11-07 00:30
VLAI
Details

The Ubia camera ecosystem fails to adequately secure API credentials, potentially enabling an attacker to connect to backend services. The attacker would then be able to gain unauthorized access to available cameras, enabling the viewing of live feeds or modification of settings.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-12636"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-06T23:15:35Z",
    "severity": "HIGH"
  },
  "details": "The Ubia camera ecosystem fails to adequately secure API credentials, \npotentially enabling an attacker to connect to backend services. The \nattacker would then be able to gain unauthorized access to available \ncameras, enabling the viewing of live feeds or modification of settings.",
  "id": "GHSA-vfq4-w7v4-7pf6",
  "modified": "2025-11-07T00:30:31Z",
  "published": "2025-11-07T00:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12636"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2025/icsa-25-310-02.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-310-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/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-VFWW-2927-4QJ3

Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53
VLAI
Details

An issue was discovered on Eaton UPS 9PX 8000 SP devices. The appliance discloses the user's password. The web page displayed by the appliance contains the password in cleartext. Passwords could be retrieved by browsing the source code of the webpage.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-9279"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-24T21:29:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered on Eaton UPS 9PX 8000 SP devices. The appliance discloses the user\u0027s password. The web page displayed by the appliance contains the password in cleartext. Passwords could be retrieved by browsing the source code of the webpage.",
  "id": "GHSA-vfww-2927-4qj3",
  "modified": "2022-05-13T01:53:54Z",
  "published": "2022-05-13T01:53:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-9279"
    },
    {
      "type": "WEB",
      "url": "https://www.bishopfox.com/news/2018/10/eaton-ups-9px-8000-sp-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VG9R-2V55-894R

Vulnerability from github – Published: 2026-03-25 21:30 – Updated: 2026-03-25 21:30
VLAI
Details

IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 could allow an attacker to obtain sensitive information due to insufficiently protected credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14790"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-25T20:16:22Z",
    "severity": "MODERATE"
  },
  "details": "IBM InfoSphere Information Server 11.7.0.0 through 11.7.1.6 could allow an attacker to obtain sensitive information due to insufficiently protected credentials.",
  "id": "GHSA-vg9r-2v55-894r",
  "modified": "2026-03-25T21:30:35Z",
  "published": "2026-03-25T21:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14790"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7266688"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VGGC-4GWQ-RQ7X

Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09
VLAI
Details

Ypsomed mylife Cloud, mylife Mobile Application:Ypsomed mylife Cloud,All versions prior to 1.7.2,Ypsomed mylife App,All versions prior to 1.7.5,The Ypsomed mylife Cloud discloses password hashes during the registration process.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-27491"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-30T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Ypsomed mylife Cloud, mylife Mobile Application:Ypsomed mylife Cloud,All versions prior to 1.7.2,Ypsomed mylife App,All versions prior to 1.7.5,The Ypsomed mylife Cloud discloses password hashes during the registration process.",
  "id": "GHSA-vggc-4gwq-rq7x",
  "modified": "2022-05-24T19:09:28Z",
  "published": "2022-05-24T19:09:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27491"
    },
    {
      "type": "WEB",
      "url": "https://us-cert.cisa.gov/ics/advisories/icsma-21-196-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-VH4V-2XQ2-G5CG

Vulnerability from github – Published: 2026-07-01 21:54 – Updated: 2026-07-01 21:54
VLAI
Summary
ORAS Go forwards registry credentials across registry redirects
Details

ORAS Go forwards registry credentials across registry redirects

Reporter / public credit: JUNYI LIU

Summary

ORAS Go can forward registry credentials configured for one registry origin to a different HTTP origin during registry redirects.

There are two related paths:

  1. A manifest or metadata request authenticates to the origin registry, then the origin returns a redirect to another host or port. The redirected request can carry the origin Authorization header to the redirect target.
  2. A blob upload POST authenticates to the origin registry, then the origin returns an upload Location on another host or port. The follow-up PUT can carry the origin Authorization header to the Location target.

The upload Location issue appears related to the existing public fix in pull request #1152 / GHSA-jxpm-75mh-9fp7. The manifest redirect path is a residual adjacent route: the v2 branch after the upload Location fix still forwards Basic credentials on an authenticated manifest redirect.

Impact

A registry response can cause an ORAS Go or ORAS CLI client to send configured registry credentials to an unintended endpoint. In common workflows, those credentials may come from a registry config / Docker-style auth file rather than command-line flags.

This is a credential exposure across the registry-origin boundary. I am not claiming remote code execution, registry compromise, arbitrary token theft, or live third-party impact.

Affected Versions Tested

  • oras-go v2.6.0: affected.
  • oras-go main at commit a57383e580c8f2c97fb67dedfc5c9945c8c3614e: affected.
  • oras-go v2 branch at commit d593d504779be8b69f0ba034ac9fd407d1fc8cfc: upload Location path is blocked, but manifest redirect credential forwarding is still affected.
  • ORAS CLI at commit 3d2646279c70ba60415440e44c2ff97896e4a209, using oras-go v2.6.0: affected when using --registry-config.

Security Invariant

Credentials resolved for one registry origin should not be silently forwarded to a different origin reached through a registry redirect or upload Location response.

Local Reproduction Overview

All testing used loopback servers and fake credentials only.

Manifest redirect flow:

  1. The client requests a manifest from the origin registry.
  2. The origin returns 401 with a Basic challenge.
  3. The client retries the origin request with the origin credential.
  4. The origin returns 307 to another port on the same hostname.
  5. The redirect sink receives the origin Authorization header.

ORAS CLI stored-credential flow:

  1. A temporary registry config contains a fake Basic credential for the origin registry only.
  2. Run:
oras manifest fetch --plain-http --registry-config <config> <origin>/probe:latest
  1. The origin authenticates the request and redirects it to another port.
  2. The redirect sink receives the origin Authorization header.

Blob upload Location flow:

  1. The client starts a blob upload with POST to the origin registry.
  2. The origin challenges with Basic and then accepts the authenticated POST.
  3. The origin returns an upload Location URL on another port.
  4. In affected versions, the follow-up PUT to the Location target carries the origin Authorization header.

Expected Result

Redirect and upload Location targets on a different HTTP origin should not receive the origin Authorization header.

Observed Result

In affected versions, redirect or Location sinks received:

Authorization: Basic <base64 origin_user:origin_pass>

Standalone Reproducer

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "net/http/httptest"
    "os"
    "sync"

    "github.com/opencontainers/go-digest"
    "github.com/oras-project/oras-go/v3/registry/remote"
    "github.com/oras-project/oras-go/v3/registry/remote/auth"
    "github.com/oras-project/oras-go/v3/registry/remote/credentials"
)

type hit struct {
    Method string `json:"method"`
    Path   string `json:"path"`
    Host   string `json:"host"`
    Auth   string `json:"auth,omitempty"`
}

func main() {
    const username = "origin_user"
    const password = "origin_pass"
    const expectedAuth = "Basic b3JpZ2luX3VzZXI6b3JpZ2luX3Bhc3M="
    var mu sync.Mutex
    var originHits, sinkHits []hit

    record := func(dst *[]hit, r *http.Request) {
        mu.Lock()
        defer mu.Unlock()
        *dst = append(*dst, hit{
            Method: r.Method,
            Path:   r.URL.RequestURI(),
            Host:   r.Host,
            Auth:   r.Header.Get("Authorization"),
        })
    }

    manifest := []byte(`{"schemaVersion":2,"mediaType":"application/vnd.oci.image.manifest.v1+json","config":{"mediaType":"application/vnd.unknown.config.v1+json","digest":"sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a","size":2},"layers":[]}`)
    manifestDigest := digest.FromBytes(manifest).String()

    sink := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        record(&sinkHits, r)
        if r.Header.Get("Authorization") != expectedAuth {
            w.Header().Set("Www-Authenticate", `Basic realm="redirect-sink"`)
            w.WriteHeader(http.StatusUnauthorized)
            return
        }
        w.Header().Set("Content-Type", "application/vnd.oci.image.manifest.v1+json")
        w.Header().Set("Docker-Content-Digest", manifestDigest)
        w.Header().Set("Content-Length", fmt.Sprint(len(manifest)))
        _, _ = w.Write(manifest)
    }))
    defer sink.Close()

    origin := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        record(&originHits, r)
        if r.Header.Get("Authorization") != expectedAuth {
            w.Header().Set("Www-Authenticate", `Basic realm="origin"`)
            w.WriteHeader(http.StatusUnauthorized)
            return
        }
        http.Redirect(w, r, sink.URL+r.URL.RequestURI(), http.StatusTemporaryRedirect)
    }))
    defer origin.Close()

    repo, err := remote.NewRepository(origin.Listener.Addr().String() + "/probe")
    if err != nil {
        panic(err)
    }
    repo.PlainHTTP = true
    repo.Client = &auth.Client{
        Client: origin.Client(),
        CredentialFunc: credentials.StaticCredentialFunc(origin.Listener.Addr().String(), credentials.Credential{
            Username: username,
            Password: password,
        }),
    }

    _, _, err = repo.Manifests().FetchReference(context.Background(), "latest")

    leaked := false
    for _, h := range sinkHits {
        if h.Auth == expectedAuth {
            leaked = true
        }
    }

    result := map[string]any{
        "origin_hits": originHits,
        "sink_hits":   sinkHits,
        "error":       "",
        "leaked":      leaked,
    }
    if err != nil {
        result["error"] = err.Error()
    }
    encoded, _ := json.MarshalIndent(result, "", "  ")
    fmt.Println(string(encoded))

    if leaked {
        fmt.Println("VULNERABLE_BEHAVIOR_CONFIRMED")
        return
    }
    fmt.Println("BOUNDARY_HELD_NO_CREDENTIAL_LEAK")
    os.Exit(1)
}

Candidate Fix

The candidate fix does two things:

  1. In the auth client, wrap redirect handling so Authorization is removed when a redirect changes HTTP origin, while preserving any caller-provided CheckRedirect callback.
  2. In blob upload completion, only reuse the previous POST Authorization header when the upload Location remains on the same HTTP origin.

The patch also adds regression coverage for both redirect cases:

  • redirect before origin authentication reaches a different origin;
  • redirect after origin authentication reaches a different origin.
diff --git a/registry/remote/auth/client.go b/registry/remote/auth/client.go
index 35826eb..60c9f88 100644
--- a/registry/remote/auth/client.go
+++ b/registry/remote/auth/client.go
@@ -122,7 +122,23 @@ func (c *Client) send(req *http.Request) (*http.Response, error) {
    for key, values := range c.Header {
        req.Header[key] = append(req.Header[key], values...)
    }
-   return c.client().Do(req)
+   client := c.client()
+   clientCopy := *client
+   checkRedirect := client.CheckRedirect
+   clientCopy.CheckRedirect = func(redirectReq *http.Request, via []*http.Request) error {
+       if len(via) > 0 && !sameHTTPOrigin(via[len(via)-1].URL, redirectReq.URL) {
+           redirectReq.Header.Del(headerAuthorization)
+       }
+       if checkRedirect != nil {
+           return checkRedirect(redirectReq, via)
+       }
+       return nil
+   }
+   return clientCopy.Do(req)
+}
+
+func sameHTTPOrigin(a, b *url.URL) bool {
+   return strings.EqualFold(a.Scheme, b.Scheme) && strings.EqualFold(a.Host, b.Host)
 }

 // credential resolves the credential for the given registry.
@@ -168,6 +184,9 @@ func (c *Client) Do(originalReq *http.Request) (*http.Response, error) {
    var attemptedKey string
    cache := c.cache()
    host := originalReq.Host
+   if host == "" {
+       host = originalReq.URL.Host
+   }
    scheme, err := cache.GetScheme(ctx, host)
    if err == nil {
        switch scheme {
@@ -193,6 +212,13 @@ func (c *Client) Do(originalReq *http.Request) (*http.Response, error) {
    if resp.StatusCode != http.StatusUnauthorized {
        return resp, nil
    }
+   respHost := resp.Request.Host
+   if respHost == "" {
+       respHost = resp.Request.URL.Host
+   }
+   if respHost != host {
+       return resp, nil
+   }

    // attempt again with credentials for recognized schemes
    challenge := resp.Header.Get(headerWWWAuthenticate)
diff --git a/registry/remote/repository.go b/registry/remote/repository.go
index 74d6b89..0bd20ec 100644
--- a/registry/remote/repository.go
+++ b/registry/remote/repository.go
@@ -982,6 +983,7 @@ func (s *blobStore) Push(ctx context.Context, expected ocispec.Descriptor, conte
 // Push or by Mount when the receiving repository does not implement the
 // mount endpoint.
 func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.Request, resp *http.Response, expected ocispec.Descriptor, content io.Reader) error {
+   originalURL := req.URL
    reqHostname := req.URL.Hostname()
    reqPort := req.URL.Port()
    // monolithic upload
@@ -1016,8 +1018,9 @@ func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.
    q.Set("digest", expected.Digest.String())
    req.URL.RawQuery = q.Encode()

-   // reuse credential from previous POST request
-   if auth := resp.Request.Header.Get("Authorization"); auth != "" {
+   // reuse credential from previous POST request only when the upload location
+   // remains on the same origin.
+   if auth := resp.Request.Header.Get("Authorization"); auth != "" && sameHTTPOrigin(originalURL, location) {
        req.Header.Set("Authorization", auth)
    }
    resp, err = s.repo.do(req)
@@ -1032,6 +1035,10 @@ func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.
    return nil
 }

+func sameHTTPOrigin(a, b *url.URL) bool {
+   return strings.EqualFold(a.Scheme, b.Scheme) && strings.EqualFold(a.Host, b.Host)
+}
+
 // Exists returns true if the described content exists.
 func (s *blobStore) Exists(ctx context.Context, target ocispec.Descriptor) (bool, error) {
    if err := s.repo.checkPolicy(ctx, ""); err != nil {

Validation Performed

The repaired candidate fix blocked:

  • manifest redirect credential forwarding;
  • upload Location credential forwarding.

Targeted tests passed:

go test ./registry/remote/auth -run 'TestClient_Do_Basic_Auth_Redirect|TestClient_Do' -count=1
go test ./registry/remote -run 'Test_BlobStore_Push|TestRepository' -count=1

Prior Art / Duplicate Notes

Public pull request #1152 fixes credential forwarding via unvalidated blob upload Location and references GHSA-jxpm-75mh-9fp7. The residual manifest redirect path described here is adjacent but not covered by that PR's stated upload Location scope.

Bearer realm credential exfiltration appears to be a separate issue family and is not part of this report's primary claim.

Claim Boundaries

Proven:

  • Origin registry Basic credentials can reach a different redirect or upload Location origin in local loopback tests.
  • ORAS CLI stored registry credentials can reach a redirect sink in a normal manifest fetch workflow.
  • The candidate fix blocks the tested redirect and upload Location credential exposures.

Not claimed:

  • Live third-party exploitation.
  • RCE, host compromise, or registry compromise.
  • Arbitrary-host exposure beyond the tested redirect/Location origin transitions.
  • Bearer realm behavior as part of the same claim.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "oras.land/oras-go/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T21:54:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# ORAS Go forwards registry credentials across registry redirects\n\nReporter / public credit: JUNYI LIU\n\n## Summary\n\nORAS Go can forward registry credentials configured for one registry origin to a different HTTP origin during registry redirects.\n\nThere are two related paths:\n\n1. A manifest or metadata request authenticates to the origin registry, then the origin returns a redirect to another host or port. The redirected request can carry the origin `Authorization` header to the redirect target.\n2. A blob upload `POST` authenticates to the origin registry, then the origin returns an upload `Location` on another host or port. The follow-up `PUT` can carry the origin `Authorization` header to the `Location` target.\n\nThe upload `Location` issue appears related to the existing public fix in pull request #1152 / GHSA-jxpm-75mh-9fp7. The manifest redirect path is a residual adjacent route: the v2 branch after the upload `Location` fix still forwards Basic credentials on an authenticated manifest redirect.\n\n## Impact\n\nA registry response can cause an ORAS Go or ORAS CLI client to send configured registry credentials to an unintended endpoint. In common workflows, those credentials may come from a registry config / Docker-style auth file rather than command-line flags.\n\nThis is a credential exposure across the registry-origin boundary. I am not claiming remote code execution, registry compromise, arbitrary token theft, or live third-party impact.\n\n## Affected Versions Tested\n\n- `oras-go v2.6.0`: affected.\n- `oras-go` main at commit `a57383e580c8f2c97fb67dedfc5c9945c8c3614e`: affected.\n- `oras-go` v2 branch at commit `d593d504779be8b69f0ba034ac9fd407d1fc8cfc`: upload `Location` path is blocked, but manifest redirect credential forwarding is still affected.\n- ORAS CLI at commit `3d2646279c70ba60415440e44c2ff97896e4a209`, using `oras-go v2.6.0`: affected when using `--registry-config`.\n\n## Security Invariant\n\nCredentials resolved for one registry origin should not be silently forwarded to a different origin reached through a registry redirect or upload `Location` response.\n\n## Local Reproduction Overview\n\nAll testing used loopback servers and fake credentials only.\n\nManifest redirect flow:\n\n1. The client requests a manifest from the origin registry.\n2. The origin returns `401` with a Basic challenge.\n3. The client retries the origin request with the origin credential.\n4. The origin returns `307` to another port on the same hostname.\n5. The redirect sink receives the origin `Authorization` header.\n\nORAS CLI stored-credential flow:\n\n1. A temporary registry config contains a fake Basic credential for the origin registry only.\n2. Run:\n\n```sh\noras manifest fetch --plain-http --registry-config \u003cconfig\u003e \u003corigin\u003e/probe:latest\n```\n\n3. The origin authenticates the request and redirects it to another port.\n4. The redirect sink receives the origin `Authorization` header.\n\nBlob upload `Location` flow:\n\n1. The client starts a blob upload with `POST` to the origin registry.\n2. The origin challenges with Basic and then accepts the authenticated `POST`.\n3. The origin returns an upload `Location` URL on another port.\n4. In affected versions, the follow-up `PUT` to the `Location` target carries the origin `Authorization` header.\n\n## Expected Result\n\nRedirect and upload `Location` targets on a different HTTP origin should not receive the origin `Authorization` header.\n\n## Observed Result\n\nIn affected versions, redirect or `Location` sinks received:\n\n```http\nAuthorization: Basic \u003cbase64 origin_user:origin_pass\u003e\n```\n\n## Standalone Reproducer\n\n```go\npackage main\n\nimport (\n\t\"context\"\n\t\"encoding/json\"\n\t\"fmt\"\n\t\"net/http\"\n\t\"net/http/httptest\"\n\t\"os\"\n\t\"sync\"\n\n\t\"github.com/opencontainers/go-digest\"\n\t\"github.com/oras-project/oras-go/v3/registry/remote\"\n\t\"github.com/oras-project/oras-go/v3/registry/remote/auth\"\n\t\"github.com/oras-project/oras-go/v3/registry/remote/credentials\"\n)\n\ntype hit struct {\n\tMethod string `json:\"method\"`\n\tPath   string `json:\"path\"`\n\tHost   string `json:\"host\"`\n\tAuth   string `json:\"auth,omitempty\"`\n}\n\nfunc main() {\n\tconst username = \"origin_user\"\n\tconst password = \"origin_pass\"\n\tconst expectedAuth = \"Basic b3JpZ2luX3VzZXI6b3JpZ2luX3Bhc3M=\"\n\tvar mu sync.Mutex\n\tvar originHits, sinkHits []hit\n\n\trecord := func(dst *[]hit, r *http.Request) {\n\t\tmu.Lock()\n\t\tdefer mu.Unlock()\n\t\t*dst = append(*dst, hit{\n\t\t\tMethod: r.Method,\n\t\t\tPath:   r.URL.RequestURI(),\n\t\t\tHost:   r.Host,\n\t\t\tAuth:   r.Header.Get(\"Authorization\"),\n\t\t})\n\t}\n\n\tmanifest := []byte(`{\"schemaVersion\":2,\"mediaType\":\"application/vnd.oci.image.manifest.v1+json\",\"config\":{\"mediaType\":\"application/vnd.unknown.config.v1+json\",\"digest\":\"sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a\",\"size\":2},\"layers\":[]}`)\n\tmanifestDigest := digest.FromBytes(manifest).String()\n\n\tsink := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\trecord(\u0026sinkHits, r)\n\t\tif r.Header.Get(\"Authorization\") != expectedAuth {\n\t\t\tw.Header().Set(\"Www-Authenticate\", `Basic realm=\"redirect-sink\"`)\n\t\t\tw.WriteHeader(http.StatusUnauthorized)\n\t\t\treturn\n\t\t}\n\t\tw.Header().Set(\"Content-Type\", \"application/vnd.oci.image.manifest.v1+json\")\n\t\tw.Header().Set(\"Docker-Content-Digest\", manifestDigest)\n\t\tw.Header().Set(\"Content-Length\", fmt.Sprint(len(manifest)))\n\t\t_, _ = w.Write(manifest)\n\t}))\n\tdefer sink.Close()\n\n\torigin := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\trecord(\u0026originHits, r)\n\t\tif r.Header.Get(\"Authorization\") != expectedAuth {\n\t\t\tw.Header().Set(\"Www-Authenticate\", `Basic realm=\"origin\"`)\n\t\t\tw.WriteHeader(http.StatusUnauthorized)\n\t\t\treturn\n\t\t}\n\t\thttp.Redirect(w, r, sink.URL+r.URL.RequestURI(), http.StatusTemporaryRedirect)\n\t}))\n\tdefer origin.Close()\n\n\trepo, err := remote.NewRepository(origin.Listener.Addr().String() + \"/probe\")\n\tif err != nil {\n\t\tpanic(err)\n\t}\n\trepo.PlainHTTP = true\n\trepo.Client = \u0026auth.Client{\n\t\tClient: origin.Client(),\n\t\tCredentialFunc: credentials.StaticCredentialFunc(origin.Listener.Addr().String(), credentials.Credential{\n\t\t\tUsername: username,\n\t\t\tPassword: password,\n\t\t}),\n\t}\n\n\t_, _, err = repo.Manifests().FetchReference(context.Background(), \"latest\")\n\n\tleaked := false\n\tfor _, h := range sinkHits {\n\t\tif h.Auth == expectedAuth {\n\t\t\tleaked = true\n\t\t}\n\t}\n\n\tresult := map[string]any{\n\t\t\"origin_hits\": originHits,\n\t\t\"sink_hits\":   sinkHits,\n\t\t\"error\":       \"\",\n\t\t\"leaked\":      leaked,\n\t}\n\tif err != nil {\n\t\tresult[\"error\"] = err.Error()\n\t}\n\tencoded, _ := json.MarshalIndent(result, \"\", \"  \")\n\tfmt.Println(string(encoded))\n\n\tif leaked {\n\t\tfmt.Println(\"VULNERABLE_BEHAVIOR_CONFIRMED\")\n\t\treturn\n\t}\n\tfmt.Println(\"BOUNDARY_HELD_NO_CREDENTIAL_LEAK\")\n\tos.Exit(1)\n}\n```\n\n## Candidate Fix\n\nThe candidate fix does two things:\n\n1. In the auth client, wrap redirect handling so `Authorization` is removed when a redirect changes HTTP origin, while preserving any caller-provided `CheckRedirect` callback.\n2. In blob upload completion, only reuse the previous `POST` `Authorization` header when the upload `Location` remains on the same HTTP origin.\n\nThe patch also adds regression coverage for both redirect cases:\n\n- redirect before origin authentication reaches a different origin;\n- redirect after origin authentication reaches a different origin.\n\n```diff\ndiff --git a/registry/remote/auth/client.go b/registry/remote/auth/client.go\nindex 35826eb..60c9f88 100644\n--- a/registry/remote/auth/client.go\n+++ b/registry/remote/auth/client.go\n@@ -122,7 +122,23 @@ func (c *Client) send(req *http.Request) (*http.Response, error) {\n \tfor key, values := range c.Header {\n \t\treq.Header[key] = append(req.Header[key], values...)\n \t}\n-\treturn c.client().Do(req)\n+\tclient := c.client()\n+\tclientCopy := *client\n+\tcheckRedirect := client.CheckRedirect\n+\tclientCopy.CheckRedirect = func(redirectReq *http.Request, via []*http.Request) error {\n+\t\tif len(via) \u003e 0 \u0026\u0026 !sameHTTPOrigin(via[len(via)-1].URL, redirectReq.URL) {\n+\t\t\tredirectReq.Header.Del(headerAuthorization)\n+\t\t}\n+\t\tif checkRedirect != nil {\n+\t\t\treturn checkRedirect(redirectReq, via)\n+\t\t}\n+\t\treturn nil\n+\t}\n+\treturn clientCopy.Do(req)\n+}\n+\n+func sameHTTPOrigin(a, b *url.URL) bool {\n+\treturn strings.EqualFold(a.Scheme, b.Scheme) \u0026\u0026 strings.EqualFold(a.Host, b.Host)\n }\n \n // credential resolves the credential for the given registry.\n@@ -168,6 +184,9 @@ func (c *Client) Do(originalReq *http.Request) (*http.Response, error) {\n \tvar attemptedKey string\n \tcache := c.cache()\n \thost := originalReq.Host\n+\tif host == \"\" {\n+\t\thost = originalReq.URL.Host\n+\t}\n \tscheme, err := cache.GetScheme(ctx, host)\n \tif err == nil {\n \t\tswitch scheme {\n@@ -193,6 +212,13 @@ func (c *Client) Do(originalReq *http.Request) (*http.Response, error) {\n \tif resp.StatusCode != http.StatusUnauthorized {\n \t\treturn resp, nil\n \t}\n+\trespHost := resp.Request.Host\n+\tif respHost == \"\" {\n+\t\trespHost = resp.Request.URL.Host\n+\t}\n+\tif respHost != host {\n+\t\treturn resp, nil\n+\t}\n \n \t// attempt again with credentials for recognized schemes\n \tchallenge := resp.Header.Get(headerWWWAuthenticate)\ndiff --git a/registry/remote/repository.go b/registry/remote/repository.go\nindex 74d6b89..0bd20ec 100644\n--- a/registry/remote/repository.go\n+++ b/registry/remote/repository.go\n@@ -982,6 +983,7 @@ func (s *blobStore) Push(ctx context.Context, expected ocispec.Descriptor, conte\n // Push or by Mount when the receiving repository does not implement the\n // mount endpoint.\n func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.Request, resp *http.Response, expected ocispec.Descriptor, content io.Reader) error {\n+\toriginalURL := req.URL\n \treqHostname := req.URL.Hostname()\n \treqPort := req.URL.Port()\n \t// monolithic upload\n@@ -1016,8 +1018,9 @@ func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.\n \tq.Set(\"digest\", expected.Digest.String())\n \treq.URL.RawQuery = q.Encode()\n \n-\t// reuse credential from previous POST request\n-\tif auth := resp.Request.Header.Get(\"Authorization\"); auth != \"\" {\n+\t// reuse credential from previous POST request only when the upload location\n+\t// remains on the same origin.\n+\tif auth := resp.Request.Header.Get(\"Authorization\"); auth != \"\" \u0026\u0026 sameHTTPOrigin(originalURL, location) {\n \t\treq.Header.Set(\"Authorization\", auth)\n \t}\n \tresp, err = s.repo.do(req)\n@@ -1032,6 +1035,10 @@ func (s *blobStore) completePushAfterInitialPost(ctx context.Context, req *http.\n \treturn nil\n }\n \n+func sameHTTPOrigin(a, b *url.URL) bool {\n+\treturn strings.EqualFold(a.Scheme, b.Scheme) \u0026\u0026 strings.EqualFold(a.Host, b.Host)\n+}\n+\n // Exists returns true if the described content exists.\n func (s *blobStore) Exists(ctx context.Context, target ocispec.Descriptor) (bool, error) {\n \tif err := s.repo.checkPolicy(ctx, \"\"); err != nil {\n```\n\n## Validation Performed\n\nThe repaired candidate fix blocked:\n\n- manifest redirect credential forwarding;\n- upload `Location` credential forwarding.\n\nTargeted tests passed:\n\n```sh\ngo test ./registry/remote/auth -run \u0027TestClient_Do_Basic_Auth_Redirect|TestClient_Do\u0027 -count=1\ngo test ./registry/remote -run \u0027Test_BlobStore_Push|TestRepository\u0027 -count=1\n```\n\n## Prior Art / Duplicate Notes\n\nPublic pull request #1152 fixes credential forwarding via unvalidated blob upload `Location` and references GHSA-jxpm-75mh-9fp7. The residual manifest redirect path described here is adjacent but not covered by that PR\u0027s stated upload `Location` scope.\n\nBearer realm credential exfiltration appears to be a separate issue family and is not part of this report\u0027s primary claim.\n\n## Claim Boundaries\n\nProven:\n\n- Origin registry Basic credentials can reach a different redirect or upload `Location` origin in local loopback tests.\n- ORAS CLI stored registry credentials can reach a redirect sink in a normal manifest fetch workflow.\n- The candidate fix blocks the tested redirect and upload `Location` credential exposures.\n\nNot claimed:\n\n- Live third-party exploitation.\n- RCE, host compromise, or registry compromise.\n- Arbitrary-host exposure beyond the tested redirect/`Location` origin transitions.\n- Bearer realm behavior as part of the same claim.",
  "id": "GHSA-vh4v-2xq2-g5cg",
  "modified": "2026-07-01T21:54:06Z",
  "published": "2026-07-01T21:54:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/security/advisories/GHSA-vh4v-2xq2-g5cg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/commit/3c2e884e12ea52b6bff60c97f1edb7df7d0e0909"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/oras-project/oras-go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oras-project/oras-go/releases/tag/v2.6.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ORAS Go forwards registry credentials across registry redirects"
}

Mitigation
Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Mitigation
Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Mitigation
Implementation

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-474: Signature Spoofing by Key Theft

An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.

CAPEC-50: Password Recovery Exploitation

An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.

CAPEC-509: Kerberoasting

Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.

CAPEC-551: Modify Existing Service

When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.

CAPEC-555: Remote Services with Stolen Credentials

This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.

CAPEC-560: Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.

CAPEC-561: Windows Admin Shares with Stolen Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.

CAPEC-600: Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.

CAPEC-644: Use of Captured Hashes (Pass The Hash)

An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.

CAPEC-645: Use of Captured Tickets (Pass The Ticket)

An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

CAPEC-653: Use of Known Operating System Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.