CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1277 vulnerabilities reference this CWE, most recent first.
GHSA-6JQJ-F58P-MRW3
Vulnerability from github – Published: 2021-12-20 18:17 – Updated: 2024-05-31 17:46Description
Denial of Service
Tendermint 0.33.0 and above allow block proposers to include signatures for the wrong block. This may happen naturally if you start a network, have it run for some time and restart it without changing the chainID. (It is a misconfiguration to reuse chainIDs.) Correct block proposers will accidentally include signatures for the wrong block if they see these signatures, and then commits won't validate, making all proposed blocks invalid. A malicious validator (even with a minimal amount of stake) can use this vulnerability to completely halt the network.
Tendermint 0.33.6 checks all the signatures are for the block with +2/3 majority before creating a commit.
False Witness
Tendermint 0.33.1 and above are no longer fully verifying commit signatures during block execution - they stop after +2/3. This means proposers can propose blocks that contain valid +2/3 signatures and then the rest of the signatures can be whatever they want. They can claim that all the other validators signed just by including a CommitSig with arbitrary signature data. While this doesn't seem to impact safety of Tendermint per se, it means that Commits may contain a lot of invalid data **.
** This was already true of blocks, since they could include invalid txs filled with garbage, but in that case the application knew that they are invalid and could punish the proposer. But since applications didn't--and don't-- verify commit signatures directly (they trust Tendermint to do that), they won't be able to detect it.
This can impact incentivization logic in the application that depends on the LastCommitInfo sent in BeginBlock, which includes which validators signed. For instance, Gaia incentivizes proposers with a bonus for including more than +2/3 of the signatures. But a proposer can now claim that bonus just by including arbitrary data for the final -1/3 of validators without actually waiting for their signatures. There may be other tricks that can be played because of this.
Tendermint 0.33.6 verifies all the signatures during block execution ***.
*** Please note that the light client does not check nil votes and exits as soon as 2/3+ of the signatures are checked.
Impact
- All nodes
- The network stops due to having a commit with a wrong signature.
Patches
- v0.33.6 andn v0.34.0-dev1.0.20200702134149-480b995a3172
Workarounds
No workarounds.
References
- https://github.com/tendermint/tendermint/issues/4926
For more information
If you have any questions or comments about this advisory: * Open an issue in tendermint/tendermint * Email us at security@tendermint.com
More information can be found here.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tendermint/tendermint"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.33.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15091"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-24T20:49:56Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Description\n\n**Denial of Service**\n\nTendermint 0.33.0 and above allow block proposers to include signatures for the wrong block. This may happen naturally if you start a network, have it run for some time and restart it without changing the chainID. (It is a [misconfiguration](https://docs.tendermint.com/master/tendermint-core/using-tendermint.html) to reuse chainIDs.) Correct block proposers will accidentally include signatures for the wrong block if they see these signatures, and then commits won\u0027t validate, making all proposed blocks invalid. A malicious validator (even with a minimal amount of stake) can use this vulnerability to completely halt the network.\n\nTendermint 0.33.6 checks all the signatures are for the block with +2/3 majority before creating a commit.\n\n**False Witness**\n\nTendermint 0.33.1 and above are no longer fully verifying commit signatures during block execution - they stop after +2/3. This means proposers can propose blocks that contain valid +2/3 signatures and then the rest of the signatures can be whatever they want. They can claim that all the other validators signed just by including a CommitSig with arbitrary signature data. While this doesn\u0027t seem to impact safety of Tendermint per se, it means that Commits may contain a lot of invalid data **.\n\n_** This was already true of blocks, since they could include invalid txs filled with garbage, but in that case the application knew that they are invalid and could punish the proposer. But since applications didn\u0027t--and don\u0027t-- verify commit signatures directly (they trust Tendermint to do that), they won\u0027t be able to detect it._\n\nThis can impact incentivization logic in the application that depends on the LastCommitInfo sent in BeginBlock, which includes which validators signed. For instance, Gaia incentivizes proposers with a bonus for including more than +2/3 of the signatures. But a proposer can now claim that bonus just by including arbitrary data for the final -1/3 of validators without actually waiting for their signatures. There may be other tricks that can be played because of this.\n\nTendermint 0.33.6 verifies all the signatures during block execution ***.\n\n_*** Please note that the light client does not check nil votes and exits as soon as 2/3+ of the signatures are checked._\n\n### Impact\n\n- All nodes\n- The network stops due to having a commit with a wrong signature.\n\n### Patches\n\n- v0.33.6 andn v0.34.0-dev1.0.20200702134149-480b995a3172\n\n### Workarounds\n\nNo workarounds.\n\n### References\n\n- https://github.com/tendermint/tendermint/issues/4926\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [tendermint/tendermint](https://github.com/tendermint/tendermint)\n* Email us at [security@tendermint.com](mailto:security@tendermint.com)\n\nMore information can be found [here](https://tendermint.com/security/).",
"id": "GHSA-6jqj-f58p-mrw3",
"modified": "2024-05-31T17:46:56Z",
"published": "2021-12-20T18:17:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/security/advisories/GHSA-6jqj-f58p-mrw3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15091"
},
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/issues/4926"
},
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/pull/5426"
},
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/commit/480b995a31727593f58b361af979054d17d84340"
},
{
"type": "PACKAGE",
"url": "https://github.com/tendermint/tendermint"
},
{
"type": "WEB",
"url": "https://github.com/tendermint/tendermint/blob/master/CHANGELOG.md#v0336"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2021-0090"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of Service in TenderMint"
}
GHSA-6M7W-FFCP-F725
Vulnerability from github – Published: 2022-01-29 00:00 – Updated: 2022-04-20 00:01A firmware update vulnerability exists in the "update" firmware checks functionality of reolink RLC-410W v3.0.0.136_20121102. A specially-crafted HTTP request can lead to firmware update. An attacker can send a sequence of requests to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-21134"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-28T20:15:00Z",
"severity": "HIGH"
},
"details": "A firmware update vulnerability exists in the \u0026quot;update\u0026quot; firmware checks functionality of reolink RLC-410W v3.0.0.136_20121102. A specially-crafted HTTP request can lead to firmware update. An attacker can send a sequence of requests to trigger this vulnerability.",
"id": "GHSA-6m7w-ffcp-f725",
"modified": "2022-04-20T00:01:44Z",
"published": "2022-01-29T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21134"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2021-1447"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6PCX-JF98-3W2H
Vulnerability from github – Published: 2026-04-16 06:31 – Updated: 2026-04-16 06:31The Payment Gateway for Redsys & WooCommerce Lite plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in versions up to, and including, 7.0.0 due to successful_request() handlers calculating a local signature but not validating Ds_Signature from the request before accepting payment status across the Redsys, Bizum, and Google Pay gateway flows. This makes it possible for unauthenticated attackers to forge payment callback data and mark pending orders as paid when they know a valid order key and order amount, potentially allowing checkout completion and product or service fulfillment without a successful payment.
{
"affected": [],
"aliases": [
"CVE-2026-5050"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-16T06:16:20Z",
"severity": "HIGH"
},
"details": "The Payment Gateway for Redsys \u0026 WooCommerce Lite plugin for WordPress is vulnerable to Improper Verification of Cryptographic Signature in versions up to, and including, 7.0.0 due to successful_request() handlers calculating a local signature but not validating Ds_Signature from the request before accepting payment status across the Redsys, Bizum, and Google Pay gateway flows. This makes it possible for unauthenticated attackers to forge payment callback data and mark pending orders as paid when they know a valid order key and order amount, potentially allowing checkout completion and product or service fulfillment without a successful payment.",
"id": "GHSA-6pcx-jf98-3w2h",
"modified": "2026-04-16T06:31:23Z",
"published": "2026-04-16T06:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5050"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3501998/woo-redsys-gateway-light"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/80544889-8efc-4aa0-a690-774b1ee6a1a0?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6QHV-4H7R-2G9M
Vulnerability from github – Published: 2025-06-20 18:08 – Updated: 2025-06-27 22:02Impact
rfc3161-client 1.0.2 and earlier contain a flaw in their timestamp response signature verification logic. In particular, it performs chain verification against the TSR's embedded certificates up to the trusted root(s), but fails to verify the TSR's own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce any TSR signature so long as the embedded leaf chains up to some root TSA.
Patches
Users should immediately upgrade to rfc3161-client 1.0.3 or later.
Workarounds
There is no workaround possible. Users should immediately upgrade to a fixed version.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.2"
},
"package": {
"ecosystem": "PyPI",
"name": "rfc3161-client"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-52556"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-20T18:08:40Z",
"nvd_published_at": "2025-06-21T02:15:19Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\n`rfc3161-client` 1.0.2 and earlier contain a flaw in their timestamp response signature verification logic. In particular, it performs chain verification against the TSR\u0027s embedded certificates up to the trusted root(s), but fails to verify the TSR\u0027s own signature against the timestamping leaf certificates. Consequently, vulnerable versions perform insufficient signature validation to properly consider a TSR verified, as the attacker can introduce _any_ TSR signature so long as the embedded leaf chains up to some root TSA.\n\n### Patches\n\nUsers should immediately upgrade to `rfc3161-client` 1.0.3 or later.\n\n### Workarounds\n\nThere is no workaround possible. Users should immediately upgrade to a fixed version.",
"id": "GHSA-6qhv-4h7r-2g9m",
"modified": "2025-06-27T22:02:46Z",
"published": "2025-06-20T18:08:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/trailofbits/rfc3161-client/security/advisories/GHSA-6qhv-4h7r-2g9m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52556"
},
{
"type": "WEB",
"url": "https://github.com/trailofbits/rfc3161-client/commit/724a184f953e3f171f85cb223871172b41b0d0dc"
},
{
"type": "PACKAGE",
"url": "https://github.com/trailofbits/rfc3161-client"
}
],
"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": "rfc3161-client has insufficient verification for timestamp response signatures"
}
GHSA-6R88-384V-FG82
Vulnerability from github – Published: 2022-05-13 01:23 – Updated: 2022-05-13 01:23The crypto.generateCRMFRequest method in Mozilla Firefox before 28.0 and SeaMonkey before 2.25 does not properly validate a certain key type, which allows remote attackers to cause a denial of service (application crash) via vectors that trigger generation of a key that supports the Elliptic Curve ec-dual-use algorithm.
{
"affected": [],
"aliases": [
"CVE-2014-1498"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-03-19T10:55:00Z",
"severity": "MODERATE"
},
"details": "The crypto.generateCRMFRequest method in Mozilla Firefox before 28.0 and SeaMonkey before 2.25 does not properly validate a certain key type, which allows remote attackers to cause a denial of service (application crash) via vectors that trigger generation of a key that supports the Elliptic Curve ec-dual-use algorithm.",
"id": "GHSA-6r88-384v-fg82",
"modified": "2022-05-13T01:23:27Z",
"published": "2022-05-13T01:23:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-1498"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=935618"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/201504-01"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2014-03/msg00016.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2014-03/msg00017.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2014-03/msg00022.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2014-04/msg00016.html"
},
{
"type": "WEB",
"url": "http://www.mozilla.org/security/announce/2014/mfsa2014-18.html"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/topics/security/bulletinapr2016-2952098.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6V48-QPG5-FJ4M
Vulnerability from github – Published: 2023-09-13 18:31 – Updated: 2024-01-25 18:30A vulnerability in Cisco IOS XR Software image verification checks could allow an authenticated, local attacker to execute arbitrary code on the underlying operating system.
This vulnerability is due to a time-of-check, time-of-use (TOCTOU) race condition when an install query regarding an ISO image is performed during an install operation that uses an ISO image. An attacker could exploit this vulnerability by modifying an ISO image and then carrying out install requests in parallel. A successful exploit could allow the attacker to execute arbitrary code on an affected device.
{
"affected": [],
"aliases": [
"CVE-2023-20135"
],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-13T17:15:09Z",
"severity": "HIGH"
},
"details": "A vulnerability in Cisco IOS XR Software image verification checks could allow an authenticated, local attacker to execute arbitrary code on the underlying operating system.\n\n This vulnerability is due to a time-of-check, time-of-use (TOCTOU) race condition when an install query regarding an ISO image is performed during an install operation that uses an ISO image. An attacker could exploit this vulnerability by modifying an ISO image and then carrying out install requests in parallel. A successful exploit could allow the attacker to execute arbitrary code on an affected device.",
"id": "GHSA-6v48-qpg5-fj4m",
"modified": "2024-01-25T18:30:43Z",
"published": "2023-09-13T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20135"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-lnt-L9zOkBz5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6VJQ-3XR5-4JH8
Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30Secure Boot Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-26194"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-09T17:15:37Z",
"severity": "HIGH"
},
"details": "Secure Boot Security Feature Bypass Vulnerability",
"id": "GHSA-6vjq-3xr5-4jh8",
"modified": "2024-04-09T18:30:25Z",
"published": "2024-04-09T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26194"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26194"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6VVH-PXR4-25R7
Vulnerability from github – Published: 2026-06-18 21:08 – Updated: 2026-06-18 21:08Impact
The experimental Chacha20Poly1305 key-encryption algorithm generates the 16-byte Poly1305 authentication tag during encryptKey() but discards it: the tag is never written to the header and therefore never reaches the wire. On the receiving side, decryptKey() calls openssl_decrypt('chacha20-poly1305', ...) without the tag argument, which makes OpenSSL skip authentication entirely.
As a result the AEAD construction is silently degraded to unauthenticated ChaCha20: a tampered encrypted CEK is accepted, and because ChaCha20 is a stream cipher, a single-byte change in the ciphertext propagates as a single-byte change in the recovered CEK with no integrity check (CWE-353 / CWE-347). An attacker on the token path can manipulate the wrapped key without detection.
Affected configurations
Applications that register Jose\Experimental\KeyEncryption\Chacha20Poly1305 (package web-token/jwt-experimental) as a JWE alg.
Patches
encryptKey() now publishes the Poly1305 tag as the base64url tag header parameter (and asserts it is 16 bytes). decryptKey() requires the tag header, validates its length, and passes it to openssl_decrypt() so the tag is actually verified, in line with RFC 7539 / RFC 8439. Tampering now results in a decryption failure.
Note: this changes the wire format of tokens produced with this experimental algorithm (a
tagheader is now emitted and required).
Workarounds
Do not use the experimental Chacha20Poly1305 key-encryption algorithm for untrusted input until upgraded.
References
- RFC 7539 / RFC 8439 (ChaCha20-Poly1305 AEAD)
- CWE-353: Missing Support for Integrity Check
Résolution
Un correctif a été préparé sur une branche dédiée basée sur 3.4.x, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).
ChaCha20-Poly1305 — le tag d'authentification Poly1305 est désormais publié dans le header au chiffrement et vérifié au déchiffrement (RFC 7539), rétablissant l'intégrité AEAD.
Validation : php -l OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs 3.4.x), aucun commentaire ajouté dans le code source. Après merge, cascade prévue 3.4.x → 4.0.x → 4.1.x.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "web-token/jwt-experimental"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "4.1.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "web-token/jwt-library"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "web-token/jwt-library"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "web-token/jwt-library"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.0"
},
{
"fixed": "4.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-347",
"CWE-353"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T21:08:15Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe experimental `Chacha20Poly1305` key-encryption algorithm generates the 16-byte Poly1305 authentication tag during `encryptKey()` but **discards it**: the tag is never written to the header and therefore never reaches the wire. On the receiving side, `decryptKey()` calls `openssl_decrypt(\u0027chacha20-poly1305\u0027, ...)` **without the tag argument**, which makes OpenSSL skip authentication entirely.\n\nAs a result the AEAD construction is silently degraded to unauthenticated ChaCha20: a tampered encrypted CEK is accepted, and because ChaCha20 is a stream cipher, a single-byte change in the ciphertext propagates as a single-byte change in the recovered CEK with no integrity check (CWE-353 / CWE-347). An attacker on the token path can manipulate the wrapped key without detection.\n\n### Affected configurations\n\nApplications that register `Jose\\Experimental\\KeyEncryption\\Chacha20Poly1305` (package `web-token/jwt-experimental`) as a JWE `alg`.\n\n### Patches\n\n`encryptKey()` now publishes the Poly1305 tag as the base64url `tag` header parameter (and asserts it is 16 bytes). `decryptKey()` requires the `tag` header, validates its length, and passes it to `openssl_decrypt()` so the tag is actually verified, in line with RFC 7539 / RFC 8439. Tampering now results in a decryption failure.\n\n\u003e Note: this changes the wire format of tokens produced with this experimental algorithm (a `tag` header is now emitted and required).\n\n### Workarounds\n\nDo not use the experimental `Chacha20Poly1305` key-encryption algorithm for untrusted input until upgraded.\n\n### References\n\n- RFC 7539 / RFC 8439 (ChaCha20-Poly1305 AEAD)\n- CWE-353: Missing Support for Integrity Check\n\n## R\u00e9solution\n\nUn correctif a \u00e9t\u00e9 pr\u00e9par\u00e9 sur une branche d\u00e9di\u00e9e bas\u00e9e sur `3.4.x`, avec des tests anti-r\u00e9gression d\u00e9di\u00e9s (fork priv\u00e9 temporaire de cette advisory, PR #1).\n\n**ChaCha20-Poly1305** \u2014 le tag d\u0027authentification Poly1305 est d\u00e9sormais publi\u00e9 dans le header au chiffrement et v\u00e9rifi\u00e9 au d\u00e9chiffrement (RFC 7539), r\u00e9tablissant l\u0027int\u00e9grit\u00e9 AEAD.\n\n**Validation :** `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (diff\u00e9rentiel nul vs `3.4.x`), aucun commentaire ajout\u00e9 dans le code source. Apr\u00e8s merge, cascade pr\u00e9vue `3.4.x \u2192 4.0.x \u2192 4.1.x`.",
"id": "GHSA-6vvh-pxr4-25r7",
"modified": "2026-06-18T21:08:15Z",
"published": "2026-06-18T21:08:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/web-token/jwt-framework/security/advisories/GHSA-6vvh-pxr4-25r7"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/web-token/jwt-library/GHSA-6vvh-pxr4-25r7.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/web-token/jwt-framework"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "PHP JWT Framework: Chacha20Poly1305 key-encryption algorithm discards the Poly1305 authentication tag, performing no authentication on decryption"
}
GHSA-6W2F-Q3RQ-JH8V
Vulnerability from github – Published: 2021-12-31 00:00 – Updated: 2022-01-08 00:00Trendnet AC2600 TEW-827DRU version 2.08B01 contains an improper access control configuration that could allow for a malicious firmware update. It is possible to manually install firmware that may be malicious in nature as there does not appear to be any signature validation done to determine if it is from a known and trusted source. This includes firmware updates that are done via the automated "check for updates" in the admin interface. If an attacker is able to masquerade as the update server, the device will not verify that the firmware updates downloaded are legitimate.
{
"affected": [],
"aliases": [
"CVE-2021-20156"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-30T22:15:00Z",
"severity": "MODERATE"
},
"details": "Trendnet AC2600 TEW-827DRU version 2.08B01 contains an improper access control configuration that could allow for a malicious firmware update. It is possible to manually install firmware that may be malicious in nature as there does not appear to be any signature validation done to determine if it is from a known and trusted source. This includes firmware updates that are done via the automated \"check for updates\" in the admin interface. If an attacker is able to masquerade as the update server, the device will not verify that the firmware updates downloaded are legitimate.",
"id": "GHSA-6w2f-q3rq-jh8v",
"modified": "2022-01-08T00:00:35Z",
"published": "2021-12-31T00:00:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20156"
},
{
"type": "WEB",
"url": "https://www.tenable.com/security/research/tra-2021-54"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6W2P-CGH8-M9Q9
Vulnerability from github – Published: 2023-02-13 21:31 – Updated: 2025-06-19 00:31The cryptographic code signing process and controls on ConnectWise Control through 22.9.10032 (formerly known as ScreenConnect) are cryptographically flawed. An attacker can remotely generate or locally alter file contents and bypass code-signing controls. This can be used to execute code as a trusted application provider, escalate privileges, or execute arbitrary commands in the context of the user. The attacker tampers with a trusted, signed executable in transit.
{
"affected": [],
"aliases": [
"CVE-2023-25718"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-13T20:15:00Z",
"severity": "CRITICAL"
},
"details": "The cryptographic code signing process and controls on ConnectWise Control through 22.9.10032 (formerly known as ScreenConnect) are cryptographically flawed. An attacker can remotely generate or locally alter file contents and bypass code-signing controls. This can be used to execute code as a trusted application provider, escalate privileges, or execute arbitrary commands in the context of the user. The attacker tampers with a trusted, signed executable in transit.",
"id": "GHSA-6w2p-cgh8-m9q9",
"modified": "2025-06-19T00:31:02Z",
"published": "2023-02-13T21:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25718"
},
{
"type": "WEB",
"url": "https://cybir.com/2022/cve/connectwise-control-dns-spoofing-poc"
},
{
"type": "WEB",
"url": "https://m.youtube.com/watch?v=fbNVUgmstSc\u0026pp=0gcJCf0Ao7VqN5tD"
},
{
"type": "WEB",
"url": "https://www.connectwise.com"
},
{
"type": "WEB",
"url": "https://www.connectwise.com/blog/cybersecurity/the-importance-of-responsible-security-disclosures"
},
{
"type": "WEB",
"url": "https://www.huntress.com/blog/clearing-the-air-overblown-claims-of-vulnerabilities-exploits-severity"
}
],
"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"
}
]
}
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.