The product has a hardware interface that silently discards operations
in situations for which feedback would be security-relevant, such as
the timely detection of failures or attacks.

While some systems intentionally withhold feedback as a security
measure, this approach must be strictly controlled to ensure it does
not obscure operational failures that require prompt detection and
remediation. Without these essential confirmations, failures go
undetected, increasing the risk of data loss, security
vulnerabilities, and overall system instability. Even when withholding
feedback is an intentional part of a security policy designed, for
example, to prevent attackers from gleaning sensitive internal
details, the absence of expected feedback becomes a critical weakness
when it masks operational failures that require prompt detection and
remediation.
For instance, certain encryption algorithms always return ciphertext
regardless of errors to prevent attackers from gaining insight into
internal state details. However, if such an algorithm fails to
generate the expected ciphertext and provides no error feedback, the
system cannot distinguish between a legitimate output and a
malfunction. This can lead to undetected cryptographic failures,
potentially compromising data security and system reliability. Without
proper notification, a critical failure might remain hidden,
undermining both the reliability and security of the process.
Therefore, this weakness captures issues across various hardware
interfaces where operations are discarded without any feedback, error
handling, or logging. Such omissions can lead to data loss, security
vulnerabilities, and system instability, with potential impacts
ranging from minor to catastrophic.
For some kinds of hardware products, some errors may be correctly
identified and subsequently discarded, and the lack of feedback may
have been an intentional design decision. However, this could result
in a weakness if system operators or other authorized entities are not
provided feedback about security-critical operations or failures that
could prevent the operators from detecting and responding to an
attack.
For example:

In a System-on-Chip (SoC) platform, write operations to reserved
memory addresses might be correctly identified as invalid and
subsequently discarded. However, if no feedback is provided to
system operators, they may misinterpret the device's state, failing
to recognize conditions that could lead to broader failures or
security vulnerabilities. For example, if an attacker attempts
unauthorized writes to protected regions, the system may silently
discard these writes without alerting security mechanisms. This lack
of feedback could obscure intrusion attempts or misconfigurations,
increasing the risk of unnoticed system compromise
Microcontroller Interrupt Systems: When interrupts are silently
ignored due to priority conflicts or internal errors without
notifying higher-level control, it becomes challenging to diagnose
system failures or detect potential security breaches in a timely
manner.
Network Interface Controllers: Dropping packets - perhaps due to
buffer overflows - without any error feedback can not only cause data
loss but may also contribute to exploitable timing discrepancies
that reveal sensitive internal processing details.

Primary

Architecture and Design
This weakness can be introduced during the architecture and
design phase when the system does not incorporate proper mechanisms
for error reporting or feedback for discarded operations, such as when
handling reserved addresses or unexecuted instructions.

Implementation
It can also arise during implementation if developers fail to
include appropriate feedback or logging for critical operations. This
leads to silent failures in certain scenarios like interrupt handling
or network buffer overflows.

Requirements
A further layer of complexity emerges when considering
specifications. The weakness may stem either from ambiguous product
design specifications that fail to delineate when feedback should
occur or from implementations that do not adhere to existing
requirements. In either case, the result is the same: feedback that is
critical for detecting operational failures or security breaches is
missing.

Confidentiality
Read Memory
Read Files or Directories
Medium
Critical data may be exposed if operations are unexecuted or
discarded silently, allowing attackers to exploit the lack of
feedback.

Integrity
Modify Memory
Modify Files or Directories
Medium
Operations may proceed based on incorrect assumptions,
potentially causing data corruption or incorrect system behavior. In
integrity-sensitive contexts, failing to signal that an operation did
not occur as expected can mask errors that disrupt data
consistency. Without feedback, the mitigation measures that should
ensure updates have been performed cannot be verified, leaving the
system vulnerable to both accidental and malicious data alterations.

Availability
DoS: Resource Consumption (Memory)
DoS: Crash, Exit, or Restart
High
Unhandled discarded operations can lead to resource exhaustion,
triggering system crashes or denial of service. For availability,
consistent feedback is crucial. Without proper notification of
discarded operations, administrators or other authorized entities
might miss early warning signs of resource imbalances. This delayed
detection could allow a DoS condition to develop, compromising the
system's ability to serve legitimate requests and maintain continuous
operations.

Automated Static Analysis - Source Code
Scans code for missing error handling or feedback mechanisms.

