CVE-2026-107605: Swann SWIFI-SE2KIC Cameras Expose Video Feeds Without Authentication — Detection and Remediation Guide

CISA has published ICS advisory ICSA-26-286-02 covering three vulnerabilities in the Swann Communications SWIFI-SE2KIC Wi-Fi security camera. The headline issue is a Missing Authentication for Critical Function weakness: an attacker with network access to the device can view video information without presenting any credentials. All firmware versions 2.0.22 and prior are affected.

Affected CVEs: CVE-2026-107605, CVE-2026-107606, and CVE-2026-107607, with a CVSS v3 base score of 6.2 (Medium). Do not let the 'medium' label lull you — for a camera deployed in a commercial facility, unauthenticated video access is a direct physical-security and privacy exposure. Reconnaissance of camera placement, guard patrol timing, badge readers, loading docks, and cash-handling areas becomes trivially available to anyone who can reach the device's web or streaming interface.

Swann is headquartered in Australia, and these devices are deployed worldwide, with CISA flagging the Commercial Facilities critical infrastructure sector. If your organization runs these cameras — in retail, warehousing, small-office deployments, or even home-office environments that bridge into corporate VPNs — you need to treat this as an active exposure until patched and segmented.

Technical Analysis

Affected Products

How the Vulnerability Works

CWE-306 (Missing Authentication for Critical Function) in embedded camera firmware almost always takes one of a few shapes, and defenders should assume all of them until the vendor documents otherwise:

1. Unauthenticated HTTP/RTSP endpoints — the camera's web server or streaming daemon serves snapshot images, configuration pages, or live streams (commonly over HTTP port 80/8080 and RTSP port 554) without validating a session token or credentials.
2. Direct-URL access — endpoints such as /snapshot.cgi, /videostream.cgi, /cgi-bin/ handlers, or API paths under /api/ respond to requests that never passed through the login flow. Authentication is enforced on the login page but not on the underlying handlers.
3. Predictable stream identifiers — stream URLs keyed by device MAC, serial, or a static token that an attacker can enumerate or read from network traffic.

The exploitation requirement is network reachability. There is no user interaction, no privilege requirement, and no specialized tooling — a single HTTP GET from any host that can route to the camera is sufficient. That means the blast radius is defined entirely by your network architecture: a camera on a flat corporate LAN is exposed to every workstation; a camera exposed to the internet via port forwarding or UPnP is exposed to everyone.

Exploitation Status

As of the advisory publication, CISA has not reported confirmed in-the-wild exploitation, and these CVEs are not listed in the CISA Known Exploited Vulnerabilities catalog at the time of writing. However, the barrier to exploitation is effectively zero — Shodan/Censys indexing of consumer-grade cameras is routine, and unauthenticated camera feeds are a perennial target for botnet operators, voyeurism forums, and pre-intrusion physical reconnaissance. Treat exposure as probable, not hypothetical.

Detection & Response

Because the vulnerability lives on the camera itself, your detection surface is the network: who is talking to these devices, on which ports, and whether those requests carry legitimate authenticated sessions. Consumer-grade cameras like the SWIFI-SE2KIC rarely emit useful syslog, so NetFlow, firewall logs, DNS, and EDR network telemetry are your primary instruments.

Sigma Rules

---
title: Unauthenticated Access Attempt to Swann Camera Streaming Endpoint
id: 8f2c6a41-3b7d-4e19-a5c2-9d1e4f6b8a03
status: experimental
description: Detects HTTP requests to common camera streaming and snapshot endpoints typically served without authentication on vulnerable Swann SWIFI-SE2KIC firmware (CVE-2026-107605). Tune the URI list to confirmed device paths during your assessment.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-286-02
  - https://cwe.mitre.org/data/definitions/306.html
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: zeek
detection:
  selection_uri:
    uri|contains:
      - '/snapshot'
      - '/videostream'
      - '/video.cgi'
      - '/live/'
      - '/cgi-bin/'
      - '/api/stream'
      - '/api/live'
  selection_dst:
    dst_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  filter_auth:
    status_code: 401
  condition: selection_uri and selection_dst and not filter_auth
falsepositives:
  - Legitimate NVR/VMS polling of camera streams from the recording server
level: medium
---
title: External or Cross-VLAN Connection to Camera Management and RTSP Ports
id: 2d7b9e35-61c4-4f08-b3a1-7e5c2d9f4a86
status: experimental
description: Detects inbound connections to typical IP-camera service ports (HTTP 80/8080, RTSP 554) destined to internal IoT/camera address space from sources outside the designated camera VLAN or from the internet. Relevant to CVE-2026-107605 exploitation, which requires only network reachability.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-286-02
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.reconnaissance
  - attack.t1046
logsource:
  category: firewall
  product: generic
detection:
  selection_ports:
    dst_port:
      - 80
      - 554
      - 8080
      - 8000
  selection_camera_subnet:
    dst_ip|cidr:
      - '192.168.30.0/24'
      - '10.30.0.0/16'
  filter_known_nvr:
    src_ip:
      - '192.168.30.5'
      - '192.168.30.6'
  condition: selection_ports and selection_camera_subnet and not filter_known_nvr
falsepositives:
  - Camera vendor mobile-app relay traffic
  - Authorized viewing workstations not yet added to the allowlist
level: medium

Tuning guidance: Replace the example camera subnets and NVR allowlist with your actual inventory before deploying. The detection value comes from the deviation — cameras should talk to exactly two places: their NVR/VMS and the vendor's cloud relay. Anything else is signal.

KQL Hunt — Microsoft Sentinel / Defender

This query hunts for network connections to your camera subnet from unexpected sources, and flags inbound internet exposure. It assumes CommonSecurityLog (firewall CEF) or DeviceNetworkEvents ingestion.

// Hunt: Unexpected network access to Swann camera subnet (ICSA-26-286-02 / CVE-2026-107605)
let CameraSubnet = "192.168.30.0/24";   // TODO: replace with your camera VLAN CIDR
let AuthorizedViewers = dynamic(["192.168.30.5", "192.168.30.6"]); // NVR / VMS hosts
let CameraPorts = dynamic([80, 554, 8080, 8000]);
union isfuzzy=true
    (CommonSecurityLog
    | where ipv4_is_in_range(DestinationIP, CameraSubnet)
    | where DestinationPort in (CameraPorts)
    | where SourceIP !in (AuthorizedViewers)
    | where ipv4_is_private(SourceIP) == false or ipv4_is_in_range(SourceIP, CameraSubnet) == false
    | summarize ConnCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
      by SourceIP, DestinationIP, DestinationPort, DeviceAction
    | extend Source = "Firewall"),
    (DeviceNetworkEvents
    | where ipv4_is_in_range(RemoteIP, CameraSubnet)
    | where RemotePort in (CameraPorts)
    | where LocalIP !in (AuthorizedViewers)
    | summarize ConnCount=count(), FirstSeen=min(Timestamp), LastSeen=max(Timestamp)
      by DeviceName, LocalIP, RemoteIP, RemotePort, InitiatingProcessFileName
    | extend Source = "EDR")
| sort by ConnCount desc

A companion query to identify cameras reaching out to unexpected external destinations (possible compromise or telemetry leakage):

// Hunt: Cameras initiating outbound connections to non-vendor destinations
let CameraSubnet = "192.168.30.0/24";
let VendorASNKeywords = dynamic(["swann"]); // extend with confirmed vendor cloud domains
CommonSecurityLog
| where ipv4_is_in_range(SourceIP, CameraSubnet)
| where ipv4_is_private(DestinationIP) == false
| summarize ConnCount=count(), Destinations=make_set(DestinationIP, 25)
  by SourceIP, DestinationPort
| sort by ConnCount desc

Velociraptor VQL

If you suspect a workstation has been used to browse camera feeds (insider misuse or attacker staging), hunt for recent HTTP connections to the camera subnet from endpoint netstat data:

-- Hunt: Endpoint connections to camera subnet on streaming/management ports
-- ICSA-26-286-02 / CVE-2026-107605 — unauthenticated Swann SWIFI-SE2KIC video access
LET camera_ports <= (80, 554, 8080, 8000)

SELECT Pid, Name, Path, RemoteAddress, RemotePort, Status, Username
FROM netstat()
WHERE RemoteAddress =~ '^(192\\.168\\.30\\.|10\\.30\\.)'   -- TODO: your camera VLAN
  AND RemotePort in camera_ports
  AND NOT Path =~ '(?i)nvr|vms|milestone|genetec'

