Ubuntu USN-8822-1: Libwebsockets DoS Vulnerabilities — Detection, Patching, and Hardening Guide

Canonical has released Ubuntu Security Notice USN-8822-1, addressing several security vulnerabilities in Libwebsockets — the lightweight C library that underpins WebSocket and HTTP/2 server implementations across countless embedded devices, IoT gateways, network appliances, and Linux server applications. The headline risk is denial of service: an unauthenticated remote attacker can crash or hang services built on vulnerable Libwebsockets versions by sending malformed WebSocket traffic, taking down whatever application sits on top of the library.

This is the kind of advisory that gets deprioritized because "it's just a DoS" — and that's a mistake. In my incident response work, I've repeatedly seen availability attacks against edge services used as smoke screens for concurrent intrusions, and I've seen single-library DoS flaws knock out management planes on network infrastructure at the worst possible moment. If your Ubuntu systems run anything that terminates WebSocket connections — and you'd be surprised how many do, often without the application team even knowing Libwebsockets is in the dependency tree — this advisory applies to you.

Technical Analysis

What's affected

Libwebsockets is a dependency, not a standalone product, which makes scoping harder than a typical patch. It is commonly linked into:

• Embedded and IoT device firmware built on Ubuntu base images
• Network appliance management interfaces and REST/WebSocket APIs
• Container images where libwebsockets was pulled in transitively (notably via tools like ttyd, certain build pipelines, and various proxy/gateway software)
• Custom C/C++ services using Libwebsockets for HTTP/2 or WebSocket server functionality

Affected systems include supported Ubuntu LTS releases where the libwebsockets package family (e.g., libwebsockets-dev, and the versioned runtime libraries such as libwebsockets16/libwebsockets17/libwebsockets19 depending on release) is installed. Consult the advisory at linuxsecurity.com and the Canonical USN portal for the exact package versions fixed in each release.

