Common Weakness Enumeration

CWE-522

Allowed-with-Review

Insufficiently Protected Credentials

Abstraction: Class · Status: Incomplete

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

2083 vulnerabilities reference this CWE, most recent first.

GHSA-2M28-WGXJ-V265

Vulnerability from github – Published: 2023-04-25 21:30 – Updated: 2024-04-04 03:41
VLAI
Details

An HPE OneView appliance dump may expose SAN switch administrative credentials

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-28088"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-25T19:15:10Z",
    "severity": "HIGH"
  },
  "details": "An HPE OneView appliance dump may expose SAN switch administrative credentials",
  "id": "GHSA-2m28-wgxj-v265",
  "modified": "2024-04-04T03:41:08Z",
  "published": "2023-04-25T21:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28088"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US\u0026docId=hpesbgn04469en_us"
    }
  ],
  "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"
    }
  ]
}

GHSA-2MJF-69XR-J2P4

Vulnerability from github – Published: 2022-03-10 00:00 – Updated: 2022-03-17 00:02
VLAI
Details

Azure Site Recovery Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-24469, CVE-2022-24515, CVE-2022-24518, CVE-2022-24519.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-24506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-09T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Azure Site Recovery Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-24469, CVE-2022-24515, CVE-2022-24518, CVE-2022-24519.",
  "id": "GHSA-2mjf-69xr-j2p4",
  "modified": "2022-03-17T00:02:14Z",
  "published": "2022-03-10T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24506"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-24506"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-24506"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2MVF-3MC9-CJQ9

Vulnerability from github – Published: 2022-05-24 16:47 – Updated: 2023-02-27 18:32
VLAI
Details

Insufficient password protection in the attestation database for Open CIT may allow an authenticated user to potentially enable information disclosure via local access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-0175"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-06-13T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient password protection in the attestation database for Open CIT may allow an authenticated user to potentially enable information disclosure via local access.",
  "id": "GHSA-2mvf-3mc9-cjq9",
  "modified": "2023-02-27T18:32:07Z",
  "published": "2022-05-24T16:47:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0175"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/in"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00248.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2MWM-HHV7-V7HX

Vulnerability from github – Published: 2022-08-19 00:00 – Updated: 2025-05-05 18:32
VLAI
Details

Insufficiently protected credentials for Intel(R) AMT and Intel(R) Standard Manageability may allow an unauthenticated user to potentially enable information disclosure and escalation of privilege via network access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-30601"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-18T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Insufficiently protected credentials for Intel(R) AMT and Intel(R) Standard Manageability may allow an unauthenticated user to potentially enable information disclosure and escalation of privilege via network access.",
  "id": "GHSA-2mwm-hhv7-v7hx",
  "modified": "2025-05-05T18:32:23Z",
  "published": "2022-08-19T00:00:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30601"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20221014-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00709.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2MWR-XJCG-37J7

Vulnerability from github – Published: 2026-10-08 22:09 – Updated: 2026-10-08 22:09
VLAI
Summary
Mechanize sends credential headers to another host after an HTTP redirect
Details

Summary

mechanize leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through Mechanize#request_headers= leaked even when they were Authorization.

Details

Two defects, both in lib/mechanize/http/agent.rb.

1. Mechanize#request_headers= bypassed the redirect strip entirely. #request_add_headers copied @request_headers onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in #response_redirect mutated only the per-request headers hash and never touched agent state. Because request_headers= is the documented way to set a default credential for every request, the header the code explicitly protected — Authorization — was the one most likely to leak.

2. The strip list omitted Proxy-Authorization and Cookie2. Only CREDENTIAL_HEADERS = ['Authorization'] and COOKIE_HEADERS = ['Cookie'] were removed from the per-request headers hash on a cross-host redirect.

Cookies held in Mechanize#cookie_jar and credentials held in Mechanize::HTTP::AuthStore are not affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.

PoC

agent = Mechanize.new
agent.request_headers = { 'Authorization' => 'Bearer secret' }
agent.get('https://example.test/redirects-to-attacker')
# the request to the attacker's host carries "Authorization: Bearer secret"

Impact

An attacker who controls a redirect target — through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM — captures bearer tokens and session cookies from any mechanize agent that sets credentials through request_headers= or the per-request headers argument. Disclosure only; no integrity or availability impact.

Patches

Fixed in mechanize v2.14.1.

  • Credentials and cookies are withheld from a request that follows a redirect across an origin, from both header sources: the per-request headers argument and Mechanize#request_headers=.
  • CREDENTIAL_HEADERS gains Proxy-Authorization; COOKIE_HEADERS gains Cookie2.

Proxy-Authorization is withheld here although curl does not withhold it, because Net::HTTP tunnels https: requests with CONNECT, so a caller-supplied Proxy-Authorization travels inside the tunnel to the origin server rather than to the proxy.

Headers set through Mechanize#request_headers= no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.

What this fix does not cover

