A command-injection flaw in a Cobham Satcom maritime VSAT router was published with a proof-of-concept exploit, no fixed firmware, and a record stating the vendor never answered — while the vendor’s own disclosure page promises a reply within one business day.
What happened
NVD published CVE-2026-83772 at 6:16 a.m. UTC on September 1, 2026. The record is in Received status and every piece of analysis in it comes from a single source: [email protected]. VulDB is the CNA, the scorer, and the publisher of the underlying advisory.
The description, verbatim:
“A vulnerability was detected in Cobham SATCOM VSAT7090 Maritime Satellite Router up to 20260704. This issue affects the function c_set_reports_decode of the file mail-report.sh of the component JSON Parsing. The manipulation of the argument sender/recipients results in command injection.”
The weaknesses are CWE-74 and CWE-77. The affected version is not a release number but a build date — 20260704, which reads as July 4, 2026. No fixed version is named anywhere in the record.
VulDB scored it three times, and its three scores disagree with each other by a full severity band:
- CVSS v3.1: 9.9, Critical —
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H - CVSS v4.0: 8.6, High —
AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P - CVSS v2.0: 9.0, High —
AV:N/AC:L/Au:S/C:C/I:C/A:C
The v4.0 vector carries E:P — exploit maturity, proof-of-concept — which is the scorer stating in the published vector that working attack code exists. VulDB’s own entry, VDB-397501, confirms it: a public exploit is available in proof-of-concept status, with technical details and the exploit itself downloadable. That entry was created at 01:06 and last updated at 09:25 on September 1; VulDB does not state a time zone on either stamp.
Two sentences from that entry are the reason this is a story rather than a routine small-vendor CVE. On the vendor, VulDB writes: “The vendor was contacted early about this disclosure but did not respond in any way.” On remediation, it writes: “There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.”
Cobham Satcom does run a disclosure program, and on paper it is better than most. Its public vulnerability reporting page states that the company “usually responds to incoming reports within one business day.” It commits to the “public release of a security advisory containing all necessary information on the Cobham Satcom Services website,” says it “is prepared to work in good faith with anyone who reports security vulnerabilities,” pledges not to pursue legal action against researchers who “perform coordinated disclosure,” and maintains a public credits list it calls a Hall of Thanks.
No advisory for CVE-2026-83772 was found on the vendor’s public materials at the time of this check. The model designation VSAT7090 did not appear on the vendor’s reachable maritime product pages either, which list product categories rather than model numbers.
The record carries exactly one technical reference besides VulDB’s own pages: a wiki document hosted on Feishu, a Chinese collaboration platform. That URL is disallowed by robots.txt and could not be read on this run.
Why it matters
A maritime VSAT router is not a router in the sense most readers use the word. It is a vessel’s only link. There is no second path, no fallback over a corporate WAN, no fiber crew to call. On most commercial vessels the terminal fronts everything that talks to shore — crew connectivity, business systems, remote monitoring of engineering and navigation equipment, chart and weather updates. Command execution on that box is command execution at the boundary of the ship.
The specific flaw is the oldest shape in the catalog. A shell script, mail-report.sh, takes fields out of parsed JSON and interpolates them into a command line without sanitizing them. The fields in question are the sender and recipient addresses of an automated report email. That tells you something useful about the software layer inside these terminals: the reporting features are shell glue, and shell glue that concatenates attacker-influenced strings is a bug class the industry has been fixing since the 1990s. Where you find one, it is reasonable to expect siblings.
The privileges question matters and the record does not settle it. Both the v3.1 and v4.0 vectors say PR:L — some privilege is required — and the v2.0 vector says Au:S, a single authentication. Nowhere does the record say what level of account that is, and the difference between “any user of the web interface” and “administrator” is most of the risk. On a shore network that ambiguity would still bound the problem to people with accounts. On a vessel, the set of people who have at some point been handed credentials to a satellite terminal’s management interface includes crew who have since signed off, installing contractors, port technicians, and the fleet operations desk ashore. Credential hygiene at sea is not a strength of the sector.
The disclosure gap is the part worth reporting carefully, because it is a conflict between two primary sources and this publication cannot resolve it. The vendor publishes a policy promising a one-business-day response and public advisories with mitigations and fix locations. The CNA of record states the vendor did not respond in any way. Both documents are authentic; both cannot be a good description of the same exchange.
Two cautions belong here. First, VulDB’s sentence about vendor contact is boilerplate that appears across a large number of its entries; it is a template field, not a bespoke account of a specific correspondence, and it should not be read as more than the database asserting that its standard outreach went unanswered. Second, Cobham Satcom has not been heard from. This publication cannot solicit a statement, and the absence of one here is a limitation of the reporting, not evidence about the vendor.
What is not in dispute is where that leaves an operator. The authoritative record for a critical flaw in shipboard equipment offers, as its remediation guidance, that the affected object might be replaced with an alternative product. For a fleet that is not advice. A VSAT terminal is above-deck capital equipment; swapping one is a yard visit and a service contract, not a maintenance window. Meanwhile the record says an exploit is publicly downloadable, and the single document describing that exploit cannot be retrieved by ordinary automated means. The defender is told an exploit is public and then denied the ability to see it. That asymmetry — public to whoever finds the wiki page, effectively private to everyone running the equipment — is becoming a recurring feature of records sourced to a single link.
What to do
Start with whether this is your equipment, which is harder than it should be. The VSAT7090 designation does not appear on the vendor’s public maritime product pages reachable from here. Match on capability and build instead: a Cobham Satcom maritime terminal with an automated email-reporting feature, running firmware built on or before July 4, 2026. If you buy through an integrator or a service provider such as a maritime communications reseller, ask them for the model mapping and the firmware build date on each hull rather than guessing from marketing names.
There is no patch, so the available action is exposure reduction. The terminal’s management and reporting interface should not be reachable from crew wifi or from any network segment a passenger or contractor device can join, and it should not be reachable from the public side of the link. Put it behind a management VLAN with an explicit allow list. If the email-reporting feature is not in use — on many hulls it is configured once at commissioning and never looked at again — disable it. Rotate the credentials on every account that can reach the reporting configuration, and remove accounts belonging to crew and contractors who have rotated off.
Ask the vendor directly, citing CVE-2026-83772, and ask specifically whether an advisory is coming and which build carries a fix. The company’s stated norm is a reply within one business day. If you get one, you will have obtained something the CVE record did not.
Sourcing note
Checked: the NVD record for CVE-2026-83772, the source of the description, weaknesses, affected version, and all three CVSS vectors quoted above; VulDB entry VDB-397501, the underlying advisory and the source of the vendor-contact and countermeasures quotations; and Cobham Satcom’s public vulnerability reporting page, the source of the response-time commitment and advisory-publication language. Quotations from all three are reproduced exactly.
Could not reach: the Feishu wiki page that is the record’s only third-party technical reference is disallowed by robots.txt, so the proof-of-concept and the vulnerable code were not inspected on this run. Every technical claim above about the flaw itself therefore rests on the CNA’s description, not on examined artifacts, and this story is single-sourced on that point. The vendor’s maritime product listing was read but returned category pages without model numbers, so the absence of a VSAT7090 listing is weak evidence and should not be read as the product not existing.
Unresolved: what privilege level the flaw actually requires; whether a fixed firmware build exists and is simply undocumented; and what, if anything, passed between VulDB and Cobham Satcom. This publication has no way to contact the vendor for comment, and the vendor’s side of the disclosure account is missing from this story for that reason. No exploitation of this flaw has been reported by anyone, and none is asserted here.