CWE-312
AllowedCleartext Storage of Sensitive Information
Abstraction: Base · Status: Draft
The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.
1017 vulnerabilities reference this CWE, most recent first.
GHSA-PVV9-MC25-J2PR
Vulnerability from github – Published: 2024-02-10 18:30 – Updated: 2024-02-10 18:30IBM Storage Defender - Resiliency Service 2.0 could allow a privileged user to perform unauthorized actions after obtaining encrypted data from clear text key storage. IBM X-Force ID: 275783.
{
"affected": [],
"aliases": [
"CVE-2023-50957"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-10T16:15:07Z",
"severity": "HIGH"
},
"details": "IBM Storage Defender - Resiliency Service 2.0 could allow a privileged user to perform unauthorized actions after obtaining encrypted data from clear text key storage. IBM X-Force ID: 275783.",
"id": "GHSA-pvv9-mc25-j2pr",
"modified": "2024-02-10T18:30:34Z",
"published": "2024-02-10T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50957"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/275783"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7115261"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PXRF-M294-JQFF
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02An issue was discovered in Couchbase Server 5.x and 6.x through 6.6.1 and 7.0.0 Beta. Incorrect commands to the REST API can result in leaked authentication information being stored in cleartext in the debug.log and info.log files, and is also shown in the UI visible to administrators.
{
"affected": [],
"aliases": [
"CVE-2021-25644"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-19T19:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Couchbase Server 5.x and 6.x through 6.6.1 and 7.0.0 Beta. Incorrect commands to the REST API can result in leaked authentication information being stored in cleartext in the debug.log and info.log files, and is also shown in the UI visible to administrators.",
"id": "GHSA-pxrf-m294-jqff",
"modified": "2022-05-24T19:02:47Z",
"published": "2022-05-24T19:02:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25644"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/downloads"
},
{
"type": "WEB",
"url": "https://www.couchbase.com/resources/security#SecurityAlerts"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PXXP-9P24-326H
Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34389-ds-base before versions 1.3.8.5, 1.4.0.12 is vulnerable to a Cleartext Storage of Sensitive Information. By default, when the Replica and/or retroChangeLog plugins are enabled, 389-ds-base stores passwords in plaintext format in their respective changelog files. An attacker with sufficiently high privileges, such as root or Directory Manager, can query these files in order to retrieve plaintext passwords.
{
"affected": [],
"aliases": [
"CVE-2018-10871"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-18T13:29:00Z",
"severity": "HIGH"
},
"details": "389-ds-base before versions 1.3.8.5, 1.4.0.12 is vulnerable to a Cleartext Storage of Sensitive Information. By default, when the Replica and/or retroChangeLog plugins are enabled, 389-ds-base stores passwords in plaintext format in their respective changelog files. An attacker with sufficiently high privileges, such as root or Directory Manager, can query these files in order to retrieve plaintext passwords.",
"id": "GHSA-pxxp-9p24-326h",
"modified": "2022-05-13T01:34:56Z",
"published": "2022-05-13T01:34:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10871"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:3401"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10871"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2018/08/msg00032.html"
},
{
"type": "WEB",
"url": "https://pagure.io/389-ds-base/issue/49789"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-Q2HM-2H45-V5G3
Vulnerability from github – Published: 2022-11-21 22:37 – Updated: 2022-12-03 04:09Impact
We discovered that when the reset a forgotten password feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and next versions. Note that it only concerns the reset password feature available from the "Forgot your password" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted.
This vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm.
Note that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this.
Patches
The problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8.
The patch involves a migration of the impacted users as well as the history of the page, to ensure no password remains in plain text in the database. This migration also involves to inform the users about the possible disclosure of their passwords: by default, two emails are automatically sent to the impacted users. A first email to inform about the possibility that their password have been leaked, and a second email using the reset password feature to ask them to set a new password. See below for the configuration options to disable the mail sending.
The first email contains by default the following text (could be translated depending on the wiki language settings):
Subject: Important security issue
Dear user,
due to a bug your password was stored in plain text in our wiki. We cannot exclude that your plain text password was exposed in a data leak. Therefore, you might receive a second email to choose a new password.
Please contact the administrator in case of problem or for further questions.
It's possible to specify another text by creating a file at the root of the permanent directory named 140600000XWIKI19869-mail.txt, this file should have same structure as used above:
Subject: [your custom subject]
[your custom mail content]
This mail is sent plain text and cannot contain any variable. Note that the second mail for the reset password is using the standard feature, so you can find information about the email templates there. Also note that if the users doesn't have any registered email address obviously no mail will be sent, so it's the administrators responsibility to find a way to contact the user (through comment on the user profile, or any other channel used for that wiki). The administrator should be particularly careful on the presence of logs such as:
WARN WIKI19869DataMigrationListener - Reset email cannot be sent for user [reference = [xwiki:XWiki.Foo]] as no email address is provided
It's also possible for administrators to set some properties for the migration: it's possible to decide if the user password should be reset (default) or if the passwords should be kept but only hashed. Note that in the first option, the users won't be able to login anymore until they set a new password if they were impacted. Note that in both options, mails will be sent to users to inform them and encourage them to change their passwords.
Two other properties are available to chose the behaviour regarding the mails to be sent: it's possible to chose to only send the first security email, or to only send the reset password email. It's important to note that those emails are sent after the migration during the initialization of the wiki, by reading a file creating by the migration in the permanent directory (the file is named 140600000XWIKI19869DataMigration-users.txt): then it's possible for an administrator to chose to not sent any email when the migration is performed (by setting the properties to false), and to send them later in a future restart by then setting back the properties to true before the restart of the wiki. Also note that the file is deleted after the mails are sent.
The mentioned properties can be found in xwiki.properties in the [Security] section:
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioning above.
#-# This parameter defines if as part of the migration R140600000XWIKI19869 the passwords of impacted user should be
#-# reset or not. It's advised to keep this value as true, now for some usecases advertised administrators might want
#-# their users to keep their passwords nevertheless, then enable the configuration and set it to false before the
#-# migration is executed.
# security.migration.R140600000XWIKI19869.resetPassword = true
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-# This parameter defines if reset password emails should be sent as part of the migration R140600000XWIKI19869.
#-# By default this value is set to true, so emails will be automatically produced. Now it's possible for admin to set
#-# this option to false: note that in such case a file containing the list of users for whom a reset password email
#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).
#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to
#-# send the emails, so it's possible to perform the migration and send the emails only later if needed.
# security.migration.R140600000XWIKI19869.sendResetPasswordEmail = true
#-# [Since 14.6RC1]
#-# [Since 14.4.3]
#-# [Since 13.10.8]
#-# This option is only used when performing a migration from a wiki before the versions mentioned above.
#-#
#-# This parameter defines if a security email information should be sent as part of the migration R140600000XWIKI19869.
#-# By default this value is set to true, so emails will be automatically produced. Now it's possible for admin to set
#-# this option to false: note that in such case a file containing the list of users for whom a reset password email
#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).
#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to
#-# send the emails, so it's possible to perform the migration and send the emails only later if needed.
# security.migration.R140600000XWIKI19869.sendSecurityEmail = true
Workarounds
There is actually 2 parts of the vulnerability:
1. users who might have use the reset feature should get their password protected. We provide some instructions how to identify and fix those.
2. the next usage of the reset password feature shouldn't lead to plain text password: sadly there is no easy workaround for that, except by recompiling xwiki-platform-security-authentication-default with that change: https://github.com/xwiki/xwiki-platform/commit/443e8398b75a1295067d74afb5898370782d863a#diff-f8a8f8ba80dfc55f044e2e60b521ce379176430ca6921b0f87b79cf682531f79L322
It's possible to identify all impacted users and to manually reset their passwords with an Admin account. For identifying the impacted users, a query such as the following is possible:
{{velocity}}
## The statement is put on multiple lines for readability of the snippet
#set ($statement = "select distinct doc.fullName from Document doc, doc.object(XWiki.XWikiUsers) objUser
where objUser.password not like 'hash:%' and objUser.password <> ''
order by doc.fullName")
$services.query.xwql($statement).execute()
{{/velocity}}
Once impacted users are identified at least 2 options are possible: 1. Set a new password (manually by going to the user profile, or automatically with a groovy script for example) 4. rollback to a previous version of the user document: in such case the password will be automatically processed properly
Be aware that those workarounds won't remove the clear password entry that might remain in database due to history.
References
- Jira ticket: https://jira.xwiki.org/browse/XWIKI-19869
- Advisory of a data leak vulnerability that increases the criticality of this vulnerability: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm
- Bug discovered "protecting" subwiki from this vulnerability: https://jira.xwiki.org/browse/XWIKI-19945
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira * Email us at security ML
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-security-authentication-default"
},
"ranges": [
{
"events": [
{
"introduced": "13.1RC1"
},
{
"fixed": "13.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-security-authentication-default"
},
"ranges": [
{
"events": [
{
"introduced": "14.0.0"
},
{
"fixed": "14.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-41933"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-21T22:37:11Z",
"nvd_published_at": "2022-11-23T21:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nWe discovered that when the reset a forgotten password feature of XWiki was used, the password was then stored in plain text in database. This only concerns XWiki 13.1RC1 and next versions.\nNote that it only concerns the reset password feature available from the \"Forgot your password\" link in the login view: the features allowing a user to change their password, or for an admin to change a user password are not impacted.\n\nThis vulnerability is particularly dangerous in combination with other vulnerabilities allowing to perform data leak of personal data from users, such as https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm. \n\nNote that this vulnerability only concerns the users of the main wiki: in case of farms, the users registered on subwiki are not impacted thanks to a bug we discovered when investigating this.\n\n### Patches\n\nThe problem has been patched in version 14.6RC1, 14.4.3 and 13.10.8.\n\nThe patch involves a migration of the impacted users as well as the history of the page, to ensure no password remains in plain text in the database. This migration also involves to inform the users about the possible disclosure of their passwords: by default, two emails are automatically sent to the impacted users. A first email to inform about the possibility that their password have been leaked, and a second email using the reset password feature to ask them to set a new password. See below for the configuration options to disable the mail sending.\n\nThe first email contains by default the following text (could be translated depending on the wiki language settings):\n```\nSubject: Important security issue\nDear user,\n\ndue to a bug your password was stored in plain text in our wiki. We cannot exclude that your plain text password was exposed in a data leak. Therefore, you might receive a second email to choose a new password. \nPlease contact the administrator in case of problem or for further questions.\n```\nIt\u0027s possible to specify another text by creating a file at the root of the permanent directory named `140600000XWIKI19869-mail.txt`, this file should have same structure as used above:\n```\nSubject: [your custom subject]\n[your custom mail content]\n```\nThis mail is sent plain text and cannot contain any variable. \nNote that the second mail for the reset password is using the standard feature, so you can find information about the email templates [there](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HMailTemplates).\nAlso note that if the users doesn\u0027t have any registered email address obviously no mail will be sent, so it\u0027s the administrators responsibility to find a way to contact the user (through comment on the user profile, or any other channel used for that wiki). The administrator should be particularly careful on the presence of logs such as: \n```\nWARN WIKI19869DataMigrationListener - Reset email cannot be sent for user [reference = [xwiki:XWiki.Foo]] as no email address is provided\n```\n\nIt\u0027s also possible for administrators to set some properties for the migration: it\u0027s possible to decide if the user password should be reset (default) or if the passwords should be kept but only hashed. Note that in the first option, the users won\u0027t be able to login anymore until they set a new password if they were impacted. Note that in both options, mails will be sent to users to inform them and encourage them to change their passwords.\n\nTwo other properties are available to chose the behaviour regarding the mails to be sent: it\u0027s possible to chose to only send the first security email, or to only send the reset password email. It\u0027s important to note that those emails are sent after the migration during the initialization of the wiki, by reading a file creating by the migration in the permanent directory (the file is named `140600000XWIKI19869DataMigration-users.txt`): then it\u0027s possible for an administrator to chose to not sent any email when the migration is performed (by setting the properties to false), and to send them later in a future restart by then setting back the properties to true before the restart of the wiki. Also note that the file is deleted after the mails are sent. \n\nThe mentioned properties can be found in `xwiki.properties` in the `[Security]` section:\n```\n#-# [Since 14.6RC1]\n#-# [Since 14.4.3]\n#-# [Since 13.10.8]\n#-# This option is only used when performing a migration from a wiki before the versions mentioning above.\n#-# This parameter defines if as part of the migration R140600000XWIKI19869 the passwords of impacted user should be\n#-# reset or not. It\u0027s advised to keep this value as true, now for some usecases advertised administrators might want\n#-# their users to keep their passwords nevertheless, then enable the configuration and set it to false before the\n#-# migration is executed.\n# security.migration.R140600000XWIKI19869.resetPassword = true\n\n#-# [Since 14.6RC1]\n#-# [Since 14.4.3]\n#-# [Since 13.10.8]\n#-# This option is only used when performing a migration from a wiki before the versions mentioned above.\n\n#-# This parameter defines if reset password emails should be sent as part of the migration R140600000XWIKI19869.\n#-# By default this value is set to true, so emails will be automatically produced. Now it\u0027s possible for admin to set\n#-# this option to false: note that in such case a file containing the list of users for whom a reset password email\n#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).\n#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to\n#-# send the emails, so it\u0027s possible to perform the migration and send the emails only later if needed.\n# security.migration.R140600000XWIKI19869.sendResetPasswordEmail = true\n\n#-# [Since 14.6RC1]\n#-# [Since 14.4.3]\n#-# [Since 13.10.8]\n#-# This option is only used when performing a migration from a wiki before the versions mentioned above.\n#-#\n#-# This parameter defines if a security email information should be sent as part of the migration R140600000XWIKI19869.\n#-# By default this value is set to true, so emails will be automatically produced. Now it\u0027s possible for admin to set\n#-# this option to false: note that in such case a file containing the list of users for whom a reset password email\n#-# should be sent will still be created in the permanent directory (named 140600000XWIKI19869DataMigration-users.txt).\n#-# If this file exists and this property is set back to true after the migration, the file will still be consumed to\n#-# send the emails, so it\u0027s possible to perform the migration and send the emails only later if needed.\n# security.migration.R140600000XWIKI19869.sendSecurityEmail = true\n```\n\n\n### Workarounds\n\nThere is actually 2 parts of the vulnerability:\n 1. users who might have use the reset feature should get their password protected. We provide some instructions how to identify and fix those. \n 2. the next usage of the reset password feature shouldn\u0027t lead to plain text password: sadly there is no easy workaround for that, except by recompiling `xwiki-platform-security-authentication-default` with that change: https://github.com/xwiki/xwiki-platform/commit/443e8398b75a1295067d74afb5898370782d863a#diff-f8a8f8ba80dfc55f044e2e60b521ce379176430ca6921b0f87b79cf682531f79L322\n \nIt\u0027s possible to identify all impacted users and to manually reset their passwords with an Admin account. For identifying the impacted users, a query such as the following is possible:\n\n```\n{{velocity}}\n## The statement is put on multiple lines for readability of the snippet\n#set ($statement = \"select distinct doc.fullName from Document doc, doc.object(XWiki.XWikiUsers) objUser \nwhere objUser.password not like \u0027hash:%\u0027 and objUser.password \u003c\u003e \u0027\u0027 \norder by doc.fullName\")\n$services.query.xwql($statement).execute()\n{{/velocity}}\n```\nOnce impacted users are identified at least 2 options are possible:\n 1. Set a new password (manually by going to the user profile, or automatically with a groovy script for example)\n 4. rollback to a previous version of the user document: in such case the password will be automatically processed properly\n\nBe aware that those workarounds won\u0027t remove the clear password entry that might remain in database due to history.\n\n### References\n\n * Jira ticket: https://jira.xwiki.org/browse/XWIKI-19869\n * Advisory of a data leak vulnerability that increases the criticality of this vulnerability: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm\n * Bug discovered \"protecting\" subwiki from this vulnerability: https://jira.xwiki.org/browse/XWIKI-19945\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira](https://jira.xwiki.org)\n* Email us at [security ML](mailto:security@xwiki.org)\n",
"id": "GHSA-q2hm-2h45-v5g3",
"modified": "2022-12-03T04:09:18Z",
"published": "2022-11-21T22:37:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-599v-w48h-rjrm"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-q2hm-2h45-v5g3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41933"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/443e8398b75a1295067d74afb5898370782d863a#diff-f8a8f8ba80dfc55f044e2e60b521ce379176430ca6921b0f87b79cf682531f79L322"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19869"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19945"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Plaintext storage of password after a reset in org.xwiki.platform:xwiki-platform-security-authentication-default"
}
GHSA-Q2Q3-G3X6-PFHJ
Vulnerability from github – Published: 2025-12-04 21:31 – Updated: 2025-12-04 21:31R Radio Network FM Transmitter 1.07 allows unauthenticated attackers to access the admin user's password through the system.cgi endpoint, enabling authentication bypass and FM station setup access.
{
"affected": [],
"aliases": [
"CVE-2024-58277"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-04T21:16:07Z",
"severity": "HIGH"
},
"details": "R Radio Network FM Transmitter 1.07 allows unauthenticated attackers to access the admin user\u0027s password through the system.cgi endpoint, enabling authentication bypass and FM station setup access.",
"id": "GHSA-q2q3-g3x6-pfhj",
"modified": "2025-12-04T21:31:06Z",
"published": "2025-12-04T21:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58277"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/51855"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/r-radio-network-fm-transmitter-107-system-settings-disclosure"
},
{
"type": "WEB",
"url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2023-5802.php"
}
],
"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-Q47V-W7JJ-MHCF
Vulnerability from github – Published: 2025-05-25 21:30 – Updated: 2025-05-25 21:30A vulnerability, which was classified as problematic, was found in PhonePe App 25.03.21.0 on Android. Affected is an unknown function of the file /data/data/com.phonepe.app/databases/ of the component SQLite Database. The manipulation leads to cleartext storage in a file or on disk. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-5154"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-25T19:15:19Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as problematic, was found in PhonePe App 25.03.21.0 on Android. Affected is an unknown function of the file /data/data/com.phonepe.app/databases/ of the component SQLite Database. The manipulation leads to cleartext storage in a file or on disk. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-q47v-w7jj-mhcf",
"modified": "2025-05-25T21:30:27Z",
"published": "2025-05-25T21:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5154"
},
{
"type": "WEB",
"url": "https://drive.google.com/drive/folders/1Xj9y2w3E98IZu8PUeGGI0nQPNsvVm87I?usp=sharing"
},
{
"type": "WEB",
"url": "https://github.com/honestcorrupt/-Insecure-Local-Storage-of-Sensitive-User-Data-in-PhonePe-Android-App-Unpatched-"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.310242"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.310242"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.576245"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-Q49H-QG5V-M8H5
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42An issue was discovered in Mutare Voice (EVM) 3.x before 3.3.8. On the admin portal of the web application, password information for external systems is visible in cleartext. The Settings.asp page is affected by this issue.
{
"affected": [],
"aliases": [
"CVE-2021-27233"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-16T04:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Mutare Voice (EVM) 3.x before 3.3.8. On the admin portal of the web application, password information for external systems is visible in cleartext. The Settings.asp page is affected by this issue.",
"id": "GHSA-q49h-qg5v-m8h5",
"modified": "2022-05-24T17:42:22Z",
"published": "2022-05-24T17:42:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27233"
},
{
"type": "WEB",
"url": "https://www.mutare.com/security-adv-mutare-2021-004-mutare-voice"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-Q4VM-PQ3Q-8WGQ
Vulnerability from github – Published: 2026-07-14 20:17 – Updated: 2026-07-14 20:17Impact
Operator session tokens are stored in plaintext in the operator_sessions table (the token column is the PRIMARY KEY). The session token is a 32-byte random hex value sent directly in a cookie and valid for 24 hours.
internal/models/operator.go:61—OperatorSession.Tokenholds the plaintext token.internal/store/sqlite_operators.go:590—CreateOperatorSessioninsertssess.Tokenverbatim.internal/store/sqlite_operators.go:603,642,681,698— lookups/updates/deletes useWHERE token = ?against the plaintext value.
Anyone who can read the database (backup, snapshot, file copy, or SQL-level disclosure) obtains every active session token and can hijack operator sessions directly, with no further authentication.
This is functionally identical to the plaintext enrollment-token issue fixed in GHSA-ghmh-jhmj-wcmf. API keys (OperatorAPIKey.KeyHash) and enrollment tokens (EnrollmentToken.TokenHash) already store only a SHA256 hash; session tokens were missed.
Patches
Store only a SHA256 hash of the session token, mirroring API keys and enrollment tokens:
1. Add a HashSessionToken helper (alongside the existing token-hash helpers).
2. Migration to add a token_hash column.
3. Update CreateOperatorSession, PromoteOperatorSession, and GetOperatorBySession to write/look up by hash.
4. Drop the plaintext token column in a follow-up migration.
Sessions are ephemeral (24h TTL), so all active sessions can be invalidated on deployment — no backward compatibility needed.
Workarounds
Restrict and encrypt database backups; rotate the operator database. These mitigate exposure but do not fix the underlying storage of plaintext tokens.
Resources
internal/models/operator.go:58-66internal/store/sqlite_operators.go:577-698- Migration
005_operators.up.sql:27 - Prior related advisory: GHSA-ghmh-jhmj-wcmf
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.3.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/forgekeep/nebula-mesh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53603"
],
"database_specific": {
"cwe_ids": [
"CWE-312",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-14T20:17:04Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Impact\n\nOperator session tokens are stored in plaintext in the `operator_sessions` table (the `token` column is the PRIMARY KEY). The session token is a 32-byte random hex value sent directly in a cookie and valid for 24 hours.\n\n- `internal/models/operator.go:61` \u2014 `OperatorSession.Token` holds the plaintext token.\n- `internal/store/sqlite_operators.go:590` \u2014 `CreateOperatorSession` inserts `sess.Token` verbatim.\n- `internal/store/sqlite_operators.go:603,642,681,698` \u2014 lookups/updates/deletes use `WHERE token = ?` against the plaintext value.\n\nAnyone who can read the database (backup, snapshot, file copy, or SQL-level disclosure) obtains every active session token and can hijack operator sessions directly, with no further authentication.\n\nThis is functionally identical to the plaintext enrollment-token issue fixed in GHSA-ghmh-jhmj-wcmf. API keys (`OperatorAPIKey.KeyHash`) and enrollment tokens (`EnrollmentToken.TokenHash`) already store only a SHA256 hash; session tokens were missed.\n\n## Patches\n\nStore only a SHA256 hash of the session token, mirroring API keys and enrollment tokens:\n1. Add a `HashSessionToken` helper (alongside the existing token-hash helpers).\n2. Migration to add a `token_hash` column.\n3. Update `CreateOperatorSession`, `PromoteOperatorSession`, and `GetOperatorBySession` to write/look up by hash.\n4. Drop the plaintext `token` column in a follow-up migration.\n\nSessions are ephemeral (24h TTL), so all active sessions can be invalidated on deployment \u2014 no backward compatibility needed.\n\n## Workarounds\n\nRestrict and encrypt database backups; rotate the operator database. These mitigate exposure but do not fix the underlying storage of plaintext tokens.\n\n## Resources\n\n- `internal/models/operator.go:58-66`\n- `internal/store/sqlite_operators.go:577-698`\n- Migration `005_operators.up.sql:27`\n- Prior related advisory: GHSA-ghmh-jhmj-wcmf",
"id": "GHSA-q4vm-pq3q-8wgq",
"modified": "2026-07-14T20:17:04Z",
"published": "2026-07-14T20:17:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/security/advisories/GHSA-q4vm-pq3q-8wgq"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/commit/7cb01bab281ded557f8b6c81dab5f48d4c10182e"
},
{
"type": "PACKAGE",
"url": "https://github.com/forgekeep/nebula-mesh"
},
{
"type": "WEB",
"url": "https://github.com/forgekeep/nebula-mesh/releases/tag/v0.3.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "nebula-mesh: Operator session tokens stored in plaintext in the database"
}
GHSA-Q5CJ-XF99-79M8
Vulnerability from github – Published: 2023-12-13 18:31 – Updated: 2023-12-18 18:39Jenkins Dingding JSON Pusher Plugin 2.0 and earlier does not mask access tokens displayed on the job configuration form, increasing the potential for attackers to observe and capture them.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.zintow:dingding-json-pusher"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-50773"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-312"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-13T19:44:18Z",
"nvd_published_at": "2023-12-13T18:15:44Z",
"severity": "MODERATE"
},
"details": "Jenkins Dingding JSON Pusher Plugin 2.0 and earlier does not mask access tokens displayed on the job configuration form, increasing the potential for attackers to observe and capture them.",
"id": "GHSA-q5cj-xf99-79m8",
"modified": "2023-12-18T18:39:29Z",
"published": "2023-12-13T18:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50773"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2023-12-13/#SECURITY-3184"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/12/13/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Displayed in plain text by Dingding JSON Pusher Plugin "
}
GHSA-Q65C-V485-VHFQ
Vulnerability from github – Published: 2022-05-13 01:21 – Updated: 2022-05-13 01:21The .NET SDK WebForm Viewer in SAP Crystal Reports for Visual Studio (fixed in version 2010) discloses sensitive database information including credentials which can be misused by the attacker.
{
"affected": [],
"aliases": [
"CVE-2019-0285"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-10T21:29:00Z",
"severity": "CRITICAL"
},
"details": "The .NET SDK WebForm Viewer in SAP Crystal Reports for Visual Studio (fixed in version 2010) discloses sensitive database information including credentials which can be misused by the attacker.",
"id": "GHSA-q65c-v485-vhfq",
"modified": "2022-05-13T01:21:13Z",
"published": "2022-05-13T01:21:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-0285"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2687663"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=517899114"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/153471/SAP-Crystal-Reports-Information-Disclosure.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]
Mitigation
In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.
CAPEC-37: Retrieve Embedded Sensitive Data
An attacker examines a target system to find sensitive data that has been embedded within it. This information can reveal confidential contents, such as account numbers or individual keys/credentials that can be used as an intermediate step in a larger attack.