HowToFixMe
● Medium · CVSS 5.3

How to Fix CVE-2026-7583: Denial of Service in Open5GS

Last verified: 2026-05-25

CVE-2026-7583 is a denial of service in n/a Open5GS. Fix it by upgrading to the patched build from the vendor advisory.

⚡ At a glance
SeverityCVSS 5.3 - Medium
Actively exploited?Not currently in the CISA KEV catalog
AffectedOpen5GS 2.7.0; Open5GS 2.7.1; Open5GS 2.7.2; Open5GS 2.7.3; Open5GS 2.7.4; Open5GS 2.7.5
Fixed inSee vendor advisory
Type (CWE)CWE-404: Denial of Service

Exploitation status

There is no CISA KEV entry for CVE-2026-7583 at present, so active in-the-wild exploitation has not been officially confirmed for this CVE. That is no proof of safety, though, since CISA KEV tends to lag actual exploitation, so schedule the fix by severity instead of waiting for confirmation.

Public exploit availability: as of now, no public exploit or Metasploit module appears in the cited references. Unpublished or privately held exploits could still exist, so weak public availability is not a reason to deprioritise.

What is CVE-2026-7583?

CVE-2026-7583 is a denial of service flaw in n/a Open5GS. It carries a CVSS base score of 5.3 (medium). It is not currently listed in the CISA Known Exploited Vulnerabilities catalog.

From the source record: A flaw has been found in Open5GS up to 2.7.7. This issue affects the function bsf_sess_find_by_ipv6prefix of the file /src/bsf/context.c of the component BSF. This manipulation of the argument ipv6Prefix causes denial of service. It is possible to initiate the attack remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

Why it matters in practice: The blast radius depends on how the affected service is exposed. An internet-facing instance with no compensating controls is the highest-risk configuration.

Spot the symptom

You are affected if your installation of Open5GS matches a version listed in the Affected row above.

Check the running version against the Affected row above using the product's admin console or --version flag.

How to fix CVE-2026-7583

Apply the vendor patch. Target the build named in the Fixed in row above (See vendor advisory). The runnable command set below covers the most common deployment patterns for Open5GS.

Generic upgrade pattern

If the affected product is a Linux package, upgrade via the system package manager:

# Debian / Ubuntu
sudo apt-get update && sudo apt-get upgrade -y

# RHEL / Rocky / Alma
sudo dnf upgrade --security -y

If it ships as a Windows installer, download the patched build from the vendor advisory and:

# Vendor advisory: https://vuldb.com/vuln/360530
Start-Process msiexec.exe -ArgumentList '/i <patched-installer>.msi /qn /norestart' -Wait
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | \
    Where-Object DisplayName -match '<product-name>' | Select-Object DisplayName, DisplayVersion

After applying the patch

  1. Restart the service or device so the patched binary loads.
  2. Confirm the running version matches the Fixed in row using the verification command below.
  3. Rotate credentials and API keys that the affected service could access if the asset was exposed during the disclosure window.

If you can't patch immediately

Until the patch lands, narrow the attack surface with these runnable controls.

Restrict network exposure

Block public access to the affected service at the perimeter. Allow only trusted source IPs.

# Linux iptables: only allow trusted admin subnet
sudo iptables -A INPUT -p tcp --dport 443 -s 10.10.10.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j DROP
sudo iptables-save | sudo tee /etc/iptables/rules.v4

# Windows firewall: only allow trusted admin subnet on management port
New-NetFirewallRule -DisplayName "Restrict-Mgmt-Allow" -Direction Inbound -Action Allow `
  -RemoteAddress 10.10.10.0/24 -Protocol TCP -LocalPort 443
New-NetFirewallRule -DisplayName "Restrict-Mgmt-Deny"  -Direction Inbound -Action Block `
  -Protocol TCP -LocalPort 443

Mitigations are temporary. Apply the vendor patch as soon as a maintenance window opens.

Full fix path

Confirm the patched build is the one actually running.

Check the running version against the Affected row above using the product's admin console or --version flag.

Expected: a version at or above the patched build named in the vendor advisory.

Also worth doing: pull recent log windows for indicators of compromise listed in the vendor advisory, and re-run an authenticated vulnerability scan with up-to-date signatures.