How the attack works (defender's view)

The vulnerability class here is remote denial of service via malformed protocol input. The exploitation pattern for Libwebsockets flaws of this type is consistent:

1. Reconnaissance — the attacker identifies exposed WebSocket endpoints (typically TCP 443, 80, or application-specific ports such as 7681 for ttyd-style web terminals).
2. Trigger — a crafted WebSocket handshake or frame sequence (malformed headers, oversized/undersized length fields, invalid close codes, or malformed HTTP/2 frames) reaches the vulnerable parsing path.
3. Impact — the service crashes (segmentation fault / assertion failure) or enters a resource-exhaustion state, terminating the WebSocket service and potentially the parent application.

Because exploitation happens at the protocol parsing layer before authentication completes in many deployments, this is a pre-auth remote DoS — the most operationally dangerous kind of availability bug for internet-facing services.

Exploitation status

At the time of writing, there is no confirmed in-the-wild mass exploitation and this advisory does not appear in the CISA Known Exploited Vulnerabilities catalog. However, Libwebsockets parsing bugs are historically quick to attract proof-of-concept development because the library is open source and fuzzing targets are trivial to build. Treat the window between patch release and public PoC as days-to-weeks, not months — patch accordingly.

Detection & Response

A protocol-parsing DoS leaves limited forensic artifacts — the most reliable telemetry is service crash behavior and connection anomalies, not malware indicators. The detections below focus on crash-loop patterns and connection floods against WebSocket-terminating services.

Sigma Rules

---
title: Repeated Crash of WebSocket-Linked Service on Linux
id: 8f2b6c41-3d9e-4a7b-b1c4-9e2f5a7d3c8b
status: experimental
description: Detects rapid repeated crashes/restarts of services linked against libwebsockets, consistent with remote DoS exploitation via malformed WebSocket traffic (USN-8822-1 class flaws).
references:
  - https://linuxsecurity.com/advisories/ubuntu/ubuntu-8822-1-libwebsockets
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1499
logsource:
  product: linux
  service: syslog
detection:
  selection:
    - 'segfault'
    - 'core dumped'
    - 'assertion failed'
    - 'SIGSEGV'
    - 'SIGABRT'
  filter_known_noisy:
    - 'apt'
    - 'unattended-upgrade'
  condition: selection and not filter_known_noisy
falsepositives:
  - Legitimate application instability unrelated to attack; baseline crash rates per service before tuning
level: high
---
title: systemd Service Entering Rapid Restart Loop
id: 2c7d9e15-4f8a-4b6c-a2d1-7e3f9b5c1d6a
status: experimental
description: Detects systemd reporting that a service has hit its restart rate limit or is being repeatedly respawned, a strong indicator of crash-loop DoS against a network-facing daemon.
references:
  - https://linuxsecurity.com/advisories/ubuntu/ubuntu-8822-1-libwebsockets
author: Security Arsenal
date: 2026/02/14
tags:
  - attack.impact
  - attack.t1499
logsource:
  product: linux
  service: syslog
detection:
  selection:
    - 'start request repeated too quickly'
    - 'Failed with result'
    - 'Scheduled restart job'
  condition: selection
falsepositives:
  - Misconfigured units; failed package upgrades; legitimately unstable dev workloads
level: medium

KQL (Microsoft Sentinel)

Assumes Ubuntu syslog is ingested into Sentinel via the Syslog/CEF connector. This query surfaces hosts where a WebSocket-adjacent service is crash-looping or where syslog shows parsing-layer crash signatures.

Syslog
| where TimeGenerated > ago(24h)
| where SyslogMessage has_any ("segfault", "core dumped", "start request repeated too quickly", "Failed with result", "SIGSEGV", "SIGABRT")
| extend CrashSignature = extract(@"(segfault|core dumped|start request repeated too quickly|Failed with result|SIGSEGV|SIGABRT)", 1, SyslogMessage)
| summarize CrashCount = count(), Signatures = make_set(CrashSignature), SampleMessages = make_set(SyslogMessage, 5) by Computer, ProcessName, bin(TimeGenerated, 15m)
| where CrashCount >= 3
| sort by CrashCount desc

For connection-flood visibility against known WebSocket ports (adjust the port list to your environment):

CommonSecurityLog
| where TimeGenerated > ago(1h)
| where DestinationPort in (443, 80, 7681, 8080, 8443)
| summarize ConnCount = count(), UniqueSources = dcount(SourceIP) by DestinationIP, DestinationPort, bin(TimeGenerated, 5m)
| where ConnCount > 500 and UniqueSources > 20
| sort by ConnCount desc

Velociraptor VQL

Use this hunt to identify Linux endpoints running libwebsockets-linked binaries and to enumerate listening WebSocket services — essential for scoping exposure before an attacker does.

-- Scope exposure: find installed libwebsockets packages and listening WebSocket services
SELECT {
  SELECT Pid, Name, Address, Port, Status
  FROM netstat()
  WHERE Status = 'LISTEN' AND Port in (80, 443, 7681, 8080, 8443)
} AS Listeners,
{
  SELECT FullPath, Size, Mtime
  FROM glob(globs='/usr/lib/x86_64-linux-gnu/libwebsockets.so*')
} AS LibwebsocketsLibs
FROM scope()

And to catch crash-looping processes during an active hunt:

-- Identify short-lived, frequently respawning processes (crash-loop indicator)
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime,
       timestamp(epoch=now()) - CreateTime AS UptimeSeconds
FROM pslist()
WHERE UptimeSeconds < 60
  AND Name =~ '(websocket|ttyd|lws|wss|gateway|proxy)'

Remediation & Verification Script

#!/bin/bash
# USN-8822-1 Libwebsockets remediation & verification - Ubuntu
set -euo pipefail

echo "=== [1] Identifying installed libwebsockets packages ==="
dpkg -l | grep -i libwebsockets || echo "No libwebsockets packages installed."

echo ""
echo "=== [2] Current installed versions ==="
dpkg -l | grep -i libwebsockets | awk '{print $2" "$3}'

echo ""
echo "=== [3] Refreshing package metadata and applying security updates ==="
apt-get update
apt-get install --only-upgrade -y $(dpkg -l | grep -i libwebsockets | awk '{print $2}')

echo ""
echo "=== [4] Post-patch versions (verify against USN-8822-1 fixed versions) ==="
dpkg -l | grep -i libwebsockets | awk '{print $2" "$3}'

echo ""
echo "=== [5] Finding binaries dynamically linked to libwebsockets ==="
for bin in $(ls /usr/sbin /usr/bin /usr/local/bin 2>/dev/null); do
  ldd "/usr/sbin/$bin" 2>/dev/null | grep -q libwebsockets && echo "/usr/sbin/$bin"
  ldd "/usr/bin/$bin" 2>/dev/null | grep -q libwebsockets && echo "/usr/bin/$bin"
  ldd "/usr/local/bin/$bin" 2>/dev/null | grep -q libwebsockets && echo "/usr/local/bin/$bin"
done

echo ""
echo "=== [6] Restarting dependent services (library updates require restart) ==="
needrestart -r a 2>/dev/null || echo "Install 'needrestart' to auto-restart affected services, or reboot."

echo ""
echo "=== [7] Checking for recently crashed services ==="
systemctl --failed --no-pager
journalctl -p err --since "24 hours ago" --no-pager | grep -iE "segfault|core dumped|libwebsockets" | tail -20 || true

echo ""
echo "Done. Cross-reference versions at: https://ubuntu.com/security/notices/USN-8822-1"

Critical operational note: upgrading the library package is not sufficient. Libwebsockets is linked into running processes — every dependent service must be restarted (or the host rebooted) before the patched code is actually in memory. Use needrestart or checkrestart (from debian-goodies) to enumerate stale processes holding the old library.

Remediation

1. Patch immediately. Run apt update && apt upgrade on all supported Ubuntu systems, or apply the targeted upgrade to the libwebsockets package family. Verify installed versions against the fixed versions listed in USN-8822-1 at the Canonical USN portal and the LinuxSecurity advisory: https://linuxsecurity.com/advisories/ubuntu/ubuntu-8822-1-libwebsockets
2. Restart dependent services. A library patch without a service restart leaves the vulnerable code running. Reboot embedded/IoT fleet devices if per-service restart isn't feasible.
3. Inventory your real exposure. Most organizations don't know where Libwebsockets lives. Use the VQL hunt above, plus dpkg -l | grep libwebsockets and container image scanning (trivy image <image> catches OS-package CVEs in images), to enumerate dependents — including Docker images built from Ubuntu bases.
4. Reduce attack surface. WebSocket endpoints should not be internet-exposed without a business justification. Place them behind a reverse proxy or WAF that can terminate and validate WebSocket handshakes before traffic reaches the vulnerable parser, and enforce per-source connection rate limits (limit_conn in nginx, or equivalent).
5. Apply availability engineering. Configure systemd units for affected services with sane Restart=on-failure, StartLimitIntervalSec, and watchdog settings so a successful DoS crash results in seconds of downtime, not an outage — and alerts you when it happens.
6. Monitor for the smoke screen. If you observe DoS conditions against edge WebSocket services, treat it as a potential diversion. Check authentication logs, lateral movement telemetry, and new persistence mechanisms on the same hosts during the same window.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub