Skip to content

← Public intelligence

NuGet package

corewcf.netframingbase

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.5NuGetPublished

    CoreWCF: Pre-authentication infinite-loop CPU exhaustion in CoreWCF net.tcp / net.pipe / net.uds framing handshake

    CVE-2026-54772 · GHSA-p86g-xrr2-pf7c

    Affected
    • NuGet corewcf.netframingbase < 1.8.1; >= 1.9.0, < 1.9.1
    Fixed in
    1.8.11.9.1· Vendor fix available
    Issue
    Impact An unauthenticated remote attacker can pin one server thread‑pool worker at 100 % CPU per connection. With a few connections, the CPU usage can be exhausted. Preconditions An attacker being able to reach a service which is exposing an endpoint using one of NetTcpBinding, NetNamedPipeBinding, or UnixDomainSocketBinding. Patches Fixed in CoreWCF v1.8.1 and v1.9.1 Workarounds None

    Recommended action: Upgrade to 1.9.1 or 1.8.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 7.5NuGetPublished

    CoreWCF NetFraming based services can leave connections open when they should be closed

    CVE-2024-28252 · GHSA-32jq-mv89-5rx7

    Affected
    • NuGet corewcf.netframingbase >= 1.4.0, < 1.4.2; >= 1.5.0, < 1.5.2
    Fixed in
    1.4.21.5.2· Vendor fix available
    Issue
    Impact If you have a NetFraming based CoreWCF service, extra system resources could be consumed by connections being left established instead of closing or aborting them. There are two scenarios when this can happen. When a client established a connection to the service and sends no data, the service will wait indefinitely for the client to initiate the NetFraming session handshake. Additionally, once a client has established a session, if the client doesn't send any requests for the period of time configured in the binding ReceiveTimeout, the connection is not properly closed as part of the session being aborted. The bindings affected by this behavior are NetTcpBinding, NetNamedPipeBinding, and UnixDomainSocketBinding. Only NetTcpBinding has the ability to accept non local connections. Patches The currently supported versions of CoreWCF are v1.4.x and v1.5.x. The fix can be found in v1.4.2 and v1.5.2 of the CoreWCF packages. Workarounds There are no workarounds. References…

    Recommended action: Upgrade to 1.5.2 or 1.4.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →