CWE-522
Allowed-with-ReviewInsufficiently Protected Credentials
Abstraction: Class · Status: Incomplete
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
1811 vulnerabilities reference this CWE, most recent first.
GHSA-WH68-R6P4-7CV3
Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-28 00:00A flaw was found in Ansible Galaxy Collections. When collections are built manually, any files in the repository directory that are not explicitly excluded via the build_ignore list in "galaxy.yml" include files in the .tar.gz file. This contains sensitive info, such as the user's Ansible Galaxy API key and any secrets in ansible or ansible-playbook verbose output without theno_log redaction. Currently, there is no way to deprecate a Collection Or delete a Collection Version. Once published, anyone who downloads or installs the collection can view the secrets.
{
"affected": [],
"aliases": [
"CVE-2021-3681"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-18T17:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Ansible Galaxy Collections. When collections are built manually, any files in the repository directory that are not explicitly excluded via the ``build_ignore`` list in \"galaxy.yml\" include files in the ``.tar.gz`` file. This contains sensitive info, such as the user\u0027s Ansible Galaxy API key and any secrets in ``ansible`` or ``ansible-playbook`` verbose output without the``no_log`` redaction. Currently, there is no way to deprecate a Collection Or delete a Collection Version. Once published, anyone who downloads or installs the collection can view the secrets.",
"id": "GHSA-wh68-r6p4-7cv3",
"modified": "2022-04-28T00:00:57Z",
"published": "2022-04-19T00:00:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3681"
},
{
"type": "WEB",
"url": "https://github.com/ansible/galaxy/issues/1977"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1989407"
}
],
"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-WH7X-WW7Q-H9HP
Vulnerability from github – Published: 2024-05-07 00:30 – Updated: 2024-08-01 15:31Insecure storage of the ICT MIFARE and DESFire encryption keys in the firmware binary allows malicious actors to create credentials for any site code and card number that is using the default ICT encryption.
{
"affected": [],
"aliases": [
"CVE-2024-29941"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-06T23:15:06Z",
"severity": "HIGH"
},
"details": "Insecure storage of the ICT MIFARE and DESFire encryption keys in the firmware\nbinary allows malicious actors to create credentials for any site code and card number that is using the default\nICT encryption.\n\n",
"id": "GHSA-wh7x-ww7q-h9hp",
"modified": "2024-08-01T15:31:43Z",
"published": "2024-05-07T00:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29941"
},
{
"type": "WEB",
"url": "https://ict.co/media/1xdhaugi/credential-cloning.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-WH9J-Q6HG-X337
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-25 00:00Insufficient protection of the server-side encryption keys in Nextcloud Server 19.0.1 allowed an attacker to replace the public key to decrypt them later on.
{
"affected": [],
"aliases": [
"CVE-2020-8152"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-16T01:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient protection of the server-side encryption keys in Nextcloud Server 19.0.1 allowed an attacker to replace the public key to decrypt them later on.",
"id": "GHSA-wh9j-q6hg-x337",
"modified": "2022-05-25T00:00:32Z",
"published": "2022-05-24T17:34:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8152"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/743505"
},
{
"type": "WEB",
"url": "https://nextcloud.com/security/advisory/?id=NC-SA-2020-040"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2020/Dec/54"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WHHJ-9Q9W-QFF6
Vulnerability from github – Published: 2022-05-24 17:15 – Updated: 2024-03-21 03:33In IQrouter through 3.3.1, the Lua function diag_set_password in the web-panel allows remote attackers to change the root password arbitrarily.
{
"affected": [],
"aliases": [
"CVE-2020-11964"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-21T13:15:00Z",
"severity": "MODERATE"
},
"details": "In IQrouter through 3.3.1, the Lua function diag_set_password in the web-panel allows remote attackers to change the root password arbitrarily.",
"id": "GHSA-whhj-9q9w-qff6",
"modified": "2024-03-21T03:33:55Z",
"published": "2022-05-24T17:15:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11964"
},
{
"type": "WEB",
"url": "https://evenroute.com"
},
{
"type": "WEB",
"url": "https://evenroute.zendesk.com/hc/en-us/articles/216107838-How-do-I-configure-an-IQrouter-"
},
{
"type": "WEB",
"url": "https://openwrt.org/docs/guide-quick-start/walkthrough_login"
},
{
"type": "WEB",
"url": "https://pastebin.com/grSCSBSu"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WJ2J-QWCF-CFCC
Vulnerability from github – Published: 2026-03-16 16:26 – Updated: 2026-03-19 21:02The default configuration of systemd-cryptenroll as used by IncusOS through mkosi allows for an attacker with physical access to the machine to access the encrypted data without requiring any interaction by the system's owner or any tampering of Secure Boot state or kernel (UKI) boot image.
That's because in this configuration, the LUKS key is made available by the TPM so long as the system has the expected PCR7 value and the PCR11 policy matches. That default PCR11 policy importantly allows for the TPM to release the key to the booted system rather than just from the initrd part of the signed kernel image (UKI).
The attack relies on the attacker being able to substitute the original encrypted root partition for one that they control. By doing so, the system will prompt for a recovery key on boot, which the attacker has defined and can provide, before booting the system using the attacker's root partition rather than the system's original one.
The attacker only needs to put a systemd unit starting on system boot within their root partition to have the system run that logic on boot. That unit will then run in an environment where the TPM will allow for the retrieval of the encryption key of the real root disk, allowing the attacker to steal the LUKS volume key (immutable master key) and then use it against the real root disk, altering it or getting data out before putting the disk back the way it was and returning the system without a trace of this attack having happened.
This is all possible because the system will have still booted with Secure Boot enabled, will have measured and ran the expected bootloader and kernel image (UKI). The initrd selects the root disk based on GPT partition identifiers making it possible to easily substitute the real root disk for an attacker controlled one. This doesn't lead to any change in the TPM state and therefore allows for retrieval of the LUKS key by the attacker through a boot time systemd unit on their alternative root partition.
Reproducing steps are effectively:
- Shutdown the system
- Alter the GPT partition table to remove the GPT type UUID from the root partition
- Resize the ESP partition to make space for the attacker's own root partition
- Create a new LUKS encrypted ext4 partition in the space that was freed up and set the GPT type UUID to that of the original root partition
- Populate that new root partition with a systemd unit and script which use systemd-cryptenroll to unlock and extract the key from the original root partition
- Boot the system
- When prompted, enter the passphrase of the new (attacker) root partition
- Let the system boot IncusOS
- Stop the system
- Recover the encryption key that was extracted by the boot time systemd unit
- Access the original root partition using it, steal or modify the data
- Remove the new (attacker) root partition
- Grow back the ESP
- Restore the GPT type UUID on the root partition
- Start the system back up, it will boot as expected with no indication that it was compromised
Impact
This impacts all IncusOS users and is a particular worry for anyone running IncusOS in an unsecured physical environment where the system can be tempered with while stopped or is at risk of being seized or stolen.
Mitigation
The fix we've put in place makes use of PCR15 in addition to the existing PCR7 and PCR11 policies (and PCR4 when running without UEFI Secure Boot). This is significant as PCR15 measures a number of values during system boot, including a measurement of decrypting the root partition while in the initrd.
By binding the LUKS key(s) to an uninitialized PCR15 value, we ensure that only the initrd will be able to automatically decrypt the partitions. As soon as the system boot exits the initrd, whether to boot the legitimate root disk or an attacker's root disk, the TPM state will no longer align with the state required to release the encryption keys, preventing this attack.
https://github.com/lxc/incus-os/pull/954 implements the new logic in IncusOS.
Future improvements
We've had to use PCR15 directly as a way to prevent this attack as unfortunately mkosi doesn't currently support passing the phase option to ukify. The phase option would allow for a different PCR11 policy to be generated which allows for restricting key access only until the end of the initrd execution.
Being able to use this mechanism would provide a cleaner/simpler solution but it's not currently possible due to lack of mkosi support.
https://github.com/systemd/mkosi/issues/4109
Patches
IncusOS version 202603142010 (2026/03/14 20:10 UTC) includes the new PCR15 logic and will automatically update the TPM policy on boot.
Anyone suspecting that their system may have been physically accessed while shut down should perform a full system wipe and reinstallation as only that will rotate the LUKS volume key and prevent subsequent access to the encrypted data should the system have been previously compromised.
Workarounds
There are no known workarounds other than updating to a version with corrected logic which will automatically rebind the LUKS keys to the new set of TPM registers and prevent this from being exploited.
Thanks
This was brought to our attention by Linux Containers forum user U-00F8 who referenced a public January 2025 article by oddlama describing a similar attack on systems using the default systemd-cryptenroll setup.
We'd also like to thank Lennart Poettering for his assistance in finding a way to quickly mitigate this attack.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lxc/incus-os/incus-osd"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260313012803-e3b35f230d23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32606"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-16T16:26:00Z",
"nvd_published_at": "2026-03-18T06:16:18Z",
"severity": "HIGH"
},
"details": "The default configuration of systemd-cryptenroll as used by IncusOS through mkosi allows for an attacker with physical access to the machine to access the encrypted data without requiring any interaction by the system\u0027s owner or any tampering of Secure Boot state or kernel (UKI) boot image.\n\nThat\u0027s because in this configuration, the LUKS key is made available by the TPM so long as the system has the expected PCR7 value and the PCR11 policy matches. That default PCR11 policy importantly allows for the TPM to release the key to the booted system rather than just from the initrd part of the signed kernel image (UKI).\n\nThe attack relies on the attacker being able to substitute the original encrypted root partition for one that they control. By doing so, the system will prompt for a recovery key on boot, which the attacker has defined and can provide, before booting the system using the attacker\u0027s root partition rather than the system\u0027s original one.\n\nThe attacker only needs to put a systemd unit starting on system boot within their root partition to have the system run that logic on boot. That unit will then run in an environment where the TPM will allow for the retrieval of the encryption key of the real root disk, allowing the attacker to steal the LUKS volume key (immutable master key) and then use it against the real root disk, altering it or getting data out before putting the disk back the way it was and returning the system without a trace of this attack having happened.\n\nThis is all possible because the system will have still booted with Secure Boot enabled, will have measured and ran the expected bootloader and kernel image (UKI). The initrd selects the root disk based on GPT partition identifiers making it possible to easily substitute the real root disk for an attacker controlled one. This doesn\u0027t lead to any change in the TPM state and therefore allows for retrieval of the LUKS key by the attacker through a boot time systemd unit on their alternative root partition.\n\nReproducing steps are effectively:\n - Shutdown the system\n - Alter the GPT partition table to remove the GPT type UUID from the root partition\n - Resize the ESP partition to make space for the attacker\u0027s own root partition\n - Create a new LUKS encrypted ext4 partition in the space that was freed up and set the GPT type UUID to that of the original root partition\n - Populate that new root partition with a systemd unit and script which use `systemd-cryptenroll` to unlock and extract the key from the original root partition\n - Boot the system\n - When prompted, enter the passphrase of the new (attacker) root partition\n - Let the system boot IncusOS\n - Stop the system\n - Recover the encryption key that was extracted by the boot time systemd unit\n - Access the original root partition using it, steal or modify the data\n - Remove the new (attacker) root partition\n - Grow back the ESP\n - Restore the GPT type UUID on the root partition\n - Start the system back up, it will boot as expected with no indication that it was compromised\n\n### Impact\nThis impacts all IncusOS users and is a particular worry for anyone running IncusOS in an unsecured physical environment where the system can be tempered with while stopped or is at risk of being seized or stolen.\n\n### Mitigation\nThe fix we\u0027ve put in place makes use of PCR15 in addition to the existing PCR7 and PCR11 policies (and PCR4 when running without UEFI Secure Boot). This is significant as PCR15 measures a number of values during system boot, including a measurement of decrypting the root partition while in the initrd.\n\nBy binding the LUKS key(s) to an uninitialized PCR15 value, we ensure that only the initrd will be able to automatically decrypt the partitions. As soon as the system boot exits the initrd, whether to boot the legitimate root disk or an attacker\u0027s root disk, the TPM state will no longer align with the state required to release the encryption keys, preventing this attack.\n\nhttps://github.com/lxc/incus-os/pull/954 implements the new logic in IncusOS.\n\n### Future improvements\nWe\u0027ve had to use PCR15 directly as a way to prevent this attack as unfortunately mkosi doesn\u0027t currently support passing the `phase` option to `ukify`. The `phase` option would allow for a different PCR11 policy to be generated which allows for restricting key access only until the end of the initrd execution.\n\nBeing able to use this mechanism would provide a cleaner/simpler solution but it\u0027s not currently possible due to lack of mkosi support.\n\nhttps://github.com/systemd/mkosi/issues/4109\n\n### Patches\nIncusOS version 202603142010 (2026/03/14 20:10 UTC) includes the new PCR15 logic and will automatically update the TPM policy on boot.\n\nAnyone suspecting that their system may have been physically accessed while shut down should perform a full system wipe and reinstallation as only that will rotate the LUKS volume key and prevent subsequent access to the encrypted data should the system have been previously compromised.\n\n### Workarounds\nThere are no known workarounds other than updating to a version with corrected logic which will automatically rebind the LUKS keys to the new set of TPM registers and prevent this from being exploited.\n\n### Thanks\nThis was brought to our attention by Linux Containers forum user `U-00F8` who referenced a public January 2025 article by `oddlama` describing a similar attack on systems using the default systemd-cryptenroll setup.\n\nWe\u0027d also like to thank Lennart Poettering for his assistance in finding a way to quickly mitigate this attack.",
"id": "GHSA-wj2j-qwcf-cfcc",
"modified": "2026-03-19T21:02:12Z",
"published": "2026-03-16T16:26:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lxc/incus-os/security/advisories/GHSA-wj2j-qwcf-cfcc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32606"
},
{
"type": "WEB",
"url": "https://github.com/lxc/incus-os/pull/954"
},
{
"type": "WEB",
"url": "https://github.com/lxc/incus-os/commit/e3b35f230d23443d27752eac27ebb2b22c957b75"
},
{
"type": "WEB",
"url": "https://discuss.linuxcontainers.org/t/potential-luks-encryption-bypass-through-filesystem-confusion/26348"
},
{
"type": "PACKAGE",
"url": "https://github.com/lxc/incus-os"
},
{
"type": "WEB",
"url": "https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "IncusOS has a LUKS encryption bypass due to insufficient TPM policy"
}
GHSA-WJF7-6CX7-X9V8
Vulnerability from github – Published: 2025-07-25 18:30 – Updated: 2025-11-12 21:31A vulnerability exists in Sitecore Experience Manager (XM), Experience Platform (XP), Experience Commerce (XC), and Managed Cloud that could allow an unauthenticated attacker to read arbitrary files. This vulnerability affects all Experience Platform topologies (XM, XP, XC) from 8.0 Initial Release through 10.4 Initial Release and later. This issue affects Content Management (CM) and standalone instances. PaaS and containerized solutions are also affected.
{
"affected": [],
"aliases": [
"CVE-2025-34139"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-552"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-25T16:15:28Z",
"severity": "HIGH"
},
"details": "A vulnerability exists in Sitecore\u00a0Experience Manager (XM),\u00a0Experience Platform (XP),\u00a0Experience Commerce (XC), and\u00a0Managed Cloud that could allow an unauthenticated attacker to read arbitrary files.\u00a0This vulnerability affects all Experience Platform topologies (XM, XP, XC) from 8.0 Initial Release through 10.4 Initial Release and later. This issue affects Content Management (CM) and standalone instances. PaaS and containerized solutions are also affected.",
"id": "GHSA-wjf7-6cx7-x9v8",
"modified": "2025-11-12T21:31:04Z",
"published": "2025-07-25T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34139"
},
{
"type": "WEB",
"url": "https://support.sitecore.com/kb?id=kb_article_view\u0026sysparm_article=KB1003650"
},
{
"type": "WEB",
"url": "https://support.sitecore.com/kb?id=kb_article_view\u0026sysparm_article=KB1003661"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sitecore-xm-xp-xc-managed-cloud-arbitrary-file-read"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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/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-WJQ6-6XVC-XR82
Vulnerability from github – Published: 2024-11-26 15:31 – Updated: 2024-12-02 18:31On Android, Firefox may have inadvertently allowed viewing saved passwords without the required device PIN authentication. This vulnerability affects Firefox < 133.
{
"affected": [],
"aliases": [
"CVE-2024-11703"
],
"database_specific": {
"cwe_ids": [
"CWE-276",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-26T14:15:19Z",
"severity": "CRITICAL"
},
"details": "On Android, Firefox may have inadvertently allowed viewing saved passwords without the required device PIN authentication. This vulnerability affects Firefox \u003c 133.",
"id": "GHSA-wjq6-6xvc-xr82",
"modified": "2024-12-02T18:31:54Z",
"published": "2024-11-26T15:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11703"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1928779"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-63"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-WJVP-GG74-M678
Vulnerability from github – Published: 2025-09-24 18:30 – Updated: 2025-09-24 18:30In Puppet Enterprise versions 2025.4.0 and 2025.5, the encryption key used for encrypting content in the Infra Assistant database was not excluded from the files gathered by Puppet backup. The key is only present on the system if the user has a Puppet Enterprise Advanced license and has enabled the Infra Assistant feature. The key is used for encrypting one particular bit of data in the Infra Assistant database: the API key for their AI provider account. This has been fixed in Puppet Enterprise version 2025.6, and release notes for 2025.6 have remediation steps for users of affected versions who can't update to the latest version.
{
"affected": [],
"aliases": [
"CVE-2025-10360"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-24T16:15:32Z",
"severity": "MODERATE"
},
"details": "In Puppet Enterprise versions 2025.4.0 and 2025.5, the encryption key used for encrypting content in the Infra Assistant database was not excluded from the files gathered by Puppet backup. The key is only present on the system if the user has a Puppet Enterprise Advanced license and has enabled the Infra Assistant feature. The key is used for encrypting one particular bit of data in the Infra Assistant database: the API key for their AI provider account.\u00a0This has been fixed in Puppet Enterprise version 2025.6, and release notes for 2025.6 have remediation steps for users of affected versions who can\u0027t update to the latest version.",
"id": "GHSA-wjvp-gg74-m678",
"modified": "2025-09-24T18:30:29Z",
"published": "2025-09-24T18:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10360"
},
{
"type": "WEB",
"url": "https://portal.perforce.com/s/cve/a91PA000001Smp7YAC/insufficiently-protected-credentials-in-puppet-enterprise-20254-and-20255"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/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-WM23-HCGV-W4X3
Vulnerability from github – Published: 2025-04-21 15:31 – Updated: 2025-04-22 15:30A credential exposure vulnerability in Electrolink 500W, 1kW, 2kW Medium DAB Transmitter Web v01.09, v01.08, v01.07, and Display v1.4, v1.2 allows unauthorized attackers to access credentials in plaintext.
{
"affected": [],
"aliases": [
"CVE-2025-28228"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-18T15:15:58Z",
"severity": "HIGH"
},
"details": "A credential exposure vulnerability in Electrolink 500W, 1kW, 2kW Medium DAB Transmitter Web v01.09, v01.08, v01.07, and Display v1.4, v1.2 allows unauthorized attackers to access credentials in plaintext.",
"id": "GHSA-wm23-hcgv-w4x3",
"modified": "2025-04-22T15:30:51Z",
"published": "2025-04-21T15:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28228"
},
{
"type": "WEB",
"url": "https://github.com/shiky8/my--cve-vulnerability-research/tree/main/CVE-2025-28228"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WM4F-M9QR-Q5J6
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-05-24 19:08IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by an unauthorized user.
{
"affected": [],
"aliases": [
"CVE-2021-20439"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-15T16:15:00Z",
"severity": "HIGH"
},
"details": "IBM Security Access Manager 9.0 and IBM Security Verify Access Docker 10.0.0 stores user credentials in plain clear text which can be read by an unauthorized user.",
"id": "GHSA-wm4f-m9qr-q5j6",
"modified": "2022-05-24T19:08:11Z",
"published": "2022-05-24T19:08:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20439"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/196453"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6471903"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.