Any browser or media-player process (chrome.exe, vlc.exe, ffmpeg) holding sessions to camera IPs from hosts outside your security operations team is worth a conversation with the user.

Exposure Assessment Script

Use this Bash script from a management host to enumerate likely camera exposure on your IoT VLAN and verify whether streaming endpoints respond without authentication:

#!/bin/bash
# Swann SWIFI-SE2KIC exposure assessment — ICSA-26-286-02 / CVE-2026-107605
# Run from a host WITH authorized access to the camera VLAN.
SUBNET="192.168.30.0/24"   # TODO: replace with your camera VLAN CIDR

echo "[*] Discovering live hosts with camera service ports open..."
nmap -Pn -p 80,554,8080,8000 --open -oG - "$SUBNET" | grep "Ports:" | tee camera_scan.txt

echo "[*] Testing common streaming endpoints for unauthenticated responses..."
for HOST in $(awk '/Ports:/{print $2}' camera_scan.txt); do
  for PORT in 80 8080 8000; do
    for PATH_ in /snapshot.cgi /videostream.cgi /video.cgi /cgi-bin/snapshot.cgi /api/live; do
      CODE=$(curl -sk -o /dev/null -w "%{http_code}" --max-time 4 "http://${HOST}:${PORT}${PATH_}")
      if [ "$CODE" = "200" ]; then
        echo "[EXPOSED] http://${HOST}:${PORT}${PATH_} returned 200 WITHOUT credentials"
      fi
    done
  done
  # RTSP probe — a 200/OK DESCRIBE response without auth challenge indicates exposure
  timeout 4 curl -sk rtsp://"${HOST}":554/ -o /dev/null && echo "[CHECK] RTSP reachable on ${HOST}:554 — verify auth required"
done

echo "[*] Checking for internet-facing exposure (run from outside your perimeter too):"
echo "    Review firewall/NAT rules for port forwards to camera IPs and disable UPnP on the gateway."

Remediation

1. Inventory first. Identify every SWIFI-SE2KIC unit and record firmware versions. Search procurement records, your wireless controller's client list (Swann MAC OUI prefixes), and the NVR's camera registry.
2. Apply vendor firmware updates immediately. Update all affected units past firmware 2.0.22 via the Swann app or the vendor's support portal. Monitor the official advisory for the fixed version number and release notes: CISA ICSA-26-286-02 and Swann's support site. CISA's standing guidance for ICS advisories is to patch or mitigate without delay — do not wait for KEV inclusion to act on a zero-interaction exposure.
3. Segment the cameras. Move all cameras to a dedicated IoT VLAN with a default-deny firewall policy. Permit traffic only between cameras and the NVR/VMS, and from authorized viewing workstations. Block camera-initiated outbound internet access except to explicitly required vendor cloud endpoints.
4. Eliminate internet exposure. Audit NAT/port-forwarding rules for ports 80, 554, 8000, and 8080 pointing at camera IPs. Disable UPnP on the gateway/router — consumer cameras are notorious for punching their own holes. Check Shodan/Censys for your public IP ranges.
5. Enforce strong device credentials and disable unused services. Change default passwords, disable Telnet/ONVIF/RTSP where not operationally required, and disable the camera's P2P cloud relay if you operate a local NVR.
6. Verify remediation. Re-run the exposure assessment script above after patching and segmentation. An endpoint that returned HTTP 200 without credentials pre-patch must now return 401/403 or be unreachable from unauthorized segments.
7. Detect and monitor going forward. Deploy the Sigma and KQL content above with your environment-specific subnets. Alert on any new device appearing in the camera VLAN and any cross-VLAN connection to camera service ports.
8. Plan lifecycle replacement. If Swann does not publish a fixed firmware for this model, treat the devices as permanently untrusted: isolate them behind a VMS proxy that enforces authentication, or budget for replacement with hardware that supports signed firmware, 802.1X, and certificate-based access.

Unauthenticated camera access is the kind of vulnerability that never makes headlines but constantly feeds real intrusions — physical reconnaissance ahead of burglary, privacy violations, and footholds for lateral movement. The fix is cheap: patch, segment, and watch the wire.

Related Resources

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