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-WMVV-FHM6-W34X
Vulnerability from github – Published: 2026-05-05 18:33 – Updated: 2026-05-08 22:16A flaw has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. This issue affects the function PIL.Image.tobytes of the file libs/chatchat-server/chatchat/webui_pages/dialogue/dialogue.py of the component Vision Chat Paste Image Handler. This manipulation of the argument paste_image.image_data causes use of weak hash. The attacker needs to be present on the local network. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langchain-chatchat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.3.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-7845"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:16:42Z",
"nvd_published_at": "2026-05-05T16:16:19Z",
"severity": "LOW"
},
"details": "A flaw has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. This issue affects the function PIL.Image.tobytes of the file libs/chatchat-server/chatchat/webui_pages/dialogue/dialogue.py of the component Vision Chat Paste Image Handler. This manipulation of the argument paste_image.image_data causes use of weak hash. The attacker needs to be present on the local network. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-wmvv-fhm6-w34x",
"modified": "2026-05-08T22:16:42Z",
"published": "2026-05-05T18:33:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7845"
},
{
"type": "WEB",
"url": "https://github.com/chatchat-space/Langchain-Chatchat/issues/5462"
},
{
"type": "WEB",
"url": "https://github.com/3em0/cve_repo/blob/main/Langchain-Chatchat/Vuln-1-tobytes-Hash-Collision.md"
},
{
"type": "PACKAGE",
"url": "https://github.com/chatchat-space/Langchain-Chatchat"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/807794"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/361124"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/361124/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Langchain-Chatchat Uses a Broken or Risky Cryptographic Algorithm"
}
GHSA-WPFF-VMPR-5Q22
Vulnerability from github – Published: 2023-01-17 21:30 – Updated: 2023-01-26 18:30The Birthday attack against 64-bit block ciphers flaw (CVE-2016-2183) was reported for the health checks port (9979) on etcd grpc-proxy component. Even though the CVE-2016-2183 has been fixed in the etcd components, to enable periodic health checks from kubelet, it was necessary to open up a new port (9979) on etcd grpc-proxy, hence this port might be considered as still vulnerable to the same type of vulnerability. The health checks on etcd grpc-proxy do not contain sensitive data (only metrics data), therefore the potential impact related to this vulnerability is minimal. The CVE-2023-0296 has been assigned to this issue to track the permanent fix in the etcd component.
{
"affected": [],
"aliases": [
"CVE-2023-0296"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-17T21:15:00Z",
"severity": "MODERATE"
},
"details": "The Birthday attack against 64-bit block ciphers flaw (CVE-2016-2183) was reported for the health checks port (9979) on etcd grpc-proxy component. Even though the CVE-2016-2183 has been fixed in the etcd components, to enable periodic health checks from kubelet, it was necessary to open up a new port (9979) on etcd grpc-proxy, hence this port might be considered as still vulnerable to the same type of vulnerability. The health checks on etcd grpc-proxy do not contain sensitive data (only metrics data), therefore the potential impact related to this vulnerability is minimal. The CVE-2023-0296 has been assigned to this issue to track the permanent fix in the etcd component.",
"id": "GHSA-wpff-vmpr-5q22",
"modified": "2023-01-26T18:30:48Z",
"published": "2023-01-17T21:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0296"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2022:7399"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:0069"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:0241"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2023-0296"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2161287"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WQGP-VPHW-HPHF
Vulnerability from github – Published: 2021-10-12 16:01 – Updated: 2024-09-04 19:24Authors: Thai "thaidn" Duong
Summary
The following security vulnerabilities was discovered and reported to Amazon, affecting AWS KMS and all versions of AWS Encryption SDKs prior to version 2.0.0:
- Information leakage: an attacker can create ciphertexts that would leak the user’s AWS account ID, encryption context, user agent, and IP address upon decryption
- Ciphertext forgery: an attacker can create ciphertexts that are accepted by other users
- Robustness: an attacker can create ciphertexts that decrypt to different plaintexts for different users
The first two bugs are somewhat surprising because they show that the ciphertext format can lead to vulnerabilities. These bugs (and the infamous alg: "None" bugs in JWT) belong to a class of vulnerabilities called in-band protocol negotiation. This is the second time we’ve found in-band protocol negotiation vulnerabilities in AWS cryptography libraries; see this bug in S3 Crypto SDK discovered by my colleague Sophie Schmieg.
In JWT and S3 SDK the culprit is the algorithm field—here it is the key ID. Because the key ID is used to determine which decryption key to use, it can’t be meaningfully authenticated despite being under the attacker’s control. If the key ID is a URL indicating where to fetch the key, the attacker can replace it with their own URL, and learn side-channel information such as the timing and machines on which the decryption happens (this can also lead to SSRF issues, but that’s another topic for another day).
In AWS, the key ID is a unique Amazon Resource Name. If an attacker were to capture a ciphertext from a user and replace its key ID with their own, the victim’s AWS account ID, encryption context, user agent, and IP address would be logged to the attacker’s AWS account whenever the victim attempted to decrypt the modified ciphertext.
The last bug shows that the non-committing property of AES-GCM (and other AEAD ciphers such as AES-GCM-SIV or (X)ChaCha20Poly1305) is especially problematic in multi-recipient settings. These ciphers have a property that can cause nonidentical plaintexts when decrypting a single ciphertext with two different keys! For example, you can send a single encrypted email to Alice and Bob which, upon decryption, reads “attack” to Alice and “retreat” to Bob. The AWS Encryption SDKs are vulnerable to this attack because they allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. I believe this kind of problem is prevalent. I briefly looked at JWE and I think it is vulnerable.
Mitigations
Amazon has fixed these bugs in release 2.0.0 of the SDKs. A new major version was required because, unfortunately, the fix for the last bug requires a breaking change from earlier versions. All users are recommended to upgrade. More details about Amazon’s mitigations can be found in their announcement.
We’re collaborating with Shay Gueron on a paper regarding fast committing AEADs.
Vulnerabilities
Information Leakage
The Encrypt API in AWS KMS encrypts plaintext into ciphertext by using a customer master key (CMK). The ciphertext format is undocumented, but it contains metadata that specifies the CMK and the encryption algorithm. I reverse-engineered the format and found the location of the CMK. Externally the CMK is identified by its key ARN, but within a ciphertext it is represented by an internal ID, which remained stable during my testing.
When I replaced the internal ID of a CMK in a ciphertext with the internal ID of another CMK, I found that AWS KMS attempted to decrypt the ciphertext with the new CMK. The encryption failed and the failure event—including the AWS Account ID, the user agent and the IP address of the caller—was logged to Cloud Trail in the account that owned the replacement CMK.
This enables the following attack: * The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim. * The attacker intercepts a ciphertext from the victim, and replaces its CMK with their CMK. * Whenever the victim attempts to decrypt the modified ciphertext, the attacker learns the timing of such actions, the victim’s AWS Account ID, user agent, encryption context, and IP address.
This attack requires the victim to have an IAM policy that allows them to access the attacker’s CMK. I found that this practice was allowed by the AWS Visual Policy Editor, but I don’t know whether it is common.
The AWS Encryption SDKs also succumb to this attack. The SDKs implement envelope encryption: encrypting data with a data encryption key (DEK) and then wrapping the DEK with a CMK using the Encrypt API in AWS KMS. The wrapped DEK is stored as part of the final ciphertext (format is defined here). The attacker can mount this attack by replacing the CMK in the wrapped DEK with their own.
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "<redacted this is the principal ID of the victim>",
"accountId": "<redacted - this is the AWS account ID of the victim>"
},
"eventTime": "2020-06-21T21:05:04Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "us-west-2",
"sourceIPAddress": "<redacted - this is the IP address of the victim>",
"userAgent": "<redacted - this is the user agent of the victim>",
"errorCode": "InvalidCiphertextException",
"requestParameters": {
// The encryption context might include other data from the victim
"encryptionContext": {
"aws-crypto-public-key": "AzfNOGOnNYFmpHspKrAm1L6XtRybONkmkhmB/IriKSA7b2NsV4MEPMph9yX2KTPKWw=="
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "aeced8e8-75a2-42c3-96ac-d1fa2a1c5ee6",
"eventID": "780a0a6e-4ad8-43d4-a426-75d05022f870",
"readOnly": true,
"resources": [
{
"accountId": "<redacted - this is the account ID of the attacker>",
"type": "AWS::KMS::Key",
"ARN": <redacted - this is the key ARN of the attacker>
}
],
"eventType": "AwsApiCall",
"recipientAccountId": "<redacted - this is the account ID of the attacker>",
"sharedEventID": "033e147c-8a36-42f5-9d6c-9e071eb752b7"
}
Figure 1: A failure event logged to the attacker’s Cloud Trail when the victim attempted to decrypt a modified ciphertext containing the attacker’s CMK.
Ciphertext Forgery
The Decrypt API in AWS KMS doesn’t require the caller to specify the CMK. This parameter is required only when the ciphertext was encrypted under an asymmetric CMK. Otherwise, AWS KMS uses the metadata that it adds to the ciphertext blob to determine which CMK was used to encrypt the ciphertext.
This leads to the following attack: * The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim. * The attacker generates a ciphertext by calling the Encrypt API with their key. * The attacker intercepts a ciphertext from the victim, and replaces it entirely with their ciphertext. * The victim successfully decrypts the ciphertext, as if it was encrypted under their own key. The attacker also learns when this happened, the victim’s AWS Account ID, user agent, encryption context, and IP address.
Similar to the information leakage attack, this attack also requires the victim to have an IAM policy that allows them to access the attacker’s CMK.
The AWS Encryption SDKs also succumb to this attack. They don’t specify the CMK when they call the Decrypt API to unwrap the DEK.
Robustness
The AWS Encryption SDKs allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. To that end, it wraps the DEK multiple times, each under a different CMK. The wrapped DEKs can be combined to form a single ciphertext which can be sent to multiple recipients who can use their own credentials to decrypt it. It’s reasonable to expect that all recipients should decrypt the ciphertext to an identical plaintext. However, because of the use of AES-GMAC and AES-GCM, it’s possible to create a ciphertext that decrypts to two valid yet different plaintexts for two different users. In other words, the AWS Encryption SDKs are not robust.
The encryption of a message under two CMKs can be summarized as follows: * A DEK is randomly generated, and two wrapped DEKs are produced by calling the Encrypt API using the two CMKs * A per-message AES-GCM key (K) is derived using HKDF from the DEK, a randomly generated message ID, and a fixed algorithm ID. * A header is formed from the wrapped DEKs, the encryption context, and other metadata. A header authentication tag is computed on the header using AES-GMAC with K and a zero IV. * The message is encrypted using AES-GCM with K, a non-zero IV, and fixed associated additional data. This produces a message authentication tag. * The ciphertext consists of the header, the header authentication tag, the encrypted message, and the message authentication tag.
(There’s also a self-signed digital signature that is irrelevant to this discussion).
In order to decrypt a ciphertext, the AWS Encryption SDKs loops over the list of wrapped DEKs and returns the first one that it can successfully unwrap. The attacker therefore can wrap a unique DEK for each recipient. Next, the attacker exploits the non-committing property of GMAC to produce two messages that have the same GMAC tag under two different keys. The attacker has to do this twice, one for the header authentication tag and one for the message authentication tag.
Given a data blob B of one 128-bit block B_1, a GMAC tag is computed as follows:
B_1 * H^2 + B_len * H + J
where H and J depends on the key and B_len depends on the length of B.
To find a message that can produce the same tag under two different keys, one
can add append to B a new block B_2 whose value can be deduced by solving
an algebraic equation. That is, we want to find B_2 such that:
B_1 * H^3 + B_2 * H^2 + B_len * H + J = B_1 * H’^3 + B_2 * H’^2 + B_len * H’ + J’
where H’ and J’ are the corresponding H and J of the other key.
B_2 is the only unknown value in this equation, thus it can be computed using
finite field arithmetics of GF(2^128):
B_2 = [B_1 * (H^3+H’^3) + B_len * (H + H’) + J + J’] * (H^2 + H’^2)^-1.
Figure 2: How to find a message that has the same GMAC tag under two different keys.
The overall attack works as follows: * The attacker generates a random DEK, derives a per-message key K, and encrypts message M with it using AES in counter mode. This generates a ciphertext C. * The attacker generates another random DEK’, derives a per-message key K’, and performs trial decryption of C until the decrypted message M’ has desirable properties. For example, if the attacker wants the first bit of M’ different from that of M, this process should only take a few attempts. * The attacker finds a block C such that the GMAC of C’ = C || C under K and K’ are identical. Denote this tag C’_tag. * The attacker wraps DEK and DEK’ under two recipients’ CMK. * The attacker forms a header H and adds a block H* to the encryption context such that the new H’ has the same authentication tag H’_tag under K and K’. * The attacker output H’, H’_tag, C’, C’_tag.
This attack is similar to the one discovered in Facebook Messenger.
Acknowledgement
I’m grateful to Jen Barnason for carefully editing this advisory. I will never publish anything without her approval! I want to thank my friend and coworker Sophie “Queen of Hashing” Schmieg for wonderful discussions and for showing me how the arithmetic in GF(2^128) works. I want to thank Jonathan Bannet for asking the questions that led to this work.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.amazonaws:aws-encryption-sdk-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "aws-encryption-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-8897"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2021-10-08T22:24:29Z",
"nvd_published_at": "2020-11-16T12:15:00Z",
"severity": "HIGH"
},
"details": "Authors: Thai \"[thaidn](https://twitter.com/xorninja)\" Duong\n\n# Summary\n\nThe following security vulnerabilities was discovered and reported to Amazon, affecting AWS KMS and all versions of [AWS Encryption SDKs](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/introduction.html) prior to version 2.0.0:\n\n* **Information leakage**: an attacker can create ciphertexts that would leak the user\u2019s AWS account ID, encryption context, user agent, and IP address upon decryption\n* **Ciphertext forgery**: an attacker can create ciphertexts that are accepted by other users\n* **Robustness**: an attacker can create ciphertexts that decrypt to different plaintexts for different users\n\nThe first two bugs are somewhat surprising because they show that the ciphertext format can lead to vulnerabilities. These bugs (and the infamous [alg: \"None\"](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/) bugs in JWT) belong to a class of vulnerabilities called **in-band protocol negotiation**. This is the second time we\u2019ve found in-band protocol negotiation vulnerabilities in AWS cryptography libraries; see this [bug](https://github.com/google/security-research/security/advisories/GHSA-7f33-f4f5-xwgw) in S3 Crypto SDK discovered by my colleague Sophie Schmieg.\n\nIn JWT and S3 SDK the culprit is the algorithm field\u2014here it is the key ID. Because the key ID is used to determine which decryption key to use, it can\u2019t be meaningfully authenticated despite being under the attacker\u2019s control. If the key ID is a URL indicating where to fetch the key, the attacker can replace it with their own URL, and learn side-channel information such as the timing and machines on which the decryption happens (this can also lead to [SSRF](https://portswigger.net/web-security/ssrf) issues, but that\u2019s another topic for another day).\n\nIn AWS, the key ID is a unique [Amazon Resource Name](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). If an attacker were to capture a ciphertext from a user and replace its key ID with their own, the victim\u2019s AWS account ID, encryption context, user agent, and IP address would be logged to the attacker\u2019s AWS account whenever the victim attempted to decrypt the modified ciphertext.\n\nThe last bug shows that the non-committing property of AES-GCM (and other AEAD ciphers such as [AES-GCM-SIV](https://keymaterial.net/2020/09/07/invisible-salamanders-in-aes-gcm-siv/) or (X)ChaCha20Poly1305) is especially problematic in multi-recipient settings. These ciphers have a property that can cause nonidentical plaintexts when decrypting a single ciphertext with two different keys! For example, you can send a single encrypted email to Alice and Bob which, upon decryption, reads \u201cattack\u201d to Alice and \u201cretreat\u201d to Bob. The AWS Encryption SDKs are vulnerable to this attack because they allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. I believe this kind of problem is prevalent. I briefly looked at [JWE](https://tools.ietf.org/html/rfc7516) and I think it is vulnerable.\n\n# Mitigations\n\nAmazon has fixed these bugs in release 2.0.0 of the SDKs. A new major version was required because, unfortunately, the fix for the last bug requires a breaking change from earlier versions. All users are recommended to upgrade. More details about Amazon\u2019s mitigations can be found in [their announcement](https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/).\n\nWe\u2019re collaborating with Shay Gueron on a paper regarding fast committing AEADs.\n\n# Vulnerabilities\n\n## Information Leakage\n\nThe [Encrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Encrypt.html) API in AWS KMS encrypts plaintext into ciphertext by using a customer master key (CMK). The ciphertext format is undocumented, but it contains metadata that specifies the CMK and the encryption algorithm. I reverse-engineered the format and found the location of the CMK. Externally the CMK is identified by its key ARN, but within a ciphertext it is represented by an internal ID, which remained stable during my testing.\n\nWhen I replaced the internal ID of a CMK in a ciphertext with the internal ID of another CMK, I found that AWS KMS attempted to decrypt the ciphertext with the new CMK. The encryption failed and the failure event\u2014including the AWS Account ID, the user agent and the IP address of the caller\u2014was logged to Cloud Trail in the account that owned the replacement CMK.\n\nThis enables the following attack:\n* The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim.\n* The attacker intercepts a ciphertext from the victim, and replaces its CMK with their CMK.\n* Whenever the victim attempts to decrypt the modified ciphertext, the attacker learns the timing of such actions, the victim\u2019s AWS Account ID, user agent, encryption context, and IP address.\n\nThis attack requires the victim to have an IAM policy that allows them to access the attacker\u2019s CMK. I found that this practice was allowed by the AWS Visual Policy Editor, but I don\u2019t know whether it is common.\n\nThe AWS Encryption SDKs also succumb to this attack. The SDKs implement envelope encryption: encrypting data with a data encryption key (DEK) and then wrapping the DEK with a CMK using the Encrypt API in AWS KMS. The wrapped DEK is stored as part of the final ciphertext (format is defined [here](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/message-format.html)). The attacker can mount this attack by replacing the CMK in the wrapped DEK with their own.\n\n```\n{\n \"eventVersion\": \"1.05\",\n \"userIdentity\": {\n \"type\": \"AWSAccount\",\n \"principalId\": \"\u003credacted this is the principal ID of the victim\u003e\",\n \"accountId\": \"\u003credacted - this is the AWS account ID of the victim\u003e\"\n },\n \"eventTime\": \"2020-06-21T21:05:04Z\",\n \"eventSource\": \"kms.amazonaws.com\",\n \"eventName\": \"Decrypt\",\n \"awsRegion\": \"us-west-2\",\n \"sourceIPAddress\": \"\u003credacted - this is the IP address of the victim\u003e\",\n \"userAgent\": \"\u003credacted - this is the user agent of the victim\u003e\",\n \"errorCode\": \"InvalidCiphertextException\",\n \"requestParameters\": {\n // The encryption context might include other data from the victim\n \"encryptionContext\": {\n \"aws-crypto-public-key\": \"AzfNOGOnNYFmpHspKrAm1L6XtRybONkmkhmB/IriKSA7b2NsV4MEPMph9yX2KTPKWw==\"\n },\n \"encryptionAlgorithm\": \"SYMMETRIC_DEFAULT\"\n },\n \"responseElements\": null,\n \"requestID\": \"aeced8e8-75a2-42c3-96ac-d1fa2a1c5ee6\",\n \"eventID\": \"780a0a6e-4ad8-43d4-a426-75d05022f870\",\n \"readOnly\": true,\n \"resources\": [\n {\n \"accountId\": \"\u003credacted - this is the account ID of the attacker\u003e\",\n \"type\": \"AWS::KMS::Key\",\n \"ARN\": \u003credacted - this is the key ARN of the attacker\u003e\n }\n ],\n \"eventType\": \"AwsApiCall\",\n \"recipientAccountId\": \"\u003credacted - this is the account ID of the attacker\u003e\",\n \"sharedEventID\": \"033e147c-8a36-42f5-9d6c-9e071eb752b7\"\n}\n```\n**Figure 1: A failure event logged to the attacker\u2019s Cloud Trail when the victim attempted to decrypt a modified ciphertext containing the attacker\u2019s CMK.**\n\n## Ciphertext Forgery\n\nThe [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) API in AWS KMS doesn\u2019t require the caller to specify the CMK. This parameter is required only when the ciphertext was encrypted under an asymmetric CMK. Otherwise, AWS KMS uses the metadata that it adds to the ciphertext blob to determine which CMK was used to encrypt the ciphertext.\n\nThis leads to the following attack:\n* The attacker creates a CMK that has a key policy that allows access from everyone. This requires no prior knowledge about the victim.\n* The attacker generates a ciphertext by calling the Encrypt API with their key.\n* The attacker intercepts a ciphertext from the victim, and replaces it entirely with their ciphertext.\n* The victim successfully decrypts the ciphertext, as if it was encrypted under their own key. The attacker also learns when this happened, the victim\u2019s AWS Account ID, user agent, encryption context, and IP address.\n\nSimilar to the information leakage attack, this attack also requires the victim to have an IAM policy that allows them to access the attacker\u2019s CMK.\n\nThe AWS Encryption SDKs also succumb to this attack. They don\u2019t specify the CMK when they call the Decrypt API to unwrap the DEK.\n\n## Robustness\n\nThe AWS Encryption SDKs allow a single ciphertext to be generated for multiple recipients, with each decrypting using a different key. To that end, it wraps the DEK multiple times, each under a different CMK. The wrapped DEKs can be combined to form a single ciphertext which can be sent to multiple recipients who can use their own credentials to decrypt it. It\u2019s reasonable to expect that all recipients should decrypt the ciphertext to an identical plaintext. However, because of the use of AES-GMAC and AES-GCM, it\u2019s possible to create a ciphertext that decrypts to two valid yet different plaintexts for two different users. In other words, the AWS Encryption SDKs are [not](https://eprint.iacr.org/2008/440.pdf) [robust](https://eprint.iacr.org/2019/016.pdf).\n\nThe encryption of a message under two CMKs can be summarized as follows:\n* A DEK is randomly generated, and two wrapped DEKs are produced by calling the Encrypt API using the two CMKs\n* A per-message AES-GCM key (K) is derived using HKDF from the DEK, a randomly generated message ID, and a fixed algorithm ID.\n* A header is formed from the wrapped DEKs, the encryption context, and other metadata. A header authentication tag is computed on the header using AES-GMAC with K and a zero IV.\n* The message is encrypted using AES-GCM with K, a non-zero IV, and fixed associated additional data. This produces a message authentication tag.\n* The ciphertext consists of the header, the header authentication tag, the encrypted message, and the message authentication tag.\n\n(There\u2019s also a self-signed digital signature that is irrelevant to this discussion).\n\nIn order to decrypt a ciphertext, the AWS Encryption SDKs loops over the list of wrapped DEKs and returns the first one that it can successfully unwrap. The attacker therefore can wrap a unique DEK for each recipient. Next, the attacker exploits the non-committing property of GMAC to produce two messages that have the same GMAC tag under two different keys. The attacker has to do this twice, one for the header authentication tag and one for the message authentication tag.\n\n```\nGiven a data blob B of one 128-bit block B_1, a GMAC tag is computed as follows:\n\nB_1 * H^2 + B_len * H + J\n\nwhere H and J depends on the key and B_len depends on the length of B.\n\nTo find a message that can produce the same tag under two different keys, one\ncan add append to B a new block B_2 whose value can be deduced by solving\nan algebraic equation. That is, we want to find B_2 such that:\n\nB_1 * H^3 + B_2 * H^2 + B_len * H + J = B_1 * H\u2019^3 + B_2 * H\u2019^2 + B_len * H\u2019 + J\u2019\n\nwhere H\u2019 and J\u2019 are the corresponding H and J of the other key.\n\nB_2 is the only unknown value in this equation, thus it can be computed using\nfinite field arithmetics of GF(2^128):\n\nB_2 = [B_1 * (H^3+H\u2019^3) + B_len * (H + H\u2019) + J + J\u2019] * (H^2 + H\u2019^2)^-1.\n```\n**Figure 2: How to find a message that has the same GMAC tag under two different keys.**\n\nThe overall attack works as follows:\n* The attacker generates a random DEK, derives a per-message key K, and encrypts message M with it using AES in counter mode. This generates a ciphertext C.\n* The attacker generates another random DEK\u2019, derives a per-message key K\u2019, and performs trial decryption of C until the decrypted message M\u2019 has desirable properties. For example, if the attacker wants the first bit of M\u2019 different from that of M, this process should only take a few attempts.\n* The attacker finds a block C* such that the GMAC of C\u2019 = C || C* under K and K\u2019 are identical. Denote this tag C\u2019_tag.\n* The attacker wraps DEK and DEK\u2019 under two recipients\u2019 CMK.\n* The attacker forms a header H and adds a block H* to the encryption context such that the new H\u2019 has the same authentication tag H\u2019_tag under K and K\u2019.\n* The attacker output H\u2019, H\u2019_tag, C\u2019, C\u2019_tag.\n\nThis attack is similar to the one discovered in [Facebook Messenger](https://eprint.iacr.org/2019/016.pdf).\n\n# Acknowledgement\n\nI\u2019m grateful to Jen Barnason for carefully editing this advisory. I will never publish anything without her approval! I want to thank my friend and coworker Sophie \u201cQueen of Hashing\u201d Schmieg for wonderful discussions and for showing me how the arithmetic in GF(2^128) works. I want to thank Jonathan Bannet for asking the questions that led to this work.",
"id": "GHSA-wqgp-vphw-hphf",
"modified": "2024-09-04T19:24:49Z",
"published": "2021-10-12T16:01:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/google/security-research/security/advisories/GHSA-wqgp-vphw-hphf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8897"
},
{
"type": "WEB",
"url": "https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/aws-encryption-sdk/PYSEC-2020-261.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"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": "Security issues in AWS KMS and AWS Encryption SDKs: in-band protocol negotiation and robustness"
}
GHSA-WQGX-4Q47-J2W5
Vulnerability from github – Published: 2020-09-04 17:36 – Updated: 2020-08-31 19:00All versions of parsel use an insecure cryptography algorithm. The package uses aes-256-cbc without integrity checks, which renders the ciphertext vulnerable to bit-flipping attacks.
Recommendation
The package is deprecated and will not be updated. Consider using an alternative package.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parsel"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-31T19:00:07Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "All versions of `parsel` use an insecure cryptography algorithm. The package uses `aes-256-cbc` without integrity checks, which renders the ciphertext vulnerable to bit-flipping attacks.\n\n\n## Recommendation\n\nThe package is deprecated and will not be updated. Consider using an alternative package.",
"id": "GHSA-wqgx-4q47-j2w5",
"modified": "2020-08-31T19:00:07Z",
"published": "2020-09-04T17:36:04Z",
"references": [
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/1461"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Insecure Cryptography Algorithm in parsel"
}
GHSA-WR3P-R5FJ-WF97
Vulnerability from github – Published: 2024-07-31 21:32 – Updated: 2024-08-01 13:24An issue in beego v.2.2.0 and before allows a remote attacker to escalate privileges via the getCacheFileName function in the file.go file.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/beego/beego/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-40465"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-328"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-01T13:24:05Z",
"nvd_published_at": "2024-07-31T21:15:17Z",
"severity": "HIGH"
},
"details": "An issue in beego v.2.2.0 and before allows a remote attacker to escalate privileges via the `getCacheFileName` function in the `file.go` file.",
"id": "GHSA-wr3p-r5fj-wf97",
"modified": "2024-08-01T13:24:06Z",
"published": "2024-07-31T21:32:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/beego/beego/security/advisories/GHSA-6g9p-wv47-4fxq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40465"
},
{
"type": "WEB",
"url": "https://github.com/beego/beego/commit/5a366cd62b555354a917a2d153e6563fe4d6eb88"
},
{
"type": "WEB",
"url": "https://github.com/beego/beego/commit/8f89e12e6cafb106d5c201dbc3b2a338bfde74e2"
},
{
"type": "WEB",
"url": "https://gist.github.com/nyxfqq/a5a2fc5147a1b34538e1ac05a3e56910"
},
{
"type": "PACKAGE",
"url": "https://github.com/beego/beego"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Beego privilege escalation vulnerability"
}
GHSA-WW76-PPX6-58RM
Vulnerability from github – Published: 2024-07-02 09:32 – Updated: 2024-07-02 09:32The device is observed to accept deprecated TLS protocols, increasing the risk of cryptographic weaknesses.
{
"affected": [],
"aliases": [
"CVE-2023-41928"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-02T08:15:05Z",
"severity": "MODERATE"
},
"details": "The device is observed to accept deprecated TLS protocols, increasing the risk of cryptographic weaknesses.",
"id": "GHSA-ww76-ppx6-58rm",
"modified": "2024-07-02T09:32:06Z",
"published": "2024-07-02T09:32:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41928"
},
{
"type": "WEB",
"url": "https://advisories.ncsc.nl/advisory?id=NCSC-2024-0273"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WWXW-WHWC-CFVX
Vulnerability from github – Published: 2023-05-25 21:30 – Updated: 2023-05-25 21:30A vulnerability was found in NFine Rapid Development Platform 20230511. It has been classified as problematic. Affected is an unknown function of the file /Login/CheckLogin. The manipulation leads to use of weak hash. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. VDB-229974 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2023-2900"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-328"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-25T21:15:09Z",
"severity": "LOW"
},
"details": "A vulnerability was found in NFine Rapid Development Platform 20230511. It has been classified as problematic. Affected is an unknown function of the file /Login/CheckLogin. The manipulation leads to use of weak hash. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. VDB-229974 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-wwxw-whwc-cfvx",
"modified": "2023-05-25T21:30:31Z",
"published": "2023-05-25T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2900"
},
{
"type": "WEB",
"url": "https://github.com/Peanut886/Vulnerability/blob/main/webray.com.cn/NFine-Rapid-development-platform-has-weak-password-vulnerability.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.229974"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.229974"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WX26-FM45-HVXC
Vulnerability from github – Published: 2022-05-13 01:37 – Updated: 2022-05-13 01:37Beckhoff TwinCAT 3 supports communication over ADS. ADS is a protocol for industrial automation in protected environments. This protocol uses user configured routes, that can be edited remotely via ADS. This special command supports encrypted authentication with username/password. The encryption uses a fixed key, that could be extracted by an attacker. Precondition of the exploitation of this weakness is network access at the moment a route is added.
{
"affected": [],
"aliases": [
"CVE-2017-16718"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-27T19:29:00Z",
"severity": "MODERATE"
},
"details": "Beckhoff TwinCAT 3 supports communication over ADS. ADS is a protocol for industrial automation in protected environments. This protocol uses user configured routes, that can be edited remotely via ADS. This special command supports encrypted authentication with username/password. The encryption uses a fixed key, that could be extracted by an attacker. Precondition of the exploitation of this weakness is network access at the moment a route is added.",
"id": "GHSA-wx26-fm45-hvxc",
"modified": "2022-05-13T01:37:22Z",
"published": "2022-05-13T01:37:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16718"
},
{
"type": "WEB",
"url": "https://download.beckhoff.com/download/Document/product-security/Advisories/advisory-2017-002.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X2GC-X3Q3-8FP4
Vulnerability from github – Published: 2022-05-24 16:55 – Updated: 2024-04-04 01:53An issue was discovered in Total.js CMS 12.0.0. A low privilege user can perform a simple transformation of a cookie to obtain the random values inside it. If an attacker can discover a session cookie owned by an admin, then it is possible to brute force it with O(n)=2n instead of O(n)=n^x complexity, and steal the admin password.
{
"affected": [],
"aliases": [
"CVE-2019-15955"
],
"database_specific": {
"cwe_ids": [
"CWE-327",
"CWE-407"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-05T19:16:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Total.js CMS 12.0.0. A low privilege user can perform a simple transformation of a cookie to obtain the random values inside it. If an attacker can discover a session cookie owned by an admin, then it is possible to brute force it with O(n)=2n instead of O(n)=n^x complexity, and steal the admin password.",
"id": "GHSA-x2gc-x3q3-8fp4",
"modified": "2024-04-04T01:53:20Z",
"published": "2022-05-24T16:55:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-15955"
},
{
"type": "WEB",
"url": "https://github.com/beerpwn/CVE/blob/master/Totaljs_disclosure_report/report_final.pdf"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2019/Sep/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-X2J8-43MR-3Q57
Vulnerability from github – Published: 2023-12-14 03:30 – Updated: 2023-12-14 03:30IBM Spectrum Scale 5.1.5.0 through 5.1.5.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 239080.
{
"affected": [],
"aliases": [
"CVE-2022-43843"
],
"database_specific": {
"cwe_ids": [
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-14T01:15:07Z",
"severity": "MODERATE"
},
"details": "IBM Spectrum Scale 5.1.5.0 through 5.1.5.1 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 239080.",
"id": "GHSA-x2j8-43mr-3q57",
"modified": "2023-12-14T03:30:53Z",
"published": "2023-12-14T03:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43843"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/239080"
},
{
"type": "WEB",
"url": "https://https://www.ibm.com/support/pages/node/7094941"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7094941"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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).