CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1123 vulnerabilities reference this CWE, most recent first.
GHSA-WF4H-8HC9-6CCV
Vulnerability from github – Published: 2022-05-14 01:01 – Updated: 2022-05-14 01:01Enigmail before 2.0.6 is prone to to OpenPGP signatures being spoofed for arbitrary messages using a PGP/INLINE signature wrapped within a specially crafted multipart HTML email.
{
"affected": [],
"aliases": [
"CVE-2018-15586"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-02-11T17:29:00Z",
"severity": "MODERATE"
},
"details": "Enigmail before 2.0.6 is prone to to OpenPGP signatures being spoofed for arbitrary messages using a PGP/INLINE signature wrapped within a specially crafted multipart HTML email.",
"id": "GHSA-wf4h-8hc9-6ccv",
"modified": "2022-05-14T01:01:32Z",
"published": "2022-05-14T01:01:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15586"
},
{
"type": "WEB",
"url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired"
},
{
"type": "WEB",
"url": "https://github.com/RUB-NDS/Johnny-You-Are-Fired/blob/master/paper/johnny-fired.pdf"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/enigmail/bugs/849"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/152703/Johnny-You-Are-Fired.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2019/Apr/38"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2019/04/30/4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WFP5-6M78-CRH3
Vulnerability from github – Published: 2023-08-31 15:30 – Updated: 2024-04-04 07:20An Improper Verification of Cryptographic Signature in the SAML authentication of the Zscaler Admin UI allows a Privilege Escalation.This issue affects Admin UI: from 6.2 before 6.2r.
{
"affected": [],
"aliases": [
"CVE-2023-28801"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-31T14:15:08Z",
"severity": "CRITICAL"
},
"details": "An Improper Verification of Cryptographic Signature in the SAML authentication of the Zscaler Admin UI allows a Privilege Escalation.This issue affects Admin UI: from 6.2 before 6.2r.\n\n",
"id": "GHSA-wfp5-6m78-crh3",
"modified": "2024-04-04T07:20:24Z",
"published": "2023-08-31T15:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28801"
},
{
"type": "WEB",
"url": "https://help.zscaler.com/zia/release-upgrade-summary-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WG47-6JQ2-Q2HH
Vulnerability from github – Published: 2025-04-04 14:28 – Updated: 2025-04-04 14:28Impact
This is a high priority vulnerability and users must upgrade ASAP.
The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket,
Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary.
However with relevant information in place, uploading random objects to buckets is trivial and easy via curl
Patches
Yes https://github.com/minio/minio/pull/21103
Workarounds
Reject requests with x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER for now at LB layer, ask application users to use STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/minio/minio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20250403145552-8c70975283f9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-31489"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-04T14:28:29Z",
"nvd_published_at": "2025-04-03T20:15:25Z",
"severity": "HIGH"
},
"details": "### Impact\nThis is a high priority vulnerability and users must upgrade ASAP.\n\nThe signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket,\n\nPrior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary.\n\nHowever with relevant information in place, uploading random objects to buckets is trivial and easy via `curl`\n\n### Patches\nYes https://github.com/minio/minio/pull/21103\n\n### Workarounds\nReject requests with `x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER` for now at LB layer, ask application users to use `STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER`",
"id": "GHSA-wg47-6jq2-q2hh",
"modified": "2025-04-04T14:28:29Z",
"published": "2025-04-04T14:28:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/minio/minio/security/advisories/GHSA-wg47-6jq2-q2hh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31489"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/pull/21103"
},
{
"type": "WEB",
"url": "https://github.com/minio/minio/commit/8c70975283f9f4ce80f331a25c7475a36279e519"
},
{
"type": "PACKAGE",
"url": "https://github.com/minio/minio"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/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": "MinIO performs incomplete signature validation for unsigned-trailer uploads"
}
GHSA-WGJG-8JRW-H95F
Vulnerability from github – Published: 2022-05-17 00:17 – Updated: 2022-05-17 00:17FusionSphere OpenStack V100R006C00SPC102(NFV)has an improper verification of cryptographic signature vulnerability. The software does not verify the cryptographic signature. An attacker with high privilege may exploit this vulnerability to inject malicious software.
{
"affected": [],
"aliases": [
"CVE-2017-8190"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-22T19:29:00Z",
"severity": "MODERATE"
},
"details": "FusionSphere OpenStack V100R006C00SPC102(NFV)has an improper verification of cryptographic signature vulnerability. The software does not verify the cryptographic signature. An attacker with high privilege may exploit this vulnerability to inject malicious software.",
"id": "GHSA-wgjg-8jrw-h95f",
"modified": "2022-05-17T00:17:08Z",
"published": "2022-05-17T00:17:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8190"
},
{
"type": "WEB",
"url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20171018-01-fusionsphere-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WH2W-39F4-RPV2
Vulnerability from github – Published: 2024-08-30 18:41 – Updated: 2024-08-30 18:41Name
Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender.
Description
A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because: 1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions). 1. Any DID can change any other DID's alias. 1. The update transaction modifies the ledger metadata associated with a DID.
Expected vs Observed
We expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the Indy default auth_rules in Section "Who is the owner" in the last point of "Endorser using".
We observe that with a normal DID, we can update the field from for a random DID, for example, the one of a TRUSTEE. It creates then a new transaction on the ledger.
Explanation of the attack
We first begin to connect to the pool and open a wallet. Then, we will use a TRUSTEE (but can also be a STEWARD or an ENDORSER) DID V4SGRU86Z58d6TV7PBUe6f. We ask the information about V4SGRU86Z58d6TV7PBUe6f with a get-nym. We create a new DID V4SGRU86Z58d6TV7PBUe1a signed by V4SGRU86Z58d6TV7PBUe6f with no role. For the rest of the attack, we will use V4SGRU86Z58d6TV7PBUe1a to sign new transactions. We send a ledger nym did=V4SGRU86Z58d6TV7PBUe6f extra=hello to see if V4SGRU86Z58d6TV7PBUe1a can send an update of a TRUSTEE identity. When we ask information to the ledger about V4SGRU86Z58d6TV7PBUe6f, it answers that the from field is V4SGRU86Z58d6TV7PBUe1a (to compare with the first get-nym we did with from field = V4SGRU86Z58d6TV7PBUe6f). To see the log of the attack, I modified my indy-cli to print the json request and the json response directly on the terminal. You can find the log file indy.log in this archive.
Implementation notes
NymHandler method update_state, line 62. I think that we need to check if the DID which signs the transaction, owns the DID or is its endorser.
Steps to Reproduce
Environment
Ubuntu 18.04
Docker version 19.03.8
indy-cli
indy-ci Dockerfile is copied in this archive
To install indy-cli, run ./install_indy_cli.sh
Command
Here is the script to create the container, run the attack and remove the container and the image. Find below the command to execute each step separately.
./full_attack.sh
Installation of the environment
Install indy-cli and create an image with tag test from Dockerfile
./install.sh
Exploit
indy-cli proof_of_concept
Uninstallation of the environment
Suppress the container test and remove the image test
./uninstall.sh
Analysis
We are grateful to @alexandredeleze for discovering and responsibly disclosing the issue.
We were previously aware that any DID on the ledger can "update" the state (seqNo + txnTime) if it doesn't change the state data itself. We considered this a minor bug because only the seqNo and txnTime changed. But seeing that this can also affect the "parent" DID means that it has a higher severity.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "indy-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-11093"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2024-08-30T18:41:16Z",
"nvd_published_at": "2020-12-24T20:15:00Z",
"severity": "HIGH"
},
"details": "# Name\nUpdating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender.\n\n# Description\nA malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because:\n1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions).\n1. Any DID can change any other DID\u0027s alias. \n1. The update transaction modifies the ledger metadata associated with a DID. \n\n# Expected vs Observed\nWe expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the [Indy default auth_rules](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) in Section \"Who is the owner\" in the last point of \"Endorser using\". \n\nWe observe that with a normal DID, we can update the field `from` for a random DID, for example, the one of a TRUSTEE. It creates then a new transaction on the ledger.\n\n# Explanation of the attack\nWe first begin to connect to the pool and open a wallet. Then, we will use a TRUSTEE (but can also be a STEWARD or an ENDORSER) DID `V4SGRU86Z58d6TV7PBUe6f`. We ask the information about `V4SGRU86Z58d6TV7PBUe6f` with a get-nym. We create a new DID `V4SGRU86Z58d6TV7PBUe1a` signed by `V4SGRU86Z58d6TV7PBUe6f` with no role. For the rest of the attack, we will use `V4SGRU86Z58d6TV7PBUe1a` to sign new transactions. We send a `ledger nym did=V4SGRU86Z58d6TV7PBUe6f extra=hello` to see if `V4SGRU86Z58d6TV7PBUe1a` can send an update of a TRUSTEE identity. When we ask information to the ledger about `V4SGRU86Z58d6TV7PBUe6f`, it answers that the `from` field is `V4SGRU86Z58d6TV7PBUe1a` (to compare with the first get-nym we did with `from` field = `V4SGRU86Z58d6TV7PBUe6f`). To see the log of the attack, I modified my indy-cli to print the json request and the json response directly on the terminal. You can find the log file `indy.log` in this archive.\n\n# Implementation notes\n[NymHandler](https://github.com/hyperledger/indy-node/blob/e5676b703d625e42c9547333bd03bb8307ed534c/indy_node/server/request_handlers/domain_req_handlers/nym_handler.py) method `update_state`, line 62. I think that we need to check if the DID which signs the transaction, owns the DID or is its endorser.\n\n# Steps to Reproduce\n\n## Environment\nUbuntu 18.04\nDocker version 19.03.8\n[indy-cli](https://github.com/hyperledger/indy-sdk/tree/master/cli)\n[indy-ci](https://github.com/hyperledger/indy-sdk/tree/master/ci) Dockerfile is copied in this archive\nTo install indy-cli, run `./install_indy_cli.sh`\n\n\n## Command\nHere is the script to create the container, run the attack and remove the container and the image. Find below the command to execute each step separately.\n```\n./full_attack.sh\n```\n\n### Installation of the environment\nInstall indy-cli and create an image with tag `test` from Dockerfile\n```\n./install.sh\n```\n\n### Exploit\n```\nindy-cli proof_of_concept\n```\n\n### Uninstallation of the environment\nSuppress the container `test` and remove the image `test`\n```\n./uninstall.sh\n```\n# Analysis\nWe are grateful to @alexandredeleze for discovering and responsibly disclosing the issue.\n\nWe were previously aware that any DID on the ledger can \"update\" the state (seqNo + txnTime) if it doesn\u0027t change the state data itself. We considered this a minor bug because only the seqNo and txnTime changed. But seeing that this can also affect the \"parent\" DID means that it has a higher severity.",
"id": "GHSA-wh2w-39f4-rpv2",
"modified": "2024-08-30T18:41:16Z",
"published": "2024-08-30T18:41:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hyperledger/indy-node/security/advisories/GHSA-wh2w-39f4-rpv2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11093"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/indy-node/commit/55056f22c83b7c3520488b615e1577e0f895d75a"
},
{
"type": "PACKAGE",
"url": "https://github.com/hyperledger/indy-node"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/indy-node/blob/master/CHANGELOG.md#1124"
},
{
"type": "WEB",
"url": "https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/indy-node/PYSEC-2020-48.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hyperledger Indy\u0027s update process of a DID does not check who signs the request"
}
GHSA-WJ3M-9V78-X5G4
Vulnerability from github – Published: 2022-05-14 01:48 – Updated: 2022-05-14 01:48In sig_verify() in x509.c in axTLS version 2.1.3 and before, the PKCS#1 v1.5 signature verification does not reject excess data after the hash value. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation through fake X.509 certificates. This is a variant of CVE-2006-4340.
{
"affected": [],
"aliases": [
"CVE-2018-16150"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-07T20:29:00Z",
"severity": "MODERATE"
},
"details": "In sig_verify() in x509.c in axTLS version 2.1.3 and before, the PKCS#1 v1.5 signature verification does not reject excess data after the hash value. Consequently, a remote attacker can forge signatures when small public exponents are being used, which could lead to impersonation through fake X.509 certificates. This is a variant of CVE-2006-4340.",
"id": "GHSA-wj3m-9v78-x5g4",
"modified": "2022-05-14T01:48:57Z",
"published": "2022-05-14T01:48:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16150"
},
{
"type": "WEB",
"url": "https://github.com/igrr/axtls-8266/commit/5efe2947ab45e81d84b5f707c51d1c64be52f36c"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/axtls/mailman/message/36459928"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WJMP-WPHQ-JVQF
Vulnerability from github – Published: 2025-05-06 21:18 – Updated: 2025-05-06 21:43Overview
This vulnerability allows an attacker to impersonate any user during SAML authentication by crafting a SAMLResponse. This can be done by using a valid SAML object that was signed by the configured IdP.
Am I Affected?
You are affected by this SAML Signature Wrapping vulnerability if you are using passport-wsfed-saml2 version 4.6.3 or below, specifically under the following conditions:
1. The service provider is using passport-wsfed-saml2,
2. A valid SAML document signed by the Identity Provider can be obtained.
Fix
Upgrade to v4.6.4 or greater.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.3"
},
"package": {
"ecosystem": "npm",
"name": "passport-wsfed-saml2"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.5"
},
{
"fixed": "4.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46572"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-06T21:18:43Z",
"nvd_published_at": "2025-05-06T21:16:20Z",
"severity": "CRITICAL"
},
"details": "### Overview\nThis vulnerability allows an attacker to impersonate any user during SAML authentication by crafting a SAMLResponse. This can be done by using a valid SAML object that was signed by the configured IdP.\n\n### Am I Affected?\nYou are affected by this SAML Signature Wrapping vulnerability if you are using `passport-wsfed-saml2` version 4.6.3 or below, specifically under the following conditions:\n1. The service provider is using `passport-wsfed-saml2`,\n2. A valid SAML document signed by the Identity Provider can be obtained.\n\n### Fix\nUpgrade to v4.6.4 or greater.",
"id": "GHSA-wjmp-wphq-jvqf",
"modified": "2025-05-06T21:43:47Z",
"published": "2025-05-06T21:18:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/passport-wsfed-saml2/security/advisories/GHSA-wjmp-wphq-jvqf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46572"
},
{
"type": "WEB",
"url": "https://github.com/auth0/passport-wsfed-saml2/commit/e5cf3cc2a53748207f7a81bfba9195c8efa94181"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/passport-wsfed-saml2"
}
],
"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:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Passport-wsfed-saml2 allows SAML Authentication Bypass via Signature Wrapping"
}
GHSA-WJVM-2XMX-5VHG
Vulnerability from github – Published: 2024-07-10 21:30 – Updated: 2024-07-10 21:30An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent's executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked.
{
"affected": [],
"aliases": [
"CVE-2024-5912"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-10T19:15:11Z",
"severity": "MODERATE"
},
"details": "An improper file signature check in Palo Alto Networks Cortex XDR agent may allow an attacker to bypass the Cortex XDR agent\u0027s executable blocking capabilities and run untrusted executables on the device. This issue can be leveraged to execute untrusted software without being detected or blocked.",
"id": "GHSA-wjvm-2xmx-5vhg",
"modified": "2024-07-10T21:30:38Z",
"published": "2024-07-10T21:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5912"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2024-5912"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/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:N/R:U/V:C/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-WMMR-FRFJ-GMMW
Vulnerability from github – Published: 2023-02-06 15:30 – Updated: 2025-03-26 21:30Western Digital My Cloud devices before OS5 do not use cryptographically signed Firmware upgrade files.
{
"affected": [],
"aliases": [
"CVE-2021-36226"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-06T14:15:00Z",
"severity": "CRITICAL"
},
"details": "Western Digital My Cloud devices before OS5 do not use cryptographically signed Firmware upgrade files.",
"id": "GHSA-wmmr-frfj-gmmw",
"modified": "2025-03-26T21:30:44Z",
"published": "2023-02-06T15:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36226"
},
{
"type": "WEB",
"url": "https://github.com/pedrib/PoC/blob/master/advisories/Pwn2Own/Tokyo_2020/weekend_destroyer/weekend_destroyer.md"
},
{
"type": "WEB",
"url": "https://krebsonsecurity.com/2021/07/another-0-day-looms-for-many-western-digital-users"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=vsg9YgvGBec"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-WMQC-JFC8-PFM5
Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2024-11-27 21:32The Portable Document Format (PDF) specification does not provide any information regarding the concrete procedure of how to validate signatures. Consequently, a Signature Wrapping vulnerability exists in multiple products. An attacker can use /ByteRange and xref manipulations that are not detected by the signature-validation logic. This affects Foxit Reader before 9.4 and PhantomPDF before 8.3.9 and 9.x before 9.4. It also affects eXpert PDF 12 Ultimate, Expert PDF Reader, Nitro Pro, Nitro Reader, PDF Architect 6, PDF Editor 6 Pro, PDF Experte 9 Ultimate, PDFelement6 Pro, PDF Studio Viewer 2018, PDF Studio Pro, PDF-XChange Editor and Viewer, Perfect PDF 10 Premium, Perfect PDF Reader, Soda PDF, and Soda PDF Desktop.
{
"affected": [],
"aliases": [
"CVE-2018-18689"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-07T18:15:00Z",
"severity": "MODERATE"
},
"details": "The Portable Document Format (PDF) specification does not provide any information regarding the concrete procedure of how to validate signatures. Consequently, a Signature Wrapping vulnerability exists in multiple products. An attacker can use /ByteRange and xref manipulations that are not detected by the signature-validation logic. This affects Foxit Reader before 9.4 and PhantomPDF before 8.3.9 and 9.x before 9.4. It also affects eXpert PDF 12 Ultimate, Expert PDF Reader, Nitro Pro, Nitro Reader, PDF Architect 6, PDF Editor 6 Pro, PDF Experte 9 Ultimate, PDFelement6 Pro, PDF Studio Viewer 2018, PDF Studio Pro, PDF-XChange Editor and Viewer, Perfect PDF 10 Premium, Perfect PDF Reader, Soda PDF, and Soda PDF Desktop.",
"id": "GHSA-wmqc-jfc8-pfm5",
"modified": "2024-11-27T21:32:36Z",
"published": "2022-05-24T17:38:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18689"
},
{
"type": "WEB",
"url": "https://pdf-insecurity.org/signature/evaluation_2018.html"
},
{
"type": "WEB",
"url": "https://pdf-insecurity.org/signature/signature.html"
},
{
"type": "WEB",
"url": "https://www.foxitsoftware.com/support/security-bulletins.php"
},
{
"type": "WEB",
"url": "https://www.pdfa.org/recently-identified-pdf-digital-signature-vulnerabilities"
}
],
"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"
}
]
}
No mitigation information available for this CWE.
CAPEC-463: Padding Oracle Crypto Attack
An adversary is able to efficiently decrypt data without knowing the decryption key if a target system leaks data on whether or not a padding error happened while decrypting the ciphertext. A target system that leaks this type of information becomes the padding oracle and an adversary is able to make use of that oracle to efficiently decrypt data without knowing the decryption key by issuing on average 128*b calls to the padding oracle (where b is the number of bytes in the ciphertext block). In addition to performing decryption, an adversary is also able to produce valid ciphertexts (i.e., perform encryption) by using the padding oracle, all without knowing the encryption key.
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.