CWE-1290 describes a decoder that gets its job wrong. In a System-on-Chip (SoC), hardware engines send transactions to read, write, reset, fetch or compute. Some of those transactions carry a security identifier, and a decoder turns bus signals into that identifier so the destination knows what the sender may do. If the decoding is incorrect, an untrusted agent can end up with access to an asset it was never meant to touch.
This one lives with chip designers and verification teams, but the pattern will feel familiar to anyone who has watched an authorization check trust the wrong field.
How it happens
Every transaction on the bus has a source identity and a destination identity. Many also carry a security identifier. The destination agent uses it to pick the set of allowed actions, for example whether a read or write to an asset is permitted.
The decoder sits in the middle. It maps the bus-transaction signals to the security identifier. The weakness appears when that mapping is wrong, so that an untrusted agent's identifier is decoded into a trusted agent's identifier. Everything downstream then behaves correctly according to a wrong input.
What an attacker gains
MITRE lists a wide set of consequences, rated high likelihood: reading and modifying memory, executing unauthorized code or commands, gaining privileges or assuming another identity, bypassing access control, and resource-consumption denial of service. Quality degradation is also listed.
In plain terms, an agent that should be locked out acts with the privileges of one that is trusted.
How to find it
The record has no listed detection methods, so the practical route is the one the mitigations point to. Review the decoder design for inconsistencies, then test the access and programming flows. Useful checks include:
- Enumerate every security identifier the decoder can output and confirm each maps from exactly the sources intended.
- Send transactions from an untrusted agent and confirm none decode to a trusted identity.
- Run those same flows after silicon is back, not only in simulation.
How to fix it
MITRE gives two steps. In architecture and design, review security identifier decoders for design consistency and common weaknesses. In implementation, test access and programming flows in both pre-silicon and post-silicon testing.
Treat the decoder as a security boundary with its own test plan, not as plumbing.
Quick check
What does the decoder in CWE-1290 produce?
A security identifier derived from bus-transaction signals. The destination agent relies on it to decide which actions are allowed.
Is simulation enough to catch it?
MITRE calls for testing in both pre-silicon and post-silicon stages, so simulation alone is not the recommended end point.
