Ubuntu .NET USN-8740-1: Match Your Release Before Updating

September 10, 2026

Ubuntu security notice USN-8740-1 supplies .NET security updates for specific packages on Ubuntu 22.04, 24.04 and 26.04 LTS. Match the installed Ubuntu release and package family before choosing an update. A version intended for another release, a different software repository or a different deployment channel is not a substitute.

Fix I.T. Phill has not assessed your Ubuntu deployment and we have not independently confirmed active exploitation. Canonical published the notice September 10, 2026. This guide is a release-specific maintenance checklist, not a claim that every Ubuntu server or every .NET website is exposed.

Understand the scope

The notice covers CVE-2026-58649, involving information exposure, and CVE-2026-69806, involving possible privilege escalation and code execution. Canonical identifies .NET development watch components. Inventory development and build systems as well as servers; do not equate a .NET application with proof that the affected development functionality is exposed.

Use the package row for your Ubuntu release

These examples are literal boundaries from the official notice, not a complete package inventory or a claim that they will remain the newest versions. Runtime and SDK package versions are different. The vendor table also lists host, hostfxr, ASP.NET Core and other related packages.

Prepare the application, not just the package manager

1. Record the Ubuntu release, installed package names, configured software source and the application’s deployment owner. Distinguish distribution-managed packages from containers or self-contained application bundles.
2. Check application compatibility and your established maintenance process. Confirm the recovery owner and existing restore procedure before a risky change; this guide does not require changing customer backup schedules.
3. Apply the appropriate supported update through your normal approved process. Do not mix repositories or Ubuntu-release packages merely to obtain a matching-looking version string.
4. For an application with bundled dependencies, ask its maintainer to confirm the correct rebuild or redeployment path. Updating the host does not by itself prove that every deployed artifact changed.

Verify the maintained deployment

Confirm the installed versions against the matching vendor rows, then verify the application instance that users actually reach. Follow the application’s normal restart or redeployment procedure where required and check sign-in, a representative read/write workflow, scheduled work and ordinary service health. Keep customer communication focused on expected interruption and the checks completed.

If a verification step fails, stop widening the change. Use the agreed recovery plan and retain concise, private diagnostic notes for the maintainer. Do not publish logs or use exploit material to prove whether a live service is affected.

Installing updated packages alone does not establish that an earlier compromise has been removed. Unexpected privileged activity or unexplained service changes warrant separate incident review. This is not a Linux-kernel advisory, and it should not trigger unrelated PHP, WordPress or firewall changes.

Source and support boundaries

Source: Canonical USN-8740-1 and its complete package table, reviewed September 10, 2026 UTC. Consult the notice for packages omitted from the examples. Source review is not a laboratory or deployment assessment. The featured image is a general maintenance illustration, not a product-interface screenshot.

For a separately hosted WordPress site, WordPress support can coordinate normal website checks around an agreed maintenance window. WordPress support does not replace the .NET application’s maintainer or its release-specific remediation.