Jetson, TensorRT, and edge-AI: a population survey of NVR and inference exposure

NuClide Research · 2026-05-18 · 10,224 candidates harvested, 296 verified-unauth across 9 platform classes, two deception fleets identified (598 hosts).

Summary

The survey scoped as “Jetson / TensorRT edge” found that the dominant exposed population on the public internet is not the Jetson hardware itself. It is the edge-AI applications that ship with Jetson and run on similar hardware elsewhere. The four largest classes are Frigate (205 unauthenticated of 447 reachable), CodeProject.AI (39 of 40), DeepStack (24 of 25), and motionEye (18 of 64). Frigate alone produced 15 hosts where /api/config returns YAML containing back-end RTSP camera URLs with plaintext credentials.

DCWF KSAT coverage

Auto-derived from DCWF AI work-role rule files (ksat-tag).

• 672 (AI Test & Evaluation Specialist): K7003, K7004, K7044, S7068, S7070, S7075, T5858, T5904, T5919
• 733 (AI Risk & Ethics Specialist): K7040, S7056, S7067, T5868, T5882, T5893
• overlap (Common AI KSATs (all 5 roles)): K1158, K1159, K22, K6311, K6935, K7003, K942, T5896

Two multi-service deception fleets surfaced in Stage 2 verify and were filtered before classification. A 22-host fleet served byte-identical 92-byte Server: Triton banners to Shodan and now serves Server: Icecast 2.4.4 on every path. A 576-host fleet matches dorks for many products by rotating titles per request while serving GitLab markers in a 137KB body. Both are documented in Insight #32.

Thesis fit

The auth-on-default thesis predicts that products which ship without authentication will appear at population scale with the unauth posture intact, while products that ship auth-on will appear at population scale gated. This survey confirms both directions on the same day:

• Frigate (205 unauth of 447 reachable, 46%) confirms the unauth direction. Auth was added default-on in Frigate 0.13. Of the 205 unauth instances, 99 run 0.17.1, the current release, where fresh installs are gated. The upgrade path does not enforce auth even when fresh installs do. This is the load-bearing case for Insight #13.
• Scrypted (0 unauth of 300 reachable, 0%) confirms the auth-on direction. Scrypted ships an auth-required management console. At population scale every reachable instance enforces it. This is the falsification-confirmation for Insight #25 the thesis predicts.

---

Verified findings by class

Triton (0 of 27, all 22 reachable hosts are deception-fleet) is recorded separately. Scrypted (0 of 300, all auth-gated) confirms the auth-on-default direction.

Frigate severity breakdown (205 unauth)

Frigate version distribution top-5: 0.17.1 (99), 0.16.4 (19), 0.16.3 (16), 0.17.0 (15), 0.16.1 (8). The unauth population spans 0.12 through the current 0.17. Auth was added default-on in 0.13. The 99 instances running 0.17.1 without auth are the load-bearing observation: a current-release fresh install requires auth, but a 0.12-era operator who has upgraded to 0.17.1 keeps the unauth posture intact across the version line.

RTSP-creds-in-plaintext Frigate hosts (sample 5 of 15)

The remaining 10 are in verify_frigate.jsonl. Each carries the same exposure shape: /api/config returns the full operator YAML, including go2rtc.streams.<camera>.url entries with rtsp://user:password@<ip>:<port>/... strings. An attacker who reads /api/config can connect directly to the back-end IP camera and watch live video, bypassing Frigate entirely.

---

Standout single-host findings

F1. Frigate operator with 15 instances, 5 of them critical (cross-finding)

The 15 plaintext-credential Frigate hosts are 15 distinct operators on 15 different consumer ISPs (Verizon, Comcast, Spectrum, Yandex Cloud, Telefónica Brazil, others). Each one independently exposed /api/config on a residential or small-business uplink. The unauth posture is not a single misconfigured fleet; it is the population behavior of a class of operators who run Frigate on port 5000 directly from a home or office.

F2. SNU GPU dashboard, researcher identity leak

