301 D-Link Cameras Wide Open in Switzerland

On 2026-04-22 BleepingComputer ran a story about a new Mirai variant that Akamai’s SIRT had been tracking since March. The variant was actively exploiting CVE-2025-29635, a command injection bug in the D-Link DIR-823X router. Two days later CISA added the CVE to its Known Exploited Vulnerabilities catalog with a federal patch deadline of 2026-05-08. The vulnerability scored 7.2 HIGH on CVSS, the affected device had been end of life since November 2024, and D-Link’s official guidance was the same line they have used a lot lately. Retire the device.

Akamai also pulled a hardcoded string out of the malware binary that names the operator. The string reads AI.NEEDS.TO.DIE. The malware family is tuxnokill, picked from the next most distinctive string in the binary. The CVE bundle the operator chains together (CVE-2025-29635 against D-Link, CVE-2023-1389 against TP-Link Archer AX21, and an RCE on the ZTE ZXV10 H108L) does not match any previously named Mirai cluster, so tuxnokill is the watch list name for what is currently a new operator.

The natural question for anyone running infrastructure here was, how exposed is Switzerland?

We pulled Shodan for Swiss IP space and live verified 842 candidate hosts with a single non intrusive HTTP GET. The literal answer to the literal question: 0 DIR-823X devices visible on the Swiss public internet. The model never reached the Swiss retail market in any volume. Operator managed gateways from Sunrise, Salt, and Swisscom dominate the residential footprint, and the DIR-823X is a non US SKU with a 12 month sales window before EOL.

That should have been the end of it. A short blog post saying Switzerland got lucky on this one. Instead the same scan surfaced 301 D-Link IP cameras spread across 21 of 26 cantons, 99.7% of them leaking their full LAN topology to anyone with a web browser, 96% of them speaking plain HTTP, 9 of them streaming live video without authentication, and 121 of them sitting on hardware D-Link has officially abandoned with publicly disclosed exploits and no patch coming. tuxnokill, the same operator with the AI.NEEDS.TO.DIE calling card, is one Shodan query away from the cameras.

The rest of this post is what we found and how we counted it.

What we were looking for, and what we used

Two parallel Shodan queries against country:CH. The first was product:"D-Link" which returned 568 records. The second was http.html:"goform/login" which returned another 274. The second query was meant to catch any DIR-823X devices that Shodan had not tagged as D-Link in its product field, since the new D-Link AX series login pages bootstrap the model identifier client side via JavaScript and Shodan’s HTTP module only captures the static initial response body.

That last point is worth pausing on. A bare Shodan query for "DIR-823X" returns 0 hits globally as of 2026-04-29. Not zero in Switzerland. Zero anywhere. The same query for DIR-825 (a 2010 era model) returns 7’779 hits. DIR-868L returns 192. DIR-882 returns 57. The pattern is consistent across every newer AX series D-Link model, and it generalises beyond D-Link. Any IoT device whose login page renders the model name client side is structurally invisible to Shodan’s body capture. Censys, ZoomEye, and FOFA almost certainly have the same blind spot. If you are running an IoT census and you trust the product tag, you are systematically undercounting newer hardware. Live verification is mandatory.

After deduping the two queries to 842 unique (IP, port) pairs, we hit each one with GET /login.html and looked for the literal string DIR-823X in the body, plus secondary new UI markers (/goform/login, EAGLE PRO AI, AX3000, trans_func.js). 318 hosts responded, 524 returned RST or timed out, and 0 of them were DIR-823X.

The 318 responders were 9 legacy DIR-600 access points, 1 Hitron cable modem caught by the goform pattern, and roughly 300 D-Link DCS series IP cameras. The cameras were the rest of the story.

The pivot

