CWE-440 Base Draft

Expected Behavior Violation

This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's actual behavior deviates from its promised specification,…

Definition

What is CWE-440?

This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's actual behavior deviates from its promised specification, leading to unpredictable results.
At its core, this violation is a trust issue between the developer and the component's interface. When you call a function or use an API, you rely on its documented contract—what inputs it accepts, what processing it performs, and what outputs or side effects it guarantees. If the component silently breaks this contract, your application logic can fail, security assumptions can be invalidated, and the entire system's stability is compromised. This often stems from ambiguous documentation, implementation bugs, or unintended side effects that the spec didn't account for. For developers, mitigating this requires a proactive approach. First, treat specifications as critical requirements, not suggestions. Implement rigorous input validation and error handling even for 'trusted' components. Second, employ defensive programming practices: write comprehensive unit and integration tests that verify both the happy path and edge cases against the documented behavior. Fuzz testing can be particularly effective in uncovering unexpected behaviors. Finally, when designing your own APIs, ensure your specifications are precise, complete, and tested, as unclear docs are a primary cause of downstream violations.
Real-world impact

Real-world CVEs caused by CWE-440

  • CVE-2003-0187

    Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations.

  • CVE-2003-0465

    "strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error?

  • CVE-2005-3265

    Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.

How attackers exploit it

Step-by-step attacker path

  1. 1

    The provided code is extracted from the Control and Status Register (CSR), csr_regfile, module within the Hack@DAC'21 OpenPiton System-on-Chip (SoC). This module is designed to implement CSR registers in accordance with the RISC-V specification. The mie (machine interrupt enable) register is a 64-bit register [REF-1384], where bits correspond to different interrupt sources. As the name suggests, mie is a machine-level register that determines which interrupts are enabled. Note that in the example below the mie_q and mie_d registers represent the conceptual mie reigster in the RISC-V specification. The mie_d register is the value to be stored in the mie register while the mie_q register holds the current value of the mie register [REF-1385].

  2. 2

    The mideleg (machine interrupt delegation) register, also 64-bit wide, enables the delegation of specific interrupt sources from machine privilege mode to lower privilege levels. By setting specific bits in the mideleg register, the handling of certain interrupts can be delegated to lower privilege levels without engaging the machine-level privilege mode. For example, in supervisor mode, the mie register is limited to a specific register called the sie (supervisor interrupt enable) register. If delegated, an interrupt becomes visible in the sip (supervisor interrupt pending) register and can be enabled or blocked using the sie register. If no delegation occurs, the related bits in sip and sie are set to zero.

  3. 3

    The sie register value is computed based on the current value of mie register, i.e., mie_q, and the mideleg register.

  4. 4

    The above code snippet illustrates an instance of a vulnerable implementation of the sie register update logic, where users can tamper with the mie_d register value through the utval (user trap value) register. This behavior violates the RISC-V specification.

  5. 5

    The code shows that the value of utval, among other signals, is used in updating the mie_d value within the sie update logic. While utval is a register accessible to users, it should not influence or compromise the integrity of sie. Through manipulation of the utval register, it becomes feasible to manipulate the sie register's value. This opens the door for potential attacks, as an adversary can gain control over or corrupt the sie value. Consequently, such manipulation empowers an attacker to enable or disable critical supervisor-level interrupts, resulting in various security risks such as privilege escalation or denial-of-service attacks.

Vulnerable code example

Vulnerable Verilog

The sie register value is computed based on the current value of mie register, i.e., mie_q, and the mideleg register.

Vulnerable Verilog 
module csr_regfile #(...)(...);
 ...
 // ---------------------------
 // CSR Write and update logic
 // ---------------------------
 ...

```
   if (csr_we) begin
  	 unique case (csr_addr.address)
  	 ...
  		 riscv::CSR_SIE: begin
  			 // the mideleg makes sure only delegate-able register
  			 //(and therefore also only implemented registers) are written
```
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q) | utval_q;** 
  			 end
  		 ...
  		 endcase
  	 end
   endmodule
Secure code example

Secure Verilog

A fix to this issue is to remove the utval from the right-hand side of the assignment. That is the value of the mie_d should be updated as shown in the good code example [REF-1386].

Secure Verilog 
module csr_regfile #(...)(...);
 ...
 // ---------------------------
 // CSR Write and update logic
 // ---------------------------
 ...

```
   if (csr_we) begin
  	 unique case (csr_addr.address)
  	 ...
  		 riscv::CSR_SIE: begin
  			 // the mideleg makes sure only delegate-able register
  			 //(and therefore also only implemented registers) are written
```
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q);** 
  			 end
  		 ...
  		 endcase
  	 end
   endmodule
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist

How to prevent CWE-440

  • Architecture Use safe-by-default frameworks and APIs that prevent the unsafe pattern from being expressible.
  • Implementation Validate input at trust boundaries; use allowlists, not denylists.
  • Implementation Apply the principle of least privilege to credentials, file paths, and runtime permissions.
  • Testing Cover this weakness in CI: SAST rules + targeted unit tests for the data flow.
  • Operation Monitor logs for the runtime signals listed in the next section.
Detection signals

How to detect CWE-440

SAST High

Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.

DAST Moderate

Run dynamic application security testing against the live endpoint.

Runtime Moderate

Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.

Code review Moderate

Code review: flag any new code that handles input from this surface without using the validated framework helpers.

Plexicus auto-fix

Plexicus auto-detects CWE-440 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Get a demo Try Plexicus free
Frequently asked questions

Frequently asked questions

What is CWE-440?

This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's actual behavior deviates from its promised specification, leading to unpredictable results.

How serious is CWE-440?

MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.

What languages or platforms are affected by CWE-440?

MITRE lists the following affected platforms: ICS/OT.

How can I prevent CWE-440?

Use safe-by-default frameworks, validate untrusted input at trust boundaries, and apply the principle of least privilege. Cover the data-flow signature in CI with SAST.

How does Plexicus detect and fix CWE-440?

Plexicus's SAST engine matches the data-flow signature for CWE-440 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-440?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/440.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-440

CWE-684 Parent

Incorrect Provision of Specified Functionality

This weakness occurs when software behaves differently than its documented specifications, which can mislead users and create security…

CWE-1245 Sibling

Improper Finite State Machines (FSMs) in Hardware Logic

This vulnerability occurs when hardware logic contains flawed Finite State Machines (FSMs). Attackers can exploit these design errors to…

CWE-392 Sibling

Missing Report of Error Condition

This vulnerability occurs when a system fails to properly signal that an error has happened. Instead of returning a clear error code,…

CWE-393 Sibling

Return of Wrong Status Code

This vulnerability occurs when a function returns an inaccurate status code or value that misrepresents the actual outcome of an…

CWE-446 Sibling

UI Discrepancy for Security Feature

This vulnerability occurs when a user interface incorrectly displays a security feature as active or properly configured, misleading users…

CWE-451 Sibling

User Interface (UI) Misrepresentation of Critical Information

This vulnerability occurs when a user interface fails to accurately display or highlight crucial information, potentially misleading users…

CWE-912 Sibling

Hidden Functionality

Hidden functionality refers to undocumented features, commands, or code within a product that are not part of its official specification…

CWE-1434 Child

Insecure Setting of Generative AI/ML Model Inference Parameters

This vulnerability occurs when a generative AI or ML model is deployed with inference parameters that are too permissive, causing it to…

Resources

Further reading

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.