LiveActive security incident?Get immediate response
CWE Reference

CWE-365: DEPRECATED: Race Condition in Switch | Glexia

CWE-365 (DEPRECATED: Race Condition in Switch) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.

Release 4.20weaknessDeprecated

Glexia's Take · Automated analysis

CWE-365: DEPRECATED: Race Condition in Switch

DEPRECATED: Race Condition in Switch represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.

Executive Impact

  • Security incident exposure
  • Service disruption
  • Compliance and remediation cost

Developer Pattern

CWE-365 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.

Automation confidence

high confidence from CWE-365, 4.20.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official CWE Definition

CWE-365: DEPRECATED: Race Condition in Switch

This entry has been deprecated. There are no documented cases in which a switch's control expression is evaluated more than once.

It is likely that this entry was initially created based on a misinterpretation of the original source material. The original source intended to explain how switches could be unpredictable when using threads, if the control expressions used data or variables that could change between execution of different threads. That weakness is already covered by CWE-367. Despite the ambiguity in the documentation for some languages and compilers, in practice, they all evaluate the switch control expression only once. If future languages state that the code explicitly evaluates the control expression more than once, then this would not be a weakness, but the language performing as designed.

Type
weakness
Abstraction
Base
Status
Deprecated
Source
MITRE CWE definition

Developer And Remediation Guidance

How teams prevent and detect this weakness

Causes

  • Missing validation
  • Unsafe defaults
  • Insufficient authorization or memory-safety invariant

Remediation

  • Use safe APIs
  • Centralize the control
  • Add regression tests
  • Review logs and telemetry for attempted abuse

Detection

  • Code review
  • SAST
  • DAST
  • Focused regression tests

Mappings

Related CVEs, CWEs, and ATT&CK context

Related CWEs

No related CWE relationships are published yet.

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

Open CWE CVE mapping

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.