A sudo bug is a camera bug: component vulnerabilities in video devices

CVE-2021-3156, the sudo heap overflow known as Baron Samedit, is recorded in NVD against the Synology VS960HD and has been in CISA's Known Exploited Vulnerabilities catalogue since April 2022 — catalogued under the vendor name "Sudo", where no camera owner is looking.

What it is#

An off-by-one in sudo's sudoers policy code, classed CWE-193. Running in shell mode, the loop that copies command-line arguments mishandles an argument ending in a single backslash: it reads past the end of that argument and copies what follows into a heap buffer never sized for it. sudoedit -s reaches the vulnerable path before privileges are dropped, which is what puts the overflow in a root context. NVD's whole description is one sentence, and it gives the range as "Sudo before 1.9.5p2".

Qualys, who found it, gave more. The advisory posted to oss-security on 26 January 2021 names it Baron Samedit, says it "was introduced in July 2011 (commit 8255ed69)", and puts the affected range at "all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1". Fixed in 1.9.5p2.

The line that concerns this site is in NVD's CPE configuration. Among the Linux distributions you would expect, it lists the Synology VS960HD.

What an attacker needs#

The vector is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — 7.8 HIGH, scored by nvd@nist.gov. AV:L is about sequencing, not about comfort: something else has to be executing on the box before this is worth anything. What it needs after that is close to nothing. Qualys' advisory states the bug "is exploitable by any local user (normal users and system users, sudoers and non-sudoers), without authentication". They reported "full root privileges on Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2)" — general-purpose distributions in their own lab. Nothing in these sources shows the exploit run against VS960HD firmware, and nothing records whether that firmware exposes a reachable sudoedit to an unprivileged process.

On a sealed appliance the first stage is rarely exotic. An SSH credential left at its factory value or shared across the fleet will do it, and so will a diagnostic shell switched on at commissioning and never switched off. The third route is the interesting one: a command injection in the web UI, executing as the low-privilege web account. A web-tier bug that only yields the low-privilege web account is often triaged as low impact. A local privilege escalation on the same box removes that mitigation.

Impact and blast radius#

Everything in this section is general to Linux-based recorders. None of it is recorded for the VS960HD specifically — these sources contain no teardown of that firmware, and the reasoning below is architectural inference, not a finding.

S:U means the impact is confined to the vulnerable component's own security scope. On a recorder that scope carries more than the metric implies, because of what the box has to hold to do its job. A recorder authenticates to every camera it pulls from, over RTSP and ONVIF, and it does that unattended — so the credentials sit on the device in a form the software can use without a human present. How recoverable they are depends on the implementation. Root also puts an attacker in a position to delete or alter the archive that any subsequent investigation would depend on, and gives them a persistent listener on a segment that tends to get less scrutiny than the corporate LAN.

Whether an implant survives a factory reset depends on the boot design. That is model-specific and worth establishing before an incident rather than during one.

Settle one divergence before you rank this. NVD scores it 7.8 HIGH. Synology-SA-21:02 rates the same CVE Low, with its own CVSS3 base score of 6.7, and rates every affected product Low (advisory checked 2026-09-05). Both positions are arguable — the vendor reasoning about a hardened appliance with no interactive users, NVD about a general-purpose Linux host. Plan against 7.8 unless you can demonstrate the appliance offers no path to unprivileged local execution.

Exploitation evidence#

Facts:

• CISA added CVE-2021-3156 to the Known Exploited Vulnerabilities catalogue on 2022-04-06, with a remediation due date of 2022-04-27 and the action "Apply updates per vendor instructions." Ransomware use: Unknown. Catalogue release used here: 2026.09.04.
• The KEV entry's vendorProject and product fields both read "Sudo".

Now the reference set, because it is a trap. NVD carries 35 distinct references for this CVE, 12 of them tagged exploit. Four are Packet Storm postings for this bug — files/161160, 161230, 161270 and 161293 — all from 2021, alongside the oss-security advisory itself (which appears twice, once as http and once as https, so a naive count double-counts it). But three of those twelve exploit entries, plus a fourth tagged other, are 2024 postings about CVE-2023-6246, the heap overflow in glibc's __vsyslog_internal(): Packet Storm files/176932, seclists 2024/Feb/3, and oss-security 2024/01/30/6 and /8. That is a different vulnerability in a different component, filed under this CVE's references. Anyone sizing the threat by counting exploit tags will overcount by four. And the Qualys write-up — the primary source for the whole bug — is not in NVD's reference set at all; we cite it directly.