147.46.244.146:8001 runs a custom GPU monitoring dashboard at Seoul National University. The /api/snapshot endpoint returns:

• 6-server cluster topology
• 30 A100-SXM4-80GB GPUs
• Researcher name donghyun
• Project name openpi-actionrep
• Full training command line
• NAS mount path /mnt/snu_nas/data/donghyun/...

This is academic-tier identity-and-infrastructure leak. The researcher’s name, the project they are training, the hardware they are training on, and the storage path of their dataset are all reachable unauthenticated. The /api/metrics endpoint on the second SNU dashboard (147.46.240.92:50000) adds 4 SSH targets on non-standard port 16870 with the iil@ username.

F3. Auriga NVIDIA Isaac Lab / ROS 2 robotics pipeline (Docker Registry)

47.93.158.253:5000 is an unauthenticated Docker Registry V2 on Aliyun CN. The /v2/_catalog endpoint lists 15 repositories totaling ~150GB. The manifests reveal a mobile autonomous robot development pipeline: the operator builds multi-arch (aarch64 + x86_64) images for base_chassis_navigation_arm, runs NVIDIA Isaac Lab inside the container, and uses ROS 2 for the robotics middleware. Any internet-reachable client can docker pull the images.

F4. Mexican telecom operator with RTX A6000 ($4-5K workstation GPU)

189.155.64.244:9202 runs nvidia_smi_exporter on a residential UniNet (uninet.net.mx) connection. The /metrics endpoint returns the GPU model: NVIDIA RTX A6000, a premium workstation card priced $4,000-5,000. The combination (premium hardware, residential consumer ISP, public exposure) suggests a small-business or independent-researcher operator who installed the exporter for personal monitoring and exposed the consumer-line public IP. This is a low-severity info-disclosure finding on its own. As a chain primitive (target identification for follow-on attacks) it is a useful fingerprint.

F5. Russian “NVIDIA AI Hub” brand misuse candidate

193.58.122.16:3000 runs a Russian-language LLM proxy service at play2go.cloud, advertising “free access to 200+ NVIDIA neural networks” including Llama 3.1, DeepSeek, and Trellis 3D. The legitimacy of the NVIDIA branding is not verified. The service may be an LLM-jacking-style proxy that fronts customer LLM API keys, or a legitimate NVIDIA channel partner (unlikely given hosting on play2go.cloud and Russian-only UX). Flagged for follow-on attribution work.

---

Deception fleets (filtered before classification)

Fleet A: Triton 92-byte / Icecast pattern

Fleet B: Shinobi / GitLab rotating-title pattern

The diagnostic, recurrence, and procedural implications are in Insight #32.

---

Per-finding tool attribution

The four largest verified-unauth classes ran the full Stage 0-7 chain. Per the methodology and the per-finding template, each finding records which tool produced which signal. Below is the chain for the Frigate-RTSP-creds class (the highest-severity tier in this survey).

F-Frigate-15. 15 hosts leaking RTSP credentials in plaintext

What was found

/api/config on 15 Frigate instances returns the operator’s YAML configuration, including go2rtc.streams.<camera_name>.url strings of the form rtsp://<user>:<password>@<camera_ip>:<port>/<path>. The credentials are the operator’s back-end IP camera credentials, embedded in the live running Frigate config and served unauthenticated to any HTTP client that requests /api/config over the public internet.

Why it is bad

Verified: an internet-reachable client reads /api/config, parses the RTSP URLs, and gains direct access to the camera credentials. The operator’s own back-end cameras become directly viewable by anyone who can issue an HTTP GET to the Frigate port.

Inferred (not exercised per the restraint ethic): the credentials likely work against the back-end IP cameras at their rtsp:// URLs. We did not run the connect probe. The chain step from “credential read” to “camera feed viewed” is one VLC client away.

Hypothesized: the same credentials may be reused on adjacent services (camera admin web UI, operator NAS, operator network gear) per the known IP-camera-firmware default-credential reuse pattern. Not exercised.

