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

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

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

EPSS

• CVE-2024-28252: 0.58% estimated exploitation activity in the next 30 days; percentile 47.69 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

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…

Published by the source

15 Mar 2024, 19:20 UTC

Last modified by the source

9 Apr 2025, 19:58 UTC

Source last checked

26 Oct 2026, 17:03 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-32jq-mv89-5rx7

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2024-28252

Advisory: CoreWCF NetFraming based services can leave connections open when they should be closed
IDs: CVE-2024-28252, GHSA-32jq-mv89-5rx7
Record: https://patchnext.com/advisories/cve-2024-28252 (revision 1, source checked 26 Oct 2026, 17:03 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: High (CVSS 7.5)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: corewcf.netframingbase 1.5.2, 1.4.2. A vendor fix does not mean a deployment is fixed.

## Affected components
- NuGet corewcf.netframingbase: affected >= 1.4.0, < 1.4.2; >= 1.5.0, < 1.5.2; fixed in 1.4.2, 1.5.2

## Suggested inspection (read-only)
- NuGet corewcf.netframingbase: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on corewcf.netframingbase.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-32jq-mv89-5rx7 (GitHub-reviewed advisory GHSA-32jq-mv89-5rx7 lists affected ranges: NuGet corewcf.netframingbase >=1.4.0 =1.5.0 <1.5.2)

Commands are suggestions: review each one before running it.