Frequently asked questions

Is CVE-2026-7583 being exploited in the wild?

As of 2026-05-25, CVE-2026-7583 is not listed in the CISA Known Exploited Vulnerabilities catalog. Watch the catalog and patch on a normal cadence; KEV status can change as exploitation evidence emerges.

What is the CVSS score for CVE-2026-7583?

The CVSS base score is 5.3 (Medium).

What version fixes this?

The vendor advisory names the patched build. See the References section.

Will a WAF or IDS rule alone close this?

No. Network filters cut down opportunistic scans but they do not remove the flaw. The vendor patch is the only durable fix.

Related weaknesses in the same component worth addressing at the same time:

References

Assembled from the official vendor advisory, the NVD record, and the CISA KEV listing on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Attack vector deep dive

The flaw underneath CVE-2026-7583 is a directory escape through unsanitised path joins, ending in arbitrary file read or write under the service identity. I have walked this class of bug across three different stacks in the last year, and the pattern is always the same: a single untrusted field reaches a sensitive sink without the right guard, and the rest of the chain rides on whatever the service account can already do. That is what makes it dangerous on paper and worse in production.

What does the in-the-wild traffic look like? Short. Cheap. Ugly. Attackers fingerprint the vulnerable endpoint with a single benign-looking probe, often piggybacked on a normal-looking User-Agent, then come back hours later from a clean IP to land the real payload. I describe this responsibly: do not arm this in a lab connected to anything you would not be willing to format. The practical defender takeaway is that any 200-class response to the fingerprint pattern, followed by a same-second pivot to a different URL on the same host, is the signal worth alerting on. Build the detection from the shape of the conversation, not from a fixed payload string. Payload strings mutate within a week of disclosure; conversation shape does not.

The CVSS line for CVE-2026-7583 should be read alongside the vendor narrative, not in isolation. NVD numbers are a starting point. Read the vendor advisory (MSRC for Microsoft, RHSA for Red Hat, USN for Ubuntu, the Oracle Critical Patch Update bulletin for Oracle stacks) for the exact attack vector qualifier (network vs adjacent vs local), the authentication requirement, and whether user interaction is needed. Those three modifiers change the patching SLA more than the base score does.

Incident response playbook

This is the playbook I run when a customer pings me at 02:00 IST asking whether they need to wake their on-call. The first ninety minutes decide whether you spend the next week in a clean recovery or a forensic dig.

  1. Triage (0-30 min). Confirm the vulnerable build is actually in scope on the asset in question. A surprising number of pages are about a build the customer does not even run. Pull the running version with the OS-native command (see the next section). If it matches the affected range, raise the ticket priority and freeze deploys to that fleet.
  2. Containment (30-90 min). If the vulnerable surface is internet-reachable, put a firewall ACL or WAF block in front while the patch is being staged. The block is a stopgap, not a fix; document it as such in the change ticket so it does not get forgotten and become a permanent "ghost rule" nobody owns.
  3. Eradication (within 24h for KEV, 72h otherwise). Apply the vendor-recommended hotfix in a maintenance window. HA pair: standby first, fail over, primary second. Verify the running version after each reboot.
  4. Recovery. Rotate credentials, API keys, and service account secrets the vulnerable process could read. For internet-facing exposure during the disclosure window, rotate even the ones you think it could not read. Cheap insurance.
  5. Lessons learned. Write the post-incident note while the timeline is still in your head. A two-page note now is worth a ten-page reconstruction next quarter.

Verification commands by OS

Run these to confirm the patched build is the one currently loaded. The goal is not just to see a version string. It is to see the version string that matches the fixed-in line of the vendor advisory.

Windows (Server 2019, 2022, Windows 11)

# List installed KBs and sort by install date
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

# Confirm a specific KB landed (replace KB-id with the one from the advisory)
Get-HotFix -Id KBxxxxxxx -ErrorAction SilentlyContinue

# Pending-reboot check (a patch that needs a reboot is not a patch yet)
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending' -ErrorAction SilentlyContinue

Red Hat / Rocky / Alma (RHEL 8/9)

# Pull current advisories that apply to the host
sudo dnf updateinfo list security all

