CWE-1280 Base Incomplet

Access Control Check Implemented After Asset is Accessed

This vulnerability occurs when a hardware-based security check runs after the protected resource has already been accessed, creating a dangerous timing window.

Définition

What is CWE-1280?

This vulnerability occurs when a hardware-based security check runs after the protected resource has already been accessed, creating a dangerous timing window.
In secure systems, hardware-based access control (like memory or I/O protection) must be verified before any access is granted. This flaw breaks that fundamental rule by allowing the asset to be accessed first, with the permission check happening as a separate, non-atomic step. This creates a critical race condition where an attacker can exploit the gap between access and authorization. For developers, this means the security check is effectively bypassed because the system acts first and asks for permission later. To fix this, the access control verification must be made atomic with the access operation itself, ensuring the check is an inseparable gatekeeper that always completes successfully before any data or hardware resource is exposed.
Impact réel

Real-world CVEs caused by CWE-1280

Aucune référence CVE publique n'est liée à ce CWE dans le catalogue MITRE pour le moment.

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

  1. 1

    Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.

  2. 2

    This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1.

  3. 3

    Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below.

Exemple de code vulnérable

Vulnerable Verilog

Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.

Vulnérable Verilog
module foo_bar(data_out, usr_id, data_in, clk, rst_n);
 output reg [7:0] data_out;
 input wire [2:0] usr_id;
 input wire [7:0] data_in; 
 input wire clk, rst_n;
 wire grant_access;
 always @ (posedge clk or negedge rst_n)
 begin

```
   if (!rst_n)
  	 data_out = 0; 
   else 
  	 data_out = (grant_access) ? data_in : data_out;
  	 assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
 end
 endmodule
Exemple de code sécurisé

Secure Verilog

Flipping the order of the assignment of data_out and grant_access should solve the problem. The correct snippet of code is shown below.

Sécurisé Verilog
always @ (posedge clk or negedge rst_n)
 begin

```
   if (!rst_n)
  	 data_out = 0;
   else
  	 assign grant_access = (usr_id == 3'h4) ? 1'b1 : 1'b0;
  	 data_out = (grant_access) ? data_in : data_out;
 end
 endmodule
What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Liste de contrôle de prévention

How to prevent CWE-1280

  • Implementation Implement the access control check first. Access should only be given to asset if agent is authorized.
Signaux de détection

How to detect CWE-1280

SAST High

Exécuter une analyse statique (SAST) sur le code source à la recherche du motif non sécurisé dans le flux de données.

DAST Moderate

Exécuter des tests de sécurité applicative dynamique (DAST) contre le point de terminaison en ligne.

Runtime Moderate

Surveiller les journaux runtime pour détecter des traces d'exception inhabituelles, des entrées malformées ou des tentatives de contournement d'autorisation.

Code review Moderate

Revue de code : signaler tout nouveau code qui traite les entrées de cette surface sans utiliser les helpers du framework validés.

CWE-1280

Don't catalog this weakness. Prove it's reachable.

Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.

Questions fréquentes

Frequently asked questions

Qu'est-ce que CWE-1280 ?

This vulnerability occurs when a hardware-based security check runs after the protected resource has already been accessed, creating a dangerous timing window.

Quelle est la gravité de CWE-1280 ?

MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.

Quels langages ou plateformes sont affectés par CWE-1280 ?

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

Comment puis-je prévenir CWE-1280 ?

Implement the access control check first. Access should only be given to asset if agent is authorized.

Comment Plexicus détecte et corrige CWE-1280 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-1280 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.

Où puis-je en savoir plus sur CWE-1280 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/1280.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Faiblesses associées

Weaknesses related to CWE-1280

Prêt à valider l'essentiel ?

Prêt à valider ce qui compte.

Plexicus est Proof-Driven AppSec : findings validés, compréhension contextuelle et remédiation relue — ancrée dans la preuve, scopée avec vous.

Qualification

Vérifiez si l'AI Swarm Pentest convient à votre environnement.

Partagez le contexte minimum. Nous vérifierons le périmètre et indiquerons la prochaine étape commerciale.

Avant d'envoyer — vérifiez que vous correspondez

0 / 280

Sans engagement. Si vous ne correspondez pas, nous vous le dirons.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Tour privé Pour les investisseurs