Filtering the same Shodan dumps to records with shodan_product containing DCS- produced 454 unique candidates. We hit each one with GETs (body capped at 4 KB) on six fingerprint endpoints: /, /HNAP1/, /common/info.cgi, /info.cgi, /login.htm, /login.cgi. We hit nine video and snapshot endpoints with HEAD only (/image/jpeg.cgi, /video.cgi, /mjpg/video.mjpg, /cgi-bin/video.cgi, /cgi-bin/snapshot.cgi, /snapshot.cgi, /video1.mjpg, /img/snapshot.cgi, /dms). HEAD only matters here. If a HEAD on /video.cgi returns 200 with a Content Type of multipart/x-mixed-replace, you have confirmed the endpoint is unauthenticated and reachable without ever fetching a single video byte. That is the same envelope Shodan, Censys, and Shadowserver use for IoT census reporting. We did not authenticate. We did not POST. We did not hit any endpoint that could leak credentials (/config/getuser, /getcfg.php, /asp/getconfig.asp, /dws/api/* were explicitly excluded). We did not capture topology values, only the boolean presence of each leak field.

A follow up query to close a coverage gap (("DCS-" OR "realm=\"DCS\"") -product:"D-Link" country:"CH" returned 378 records, of which 31 were Shodan tagged honeypots, 10 were on cloud or VPS ASNs, 8 were other brand cameras, and 8 were real D-Link cameras the primary query had missed. Adding those to the first pass got us to 301 live verified D-Link cameras in Swiss IP space.

The numbers below are over those 301.

The 9 live streams

Nine cameras returned HTTP 200 with a Content Type of image/jpeg or multipart/x-mixed-replace to an unauthenticated HEAD on a video or snapshot endpoint. By model and ISP:

Model	Endpoint	ISP	Count
DCS-5020L	/video.cgi (MJPEG)	Sunrise	2
DCS-5211L	/image/jpeg.cgi (snapshot)	Swisscom	2
DCS-5222L	/image/jpeg.cgi	Swisscom + Quickline	2
DCS-933L	/video.cgi	Swisscom	1
DCS-932LB1	/video.cgi	Sunrise	1
DCS-932L	/video.cgi	Sunrise	1

Nine residential addresses, somewhere in Switzerland, with a camera pointed at a baby’s room or a living room or a workshop or a front door. The video feed is reachable on the public internet without a password. Any internet user who finds the IP can pull a frame. Per IP data is held back from this writeup permanently.

The thing to understand about this number is that it is the unauthenticated subset. The full population of cameras with a default admin / <blank> HTTP Basic on /image/jpeg.cgi is much larger, almost certainly the majority of the 301, but our scanner does not test credentials by design. Nine is the count of cameras where the operator removed authentication entirely.

The 99.7% topology leak

293 of the 301 cameras returned a complete plaintext device fingerprint in response to GET /common/info.cgi. No authentication. No cookie. Just an HTTP GET. The response, with sensitive values redacted because we did not capture them, looks like this:

model=DCS-5000L
brand=D-Link
version=1.05
build=2
hw_version=A
name=DCS-5000L
location=<owner string>
macaddr=B0:C5:54:XX:XX:XX
ipaddr=192.168.X.X
netmask=255.255.255.0
gateway=192.168.0.1
wireless=yes
ptz=P,T

What an attacker gets in one request:

The exact device fingerprint, which determines which CVE bundle to use. Internal LAN structure, which bypasses the assumption that the device is behind NAT and therefore safe. The MAC address, which is a persistent device identifier across IP changes and cross references with Wi-Fi geolocation databases like WiGLE. And an owner set location= string, which the camera UI prompts for during setup. Owners do set this. We did not capture the values, but we did record whether the field was non empty. 293 of 294 had a custom location set. People label them in the obvious ways. Babyzimmer. Eingang. Werkstatt. Wohnzimmer. Shop names. The names of children’s rooms.

This bug has a CVE. CVE-2018-18441, originally disclosed against a partial model list. The official NVD CPE list names 8 or 9 specific models with a phrase appended that says “and many more.” The Swiss data quantifies the “many more.” Every alphapd and dcs-lig-httpd based DCS camera we observed returned the same key=value schema: DCS-932L, DCS-932LB1, DCS-933L, DCS-5000L, DCS-5009L, DCS-5010L, DCS-5020L, DCS-5030L, DCS-5211L, DCS-930L, DCS-930LB1, DCS-936L, DCS-942L, DCS-942LB1, DCS-2310L, DCS-5222L, DCS-5222LB1. 17 distinct model variants, every single one of them leaking. CVE-2018-18441 has been generally affecting the entire alphapd line for 8 years, and the public CPE list is a low water mark.

The 96% HTTP ratio

Of the 301 cameras, 290 are reachable over plaintext HTTP. 13 are reachable over HTTPS, and several of those have invalid or self signed certificates. Round to the disclosure ready figure and 96% of these cameras pass admin credentials in cleartext on the public internet. Every default credential brute force attempt, every legitimate admin login from the owner, every on path observer in the Swiss residential ISP topology gets admin: and the password for free.

This is the part that surprises people the least once you point it out and bothers them the most after they sit with it. The cameras have an HTTPS option. Most of them ship with a self signed certificate. The owner gets a browser warning, clicks through it once, decides it is annoying, and switches to HTTP. The browser stops complaining. The credentials cross the wire in cleartext for the rest of the camera’s life.

The 121 unfixable cohort

The headline finding for vendor accountability sits in three subpopulations that together account for 121 cameras on hardware D-Link has officially declined to patch.

The first is the DCS-5000L, 21 cameras across four ISPs. D-Link’s advisory SAP10131 lists, per affected model, the fixed firmware version. For the DCS-5000L the field reads, verbatim, “Not Available”, with the explanation “Non-US Product EOL/EOS.” 19 of the 21 Swiss DCS-5000L cameras are on firmware 1.05, the last release. They are fully patched and fully vulnerable to a post auth RCE that D-Link has stated will not be fixed.

The second is the DCS-932L and DCS-932LB1 line, 100 cameras across 8 ISPs. These two hardware revisions share a firmware tree. D-Link’s final release was v2.18.01, EOL’d 2023-09-01. 5 new CVEs were disclosed in 2025 and 2026 against that final firmware: CVE-2025-5571, CVE-2025-5572, CVE-2025-5573, CVE-2025-4841, and CVE-2025-4843. 4 of the 5 are CVSS 8.8, 3 are command injection, 2 are stack overflow. D-Link’s response (advisory SAP10247) was to retire and replace. 69 of the 100 cameras are on firmware 2.18, which is the final available version. Same as the DCS-5000L situation. Patched as far as the vendor will go, vulnerable to 5 separately disclosed CVEs, no fix coming.

The third is smaller and worth its own paragraph. CVE-2026-2218 was disclosed 2026-02-09 against the DCS-933L on firmware 1.14.x, a post auth OS command injection in /setSystemAdmin. The model has been EOL since 2020-06-30. 16 cameras are exposed in Switzerland, 13 of them on firmware 1.15, which is the latest available release and which fixes the older CVE-2019-10999 but does not fix CVE-2026-2218.

Total across the three: 21 + 100 + 16 = 137 cameras on hardware where the vendor has explicitly said no patch is coming. We round to 121 in the headline because the DCS-933L cohort sits one footnote away from the same framing (older CVE was patched, newer one was not). Either number tells the same story. A meaningful share of the Swiss D-Link camera footprint is on devices that will never be safer than they are right now.

A camera from 2013 with bugs from 2013

The 17 model variants we observed include the expected current decade ones, and a single oddity that surfaced through the coverage gap query. One DCS-2121 is still answering on the Swiss public internet. The DCS-2121 was disclosed by Roberto Paleari in 2013 and shipped with 5 unauthenticated CVEs, CVE-2013-1599 through CVE-2013-1603. One of these cameras is online today, 13 years after the bugs went public, talking to anyone who connects.

The DCS-2121 is the most extreme single example of the lifecycle pattern this post keeps coming back to. A consumer IoT device gets installed in 2013, runs continuously for 13 years, has its known vulnerabilities widely published in that time, never gets patched because the owner does not check, and the vendor stopped shipping fixes a decade ago. The device keeps doing what it does. The internet keeps reaching it. Nothing intervenes.

Geography and ISP concentration

The 301 cameras span 21 of 26 Swiss cantons. Zürich leads with 65 cameras, mostly in the city itself. Vaud follows with 37 (Lausanne carries 22). Bern has 32, with an interesting cluster of 11 in Langenthal. The Alpine cantons Glarus, Jura, Obwalden, Uri, Nidwalden, and the two Appenzells came in at zero, which is more about population than any kind of regional security culture.

Three ISPs operate 244 of 294, or 83%, of the exposed cameras: Sunrise GmbH (143 cameras, AS6730), Swisscom (70, AS3303), and Quickline (31, AS15600). After that there is a long tail of smaller regional operators, and one of them stands out enough to name. senseLAN GmbH, AS31736, has 5 exposed D-Link cameras visible in our scan. All 5 of them are the DCS-5000L, the model with no fix available. 5 out of 5 is too clean to be coincidence. The likeliest explanation is a single installer or contractor that pushed that model through senseLAN’s customer base at some point, and the deployment is now scattered across a residential footprint with no coordinated path to remediation.

A weaker but still notable concentration sits at the /24 prefix level. 50 of 234 unique /24 prefixes carry at least 2 cameras. The largest are residential ISP prefixes with 3 or 4 cameras each, which suggests shared installer or shop deployments rather than coincidence. If you wanted to understand who is putting these cameras on the public internet, the /24 view is where the evidence lives.

Two anomalies worth flagging

39 cameras across multiple ISPs are bound to TCP port 3128. That is the default port for the Squid proxy, which has nothing to do with cameras. All 39 returned valid alphapd or dcs-lig-httpd banners and proper /common/info.cgi data, so they are real cameras and not honeypots. The most likely explanation is that an old setup tutorial, or an ISP setup wizard, or a popular forum post recommended port 3128 as a “non default” port forwarding choice, and a cohort of users followed it. Shodan crawls the long tail of ports anyway, so the obscurity bought nothing.

One residential IP on Quickline is alive on ports 70 (gopher), 79 (finger), and 80 (HTTP). Port 80 returns valid camera fingerprints. Gopher and finger were outside the scanner’s scope, but neither protocol has any business on a residential IP in 2026, and the combination is the strongest “this might be a research honeypot inside a Quickline residential range” signal in the dataset. We did not drop it from the camera count.

There is one obvious honeypot in the broader Shodan dataset that did not survive the live verification step. 37.235.50.99 is hosted by EDIS GmbH (a Vienna VPS provider, AS57169, Swiss IP geo). It has 32 ports open. Its HTTP Server header is a 4 KB concatenation of approximately 150 different embedded device server signatures (alphapd, dcs-lig-httpd, mini_httpd, Linux DIR-850L, ZTE corp 2005, TP-LINK Router, Boa, lighttpd, Cambium HTTP Server, WindRiver-WebServer). Classic Conpot style honeypot pretending to be every IoT device on the planet. Shodan had already tagged it, our heuristic flagged it again, and the live fingerprint check correctly excluded it.

tuxnokill is one Shodan query away

The CVE bundle Akamai’s SIRT pulled out of the tuxnokill malware binary does not stop at the new D-Link router. CVE-2023-1389 is a TP-Link Archer command injection. The ZTE ZXV10 H108L target is a residential gateway. CVE-2025-29635 against the new D-Link router is the headline because it is what got Akamai’s attention, but the operator’s playbook is plainly residential-IoT-shaped and not router specific.

Nothing in the playbook so far suggests the operator would skip a route to a Swiss residential foothold via cameras if Shodan started returning Swiss results. The 121 unfixable cohort is a route. The 9 unauthenticated streams are a different route. The 293 cameras returning topology data on /common/info.cgi are a third. None of these require credentials. None of them require a 0 day. They all sit one Shodan query away from the operator who is currently weaponising D-Link gear in production.

What we did not do

grep -E "Authorization|auth=|HTTPBasicAuth|requests\.post|.post\(" returns zero matches across the scanner code. No Authorization header set, ever. No auth= parameter passed to the requests library. No POST calls anywhere. No login form submission. No default credentials tried. No POST to the vulnerable /goform/set_prohibiting endpoint, which would have actually exploited CVE-2025-29635. No CVE-2019-10999 stack overflow probe. No video frames captured at any point.

The 9 unauthenticated video streams are the camera’s own behaviour. The scanner did not bypass anything. The 99.7% topology leak is documented vendor behaviour (CVE-2018-18441) the device performs for any anonymous client that asks. We observed. We did not access in the sense that Swiss law (Art. 143bis StGB) defines access. The scanner sent an identifying User Agent, a From: header pointing to a real research mailbox, ran at low concurrency, hit each fingerprint endpoint exactly once, and used HEAD wherever a HEAD would answer the question. This is the same operating envelope Shadowserver, Censys, and RIPE Atlas run within, and it is the envelope coordinated IoT research has been operating under for more than a decade.

What this means if you run anything on the public internet

The general lesson is not specifically about D-Link cameras. The pattern is older than that. A consumer device gets installed in 2016 or 2018 or 2020. The owner sets up port forwarding so they can check it from outside the LAN. The vendor ships patches for a couple of years. Eventually the device hits EOL, the patches stop, and a CVE drops. The owner does not see the CVE because they are not on D-Link’s mailing list and would not parse the advisory if they were. The camera keeps working. The camera keeps being on the internet. Years go by.

The 121 unfixable cohort in this writeup is what the end of that timeline looks like at country scale. The vendor has officially said the device cannot be patched. The device is still on the internet because nobody sent a signal that anything had changed. The signal that should have arrived is the one this post is intended to be. If you operate a small business or a residence and you set up any networked device that exposes a web interface to the public internet at any point in the last decade, that device is probably still doing it. The thing it does is not safer than it was the day you installed it. It is meaningfully less safe. That is the common case across the Swiss residential footprint, and the DCS-2121 from 2013 is the worked example.

What you can do about it that takes less than an afternoon is enumerate your own external attack surface and look at the result. The hard part is enumerating it. The easy part, once you know what is there, is making decisions about it. If a camera you forgot you had 10 years ago is still answering on port 8080, the right action is probably to disconnect it, not to write a firewall rule.

If you would rather have a tool produce that enumeration than do it manually, Sentinel scans your public IP and delivers an AI written report in about 30 minutes. Free, no account required. The report tells you which CVEs apply to your environment, which ones matter most, and which open services are best closed. It does the same kind of fingerprinting this writeup does, scaled to whatever you point it at, and it does not capture data you have not asked it to.

The 0 DIR-823X devices in Switzerland was the headline that did not happen. The 301 D-Link cameras are the one that did. tuxnokill, the operator with the AI.NEEDS.TO.DIE calling card, is one Shodan query away from every one of them, and that operator is currently exploiting D-Link gear in production right now.

If anything in your home or your business is on the wrong side of one of these numbers, the time to find out is now.