High
This identify common issues early in the development phase.

Manual Static Analysis - Source Code
Experts manually inspect the code for unhandled operations.
Moderate
Useful for identifying design-level omissions.

Architecture and Design
Incorporate logging and feedback mechanisms during the
design phase to ensure proper handling of discarded operations.
High
Addressing the issue at the design stage prevents
the weakness from manifesting later.

Implementation
Developers should ensure that every critical operation
includes proper logging or error feedback mechanisms.
Moderate
Implementation-level checks complement
design-phase measures.

This code creates an interrupt handler. If the interrupt's priority
is lower than the currently active one, the interrupt is discarded
without any feedback, perhaps due to resource constraints.

void interrupt_handler(int irq) {

if (irq_priority[irq] < current_priority) {

return;

}
process_interrupt(irq);

}

The omission of feedback for the dropped lower-priority interrupt can
cause developers to misinterpret the state of the system, leading to
incorrect assumptions and potential system failures, such as missed
sensor readings.
Attackers might leverage this lack of visibility to induce conditions
that lead to timing side-channels. For example, an attacker could
intentionally flood the system with high-priority interrupts, forcing
the system to discard lower-priority interrupts consistently. If these
discarded interrupts correspond to processes executing critical
security functions (e.g., cryptographic key handling), an attacker
might measure system timing variations to infer when and how those
functions are executing. This creates a timing side channel that could
be used to extract sensitive information. Moreover, since these
lower-priority interrupts are not reported, the system remains unaware
that critical tasks such as sensor data collection or maintenance
routines, are being starved of execution. Over time, this can lead to
functional failures or watchdog time resets in real-time systems.
One way to address this problem could be to use structured logging to
provide visibility into discarded interrupts. This allows
administrators, developers, or other authorized entities to track
missed interrupts and optimize the system.

// Priority threshold for active interrupts
int current_priority = 3;
// Simulated priority levels for different IRQs
int irq_priority[5] = {1, 2, 3, 4, 5};
void process_interrupt(int irq) {

printf("Processing interrupt %d\n", irq);

}
void interrupt_handler(int irq) {

if (irq_priority[irq] < current_priority) {

// Log the dropped interrupt using structured feedback
fprintf(stderr, "Warning: Interrupt %d dropped (Priority: %d < Current: %d)\n",

irq, irq_priority[irq], current_priority);

exit(EXIT_FAILURE); // Exit with failure status to indicate a critical issue.

}
process_interrupt(irq);

}

Consider a SoC design with these component IPs:
IP 1. Execution Core <--> IP 2 SoC Fabric (NoC, tile etc. ) <--> IP 3 Memory Controller <--> External/ internal memory.
The Core executes operations that trigger transactions that traverse
the HW fabric links to read/write to the final memory module.
There can be unexpected errors in each link. For adding reliability
and redundance, features like ECCs are used in these
transactions. Error correction capabilities have to define how many
error bits can be detected and which errors can be corrected, and
which are uncorrectable errors. In design, often the severity level
and response on different errors is allowed to be configured by system
firmware modules like BIOS.

If an uncorrectable error occurs, the design does not explicitly
trigger an alert back to the execution core.

For system security, if an uncorrectable error occurs but is not
reported to the execution core and handled before the core attempts to
consume the data that is read/written through the corrupted
transactions, then this could enable silent data corruption (SDC)
attacks.
In the case of confidential compute technologies where system firmware
is not a trusted component, error handling controls can be
misconfigured to trigger this weakness and attack the assets protected
by confidential compute.

Modify the design so that any uncorrectable error triggers an alert
back to the execution core and gets handled before the core can
consume the data read/written through the corrupted transactions.
Update design access control policies to ensure that alerts sent to
execution core on uncorrectable errors cannot be disabled or masked by
untrusted software/firmware.

[REF-1468]
Open source silicon root of trust (RoT) product does not immediately report when an integrity check fails for memory requests, causing the product to accept and continue processing data [REF-1468]
https://github.com/lowRISC/opentitan/issues/11336

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Amisha Srivastava
University of Texas at Dallas
2023-12-20
4.17
2025-04-03

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Demonstrative_Examples, Weakness_Ordinalities

Hareesh Khattri
Intel Corporation
2025-03-25
4.17
2025-04-03
Contributed an observed example and a demonstrative example.