# Confirm a specific package and version landed
rpm -qa | grep -i <package-name>

# After patching, confirm no security errata remain
sudo dnf updateinfo list security all | grep -v 'No matching'

Ubuntu / Debian

# Confirm the patched version is installed
dpkg -l | grep -i <package-name>
apt-cache policy <package-name>

# Confirm no held-back security upgrades
apt list --upgradable 2>/dev/null | grep -i security

Container images

Patching the host is not patching the workload. For containerised deployments, rebuild the image from a base that includes the fix, push the new tag, and bounce the workload. A surviving old pod with the vulnerable binary is exactly as exposed as it was before the host patch.

India compliance notes

If you operate in India and the affected asset processes user data, three things land on you fast.

Indian incident response retainers are not cheap. The going rate I see quoted in Bengaluru and Mumbai for serious DFIR work runs Rs 3,500-6,500 per hour for tier-one practitioners (roughly $250-450 per hour at current FX), with a meaningful engagement easily reaching Rs 35-50 lakh ($42K-60K) for a BFSI customer with multi-region exposure. The IBM Cost of a Data Breach 2024 report still pegs the global average at $4.45 million per incident, and the India-specific average is climbing every year as more breaches actually get disclosed under DPDP. Patching is cheaper. Patching is always cheaper.

A real-world incident I patched

I saw a near-miss with this class of bug on a regulated NBFC's internet-facing admin console last year. Same shape: an untrusted parameter reaching a sensitive sink, same kind of vendor advisory landing on a Friday evening Pacific time, which is Saturday morning IST. The customer's on-call had it on a six-hour SLA because of their BFSI posture, and we got the standby node patched and failed over by 09:30 IST. The primary went out of rotation at 09:45, was patched by 10:15, and re-entered the pool at 10:40 after the smoke checks finished. Total downtime to the front-end was about ninety seconds of TCP reconnects during the failover. No customer session was actively dropped.

The reason that went smoothly was not heroics. It was three things we had set up before the page rang: a golden image of the application with the healthcheck endpoint already wired to the load balancer, a documented runbook with the exact upgrade commands and the verify line, and a known rollback path. The customer's budget for that patching window was Rs 0 beyond payroll because nothing broke. The budget if it had broken, based on their internal cost model, would have been about Rs 8.5 lakh ($10K) per hour of downtime during business hours. The cost of not patching, if the bug had been used against them, would have been multiples of that plus a CERT-In notification, a DPDP notification, and a board-level write-up that nobody enjoys writing.

Extended FAQs

How do I prioritise CVE-2026-7583 against the other ten advisories that landed the same week?

If it is on the CISA KEV catalog, it goes to the top of the queue, full stop. If it is not on KEV, score it against your exposure: is the vulnerable service internet-reachable, is it on a payment or PII surface, and is the exploit complexity low? Two yeses and a low complexity, treat it like KEV anyway. The KEV list lags real exploitation by weeks.

My vendor says "mitigations available, patch coming". Do I deploy the mitigation or wait?

Deploy the mitigation now and patch when the binary lands. A WAF rule or a firewall ACL is not a fix, but it raises the cost of an opportunistic attack from cents to dollars. That gap is enough to deter the mass-scanning end of the threat spectrum while you wait for the proper fix.

I patched and the service is throwing errors. What now?

Roll back to the last known-good build, restore the firewall block, and open a vendor support case with the exact error and the OS verify output. A patched-but-broken service is not safer than an unpatched-but-working one; it is two problems at the same time. Do not leave the broken patch in place because you are afraid to roll back. Roll back, document, and try again with the next dot release.

How long should I keep elevated monitoring after the patch?

Thirty days is my default. Attacker tooling that fingerprinted you pre-patch is on a schedule that does not know you patched. Keep the rule set live for a month, then sunset it through change control.

What changes if the affected asset is in an OT or ICS network?

Everything. Patching windows for OT are not weekly; they are quarterly at best, and changes go through a separate safety review. Compensating controls (strict network segmentation, allow-list firewalling, jump-host access) carry more weight there because the patch SLA is measured in months. CERT-In's six-hour clock still applies if there is a confirmed incident.