Who it affects

The 15 operators are on consumer ISPs across 6 countries (US, Brazil, Russia, Mexico, Italy, Argentina, others). Each is a residential or small-business deployment running Frigate behind a residential or small-business uplink. The downstream-affected parties are the operator themselves (camera feeds), camera subjects (anyone visible in the camera frame), and the operator’s network (the back-end cameras and any pivoted device).

How it got exposed

Frigate’s /api/config endpoint is intentionally readable from the web UI because the UI needs the config to render the dashboard. Before Frigate 0.13 the API surface had no authentication layer at all. Frigate 0.13 added authentication default-on. The upgrade path does not enforce the new default for existing deployments. An operator who started on 0.12 and upgrades through to 0.17.1 keeps the auth: enabled: false posture from their old config. The current release ships secure for fresh installs; in-place upgrades inherit the old posture.

This is the load-bearing case for Insight #13: “shipping defaults are load-bearing because the population at any moment is a mix of fresh installs and upgraded-from-old installs; the secure-default fix takes one full upgrade cycle plus operator action to propagate.”

Which tools contributed to the finding

Tools that ran and produced null signal for this class:

• VisorGoose: 0 government TLDs in the Frigate candidate set (Frigate is consumer / commercial; no .gov operators). Null is a result.
• VisorBishop / VisorSD: ASN sweeps produced no new candidates beyond JAXEN’s harvest for this class.
• menlohunt: 0 GCP-EASM matches (Frigate operators are on consumer ISPs, not GCP-hosted).
• recongraph: ran for the standout single-host findings; not material for the 15-host class.
• nu-recon: ran for the SNU GPU dashboards and the Russian NVIDIA Hub; not for the Frigate class.
• VisorPlus: orchestrator runner; the chain was driven by hand for this survey for the per-class control.
• JS-bundle extract: Frigate UI bundles do not embed secrets; the secrets are in the runtime config, not the bundle.

Tools recorded as non-runs with reason (per the methodology):

• VisorHollow: [—] not applicable, Windows-only (it is a Windows process-injection benchmark).
• VisorAgent: [—] not fired at the survey set, ethical-stop. Active LLM exploitation is reserved for controlled targets.
• VisorRAG: ran in adversarial-confirmation mode against the survey’s VisorCorpus on a controlled target, not against the operator hosts.
• cortex: auth-context analyzer not material for an unauthenticated class.

The load-bearing chain for this finding: JAXEN -> aimap -> verify_frigate.py -> VisorLog -> case-study codification.

---

Cross-survey and cross-finding analysis

Real rate by platform class

The 51% verified-real rate aggregated across the survey confirms Insight #15 at the multi-class population level. Per-class real rates split into two populations:

• Marker-strong classes: CodeProject.AI (98%), DeepStack (96%), Docker Registry (100%), nvidia_smi_exporter (100%). The Shodan dork picks up the product-specific marker (a route, a header, a body string) that no other product emits. The real rate is near 100%.
• Marker-weak classes: motionEye (28%), Frigate (46%). The Shodan dork picks up a string that other products and honeypots also emit. The real rate drops sharply.

This generalizes the procedural rule: when constructing a dork, prefer a unique route or header over a title or body word. The dorks for the marker-strong classes anchor on a route (/v1/log/list, /admin, /v2/_catalog, nvidia_smi_exporter metric prefix); the dorks for the marker-weak classes anchor on a body word (Frigate, MotionEye) that appears in fan pages, vendor marketing, and deception fleets.

Provider distribution

The unauth Frigate population skews consumer ISP heavy. The unauth Docker Registries skew cloud heavy (Hetzner, Aliyun, Volcano Engine, HostPapa, APNIC). The unauth CodeProject.AI population skews small-business or hobbyist VPS. This is the operator-tier-by-platform pattern. The hosting provider is a proxy for the operator’s deployment maturity, and the deployment maturity predicts the class of findings.

Persistence

