CVE-2025-55315: Patch ASP.NET Core to Stop HTTP Request Smuggling in NetBak PC Agent

QNAP has issued an urgent security advisory after Microsoft disclosed a critical ASP.NET Core vulnerability that can be abused for HTTP request smuggling (CVE-2025-55315), and administrators should treat NetBak PC Agent installations as potentially exposed until the appropriate ASP.NET Core runtime updates are applied.

Background​

Microsoft released an emergency servicing update in mid‑October 2025 to address an HTTP request‑smuggling flaw in the Kestrel web server used by ASP.NET Core. The vulnerability received a CVSS base score of 9.9 (Critical) and is tracked as CVE‑2025‑55315. Microsoft’s advisory and the .NET servicing notes describe the issue as an inconsistent interpretation of HTTP requests that can allow specially crafted traffic to bypass security logic in affected deployments.
QNAP’s security advisory specifically calls out its Windows backup client, NetBak PC Agent, because the installer and runtime of that client make use of Microsoft’s ASP.NET Core components. QNAP recommends that Windows systems running NetBak PC Agent either reinstall the latest NetBak installer (which pulls updated ASP.NET Core components) or manually install the patched ASP.NET Core Runtime / Hosting Bundle (for .NET 8.0). QNAP also notes that as of October 2025 the patched runtime version for .NET 8.0 is 8.0.21.

---

What is CVE‑2025‑55315 and why it matters​

Technical summary​

CVE‑2025‑55315 is an HTTP request/response smuggling vulnerability in the Kestrel HTTP server that ships with ASP.NET Core frameworks. The flaw stems from inconsistent parsing and interpretation of HTTP framing between Kestrel and other components (proxies, load balancers, middleware), producing a scenario where a single network request can be interpreted as two logical requests by the backend. An attacker can craft headers (for example, manipulating Transfer‑Encoding and Content‑Length combinations) to hide — or “smuggle” — a secondary request past security checks.

Why this classification is critical​

Microsoft, along with independent security analysts, treats the issue as a security feature bypass rather than a simple denial‑of‑service. The worst‑case impacts include:

• Authentication/authorization bypass — a smuggled request may be executed without the normal authentication checks.
• Data exposure — attackers can trick applications into exposing other users’ data or credentials.
• Integrity and file modification — crafted requests can cause unauthorized server‑side changes.
• Application instability — some payloads may crash or destabilize the server process.

Because these outcomes depend heavily on hosting configuration, application logic, and the presence of fronting proxies, Microsoft scored the issue with a high severity to cover worst‑case exposure scenarios.

---

Why NetBak PC Agent installations are at risk​

NetBak PC Agent is a Windows backup client that uses ASP.NET Core components during install and runtime. When NetBak’s installer includes (or relies on) ASP.NET Core runtimes that are vulnerable, any machine running the older runtime versions may expose that installed service to the Kestrel parsing bug — even if the NetBak app itself is not network‑facing in the traditional sense. QNAP’s advisory is precautionary: because the product bundle can contain an affected runtime, users must either reinstall the app (so the installer pulls the updated runtime) or manually update the system‑level ASP.NET Core Runtime to the patched version.
Two practical points to understand:

• Many Windows apps ship or install ASP.NET Core runtimes as part of setup. If the system still has an unpatched runtime, apps can inherit that vulnerability surface.
• Even local‑only services or developer tools can become attack vectors in complex hosting stacks (containers, reverse proxies, dev tools exposing endpoints), so a cautious posture is necessary.

---

What vendors released and the patched versions​

Microsoft added CVE‑2025‑55315 to the October 2025 servicing updates. The servicing notes and advisories show patched versions across multiple release lines:

• ASP.NET Core 8.0: patched to 8.0.21.
• ASP.NET Core 9.0: patched to 9.0.10.
• Kestrel 2.3 (the 2.x package): patched to 2.3.6 for legacy 2.x apps.
• ASP.NET Core 10 (release candidates): the RC2 images include the fix where applicable.

Microsoft’s guidance differentiates between framework‑dependent deployments (install the updated runtime), self‑contained applications (recompile and redeploy with the updated SDK/runtime), and 2.x package consumers (update the Kestrel package and redeploy).
Independent security vendors, incident responders, and third‑party vendors corroborated the same corrective versions and added practical remediation notes for container images and CI/CD pipelines. That consensus confirms the specific patched versions above.

---

