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.
1824 vulnerabilities reference this CWE, most recent first.
GHSA-828P-X24M-MVW6
Vulnerability from github – Published: 2025-01-22 18:31 – Updated: 2025-02-04 21:32GRAU DATA Blocky before 3.1 stores passwords encrypted rather than hashed. At the login screen, the user's password is compared to the user's decrypted cleartext password. An attacker with Windows admin or debugging rights can therefore steal the user's Blocky password and from there impersonate that local user.
{
"affected": [],
"aliases": [
"CVE-2024-42012"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-22T16:15:29Z",
"severity": "MODERATE"
},
"details": "GRAU DATA Blocky before 3.1 stores passwords encrypted rather than hashed. At the login screen, the user\u0027s password is compared to the user\u0027s decrypted cleartext password. An attacker with Windows admin or debugging rights can therefore steal the user\u0027s Blocky password and from there impersonate that local user.",
"id": "GHSA-828p-x24m-mvw6",
"modified": "2025-02-04T21:32:26Z",
"published": "2025-01-22T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42012"
},
{
"type": "WEB",
"url": "https://www.blockyforveeam.com/en/security-bulletin-2024-06-25"
},
{
"type": "WEB",
"url": "https://www.graudata.com/en/products/protection-against-ransomware/blocky-for-veeam"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-82C4-6QCM-PJXG
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-07-13 00:00DEPSTECH WiFi Digital Microscope 3 has a default SSID of Jetion_xxxxxxxx with a password of 12345678.
{
"affected": [],
"aliases": [
"CVE-2020-12732"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-15T16:15:00Z",
"severity": "MODERATE"
},
"details": "DEPSTECH WiFi Digital Microscope 3 has a default SSID of Jetion_xxxxxxxx with a password of 12345678.",
"id": "GHSA-82c4-6qcm-pjxg",
"modified": "2022-07-13T00:00:42Z",
"published": "2022-05-24T19:08:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12732"
},
{
"type": "WEB",
"url": "https://github.com/ethanhunnt/IoT_vulnerabilities/blob/master/Depstech%20Microscope%20Smart%20Kid%20Toy.pdf"
},
{
"type": "WEB",
"url": "https://www.depstech.com/mw001-s02-wifi-usb-digital-microscope"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-82RF-Q3PR-4F6P
Vulnerability from github – Published: 2020-10-08 22:11 – Updated: 2023-09-11 20:18Preview versions of two NPM packages and one Deno package from the NATS project contain an information disclosure flaw, leaking options to the NATS server; for one package, this includes TLS private credentials.
The _connection_ configuration options in these JavaScript-based implementations were fully serialized and sent to the server in the client's CONNECT message, immediately after TLS establishment.
The nats.js client supports Mutual TLS and the credentials for the TLS client key are included in the connection configuration options; disclosure of the client's TLS private key to the server has been observed.
Most authentication mechanisms are handled after connection, instead of as part of connection, so other authentication mechanisms are unaffected. For clarity: NATS account NKey authentication is NOT affected.
Neither the nats.ws nor the nats.deno clients support Mutual TLS: the affected versions listed below are those where the logic flaw is present. We are including the nats.ws and nats.deno versions out of an abundance of caution, as library maintainers, but rate as minimal the likelihood of applications leaking sensitive data.
Security impact:
- NPM package nats.js:
- mainline is unaffected
- beta branch is vulnerable from 2.0.0-201, fixed in 2.0.0-209
Logic flaw:
- NPM package nats.ws:
- status: preview
- flawed from 1.0.0-85, fixed in 1.0.0-111
- Deno repository https://github.com/nats-io/nats.deno
- status: preview
- flawed in all git tags prior to fix
- fixed with git tag v1.0.0-9
Impact:
For deployments using TLS client certificates (for mutual TLS), private key material for TLS is leaked from the client application to the server. If the server is untrusted (run by a third party), or if the client application also disables TLS verification (and so the true identity of the server is unverifiable) then authentication credentials are leaked.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.0-206"
},
"package": {
"ecosystem": "npm",
"name": "nats"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-201"
},
{
"fixed": "2.0.0-209"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.0-110"
},
"package": {
"ecosystem": "npm",
"name": "nats.ws"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0-85"
},
{
"fixed": "1.0.0-111"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-26149"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2020-10-08T22:11:09Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Preview versions of two NPM packages and one Deno package from the NATS project contain an information disclosure flaw, leaking options to the NATS server; for one package, this includes TLS private credentials.\n\nThe `_connection_` configuration options in these JavaScript-based implementations were fully serialized and sent to the server in the client\u0027s CONNECT message, immediately after TLS establishment.\n\nThe nats.js client supports Mutual TLS and the credentials for the TLS client key are included in the connection configuration options; disclosure of the client\u0027s TLS private key to the server has been observed.\n\nMost authentication mechanisms are handled after connection, instead of as part of connection, so other authentication mechanisms are unaffected. For clarity: NATS account NKey authentication is NOT affected.\n\nNeither the nats.ws nor the nats.deno clients support Mutual TLS: the affected versions listed below are those where the logic flaw is present. We are including the nats.ws and nats.deno versions out of an abundance of caution, as library maintainers, but rate as minimal the likelihood of applications leaking sensitive data.\n\n### Security impact:\n\n* NPM package nats.js:\n+ mainline is unaffected\n+ beta branch is vulnerable from 2.0.0-201, fixed in 2.0.0-209\n\n### Logic flaw:\n\n* NPM package nats.ws:\n+ status: preview\n+ flawed from 1.0.0-85, fixed in 1.0.0-111\n* Deno repository https://github.com/nats-io/nats.deno\n+ status: preview\n+ flawed in all git tags prior to fix\n+ fixed with git tag v1.0.0-9\n\n### Impact:\n\nFor deployments using TLS client certificates (for mutual TLS), private key material for TLS is leaked from the client application to the server. If the server is untrusted (run by a third party), or if the client application also disables TLS verification (and so the true identity of the server is unverifiable) then authentication credentials are leaked.",
"id": "GHSA-82rf-q3pr-4f6p",
"modified": "2023-09-11T20:18:19Z",
"published": "2020-10-08T22:11:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26149"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/nats.ws/commit/0a37ac2a411ff63f0707cda69a268c5fc4079eb7"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/nats.deno/compare/v1.0.0-8...v1.0.0-9"
},
{
"type": "PACKAGE",
"url": "https://github.com/nats-io/nats.ws"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/09/30/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Sensitive data exposure in NATS"
}
GHSA-82WV-QVFH-PQC2
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44A BIOS password extraction vulnerability has been reported on certain consumer notebooks with firmware F.22 and others. The BIOS password was stored in CMOS in a way that allowed it to be extracted. This applies to consumer notebooks launched in early 2014.
{
"affected": [],
"aliases": [
"CVE-2017-2751"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-03T20:29:00Z",
"severity": "MODERATE"
},
"details": "A BIOS password extraction vulnerability has been reported on certain consumer notebooks with firmware F.22 and others. The BIOS password was stored in CMOS in a way that allowed it to be extracted. This applies to consumer notebooks launched in early 2014.",
"id": "GHSA-82wv-qvfh-pqc2",
"modified": "2022-05-13T01:44:57Z",
"published": "2022-05-13T01:44:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2751"
},
{
"type": "WEB",
"url": "https://support.hp.com/us-en/document/c05913581"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-833G-CQHP-H72J
Vulnerability from github – Published: 2026-07-20 22:17 – Updated: 2026-07-20 22:17Summary
When a user creates a password-protected share or lists existing shares, the JSON response includes the full bcrypt password_hash and the secret token of the share. The Link storage struct is serialized directly with json.Marshal and tags password_hash and token for output, with no field filtering. Any authenticated user receives these secrets for their own shares, and an administrator listing all shares via GET /api/shares receives the password hash and bypass token for every user's shares, enabling offline cracking of share passwords and direct password-bypass access to protected shares.
Details
1. The Link struct serializes both secrets to JSON (share/share.go:10-19)
type Link struct {
Hash string `json:"hash" storm:"id,index"`
Path string `json:"path" storm:"index"`
UserID uint `json:"userID"`
Expire int64 `json:"expire"`
PasswordHash string `json:"password_hash,omitempty"` // line 15, bcrypt hash exposed
// Token is only set when PasswordHash is set; it bypasses the password.
Token string `json:"token,omitempty"` // line 19, bypass token exposed
}
omitempty means the hash and token are emitted whenever a share is password-protected, i.e. in every response for such a share.
2. The share handlers return the full struct through unfiltered json.Marshal
sharePostHandler returns the created Link with renderJSON(w, r, s) (http/share.go:179); shareListHandler and shareGetsHandler return shares the same way (http/share.go:55, http/share.go:76). renderJSON performs an unfiltered json.Marshal(data) (http/utils.go:16), so every tagged field, including password_hash and token, reaches the client.
3. Administrators receive every user's secrets (http/share.go:36)
s, err = d.store.Share.All() // admin path: returns ALL users' shares
// ...
return renderJSON(w, r, s) // including each share's password_hash and token
An admin calling GET /api/shares receives the bcrypt hash and bypass token for all shares across all users.
PoC
Tested against filebrowser/filebrowser:v2.63.15.
Attack Vector: read the bcrypt hash and bypass token from the share API:
#1. Seed a file in /tmp and start a fresh v2.63.15 container
mkdir -p /tmp/filebrowser-test/srv/user1
echo "hello" > /tmp/filebrowser-test/srv/user1/readme.txt
docker run -d --name filebrowser-test -p 8090:80 -v /tmp/filebrowser-test/srv:/srv filebrowser/filebrowser:v2.63.15 && sleep 4
B=http://localhost:8090
#2. Log in as admin
AP=$(docker logs filebrowser-test 2>&1 | grep -o 'password: .*' | awk '{print $2}')
T=$(curl -s -X POST $B/api/login -H 'Content-Type: application/json' -d "{\"username\":\"admin\",\"password\":\"$AP\"}")
#3. Create a password-protected share
curl -s -X POST "$B/api/share/user1/readme.txt" -H "X-Auth: $T" -H 'Content-Type: application/json' \
-d '{"password":"ShareSecret123!","expires":"24","unit":"hours"}'
#4. List shares (as admin this returns every user's shares, each with the bcrypt password_hash and bypass token)
curl -s "$B/api/shares" -H "X-Auth: $T"
The returned bcrypt hash cracks offline (hashcat -m 3200) to recover the share password, and the token opens the protected share directly without the password.
Expected output (reproduced on a fresh filebrowser-test container, v2.63.15):
Both the POST /api/share/... response and the GET /api/shares response return HTTP 200 with a body that includes the full bcrypt password_hash and the 128-character bypass token:
POST /api/share/user1/readme.txt -> 200
GET /api/shares -> 200
{
"hash": "yy9159Cs",
"path": "/user1/readme.txt",
"userID": 1,
"expire": 1781758642,
"password_hash": "$2a$10$SX2h.eKiqMaThRTJNIKVxeVkbXSbGf5XoU0ZX2frcAasjE4RbvBla",
"token": "bO4YpOtayjDNG_72qYk6MHIIn0BNxskySLSAbinAkPcKZX6XD2rRrtDX8Bmro..."
}
The hash cracks offline to the known password (bcrypt.checkpw(b"ShareSecret123!", hash) == True, hashcat -m 3200), and the token grants direct access to the password-protected share without knowing the password.
Impact
- Offline password cracking: the bcrypt hash of every password-protected share is returned to clients; weak or reused share passwords can be recovered offline.
- Password-bypass token leak: the
tokenis the value that bypasses the share password entirely; exposing it in list responses lets any holder of the response open the protected share directly. - Admin sees everyone's secrets:
GET /api/sharesas an administrator returns the hash and token of every user's shares, broadening the exposure across all tenants. - Credential reuse risk: users who reuse an account or service password as a share password expose that password to offline recovery.
Recommended Fix
Never serialize the hash or the bypass token to clients. Change the JSON tags so the secrets stay server-side:
// share/share.go
type Link struct {
Hash string `json:"hash" storm:"id,index"`
Path string `json:"path" storm:"index"`
UserID uint `json:"userID"`
Expire int64 `json:"expire"`
PasswordHash string `json:"-" storm:"index"` // never serialize
Token string `json:"-"` // never serialize in list responses
}
PasswordHash and Token are only needed server-side (for bcrypt.CompareHashAndPassword and token comparison during share authentication). If a client needs to know whether a share is password-protected, expose a derived HasPassword bool instead of the hash. Prefer a response DTO over serializing the storage struct directly so future field additions are not exposed by default.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.16"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62684"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T22:17:56Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n\nWhen a user creates a password-protected share or lists existing shares, the JSON response includes the full bcrypt `password_hash` and the secret `token` of the share. The `Link` storage struct is serialized directly with `json.Marshal` and tags `password_hash` and `token` for output, with no field filtering. Any authenticated user receives these secrets for their own shares, and an administrator listing all shares via `GET /api/shares` receives the password hash and bypass token for **every** user\u0027s shares, enabling offline cracking of share passwords and direct password-bypass access to protected shares.\n\n## Details\n\n**1. The `Link` struct serializes both secrets to JSON (`share/share.go:10-19`)**\n\n```go\ntype Link struct {\n Hash string `json:\"hash\" storm:\"id,index\"`\n Path string `json:\"path\" storm:\"index\"`\n UserID uint `json:\"userID\"`\n Expire int64 `json:\"expire\"`\n PasswordHash string `json:\"password_hash,omitempty\"` // line 15, bcrypt hash exposed\n // Token is only set when PasswordHash is set; it bypasses the password.\n Token string `json:\"token,omitempty\"` // line 19, bypass token exposed\n}\n```\n\n`omitempty` means the hash and token are emitted whenever a share is password-protected, i.e. in every response for such a share.\n\n**2. The share handlers return the full struct through unfiltered `json.Marshal`**\n\n`sharePostHandler` returns the created `Link` with `renderJSON(w, r, s)` (`http/share.go:179`); `shareListHandler` and `shareGetsHandler` return shares the same way (`http/share.go:55`, `http/share.go:76`). `renderJSON` performs an unfiltered `json.Marshal(data)` (`http/utils.go:16`), so every tagged field, including `password_hash` and `token`, reaches the client.\n\n**3. Administrators receive every user\u0027s secrets (`http/share.go:36`)**\n\n```go\ns, err = d.store.Share.All() // admin path: returns ALL users\u0027 shares\n// ...\nreturn renderJSON(w, r, s) // including each share\u0027s password_hash and token\n```\n\nAn admin calling `GET /api/shares` receives the bcrypt hash and bypass token for all shares across all users.\n\n## PoC\n\nTested against `filebrowser/filebrowser:v2.63.15`.\n\n**Attack Vector: read the bcrypt hash and bypass token from the share API:**\n\n```bash\n#1. Seed a file in /tmp and start a fresh v2.63.15 container\nmkdir -p /tmp/filebrowser-test/srv/user1\necho \"hello\" \u003e /tmp/filebrowser-test/srv/user1/readme.txt\ndocker run -d --name filebrowser-test -p 8090:80 -v /tmp/filebrowser-test/srv:/srv filebrowser/filebrowser:v2.63.15 \u0026\u0026 sleep 4\nB=http://localhost:8090\n\n#2. Log in as admin\nAP=$(docker logs filebrowser-test 2\u003e\u00261 | grep -o \u0027password: .*\u0027 | awk \u0027{print $2}\u0027)\nT=$(curl -s -X POST $B/api/login -H \u0027Content-Type: application/json\u0027 -d \"{\\\"username\\\":\\\"admin\\\",\\\"password\\\":\\\"$AP\\\"}\")\n\n#3. Create a password-protected share\ncurl -s -X POST \"$B/api/share/user1/readme.txt\" -H \"X-Auth: $T\" -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"password\":\"ShareSecret123!\",\"expires\":\"24\",\"unit\":\"hours\"}\u0027\n\n#4. List shares (as admin this returns every user\u0027s shares, each with the bcrypt password_hash and bypass token)\ncurl -s \"$B/api/shares\" -H \"X-Auth: $T\"\n```\n\nThe returned bcrypt hash cracks offline (`hashcat -m 3200`) to recover the share password, and the `token` opens the protected share directly without the password.\n\nExpected output (reproduced on a fresh `filebrowser-test` container, v2.63.15):\n\nBoth the `POST /api/share/...` response and the `GET /api/shares` response return HTTP 200 with a body that includes the full bcrypt `password_hash` and the 128-character bypass `token`:\n\n```http\nPOST /api/share/user1/readme.txt -\u003e 200\nGET /api/shares -\u003e 200\n{\n \"hash\": \"yy9159Cs\",\n \"path\": \"/user1/readme.txt\",\n \"userID\": 1,\n \"expire\": 1781758642,\n \"password_hash\": \"$2a$10$SX2h.eKiqMaThRTJNIKVxeVkbXSbGf5XoU0ZX2frcAasjE4RbvBla\",\n \"token\": \"bO4YpOtayjDNG_72qYk6MHIIn0BNxskySLSAbinAkPcKZX6XD2rRrtDX8Bmro...\"\n}\n```\n\nThe hash cracks offline to the known password (`bcrypt.checkpw(b\"ShareSecret123!\", hash) == True`, `hashcat -m 3200`), and the `token` grants direct access to the password-protected share without knowing the password.\n\n## Impact\n\n- **Offline password cracking:** the bcrypt hash of every password-protected share is returned to clients; weak or reused share passwords can be recovered offline.\n- **Password-bypass token leak:** the `token` is the value that bypasses the share password entirely; exposing it in list responses lets any holder of the response open the protected share directly.\n- **Admin sees everyone\u0027s secrets:** `GET /api/shares` as an administrator returns the hash and token of every user\u0027s shares, broadening the exposure across all tenants.\n- **Credential reuse risk:** users who reuse an account or service password as a share password expose that password to offline recovery.\n\n## Recommended Fix\n\nNever serialize the hash or the bypass token to clients. Change the JSON tags so the secrets stay server-side:\n\n```go\n// share/share.go\ntype Link struct {\n Hash string `json:\"hash\" storm:\"id,index\"`\n Path string `json:\"path\" storm:\"index\"`\n UserID uint `json:\"userID\"`\n Expire int64 `json:\"expire\"`\n PasswordHash string `json:\"-\" storm:\"index\"` // never serialize\n Token string `json:\"-\"` // never serialize in list responses\n}\n```\n\n`PasswordHash` and `Token` are only needed server-side (for `bcrypt.CompareHashAndPassword` and token comparison during share authentication). If a client needs to know whether a share is password-protected, expose a derived `HasPassword bool` instead of the hash. Prefer a response DTO over serializing the storage struct directly so future field additions are not exposed by default.",
"id": "GHSA-833g-cqhp-h72j",
"modified": "2026-07-20T22:17:57Z",
"published": "2026-07-20T22:17:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-833g-cqhp-h72j"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "File Browser: Share API exposes the password hash and bypass token"
}
GHSA-836C-4296-HWVW
Vulnerability from github – Published: 2024-03-18 03:30 – Updated: 2024-04-09 00:30Siklu TG Terragraph devices before 2.1.1 allow attackers to discover valid, randomly generated credentials via GetCredentials.
{
"affected": [],
"aliases": [
"CVE-2022-47037"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-18T03:15:06Z",
"severity": "HIGH"
},
"details": "Siklu TG Terragraph devices before 2.1.1 allow attackers to discover valid, randomly generated credentials via GetCredentials.",
"id": "GHSA-836c-4296-hwvw",
"modified": "2024-04-09T00:30:40Z",
"published": "2024-03-18T03:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47037"
},
{
"type": "WEB",
"url": "https://semaja2.net/2023/06/11/siklu-tg-auth-bypass.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-83C6-CPC7-FC84
Vulnerability from github – Published: 2025-02-11 15:32 – Updated: 2025-02-11 15:32In JetBrains TeamCity before 2024.12.2 improper Kubernetes connection settings could expose sensitive resources
{
"affected": [],
"aliases": [
"CVE-2025-26492"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-11T14:15:31Z",
"severity": "HIGH"
},
"details": "In JetBrains TeamCity before 2024.12.2 improper Kubernetes connection settings could expose sensitive resources",
"id": "GHSA-83c6-cpc7-fc84",
"modified": "2025-02-11T15:32:24Z",
"published": "2025-02-11T15:32:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26492"
},
{
"type": "WEB",
"url": "https://www.jetbrains.com/privacy-security/issues-fixed"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-83Q4-53FQ-58WM
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2025-08-26 15:30An issue in PDQ Smart Deploy V.3.0.2040 allows an attacker to escalate privileges via the Credential encryption routines in SDCommon.dll
{
"affected": [],
"aliases": [
"CVE-2025-52095"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:44Z",
"severity": "CRITICAL"
},
"details": "An issue in PDQ Smart Deploy V.3.0.2040 allows an attacker to escalate privileges via the Credential encryption routines in SDCommon.dll",
"id": "GHSA-83q4-53fq-58wm",
"modified": "2025-08-26T15:30:55Z",
"published": "2025-08-22T18:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52095"
},
{
"type": "WEB",
"url": "https://specterops.io/blog/2025/08/12/hklmsystemsetupsmartdeploy-the-static-keys-to-abusing-pdq-smartdeploy"
},
{
"type": "WEB",
"url": "https://www.pdq.com"
},
{
"type": "WEB",
"url": "https://www.pdq.com/products/smartdeploy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8486-H39X-CX2F
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-11-08 23:05A exposure of sensitive information vulnerability exists in Jenkins Configuration as Code Plugin 0.7-alpha and earlier in DataBoundConfigurator.java, Attribute.java, BaseConfigurator.java, ExtensionConfigurator.java that allows attackers with access to Jenkins log files to obtain the passwords configured using Configuration as Code Plugin.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.jenkins:configuration-as-code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8-alpha"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000610"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-08T23:05:43Z",
"nvd_published_at": "2018-06-26T17:29:00Z",
"severity": "HIGH"
},
"details": "A exposure of sensitive information vulnerability exists in Jenkins Configuration as Code Plugin 0.7-alpha and earlier in DataBoundConfigurator.java, Attribute.java, BaseConfigurator.java, ExtensionConfigurator.java that allows attackers with access to Jenkins log files to obtain the passwords configured using Configuration as Code Plugin.",
"id": "GHSA-8486-h39x-cx2f",
"modified": "2022-11-08T23:05:43Z",
"published": "2022-05-13T01:48:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000610"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-06-25/#SECURITY-929"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Configuration as Code Plugin has Insufficiently Protected Credentials"
}
GHSA-84H6-JF8X-FF2J
Vulnerability from github – Published: 2022-05-24 16:59 – Updated: 2022-12-06 21:38Jenkins Bitbucket OAuth Plugin prior to 0.10 stores credentials unencrypted in the global config.xml configuration file on the Jenkins master where they could be viewed by users with access to the master file system.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:bitbucket-oauth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10460"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-06T21:38:55Z",
"nvd_published_at": "2019-10-23T13:15:00Z",
"severity": "HIGH"
},
"details": "Jenkins Bitbucket OAuth Plugin prior to 0.10 stores credentials unencrypted in the global config.xml configuration file on the Jenkins master where they could be viewed by users with access to the master file system.",
"id": "GHSA-84h6-jf8x-ff2j",
"modified": "2022-12-06T21:38:55Z",
"published": "2022-05-24T16:59:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10460"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/bitbucket-oauth-plugin/commit/f55d222db910220ca8cd8631fb746c98b9e12870"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/bitbucket-oauth-plugin"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-10-23/#SECURITY-1546"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/10/23/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Jenkins Bitbucket OAuth Plugin contains Insufficiently Protected Credentials"
}
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.