Only the headers in CREDENTIAL_HEADERS and COOKIE_HEADERS are withheld. A caller-supplied header that carries a credential under some other name — X-API-Key, X-Vault-Token, or any bespoke token header — still follows a redirect to another origin, matching the behavior of curl's CURLOPT_HTTPHEADER. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.

Workarounds

Set Mechanize#redirect_ok = false and handle redirects explicitly, or avoid request_headers= for credentials and pass them per-request only to hosts you intend to authenticate to.

Credit

Reported by @SnailSploit.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "mechanize"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T22:09:00Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`mechanize` leaked credentials to the redirect target when an HTTP redirect crossed to another host. Credentials set through `Mechanize#request_headers=` leaked even when they were `Authorization`.\n\n## Details\n\nTwo defects, both in `lib/mechanize/http/agent.rb`.\n\n**1. `Mechanize#request_headers=` bypassed the redirect strip entirely.** `#request_add_headers` copied `@request_headers` onto every request unconditionally, with no host check, including the request issued after a redirect. The strip in `#response_redirect` mutated only the per-request headers hash and never touched agent state. Because `request_headers=` is the documented way to set a default credential for every request, the header the code explicitly protected \u2014 `Authorization` \u2014 was the one most likely to leak.\n\n**2. The strip list omitted `Proxy-Authorization` and `Cookie2`.** Only `CREDENTIAL_HEADERS = [\u0027Authorization\u0027]` and `COOKIE_HEADERS = [\u0027Cookie\u0027]` were removed from the per-request headers hash on a cross-host redirect.\n\nCookies held in `Mechanize#cookie_jar` and credentials held in `Mechanize::HTTP::AuthStore` are **not** affected. Both are looked up per-URI, so they never follow a redirect to a foreign host. The exposure was limited to headers the caller set by hand.\n\n## PoC\n\n```ruby\nagent = Mechanize.new\nagent.request_headers = { \u0027Authorization\u0027 =\u003e \u0027Bearer secret\u0027 }\nagent.get(\u0027https://example.test/redirects-to-attacker\u0027)\n# the request to the attacker\u0027s host carries \"Authorization: Bearer secret\"\n```\n\n## Impact\n\nAn attacker who controls a redirect target \u2014 through an open redirect on the site being fetched, an attacker-supplied fetch URL, DNS rebinding, or MITM \u2014 captures bearer tokens and session cookies from any `mechanize` agent that sets credentials through `request_headers=` or the per-request `headers` argument. Disclosure only; no integrity or availability impact.\n\n## Patches\n\nFixed in `mechanize` v2.14.1.\n\n- Credentials and cookies are withheld from a request that follows a redirect across an origin, from **both** header sources: the per-request `headers` argument and `Mechanize#request_headers=`.\n- `CREDENTIAL_HEADERS` gains `Proxy-Authorization`; `COOKIE_HEADERS` gains `Cookie2`.\n\n`Proxy-Authorization` is withheld here although curl does not withhold it, because `Net::HTTP` tunnels `https:` requests with `CONNECT`, so a caller-supplied `Proxy-Authorization` travels inside the tunnel to the origin server rather than to the proxy.\n\nHeaders set through `Mechanize#request_headers=` no longer reach a redirect target on another origin when they are credentials. Callers that relied on the previous behavior will see those headers withheld.\n\n### What this fix does not cover\n\nOnly the headers in `CREDENTIAL_HEADERS` and `COOKIE_HEADERS` are withheld. A caller-supplied header that carries a credential under some other name \u2014 `X-API-Key`, `X-Vault-Token`, or any bespoke token header \u2014 still follows a redirect to another origin, matching the behavior of curl\u0027s `CURLOPT_HTTPHEADER`. If you set such a header, do not enable redirect following for requests that carry it, or scope it to a single request whose destination you control.\n\n## Workarounds\n\nSet `Mechanize#redirect_ok = false` and handle redirects explicitly, or avoid `request_headers=` for credentials and pass them per-request only to hosts you intend to authenticate to.\n\n## Credit\n\nReported by @SnailSploit.",
  "id": "GHSA-2mwr-xjcg-37j7",
  "modified": "2026-10-08T22:09:00Z",
  "published": "2026-10-08T22:09:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/mechanize/security/advisories/GHSA-2mwr-xjcg-37j7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/mechanize/pull/676"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/mechanize/commit/02a1235842d6eda8d4a5a3d8f13aba2cecf52e4f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/mechanize/commit/94e0902867296be804f36eccbb47acf7d5018745"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/mechanize/commit/ac49abf2869297d83c3b11bbfb8b18e63b588c95"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sparklemotion/mechanize"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/mechanize/releases/tag/v2.14.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mechanize sends credential headers to another host after an HTTP redirect"
}

GHSA-2MXM-3CXJ-6CMP

Vulnerability from github – Published: 2025-03-05 15:30 – Updated: 2025-03-05 15:30
VLAI
Details