How to patch NetBak PC Agent and related systems (step‑by‑step)​

QNAP recommends two officially supported approaches for NetBak PC Agent users. Both are straightforward but differ depending on how you manage Windows endpoints.

Method A — Reinstall NetBak PC Agent (recommended for non‑admins and home users)​

• Open Settings → Apps → Installed apps and uninstall the existing NetBak PC Agent.
• Download the latest NetBak PC Agent installer from QNAP’s official download page.
• Run the new installer; it will either include or fetch the latest .NET/ASP.NET Core runtime components.
• Restart the application or reboot the host after installation to ensure the updated runtime is loaded.

This approach ensures the bundled runtime is current and minimizes manual runtime management. QNAP lists this as the primary remediation path.

Method B — Manually update ASP.NET Core Runtime (recommended for managed environments)​

• Visit the official .NET download page for .NET 8.0 and download the ASP.NET Core Runtime (Hosting Bundle) for Windows.
• Install the hosting bundle; the October servicing update installs the patched runtime (for .NET 8.0 the fixed version is 8.0.21 as of QNAP’s advisory).
• For self‑contained applications or single‑file deployments, rebuild the application with the updated SDK/runtime and redeploy.
• Restart the NetBak service or reboot the system to ensure the updated runtime is active.

Administrators who manage many endpoints may prefer staged rollouts and monitoring after applying the hosting bundle. QNAP and Microsoft both advise application restarts or host reboots after updates.

---

If you can’t patch immediately: short‑term mitigations​

Patching is the only guaranteed fix, but when immediate patching is impractical, there are mitigations that can reduce exposure:

• Normalize or block ambiguous request framing at the edge — Configure your fronting reverse proxy, load balancer, or WAF to reject requests that contain conflicting Transfer‑Encoding and Content‑Length headers or to normalize request framing. This reduces the chance that a downstream Kestrel instance will interpret requests differently.
• Restrict public exposure of Kestrel — Ensure Kestrel instances are accessible only behind vetted proxies and not bound directly to public interfaces. Limit inbound ports using host firewall rules.
• Add application‑level guards — Where feasible, add strict request validation and canonicalization logic early in the pipeline to refuse malformed requests. This is defensive and mitigates some attack patterns but does not replace the runtime patch.

These mitigations reduce risk, but none remove the flawed parsing behavior inside the runtime; they are temporary controls until the runtime is updated.

---

Attack scenarios and real‑world risk assessment​

How attackers could exploit the bug​

Successful exploitation requires the attacker to be able to deliver specially crafted HTTP requests to the vulnerable Kestrel instance. Depending on hosting, that may mean:

• Directly targeting a publicly reachable Kestrel server.
• Targeting a proxy or edge that forwards traffic inconsistently to the backend.
• Leveraging multi‑tenant hosting or developer tools that expose local endpoints.

If the smuggled request triggers logic that bypasses authentication (for example, being interpreted by the app as a fresh request when an earlier request lacked authentication), the attacker could perform actions that should have been blocked.

Practical exposure for NetBak PC Agent users​

NetBak PC Agent users’ exposures depend on how the product is used:

• Home users running NetBak locally with no public listeners have lower external exposure, but the installed runtime may still pose risk if other applications on the host expose endpoints.
• Corporate Windows endpoints with developer, admin, or remote‑management tooling may expose services that could be abused. Endpoint management teams should prioritize remediation across fleets.

Security teams should treat the vulnerability as high priority for externally reachable servers and for any system that hosts multiple services or developer tooling that might accept HTTP requests.

---

Operational remediation checklist for IT teams​

• Inventory: Identify machines with NetBak PC Agent and any other ASP.NET Core hosting on Windows endpoints.
• Prioritize: Patch externally reachable or internet‑facing hosts first.
• Apply updates: Use the hosting bundle for framework‑dependent apps; update package references and redeploy self‑contained apps.
• Validate: Restart services, validate runtime versions (dotnet --info), and check application logs for unusual parsing errors or abnormal traffic.
• Harden: Add proxy rules to normalize headers and block ambiguous requests while patching continues.
• Monitor: Watch for suspicious requests and anomalous application behavior.

Following this checklist shortens the window of exposure and documents remediation for compliance and incident response purposes.

---

Vendor response and community reaction​