No prior survey covered the Frigate or CodeProject.AI population. This survey establishes the baseline. A re-survey in 30, 90, and 180 days will produce the first persistence measurement for the edge-AI population, comparable to the agent-framework persistence measurement in Insight #30.

---

Methodology, what this case study adds

1. Insight #32 (new): multi-service deception fleets emulate target-specific services for Shodan scanners by rotating titles per request. Filter on body markers, not title. Two fleets identified in this survey (22 Triton, 576 Shinobi).
2. Insight #13 confirmed at the Frigate population level: shipping defaults are load-bearing, and the upgrade path does not enforce them. The 99 unauth instances running Frigate 0.17.1, where fresh installs require auth, are the load-bearing observation.
3. Insight #15 generalized: the ~50% real-rate split by marker type. Marker-strong classes (route / header anchored) hit ~96-100%; marker-weak classes (title / body anchored) drop to ~30-50%. The procedural rule for new dork construction is to anchor on a route or header.
4. Insight #25 falsification-confirmation: Scrypted at 300/300 reachable instances all auth-gated confirms the auth-on-default direction of the thesis. The thesis is bidirectional and tested both ways in the same day.

Honest negative space

• VisorScuba scoring gap: 894/894 events recorded as “passing” against the AI Security Baseline despite 15 critical RTSP-credential leaks. The Rego policies in the baseline check for LLM, INFERENCE, and VECTOR-DB tags; they do not check NVR or CAMERA-ACCESS tags. The scoring layer underreports edge-AI camera findings until an NVR / camera-feed policy class is added.
• Shinobi auth-state on the 361 real instances: the verify probe checked body markers and used the wrong API path for the auth-gate test. The auth state of the 361 real Shinobi instances is undetermined. Carry-forward to re-run the verify with the correct Shinobi API path.
• RTSP/GStreamer port 8554 (~911 candidates): deferred. The probe is a different protocol (RTSP DESCRIBE, not HTTP). The marginal value over the Frigate findings already in hand was judged low for this session.
• Jetson SSH (port 22, ~10 candidates): deferred. The default-credential test is write-tier and requires explicit operator authorization.
• The deception fleet’s other emulation targets: today’s survey caught the fleet on Triton and Shinobi. The fleet’s rotating-title pool includes IP camera, NVR, ERP, GitLab, and PHP application titles. Cross-survey filtering of past harvests is the natural next pass.

Disclosure queue (verified scope)

Toolchain provenance

Stage 0 Discover    JAXEN                   10,224 candidates across 6 dork batches
Stage 1 Fingerprint aimap                   9 platform classes confirmed
Stage 2 Verify      custom probes + aimap   296 verified-unauth, 2 deception fleets filtered
                    (verify_frigate.py, verify_codeproject.py, verify_nvr.py,
                     verify_scrypted.py, verify_shinobi.py, verify_triton.py)
Stage 3 Attribute   VisorGraph              ASN, WHOIS, jurisdiction per host
Stage 4 Classify    aimap-profile           tier per-finding (CRIT/HIGH/MED/LOW/INFO)
Stage 5 Ledger      VisorLog                894 events ingested to nuclide.db (0 deduped)
Stage 6 Score       VisorScuba              894/894 passing (gap noted, no NVR Rego policy)
Stage 6 Exploit     BARE                    max 0.598 motionEye Bavision-IP-cam; all under first-party-authz threshold; no commodity-CVE chain
Stage 6 Corpus      VisorCorpus             137 cases (77 HIGH, 26 MED, 19 LOW, 15 CRIT)
Stage 7 Codify      this case study + Insight #32

See also

• Insight #32, multi-service deception fleets
• Insight #13, shipping defaults are load-bearing
• Insight #15, dork hits vs platform instances
• Insight #25, Scrypted as the auth-on falsification confirmation
• Insight #1, protocol-strict probing self-filters honeypots
• Code-assistants population survey, 2026-05-18, same-day partner survey establishing the per-finding tool-attribution template
• Raw harvest: ~/recon/jetson-tensorrt-2026-05-18/