CWE-1311 Base Draft

Improper Translation of Security Attributes by Fabric Bridge

This vulnerability occurs when a hardware bridge incorrectly converts security attributes between different fabric protocols, potentially changing a transaction's identity from trusted to untrusted…

Definition

What is CWE-1311?

This vulnerability occurs when a hardware bridge incorrectly converts security attributes between different fabric protocols, potentially changing a transaction's identity from trusted to untrusted or vice versa during protocol translation.
Hardware systems often integrate components that use different communication protocols (like AHB, AXI, or OCP), requiring bridges to translate between them. These protocols use dedicated signals (such as HPROT, AxPROT, or MReqInfo) to carry critical security metadata—including the initiating controller's hardware identity, privilege level, and transaction type. The bridge must accurately preserve this security context during conversion. When the bridge misinterprets or incorrectly maps these security attributes, it can fundamentally alter a transaction's trust level. An untrusted initiator might be incorrectly labeled as trusted, or vice versa, leading to severe consequences like privilege escalation, access control bypass, or denial of service by allowing unauthorized access to protected system resources.
Real-world impact

Real-world CVEs caused by CWE-1311

No public CVE references are linked to this CWE in MITRE's catalog yet.

How attackers exploit it

Step-by-step attacker path

  1. 1

    Identify a code path that handles untrusted input without validation.

  2. 2

    Craft a payload that exercises the unsafe behavior — injection, traversal, overflow, or logic abuse.

  3. 3

    Deliver the payload through a normal request and observe the application's reaction.

  4. 4

    Iterate until the response leaks data, executes attacker code, or escalates privileges.

Vulnerable code example

Vulnerable Verilog

The bridge interfaces between OCP and AHB end points. OCP uses MReqInfo signal to indicate security attributes, whereas AHB uses HPROT signal to indicate the security attributes. The width of MReqInfo can be customized as needed. In this example, MReqInfo is 5-bits wide and carries the privilege level of the OCP controller. The values 5'h11, 5'h10, 5'h0F, 5'h0D, 5'h0C, 5'h0B, 5'h09, 5'h08, 5'h04, and 5'h02 in MReqInfo indicate that the request is coming from a privileged state of the OCP bus controller. Values 5'h1F, 5'h0E, and 5'h00 indicate untrusted, privilege state. Though HPROT is a 5-bit signal, we only consider the lower, two bits in this example. HPROT values 2'b00 and 2'b10 are considered trusted, and 2'b01 and 2'b11 are considered untrusted. The OCP2AHB bridge is expected to translate trusted identities on the controller side to trusted identities on the responder side. Similarly, it is expected to translate untrusted identities on the controller side to untrusted identities on the responder side.

Vulnerable Verilog 
module ocp2ahb
 ( 

```
   ahb_hprot, 
   ocp_mreqinfo 
 ); 
 output [1:0] ahb_hprot; // output is 2 bit signal for AHB HPROT
 input [4:0] ocp_mreqinfo; // input is 5 bit signal from OCP MReqInfo
 wire [6:0] p0_mreqinfo_o_temp; // OCP signal that transmits hardware identity of bus controller
 wire y;
 reg [1:0] ahb_hprot;
 // hardware identity of bus controller is in bits 5:1 of p0_mreqinfo_o_temp signal
 assign p0_mreqinfo_o_temp[6:0] = {1'b0, ocp_mreqinfo[4:0], y};
 always @*
 begin
   case (p0_mreqinfo_o_temp[4:2])
  	 000: ahb_hprot = 2'b11; // OCP MReqInfo to AHB HPROT mapping
  	 001: ahb_hprot = 2'b00;
  	 010: ahb_hprot = 2'b00;
  	 011: ahb_hprot = 2'b01;
  	 100: ahb_hprot = 2'b00;
  	 101: ahb_hprot = 2'b00;
  	 110: ahb_hprot = 2'b10;
  	 111: ahb_hprot = 2'b00;
   endcase
 end
 endmodule
Secure code example

Secure pseudo

Secure pseudo 
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
  const safe = validateAndEscape(input);
  return executeWithGuards(safe);
}
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-1311

  • Architecture and Design The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.
  • Implementation Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.
Detection signals

How to detect CWE-1311

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-1311 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-1311?

This vulnerability occurs when a hardware bridge incorrectly converts security attributes between different fabric protocols, potentially changing a transaction's identity from trusted to untrusted or vice versa during protocol translation.

How serious is CWE-1311?

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-1311?

MITRE lists the following affected platforms: Verilog, VHDL, Not Technology-Specific.

How can I prevent CWE-1311?

The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa. Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa.

How does Plexicus detect and fix CWE-1311?

Plexicus's SAST engine matches the data-flow signature for CWE-1311 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-1311?

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

Related weaknesses

Weaknesses related to CWE-1311

CWE-284 Parent

Improper Access Control

The software fails to properly limit who can access a resource, allowing unauthorized users or systems to interact with it.

CWE-1191 Sibling

On-Chip Debug and Test Interface With Improper Access Control

This vulnerability occurs when a hardware chip's debug or test interface (like JTAG) lacks proper access controls. Without correct…

CWE-1220 Sibling

Insufficient Granularity of Access Control

This vulnerability occurs when a system's access controls are too broad, allowing unauthorized users or processes to read or modify…

CWE-1224 Sibling

Improper Restriction of Write-Once Bit Fields

This vulnerability occurs when hardware write-once protection mechanisms, often called 'sticky bits,' are incorrectly implemented,…

CWE-1231 Sibling

Improper Prevention of Lock Bit Modification

This vulnerability occurs when hardware or firmware uses a lock bit to protect critical system registers or memory regions, but fails to…

CWE-1233 Sibling

Security-Sensitive Hardware Controls with Missing Lock Bit Protection

This vulnerability occurs when a hardware device uses a lock bit to protect critical configuration registers, but the lock fails to…

CWE-1252 Sibling

CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

This vulnerability occurs when a CPU's hardware is not set up to enforce a strict separation between writing data to memory and executing…

CWE-1257 Sibling

Improper Access Control Applied to Mirrored or Aliased Memory Regions

This vulnerability occurs when a hardware design maps the same physical memory to multiple addresses (aliasing or mirroring) but fails to…

CWE-1259 Sibling

Improper Restriction of Security Token Assignment

This vulnerability occurs when a System-on-a-Chip (SoC) fails to properly secure its Security Token mechanism. These tokens control which…

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.