Microsoft described the bug as a security feature bypass and shipped servicing updates as part of the October 2025 releases. Microsoft’s security team noted the 9.9 rating reflects worst‑case application behavior, stressing that the actual impact varies with application code and hosting configuration. Industry observers echoed Microsoft’s view: for some deployments the exploitability and damage potential are severe, while for others the risk may be limited by application checks and reverse‑proxy normalization.
QNAP’s advisory is an example of a vendor rapidly translating vendor‑agnostic runtime advisories into product‑specific guidance, which is helpful for administrators who might otherwise not realize their backup client bundles an affected runtime. Independent security firms and incident responders added practical advice for containers, base images, and CI/CD pipelines, highlighting that unpatched base images can prolong exposure even after runtime updates are published.

---

Strengths in the response — and remaining gaps​

Notable strengths​

• Rapid disclosure and coordinated patching across Microsoft servicing channels and downstream vendors minimized reaction time for administrators. Microsoft produced specific instructions for framework‑dependent vs self‑contained apps.
• Vendors like QNAP produced product‑specific advisories linking the generic runtime issue to concrete remediation steps for their users, which reduces confusion and speeds remediation.
• Community guidance from security vendors and incident responders added pragmatic mitigation measures for containerized and multi‑tenant environments.

Remaining risks and gaps​

• Patching containers and image build pipelines is harder than patching hosts; outdated base images can keep vulnerable runtimes in circulation. Organizations must rebuild and redeploy images to fully remediate containerized workloads. This is a common operational gap that extends exposure windows.
• Self‑contained or single‑file .NET deployments require recompilation and redeployment, a heavier operational lift that may delay fixes for some applications. Microsoft’s guidance is clear, but the work required can be substantial for large estates.
• Some deployments lack comprehensive inventories of where ASP.NET Core runtimes are present, which complicates prioritized patching. Endpoint and cloud asset inventories must be up to date to be effective.

Where definitive verification is difficult (for example, whether every instance of a bundled runtime in a third‑party installer has been updated), treat the claim cautiously and assume remediation is required unless you can confirm otherwise.

---

Practical recommendations — prioritized and prescriptive​

• Immediate (0–24 hours): If your NetBak PC Agent clients run on externally reachable hosts or on hosts that also surface other HTTP services, prioritize reinstalling NetBak or installing the ASP.NET Core Hosting Bundle (8.0.21 or later). Restart the host or service.
• Short term (24–72 hours): For enterprise fleets, push the hosting bundle via endpoint management tools or orchestrate NetBak reinstallation through software distribution. Audit container images and rebuild those that use older aspnet base images.
• Medium term (1–2 weeks): Recompile and redeploy self‑contained applications using the updated SDK/runtime. Verify unit/integration tests for any side effects and validate behavior behind reverse proxies.
• Ongoing: Improve asset inventory to track runtime and package usage. Add CI/CD policies that refuse builds using older vulnerable base images. Harden edge proxies to normalize request framing.

---

Lessons for developers and product teams​

• Avoid unintentionally bundling runtimes without a clear update path. When shipping components that include third‑party runtimes, document how customers will receive security updates. QNAP’s advisory underlines the importance of being explicit about included runtimes.
• Design applications to avoid security checks that are contingent on request framing assumptions. Add server‑side canonicalization and conservative parsing to stop ambiguous or malformed requests early.
• Make container base images and build pipelines part of the security patch lifecycle. Vulnerable base images are a persistent exposure vector that requires images to be rebuilt and redeployed.

---

Final analysis and conclusion​

CVE‑2025‑55315 represents a high‑impact class of vulnerability — HTTP request smuggling — that is particularly dangerous because it exploits differences in how components interpret HTTP framing. The swift patching and vendor advisories, including QNAP’s product‑specific guidance for NetBak PC Agent users, are the correct immediate responses. Administrators should act quickly: reinstall NetBak or install the patched ASP.NET Core runtime (for .NET 8.0, update to 8.0.21), rebuild and redeploy any self‑contained apps, and rebuild container images using updated base images.
This incident is a reminder that third‑party runtimes embedded in desktop or server installers tie the security posture of seemingly unrelated applications to the patch cadence of the runtime vendor. Operational controls — inventory, image hygiene, and edge normalization — are necessary complements to timely patching. Treat CVE‑2025‑55315 as a high priority for any environment using ASP.NET Core components and follow the vendor remediation guidance immediately.
Conclusion: update now, validate after restart, and include runtime and image hygiene in your ongoing security program.

---

Source: TechRadar QNAP warns of critical flaw in its Windows backup software, so update now