Insufficiently Protected Credentials vulnerability in OpenText Identity Manager Advanced Edition on Windows, Linux, 64 bit allows Privilege Abuse. This vulnerability could allow an authenticated user to obtain higher privileged user’s sensitive information via crafted payload.

This issue affects Identity Manager Advanced Edition: from 4.8.0.0 through 4.8.7.0102, 4.9.0.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-12799"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-05T15:15:13Z",
    "severity": "CRITICAL"
  },
  "details": "Insufficiently Protected Credentials\nvulnerability in OpenText Identity Manager Advanced Edition on Windows, Linux,\n64 bit allows Privilege Abuse. This vulnerability could allow an\nauthenticated user to obtain higher privileged user\u2019s sensitive information via\ncrafted payload.\n\nThis issue affects Identity Manager Advanced\nEdition: from 4.8.0.0 through 4.8.7.0102, 4.9.0.0.",
  "id": "GHSA-2mxm-3cxj-6cmp",
  "modified": "2025-03-05T15:30:57Z",
  "published": "2025-03-05T15:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12799"
    },
    {
      "type": "WEB",
      "url": "https://portal.microfocus.com/s/article/KM000037455"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:P/AU:Y/R:U/V:C/RE:H/U:Red",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-2PJ4-MR9M-QWWW

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2024-04-04 02:22
VLAI
Details

Tracker PDF-XChange Editor before 8.0.330.0 has an NTLM SSO hash theft vulnerability using crafted FDF or XFDF files (a related issue to CVE-2018-4993). For example, an NTLM hash is sent for a link to \192.168.0.2\C$\file.pdf without user interaction.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-17497"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-11T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Tracker PDF-XChange Editor before 8.0.330.0 has an NTLM SSO hash theft vulnerability using crafted FDF or XFDF files (a related issue to CVE-2018-4993). For example, an NTLM hash is sent for a link to \\\\192.168.0.2\\C$\\file.pdf without user interaction.",
  "id": "GHSA-2pj4-mr9m-qwww",
  "modified": "2024-04-04T02:22:30Z",
  "published": "2022-05-24T16:58:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17497"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ponypot/cve/raw/master/pdfXChangeEditor_FDFInclusions.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2PM6-HR95-GGXQ

Vulnerability from github – Published: 2025-08-12 12:30 – Updated: 2025-08-12 12:30
VLAI
Details

A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions < V3.3). Affected SIMATIC RTLS Locating Manager Report Clients do not properly protect credentials that are used to authenticate to the server. This could allow an authenticated local attacker to extract the credentials and use them to escalate their access rights from the Manager to the Systemadministrator role.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-40751"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T12:15:36Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been identified in SIMATIC RTLS Locating Manager (All versions \u003c V3.3). Affected SIMATIC RTLS Locating Manager Report Clients do not properly protect credentials that are used to authenticate to the server. This could allow an authenticated local attacker to extract the credentials and use them to escalate their access rights from the Manager to the Systemadministrator role.",
  "id": "GHSA-2pm6-hr95-ggxq",
  "modified": "2025-08-12T12:30:33Z",
  "published": "2025-08-12T12:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40751"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-707630.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/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-2Q27-4JJ5-PPF3

Vulnerability from github – Published: 2022-11-28 18:30 – Updated: 2022-12-02 00:30
VLAI
Details

IBM Maximo Mobile 8.7 and 8.8 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 237407.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-41732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-28T17:15:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Maximo Mobile 8.7 and 8.8 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 237407.",
  "id": "GHSA-2q27-4jj5-ppf3",
  "modified": "2022-12-02T00:30:25Z",
  "published": "2022-11-28T18:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41732"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/237407"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6841617"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2QPM-XF67-JJ26

Vulnerability from github – Published: 2022-05-24 17:00 – Updated: 2022-10-07 18:15
VLAI
Details

Postgresql Windows installer before versions 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24 is vulnerable via superuser writing password to unprotected temporary file.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-10210"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-29T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Postgresql Windows installer before versions 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24 is vulnerable via superuser writing password to unprotected temporary file.",
  "id": "GHSA-2qpm-xf67-jj26",
  "modified": "2022-10-07T18:15:57Z",
  "published": "2022-05-24T17:00:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10210"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10210"
    },
    {
      "type": "WEB",
      "url": "https://www.postgresql.org/about/news/1960"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Mitigation
Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Mitigation
Implementation

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

CAPEC-102: Session Sidejacking

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

CAPEC-474: Signature Spoofing by Key Theft

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

CAPEC-50: Password Recovery Exploitation

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

CAPEC-509: Kerberoasting

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

CAPEC-551: Modify Existing Service

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

CAPEC-555: Remote Services with Stolen Credentials

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

CAPEC-560: Use of Known Domain Credentials

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

CAPEC-561: Windows Admin Shares with Stolen Credentials

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

CAPEC-600: Credential Stuffing

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

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

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

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

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

CAPEC-652: Use of Known Kerberos Credentials

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

CAPEC-653: Use of Known Operating System Credentials

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