dbcve.org
OpensatkitApplication

CVE-2025-70083

HIGH · 7.8 CVSS v3.1 Published 2026-02-11
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
80/100
Remediation priority · High
Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
An issue was discovered in OpenSatKit 2.2.1. The DirName field in the telecommand is provided by the ground segment and must be treated as untrusted input. The program copies DirName into the local buffer DirWithSep using strcpy. The size of this buffer is OS_MAX_PATH_LEN. If the length of DirName is greater than or equal to OS_MAX_PATH_LEN, a stack buffer overflow occurs, overwriting adjacent stack memory. The path length check (FileUtil_AppendPathSep) is performed after the strcpy operation, meaning the validation occurs too late and cannot prevent the overflow.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

OpenSatKit 2.2.1 contains a stack buffer overflow vulnerability in its telecommand processing. The DirName field, received from the ground segment as untrusted input, is copied via strcpy into a fixed-size buffer (DirWithSep) of OS_MAX_PATH_LEN bytes without prior length validation. When DirName length is greater than or equal to OS_MAX_PATH_LEN, the strcpy operation overflows the buffer and overwrites adjacent stack memory. A length check exists (FileUtil_AppendPathSep) but executes after the strcpy, providing no protective value.

MitigationImplement strict input validation on DirName to enforce length < OS_MAX_PATH_LEN before any copy operation, and replace strcpy with bounded copy functions such as strncpy or strlcpy that enforce buffer size limits.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
OpensatkitApplication
Affected:= 2.2.1

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Verify OpenSatKit version
    Locate and inspect the OpenSatKit installation to confirm the installed version matches 2.2.1 (e.g., check package metadata, version file, or binary version information)
    Affected if Version is exactly 2.2.1
  2. Confirm telecommand processing is active
    Check whether the telecommand processing module (that handles DirName field from ground segment) is loaded and operational in the running system
    Affected if Telecommand processing for directory-related commands is enabled and receiving input
  3. Locate the vulnerable strcpy call
    Inspect the source code or binary for the strcpy call within the telecommand handler that copies DirName into the DirWithSep buffer of OS_MAX_PATH_LEN bytes (typically in FileUtil_AppendPathSep or adjacent code)
    Affected if The strcpy copying DirName to DirWithSep without prior length check is present in the code path being executed
  4. Check OS_MAX_PATH_LEN buffer size
    Determine the value of OS_MAX_PATH_LEN in the OpenSatKit build configuration; this defines the fixed buffer size that DirName is copied into
    Affected if OS_MAX_PATH_LEN is defined and the DirName can approach or exceed this length from external input
  5. Verify ground segment input path
    Confirm that DirName is received from the ground segment (untrusted external source) and processed by the vulnerable code path without prior length validation
    Affected if DirName input from ground segment reaches the strcpy call without length checking beforehand

If OpenSatKit 2.2.1 is running with telecommand processing enabled and receiving DirName input from the ground segment, the system is vulnerable to stack buffer overflow via unchecked strcpy into OS_MAX_PATH_LEN buffer.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

From vendor data
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Implement strict input validation on DirName to enforce length < OS_MAX_PATH_LEN before any copy operation, and replace strcpy with bounded copy functions such as strncpy or strlcpy that enforce buffer size limits.

Fix this in Opensatkit Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing4.0 h
  • Review / QA2.0 h
15.0 hours of engineering $2,640
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,224.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2025-70083 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2025-70083 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data