CWE-1267 covers a product that implements access controls with an encoding mechanism that is no longer trusted. It is a hardware design weakness, mostly relevant to teams building System-on-a-Chip (SoC) designs.
How it happens
Inside an SoC, circuits and engines generate transactions to read, write, reset, fetch or compute. Each transaction carries a source identity and a destination identity. Sometimes it also carries a security token, which helps the destination decide what actions are allowed.
A policy encoder maps bus transactions to those tokens, and the tokens act as the access control. The weakness is using an encoding for that job that is obsolete, meaning it is no longer trusted as a protection mechanism.
What an attacker gains
The recorded consequences are broad and rated high: reading and modifying memory, reading and modifying files, executing unauthorized code or commands, gaining privileges, bypassing protection, and causing denial of service through resource consumption or reduced reliability.
How to find it
The record lists no detection methods. In practice, review the policy encoder design and list every encoding it relies on. Check each against the current expectations of your security team and the standards your design follows, and flag any that have been retired.
How to fix it
The record gives no mitigation text, but the definition points to the remedy.
- Inventory the encodings used for security tokens and access policies.
- Replace any obsolete encoding with one that is currently trusted.
- Re-run access control verification after the change, since tokens drive every protection decision downstream.
Quick check
Why does the encoding matter if the policy logic is correct?
The policy decides what is allowed, but the encoding is how that decision is carried and enforced. If the encoding is no longer trusted, the correct policy rides on a weak foundation.
