CWE-327
Allowed-with-ReviewUse of a Broken or Risky Cryptographic Algorithm
Abstraction: Class · Status: Draft
The product uses a broken or risky cryptographic algorithm or protocol.
960 vulnerabilities reference this CWE, most recent first.
GHSA-6943-QR24-82VX
Vulnerability from github – Published: 2024-12-02 17:16 – Updated: 2024-12-02 22:05Impact
The OpenID Connect implementation, in the affected SFTPGo versions, allows authenticated users to brute force session cookies and thereby gain access to other users' data, since the cookies are generated predictably using the xid library and are therefore unique but not cryptographically secure.
Patches
This issue was fixed in version v2.6.4, where cookies are opaque and cryptographically secure strings.
References
https://github.com/drakkan/sftpgo/commit/f30a9a2095bf90c0661b04fe038e3b7efc788bc6
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/drakkan/sftpgo/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.3.0"
},
{
"fixed": "2.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-52801"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-02T17:16:34Z",
"nvd_published_at": "2024-11-29T19:15:08Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe OpenID Connect implementation, in the affected SFTPGo versions, allows authenticated users to brute force session cookies and thereby gain access to other users\u0027 data, since the cookies are generated predictably using the [xid](https://github.com/rs/xid) library and are therefore unique but not cryptographically secure.\n\n### Patches\n\nThis issue was fixed in version v2.6.4, where cookies are opaque and cryptographically secure strings.\n\n### References\n\nhttps://github.com/drakkan/sftpgo/commit/f30a9a2095bf90c0661b04fe038e3b7efc788bc6\n",
"id": "GHSA-6943-qr24-82vx",
"modified": "2024-12-02T22:05:00Z",
"published": "2024-12-02T17:16:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/drakkan/sftpgo/security/advisories/GHSA-6943-qr24-82vx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52801"
},
{
"type": "WEB",
"url": "https://github.com/drakkan/sftpgo/commit/f30a9a2095bf90c0661b04fe038e3b7efc788bc6"
},
{
"type": "PACKAGE",
"url": "https://github.com/drakkan/sftpgo"
},
{
"type": "WEB",
"url": "https://github.com/rs/xid"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/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"
}
],
"summary": "sftpgo vulnerable to brute force takeover of OpenID Connect session cookies"
}
GHSA-69CC-CV78-QC8G
Vulnerability from github – Published: 2026-04-09 21:31 – Updated: 2026-05-20 22:14Configured cipher preference order not preserved vulnerability in Apache Tomcat.
This issue affects Apache Tomcat: from 11.0.16 through 11.0.18, from 10.1.51 through 10.1.52, from 9.0.114 through 9.0.115.
Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-coyote"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.114"
},
{
"fixed": "9.0.116"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-coyote"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.51"
},
{
"fixed": "10.1.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat-coyote"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.16"
},
{
"fixed": "11.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.114"
},
{
"fixed": "9.0.116"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.51"
},
{
"fixed": "10.1.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat:tomcat"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.16"
},
{
"fixed": "11.0.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.114"
},
{
"fixed": "9.0.116"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "10.1.51"
},
{
"fixed": "10.1.53"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.tomcat.embed:tomcat-embed-core"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.16"
},
{
"fixed": "11.0.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29129"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T22:07:11Z",
"nvd_published_at": "2026-04-09T20:16:24Z",
"severity": "HIGH"
},
"details": "Configured cipher preference order not preserved vulnerability in Apache Tomcat.\n\nThis issue affects Apache Tomcat: from 11.0.16 through 11.0.18, from 10.1.51 through 10.1.52, from 9.0.114 through 9.0.115.\n\nUsers are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.",
"id": "GHSA-69cc-cv78-qc8g",
"modified": "2026-05-20T22:14:28Z",
"published": "2026-04-09T21:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29129"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/5cfa876d73f1ff5f4dc8309c4320f684cbeff74e"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/6db238562ec36ab1106db4d04843f8b33e7a0c06"
},
{
"type": "WEB",
"url": "https://github.com/apache/tomcat/commit/8d69b33764dba81dce89e3a768de6093a35620ae"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/tomcat"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/r4h1t6f8xhxsxfm6c2z5cprolsosho3f"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-10.html#Fixed_in_Apache_Tomcat_10.1.53"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-11.html#Fixed_in_Apache_Tomcat_11.0.20"
},
{
"type": "WEB",
"url": "https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.116"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/04/09/22"
}
],
"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"
}
],
"summary": "Apache Tomcat: Configured cipher preference order not preserved"
}
GHSA-69HF-98Q7-WJQ8
Vulnerability from github – Published: 2022-05-13 01:10 – Updated: 2022-05-13 01:10The kube-rbac-proxy container before version 0.4.1 as used in Red Hat OpenShift Container Platform does not honor TLS configurations, allowing for use of insecure ciphers and TLS 1.0. An attacker could target traffic sent over a TLS connection with a weak configuration and potentially break the encryption.
{
"affected": [],
"aliases": [
"CVE-2019-3818"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-05T17:29:00Z",
"severity": "HIGH"
},
"details": "The kube-rbac-proxy container before version 0.4.1 as used in Red Hat OpenShift Container Platform does not honor TLS configurations, allowing for use of insecure ciphers and TLS 1.0. An attacker could target traffic sent over a TLS connection with a weak configuration and potentially break the encryption.",
"id": "GHSA-69hf-98q7-wjq8",
"modified": "2022-05-13T01:10:02Z",
"published": "2022-05-13T01:10:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3818"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHBA-2019:0327"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2019-3818"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3818"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106744"
}
],
"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-69RM-7RJQ-RH7J
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31A vulnerability in the web-based management interface of Cisco Small Business RV320 and RV325 Dual Gigabit WAN VPN Routers could allow an unauthenticated, remote attacker to access administrative credentials. The vulnerability exists because affected devices use weak encryption algorithms for user credentials. An attacker could exploit this vulnerability by conducting a man-in-the-middle attack and decrypting intercepted credentials. A successful exploit could allow the attacker to gain access to an affected device with administrator privileges. This vulnerability affects Cisco Small Business RV320 and RV325 Dual Gigabit WAN VPN Routers running firmware releases prior to 1.4.2.22.
{
"affected": [],
"aliases": [
"CVE-2019-1828"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-04T16:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the web-based management interface of Cisco Small Business RV320 and RV325 Dual Gigabit WAN VPN Routers could allow an unauthenticated, remote attacker to access administrative credentials. The vulnerability exists because affected devices use weak encryption algorithms for user credentials. An attacker could exploit this vulnerability by conducting a man-in-the-middle attack and decrypting intercepted credentials. A successful exploit could allow the attacker to gain access to an affected device with administrator privileges. This vulnerability affects Cisco Small Business RV320 and RV325 Dual Gigabit WAN VPN Routers running firmware releases prior to 1.4.2.22.",
"id": "GHSA-69rm-7rjq-rh7j",
"modified": "2022-05-13T01:31:19Z",
"published": "2022-05-13T01:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1828"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190404-rv-weak-encrypt"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107774"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-69X8-HRGQ-FJJ8
Vulnerability from github – Published: 2026-04-08 00:04 – Updated: 2026-04-08 00:04Impact
Three issues combine into a full authentication bypass chain:
- Weak hashing: User passwords are stored as unsalted SHA-256 hashes, making them vulnerable to rainbow table attacks and trivially identifying users with identical passwords.
- Hash exposure: Multiple API endpoints (/user/info, /user/update, /spend/users) return the password hash field in responses to any authenticated user regardless of role. Plaintext passwords could also potentially be exposed in certain scenarios.
- Pass-the-hash: The /v2/login endpoint accepts the raw SHA-256 hash as a valid password without re-hashing, allowing direct login with a stolen
An already authenticated user can retrieve another user's password hash from the API and use it to log in as that user. This enables full privilege escalation in three HTTP requests.
Patches
Fixed in v1.83.0. Passwords are now hashed with scrypt (random 16-byte salt, n=16384, r=8, p=1). Password hashes are stripped from all API responses. Existing SHA-256 hashes are transparently migrated on next login.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "litellm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.83.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-327",
"CWE-916"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:04:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nThree issues combine into a full authentication bypass chain:\n\n1. Weak hashing: User passwords are stored as unsalted SHA-256 hashes, making them vulnerable to rainbow table attacks and trivially identifying users with identical passwords.\n2. Hash exposure: Multiple API endpoints (/user/info, /user/update, /spend/users) return the password hash field in responses to any authenticated user regardless of role. Plaintext passwords could also potentially be exposed in certain scenarios.\n4. Pass-the-hash: The /v2/login endpoint accepts the raw SHA-256 hash as a valid password without re-hashing, allowing direct login with a stolen\n\nAn already authenticated user can retrieve another user\u0027s password hash from the API and use it to log in as that user. This enables full privilege escalation in three HTTP requests.\n\n### Patches\n\nFixed in v1.83.0. Passwords are now hashed with scrypt (random 16-byte salt, n=16384, r=8, p=1). Password hashes are stripped from all API responses. Existing SHA-256 hashes are transparently migrated on next login.",
"id": "GHSA-69x8-hrgq-fjj8",
"modified": "2026-04-08T00:04:12Z",
"published": "2026-04-08T00:04:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-69x8-hrgq-fjj8"
},
{
"type": "PACKAGE",
"url": "https://github.com/BerriAI/litellm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "LiteLLM: Password hash exposure and pass-the-hash authentication bypass"
}
GHSA-6C5P-J8VQ-PQHJ
Vulnerability from github – Published: 2024-04-26 00:30 – Updated: 2025-02-18 22:48python-jose through 3.3.0 has algorithm confusion with OpenSSH ECDSA keys and other key formats. This is similar to CVE-2022-29217.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "python-jose"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-33663"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-26T16:57:59Z",
"nvd_published_at": "2024-04-26T00:15:09Z",
"severity": "CRITICAL"
},
"details": "python-jose through 3.3.0 has algorithm confusion with OpenSSH ECDSA keys and other key formats. This is similar to CVE-2022-29217.",
"id": "GHSA-6c5p-j8vq-pqhj",
"modified": "2025-02-18T22:48:15Z",
"published": "2024-04-26T00:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33663"
},
{
"type": "WEB",
"url": "https://github.com/mpdavis/python-jose/issues/346"
},
{
"type": "PACKAGE",
"url": "https://github.com/mpdavis/python-jose"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/python-jose/PYSEC-2024-232.yaml"
},
{
"type": "WEB",
"url": "https://www.vicarius.io/vsociety/posts/algorithm-confusion-in-python-jose-cve-2024-33663"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "python-jose algorithm confusion with OpenSSH ECDSA keys"
}
GHSA-6C7M-QWXJ-MVHP
Vulnerability from github – Published: 2021-11-19 20:55 – Updated: 2021-11-24 19:01Summary
Broken encryption in app-functions-sdk “AES” transform in EdgeX Foundry releases prior to Jakarta allows attackers to decrypt messages via unspecified vectors.
Detailed Description
The app-functions-sdk exports an “aes” transform that user scripts can optionally call to encrypt data in the processing pipeline. No decrypt function is provided. Encryption is not enabled by default, but if used, the level of protection may be less than the user may expects due to a broken implementation in https://github.com/edgexfoundry/app-functions-sdk-go/blob/v1.0.0/pkg/transforms/encryption.go
Version v2.1.0 (EdgeX Foundry Jakarta release and later) of app-functions-sdk-go/v2 deprecates the “aes” transform and provides an improved “aes256” transform in its place. The broken implementation will remain in a deprecated state until it is removed in the next EdgeX major release to avoid breakage of existing software that depends on the broken implementation.
Impact
As the broken transform is a library function that is not invoked by default, users who do not use the AES transform in their processing pipelines are unaffected. Those that are affected are urged to upgrade to the Jakarta EdgeX release and modify processing pipelines to use the new "aes256" transform.
Vulnerable go modules
- github.com/edgexfoundry/app-functions-sdk-go < v2.1.0
- github.com/edgexfoundry/app-functions-sdk-go/v2 < v2.1.0
- github.com/edgexfoundry/app-service-configurable < v2.1.0
Vulnerable containers
- https://hub.docker.com/r/edgexfoundry/app-service-configurable >= 2.0.0 < v2.1.0
- https://hub.docker.com/r/edgexfoundry/app-service-configurable-arm64 >= 2.0.0 < 2.1.0
- https://hub.docker.com/r/edgexfoundry/docker-app-service-configurable < 2.0.0
- https://hub.docker.com/r/edgexfoundry/docker-app-service-configurable-arm64 < 2.0.0
Vulnerable Snaps
- https://snapcraft.io/edgex-app-service-configurable >= 2.0.0 < 2.1.0
Patches
Upgrade to 2.1.0 version of app-functions-sdk-go/v2, app-service-configurable, and related docker containers shown below and modify user scripts to use the new "aes256" transform in place of the existing "aes" transform.
Patched go modules
- github.com/edgexfoundry/app-functions-sdk-go/v2 v2.1.0
- github.com/edgexfoundry/app-service-configurable v2.1.0
Modification of user scripts is necessary for full remediation.
Patched containers
- https://hub.docker.com/r/edgexfoundry/app-service-configurable:>=2.1.0
- https://hub.docker.com/r/edgexfoundry/app-service-configurable-arm64:>=2.1.0
Modification of user scripts is necessary for full remediation.
Patched Snaps
- https://snapcraft.io/edgex-app-service-configurable >= 2.1.0
Modification of user scripts is necessary for full remediation.
Workarounds
If unable to upgrade, change the processing pipeline to use an HTTPS (TLS 1.3) endpoint to export and skip encryption.
References
For more information
If you have any questions or comments about this advisory: * Contact us in the Slack #security channel * Open an issue in edgex-go * Email us at EdgeX-TSC-Security@lists.edgexfoundry.org
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/edgexfoundry/app-functions-sdk-go/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2.1.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/edgexfoundry/app-functions-sdk-go"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/edgexfoundry/app-service-configurable"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41278"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-18T23:05:06Z",
"nvd_published_at": "2021-11-19T00:15:00Z",
"severity": "MODERATE"
},
"details": "### Summary\nBroken encryption in app-functions-sdk \u201cAES\u201d transform in EdgeX Foundry releases prior to Jakarta allows attackers to decrypt messages via unspecified vectors.\n\n### Detailed Description\nThe app-functions-sdk exports an \u201caes\u201d transform that user scripts can optionally call to encrypt data in the processing pipeline. No decrypt function is provided. Encryption is not enabled by default, but if used, the level of protection may be less than the user may expects due to a broken implementation in https://github.com/edgexfoundry/app-functions-sdk-go/blob/v1.0.0/pkg/transforms/encryption.go \n\nVersion v2.1.0 (EdgeX Foundry Jakarta release and later) of app-functions-sdk-go/v2 deprecates the \u201caes\u201d transform and provides an improved \u201caes256\u201d transform in its place. The broken implementation will remain in a deprecated state until it is removed in the next EdgeX major release to avoid breakage of existing software that depends on the broken implementation.\n\n### Impact\nAs the broken transform is a library function that is not invoked by default, users who do not use the AES transform in their processing pipelines are unaffected. Those that are affected are urged to upgrade to the Jakarta EdgeX release and modify processing pipelines to use the new \"aes256\" transform.\n\n#### Vulnerable go modules\n- github.com/edgexfoundry/app-functions-sdk-go \u003c v2.1.0\n- github.com/edgexfoundry/app-functions-sdk-go/v2 \u003c v2.1.0\n- github.com/edgexfoundry/app-service-configurable \u003c v2.1.0\n\n#### Vulnerable containers\n- https://hub.docker.com/r/edgexfoundry/app-service-configurable \u003e= 2.0.0 \u003c v2.1.0\n- https://hub.docker.com/r/edgexfoundry/app-service-configurable-arm64 \u003e= 2.0.0 \u003c 2.1.0\n- https://hub.docker.com/r/edgexfoundry/docker-app-service-configurable \u003c 2.0.0\n- https://hub.docker.com/r/edgexfoundry/docker-app-service-configurable-arm64 \u003c 2.0.0 \n\n#### Vulnerable Snaps\n- https://snapcraft.io/edgex-app-service-configurable \u003e= 2.0.0 \u003c 2.1.0\n\n### Patches\nUpgrade to 2.1.0 version of app-functions-sdk-go/v2, app-service-configurable, and related docker containers shown below and modify user scripts to use the new \"aes256\" transform in place of the existing \"aes\" transform.\n\n#### Patched go modules\n- github.com/edgexfoundry/app-functions-sdk-go/v2 v2.1.0\n- github.com/edgexfoundry/app-service-configurable v2.1.0\n\nModification of user scripts is necessary for full remediation.\n\n#### Patched containers\n- https://hub.docker.com/r/edgexfoundry/app-service-configurable:\u003e=2.1.0\n- https://hub.docker.com/r/edgexfoundry/app-service-configurable-arm64:\u003e=2.1.0\n\nModification of user scripts is necessary for full remediation.\n\n#### Patched Snaps\n- https://snapcraft.io/edgex-app-service-configurable \u003e= 2.1.0\n\nModification of user scripts is necessary for full remediation.\n\n### Workarounds\nIf unable to upgrade, change the processing pipeline to use an HTTPS (TLS 1.3) endpoint to export and skip encryption.\n\n### References\n* [2.0 documentation](https://docs.edgexfoundry.org/2.0/microservices/application/BuiltIn/#aes)\n* [2.1 documentation](https://docs.edgexfoundry.org/2.1/microservices/application/BuiltIn/#encryption-deprecated)\n* [GitHub issue](https://github.com/edgexfoundry/app-functions-sdk-go/issues/968)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Contact us in the [Slack #security channel](https://slack.edgexfoundry.org/)\n* Open an issue in [edgex-go](https://github.com/edgexfoundry/edgex-go)\n* Email us at [EdgeX-TSC-Security@lists.edgexfoundry.org](mailto:EdgeX-TSC-Security@lists.edgexfoundry.org)",
"id": "GHSA-6c7m-qwxj-mvhp",
"modified": "2021-11-24T19:01:48Z",
"published": "2021-11-19T20:55:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/edgexfoundry/app-functions-sdk-go/security/advisories/GHSA-6c7m-qwxj-mvhp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41278"
},
{
"type": "WEB",
"url": "https://github.com/edgexfoundry/app-functions-sdk-go/commit/8fa13c6388ce76a6b878b54490eac61aa7d81165"
},
{
"type": "PACKAGE",
"url": "https://github.com/edgexfoundry/app-functions-sdk-go"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Broken encryption in EdgeX Foundry"
}
GHSA-6C8G-9HFH-PQ5H
Vulnerability from github – Published: 2026-05-19 14:44 – Updated: 2026-06-09 11:56Summary
The hmacBase64() function in the HAXcms Node.js backend contains two critical cryptographic implementation errors that together allow any unauthenticated attacker to extract the system’s private signing key and forge arbitrary admin-level JSON Web Tokens (JWTs) allowing them to get full admin access with a single HTTP request.
Details
Bug 1: Hardcoded HMAC Key (line 2160): The function passes the literal string "0" as the HMAC signing key instead of the key parameter, making every HAXcms instance compute identical HMACs for the same input.
Bug 2: Private Key Appended to Output (lines 2161- 2163): After computing the HMAC, the function concatenates the real key parameter which is "this.privateKey + this.salt", the system’s master signing secret is directly onto the output. The combined buffer is base64-encoded and returned as the token.
Every base64url token produced has the same structure: 32 bytes HMAC keyed with "0" and N bytes of privateKey+salt. An attacker base64-decodes any token, discards the first 32 bytes, and reads the private key directly.
The /system/api/connectionSettings endpoint is unauthenticated and returns multiple tokens generated by this function. A single GET request to this endpoint exposes the private key.
The PHP backend (HAXCMS.php:1619-1631) implements this function correctly with the actual key and returns only the hash. The PHP version produces 44-character tokens whereas the broken Node.js version produces 139+ character tokens.
PoC
- GET request to
/system/api/connectionSettingsendpoint and fetch the token. - Extract the private key from the fetched token. The
hmacBase64()function produces 32 bytes with HMAC-SHA256 with hardcoded key "0" and the rest of the bytes areprivateKey+salt(plaintext). Decode the Base64 token, discard the first 32 bytes, read the remaining bytes as UTF-8 (this is your extracted private key). - Since JWT's are signed with
privateKey+salt, use this stolen private key to forge a JWT for admin usingJWT.sign(payload, this.privateKey+this.salt). NOTE: the payload uses {id, user (set this as admin), iat (current timestamp), exp (expiration timestamp)} - The same key can also be used to create other tokens (user_token, base_token, form_token, etc).
- Use these forged tokens to hit all authenticated endpoints (modify/delete/create etc) with admin privileges.
Impact
An unauthenticated attacker can perform the complete attack chain with a single HTTP request: 1. Extract private key: GET "/system/api/connectionSettings", base64-decode any token, discard first 32 bytes. 2. Forge admin JWT: sign arbitrary JWT payloads with the stolen privateKey+salt. 3. Forge all request tokens: compute valid user_token, site_token for any API call. 4. Full admin access: create/modify/delete sites, upload files, modify content.
This works even if the admin has changed the default credentials to a strong password. The forged tokens produce no login events in logs.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 25.0.0"
},
"package": {
"ecosystem": "npm",
"name": "@haxtheweb/haxcms-nodejs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46395"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-321",
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-19T14:44:55Z",
"nvd_published_at": "2026-06-05T19:16:33Z",
"severity": "CRITICAL"
},
"details": "### Summary\nThe `hmacBase64()` function in the HAXcms Node.js backend contains two critical cryptographic implementation errors that together allow any unauthenticated attacker to extract the system\u2019s private signing key and forge arbitrary admin-level JSON Web Tokens (JWTs) allowing them to get full admin access with a single HTTP request.\n\n### Details\nBug 1: Hardcoded HMAC Key (line 2160): The function passes the literal string \"0\" as the HMAC signing key instead of the key parameter, making every HAXcms instance compute identical HMACs for the same input.\n\nBug 2: Private Key Appended to Output (lines 2161- 2163): After computing the HMAC, the function concatenates the real key parameter which is \"this.privateKey + this.salt\", the system\u2019s master signing secret is directly onto the output. The combined buffer is base64-encoded and returned as the token.\n\nEvery base64url token produced has the same structure: 32 bytes HMAC keyed with \"0\" and N bytes of `privateKey+salt`. An attacker base64-decodes any token, discards the first 32 bytes, and reads the private key directly.\n\nThe `/system/api/connectionSettings` endpoint is unauthenticated and returns multiple tokens generated by this function. A single GET request to this endpoint exposes the private key.\n\nThe PHP backend (HAXCMS.php:1619-1631) implements this function correctly with the actual key and returns only the hash. The PHP version produces 44-character tokens whereas the broken Node.js version produces 139+ character tokens.\n\n### PoC\n1. GET request to `/system/api/connectionSettings` endpoint and fetch the token.\n2. Extract the private key from the fetched token. The `hmacBase64()` function produces 32 bytes with HMAC-SHA256 with hardcoded key \"0\" and the rest of the bytes are `privateKey+salt` (plaintext). Decode the Base64 token, discard the first 32 bytes, read the remaining bytes as UTF-8 (this is your extracted private key).\n3. Since JWT\u0027s are signed with `privateKey+salt`, use this stolen private key to forge a JWT for admin using `JWT.sign(payload, this.privateKey+this.salt)`. NOTE: the payload uses {id, user (set this as admin), iat (current timestamp), exp (expiration timestamp)}\n4. The same key can also be used to create other tokens (user_token, base_token, form_token, etc).\n5. Use these forged tokens to hit all authenticated endpoints (modify/delete/create etc) with admin privileges.\n\n### Impact\nAn unauthenticated attacker can perform the complete attack chain with a single HTTP request:\n1. Extract private key: GET \"/system/api/connectionSettings\", base64-decode any token, discard first 32 bytes.\n2. Forge admin JWT: sign arbitrary JWT payloads with the stolen privateKey+salt.\n3. Forge all request tokens: compute valid user_token, site_token for any API call.\n4. Full admin access: create/modify/delete sites, upload files, modify content.\n\nThis works even if the admin has changed the default credentials to a strong password. The forged tokens produce no login events in logs.",
"id": "GHSA-6c8g-9hfh-pq5h",
"modified": "2026-06-09T11:56:50Z",
"published": "2026-05-19T14:44:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/haxtheweb/issues/security/advisories/GHSA-6c8g-9hfh-pq5h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46395"
},
{
"type": "PACKAGE",
"url": "https://github.com/haxtheweb/issues"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "HAXcms: Private Key Disclosure via Broken HMAC Implementation"
}
GHSA-6CHQ-6Q95-5FF8
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44In the "NQ Contacts Backup & Restore" application 1.1 for Android, DES encryption with a static key is used to secure transmitted contact data. This makes it easier for remote attackers to obtain cleartext information by sniffing the network.
{
"affected": [],
"aliases": [
"CVE-2017-15998"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-29T17:29:00Z",
"severity": "HIGH"
},
"details": "In the \"NQ Contacts Backup \u0026 Restore\" application 1.1 for Android, DES encryption with a static key is used to secure transmitted contact data. This makes it easier for remote attackers to obtain cleartext information by sniffing the network.",
"id": "GHSA-6chq-6q95-5ff8",
"modified": "2022-05-13T01:44:03Z",
"published": "2022-05-13T01:44:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15998"
},
{
"type": "WEB",
"url": "https://1337sec.blogspot.de/2017/10/auditing-nq-contacts-backup-restore-11.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6CQP-FRFR-84VG
Vulnerability from github – Published: 2025-10-13 00:30 – Updated: 2025-10-13 00:30A vulnerability was determined in Tomofun Furbo 360 and Furbo Mini. The impacted element is an unknown function of the file /etc/shadow of the component Password Handler. Executing manipulation can lead to use of weak hash. The physical device can be targeted for the attack. The attack requires a high level of complexity. The exploitability is regarded as difficult. The exploit has been publicly disclosed and may be utilized. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-11650"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-12T23:15:32Z",
"severity": "LOW"
},
"details": "A vulnerability was determined in Tomofun Furbo 360 and Furbo Mini. The impacted element is an unknown function of the file /etc/shadow of the component Password Handler. Executing manipulation can lead to use of weak hash. The physical device can be targeted for the attack. The attack requires a high level of complexity. The exploitability is regarded as difficult. The exploit has been publicly disclosed and may be utilized. The firmware versions determined to be affected are Furbo 360 up to FB0035_FW_036 and Furbo Mini up to MC0020_FW_074. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-6cqp-frfr-84vg",
"modified": "2025-10-13T00:30:13Z",
"published": "2025-10-13T00:30:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11650"
},
{
"type": "WEB",
"url": "https://github.com/dead1nfluence/Furbo-Advisories/blob/main/Insecure-Encryption-Algorithm.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.328061"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.328061"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.662771"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:P/AC:H/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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"
}
]
}
Mitigation MIT-24
Strategy: Libraries or Frameworks
- When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.
- For example, US government systems require FIPS 140-2 certification [REF-1192].
- Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.
- Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]
Mitigation MIT-52
Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
Mitigation
Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant.
Mitigation MIT-4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
- Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.
Mitigation MIT-25
When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks.
CAPEC-20: Encryption Brute Forcing
An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-475: Signature Spoofing by Improper Validation
An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.
CAPEC-608: Cryptanalysis of Cellular Encryption
The use of cryptanalytic techniques to derive cryptographic keys or otherwise effectively defeat cellular encryption to reveal traffic content. Some cellular encryption algorithms such as A5/1 and A5/2 (specified for GSM use) are known to be vulnerable to such attacks and commercial tools are available to execute these attacks and decrypt mobile phone conversations in real-time. Newer encryption algorithms in use by UMTS and LTE are stronger and currently believed to be less vulnerable to these types of attacks. Note, however, that an attacker with a Cellular Rogue Base Station can force the use of weak cellular encryption even by newer mobile devices.
CAPEC-614: Rooting SIM Cards
SIM cards are the de facto trust anchor of mobile devices worldwide. The cards protect the mobile identity of subscribers, associate devices with phone numbers, and increasingly store payment credentials, for example in NFC-enabled phones with mobile wallets. This attack leverages over-the-air (OTA) updates deployed via cryptographically-secured SMS messages to deliver executable code to the SIM. By cracking the DES key, an attacker can send properly signed binary SMS messages to a device, which are treated as Java applets and are executed on the SIM. These applets are allowed to send SMS, change voicemail numbers, and query the phone location, among many other predefined functions. These capabilities alone provide plenty of potential for abuse.
CAPEC-97: Cryptanalysis
Cryptanalysis is a process of finding weaknesses in cryptographic algorithms and using these weaknesses to decipher the ciphertext without knowing the secret key (instance deduction). Sometimes the weakness is not in the cryptographic algorithm itself, but rather in how it is applied that makes cryptanalysis successful. An attacker may have other goals as well, such as: Total Break (finding the secret key), Global Deduction (finding a functionally equivalent algorithm for encryption and decryption that does not require knowledge of the secret key), Information Deduction (gaining some information about plaintexts or ciphertexts that was not previously known) and Distinguishing Algorithm (the attacker has the ability to distinguish the output of the encryption (ciphertext) from a random permutation of bits).