CVE-2026-92158 in F Prime
Summary
by MITRE • 10/14/2026
F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.2.0, Svc::FpySequencer STORE directive stack write validation the bounds check adds attacker-controlled offset and size before memcpy, allowing integer wraparound to make an out-of-range destination appear valid. When a sequence-controlled STORE directive supplies a stack offset and size whose U32 sum wraps, memcpy can write outside the sequencer stack, causing memory corruption, denial of service, and potentially code execution. This issue is fixed in version 4.2.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
The F Prime framework serves as a critical infrastructure for developing and deploying embedded software applications within spaceflight systems and other high-reliability environments. These systems demand rigorous security standards due to their operational context, where failures can lead to catastrophic consequences. Within this framework, the Svc::FpySequencer component manages sequence execution, which is fundamental for controlling complex workflows in spacecraft operations. A significant vulnerability was identified prior version 4.2.0 regarding how this sequencer handles memory allocation during specific directive executions. The flaw resides specifically within the validation logic of the STORE directive, which is responsible for writing data to a designated location on the stack.
The technical root cause of this vulnerability involves an integer overflow condition that leads to out-of-bounds memory writes. When processing a sequence-controlled STORE directive, the framework calculates the destination address by adding an attacker-controlled offset and size parameters before performing the actual memcpy operation. The validation logic intended to ensure these values remain within safe bounds fails because it does not account for unsigned 32-bit integer wraparound. If the sum of the provided offset and size exceeds the maximum value representable by a U32, the result wraps around to a small positive number that appears valid according to the flawed check. Consequently, the memcpy function proceeds with this incorrect destination address, writing data beyond the allocated stack boundaries.
This memory corruption vulnerability has severe operational impacts on system integrity and availability. By allowing writes outside the sequencer stack, an attacker can corrupt adjacent memory regions, potentially overwriting critical control structures or return addresses. This capability enables a denial of service by crashing the embedded application, which is particularly dangerous in spaceflight contexts where recovery may be difficult or impossible without ground intervention. Furthermore, if the corrupted memory includes executable code pointers or function returns, it opens the door to arbitrary code execution. An attacker could leverage this flaw to gain unauthorized control over the spacecraft's software environment, potentially leading to data exfiltration, command injection, or complete system compromise.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Write in the Common Weakness Enumeration taxonomy. In terms of tactical behavior, it relates to ATT&CK techniques involving memory corruption for privilege escalation or defense evasion, specifically within embedded systems contexts where traditional endpoint protection may be absent. The exploitation requires the ability to influence sequence parameters, which implies a need for some level of access to the sequencing interface, highlighting the importance of strict input validation and authentication mechanisms in operational workflows.
To mitigate this risk, organizations using F Prime must upgrade immediately to version 4.2.0 or later, where the bounds checking logic has been corrected to properly handle integer arithmetic without wraparound errors. For systems that cannot be upgraded due to certification constraints, defensive coding practices should be implemented at the integration layer. This includes implementing explicit checks for overflow before performing addition operations on size and offset values. Additionally, employing static analysis tools configured to detect integer overflows during development can help identify similar patterns in custom sequence implementations. Runtime protection mechanisms such as stack canaries or memory-safe languages for new components can also provide additional layers of defense against exploitation attempts.