What survives that pruning is still decisive: public working exploit code for sudo, dated 2021, from four independent postings.

EPSS is a modelled probability, not a measurement. The score for this CVE is 0.99969, at the 99.977th percentile, calculated 2026-09-04. Read literally, it is a prediction that exploitation activity against something running vulnerable sudo will be observed in the next 30 days. It is not a count of attacks, not a measure of "wide use", and not a statement about your VS960HD. The percentile is the number that tells you where this sits against every other CVE, and it is as far right as the scale goes.

A plain negative, stated because its absence gets read as evidence: these sources contain no report of CVE-2021-3156 being used against a video appliance. No incident, no named campaign, no victim count. If a briefing tells you otherwise, ask which artefact it rests on.

Affected products#

Synology-SA-21:02 covers more than the recorder. As checked on 5 September 2026 it lists DSM 6.2 ("Upgrade to 6.2.4-25554 or above."), DSM UC ("Upgrade to 3.1-23033 or above."), SkyNAS as Pending, VS960HD as Ongoing, and SRM 1.2 as not affected. Of the four affected products, the two DSM lines are the only ones given a named fixed build; SkyNAS and the VS960HD have neither, five and a half years on.

Two unknowns, unglossed. NVD's version ranges are not annotated with which build line each belongs to, so < 2.2.3-1505 and < 2.3.6-1720 cannot be resolved to a single upgrade target from the record alone. And a CPE entry asserts that a product is affected; it says nothing about whether the vulnerable code path is reachable on that product.

Why the mapping is fragile#

Scanner matching runs on CPE. Your tool fingerprints the recorder, decides it is a Synology video appliance, and asks the database which CVEs name that identifier. Here the database answers, because the CPE configuration for CVE-2021-3156 includes VS960HD. That mapping exists. There is no mechanism that guarantees the next component flaw gets one — NVD's CPE assignment is part analyst work and part automation, and the record does not say which produced this entry.

Three consequences follow, and they compound.

KEV-driven work queues key on vendorProject and product. Both fields read "Sudo". A team that filters the catalogue by its camera vendors will never surface this entry, and the filter is not misconfigured; the catalogue is genuinely describing sudo.

Vendor response is discretionary and uneven. Synology published within a month of disclosure, rated it Low, and has left the VS960HD row at "Ongoing" — the advisory's own last-updated stamp is 1 September 2021.

A clean appliance scan carries less information than it appears to. Where a scanner matches only CPEs, no finding means no mapping, which is a claim about the database rather than about the device.

How to check#

Qualys publishes a test under the heading "How can I test if I have vulnerable version?" — run sudoedit -s /. An error beginning sudoedit: indicates a vulnerable build; one beginning usage: indicates a patched one. You need a shell on the device, which on a locked-down appliance you may not have and should not enable for this. Appliance shells are also frequently stripped, so treat an unexpected response as inconclusive; an absent sudoedit is itself an answer. Cross-check sudo --version against 1.9.5p2 and against the Qualys ranges above.

The longer-run check is procedural. Ask each video vendor, in writing, for an SBOM covering the firmware build you actually run. Where you do not get one, record "component inventory: unknown" against that model along with the date you asked, because an empty row and a clean row look identical six months later. Then, when the next component CVE lands on something ubiquitous — a glibc, an OpenSSL — you already have the list of models to ask about and a record of which vendors answered last time.

Sources

1. CVE-2021-3156 detail. NVD, 2026-06-17
2. Known Exploited Vulnerabilities Catalog, release 2026.09.04. CISA, 2026-09-04
3. EPSS model output for CVE-2021-3156, scored 2026-09-04. FIRST, 2026-09-04
4. Baron Samedit: heap-based buffer overflow in sudo (CVE-2021-3156). Qualys, via openwall oss-security, 2021-01-26
5. Baron Samedit: heap-based buffer overflow in sudo. Qualys, 2021-01-26; accessed 2026-09-05
6. Synology-SA-21:02 Sudo. Synology, published 2021-02-22, last updated 2021-09-01; accessed 2026-09-05
7. sudo stable release notes, 1.9.5p2. Sudo Project, 2021
8. CVE-2023-6246: Heap-based buffer overflow in the glibc's syslog(). Qualys, via openwall oss-security, 2024-01-30; accessed 2026-09-05

Revision history