CWE Reference

The Common Weakness Enumeration (CWE) is a community-developed list of software and hardware weakness types maintained by MITRE. Every SAST finding in ByteHide Radar is mapped to one or more CWE identifiers, providing a standardized classification that helps teams understand, communicate, and track vulnerabilities consistently across tools, teams, and organizations.

What is CWE

CWE provides a unified, measurable set of software weakness types that serves as a common language for describing security vulnerabilities. It is the industry standard used by security tools, compliance frameworks, and organizations worldwide to classify and communicate about software weaknesses.

Each CWE entry includes:

  • A unique identifier (e.g., CWE-79) that unambiguously references the weakness type
  • A descriptive name that summarizes the weakness in plain language
  • A detailed description explaining the weakness, its root cause, and its consequences
  • Relationships to other CWE entries, showing how weaknesses relate to broader categories and more specific variants
  • Common consequences describing the potential impact when the weakness is exploited
  • Potential mitigations providing guidance on how to prevent or remediate the weakness
  • Observed examples referencing real-world CVEs where the weakness was exploited

ByteHide Radar supports the full CWE catalog relevant to application security. The CWE mapping on each finding enables consistent tracking across scans and provides direct links to the authoritative MITRE documentation.

CWE Categories Detected by Radar

The following sections detail the CWE identifiers detected by Radar's SAST engine, organized by vulnerability category. For each CWE, the description, impact, and a representative vulnerable code pattern are provided.

Injection

Injection vulnerabilities occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

CWE-89: SQL Injection

Improper Neutralization of Special Elements used in an SQL Command

SQL injection occurs when user-supplied data is included in SQL queries without proper sanitization or parameterization. An attacker can modify the query logic to read, modify, or delete database contents, bypass authentication, or in some cases execute operating system commands.

Impact: Complete database compromise, unauthorized data access, data modification or deletion, authentication bypass, and in severe cases remote code execution via database features like xp_cmdshell.

Vulnerable pattern:

JavaScript
// Dangerous: user input concatenated into SQL query
const query = "SELECT * FROM users WHERE username = '" + req.body.username + "'";
db.query(query);

Secure pattern:

JavaScript
// Safe: parameterized query
const query = "SELECT * FROM users WHERE username = ?";
db.query(query, [req.body.username]);

CWE-78: OS Command Injection

Improper Neutralization of Special Elements used in an OS Command

Command injection occurs when an application passes user-controlled data to a system shell or command interpreter. Attackers can append additional commands using shell metacharacters like ;, &&, |, or backticks to execute arbitrary commands on the host operating system.

Impact: Full server compromise, arbitrary command execution with the privileges of the application process, data exfiltration, lateral movement within the network.

Vulnerable pattern:

Python
# Dangerous: user input passed to shell command
import os
filename = request.args.get('file')
os.system(f"cat /var/logs/{filename}")

Secure pattern:

Python
# Safe: use subprocess with list arguments (no shell)
import subprocess
filename = request.args.get('file')
# Validate filename first
if not re.match(r'^[a-zA-Z0-9_\-\.]+$', filename):
    abort(400)
subprocess.run(["cat", f"/var/logs/{filename}"], shell=False)

CWE-90: LDAP Injection

Improper Neutralization of Special Elements used in an LDAP Query

LDAP injection occurs when user input is included in LDAP search filters without proper encoding. Attackers can modify the filter logic to bypass authentication, enumerate directory entries, or access unauthorized data within the directory service.

Impact: Authentication bypass, unauthorized access to directory information, user enumeration, privilege escalation within LDAP-based access control systems.

Vulnerable pattern:

Java
// Dangerous: user input in LDAP filter
String filter = "(&(uid=" + username + ")(userPassword=" + password + "))";
NamingEnumeration results = ctx.search("ou=users,dc=example,dc=com", filter, sc);

CWE-917: Expression Language Injection

Improper Neutralization of Special Elements used in an Expression Language Statement

Expression Language (EL) injection occurs when user input is evaluated as part of an expression language statement in frameworks like Spring (SpEL), Struts (OGNL), or JSP (EL). Successful exploitation can lead to remote code execution.

Impact: Remote code execution, server compromise, data exfiltration, denial of service.

Vulnerable pattern:

Java
// Dangerous: user input evaluated as SpEL expression
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression(userInput);
Object result = exp.getValue();

CWE-943: NoSQL Injection

Improper Neutralization of Special Elements in Data Query Logic

NoSQL injection targets non-relational databases like MongoDB, CouchDB, and Cassandra. Attackers exploit query operators passed through unsanitized request bodies to manipulate query logic, bypass authentication, or extract data.

Impact: Authentication bypass, unauthorized data access, data manipulation, denial of service through resource-intensive queries.

Vulnerable pattern:

JavaScript
// Dangerous: request body passed directly to MongoDB query
// An attacker can send { "username": {"$gt": ""}, "password": {"$gt": ""} }
const user = await db.collection('users').findOne({
  username: req.body.username,
  password: req.body.password
});

Cross-Site Scripting

Cross-site scripting vulnerabilities allow attackers to inject malicious scripts into web pages viewed by other users, compromising the victim's session, stealing sensitive data, or performing actions on their behalf.

CWE-79: Cross-Site Scripting (XSS)

Improper Neutralization of Input During Web Page Generation

XSS occurs when an application includes user-controlled data in its HTML output without proper encoding or sanitization. The injected script executes in the victim's browser within the security context of the vulnerable application. Radar detects all three variants: Reflected (input immediately echoed back), Stored (input persisted and served to other users), and DOM-based (client-side script writes untrusted data to the DOM).

Impact: Session hijacking via cookie theft, credential harvesting through fake login forms, keylogging, phishing, defacement, and malware distribution.

Vulnerable pattern:

Python
# Dangerous: user input rendered without encoding
@app.route('/search')
def search():
    query = request.args.get('q', '')
    return f"<h1>Results for: {query}</h1>"

Secure pattern:

Python
# Safe: use template engine with auto-escaping
@app.route('/search')
def search():
    query = request.args.get('q', '')
    return render_template('search.html', query=query)

Deserialization

Deserialization vulnerabilities occur when applications reconstruct objects from serialized data provided by untrusted sources without validating the object types or contents.

CWE-502: Deserialization of Untrusted Data

Deserialization of Untrusted Data

Insecure deserialization occurs when an application deserializes data from an untrusted source without proper validation. Depending on the language and serialization format, this can lead to remote code execution, denial of service, or authentication bypass. The risk is particularly severe in languages like Java, Python, PHP, and C# where deserialization can trigger arbitrary method calls.

Impact: Remote code execution through gadget chains, denial of service, authentication bypass, arbitrary file operations.

Vulnerable patterns by language:

C#
// C# - Dangerous: BinaryFormatter with untrusted data
BinaryFormatter formatter = new BinaryFormatter();
object obj = formatter.Deserialize(networkStream); // RCE risk
Python
# Python - Dangerous: pickle with untrusted data
import pickle
data = pickle.loads(request.body)  # RCE risk
Java
// Java - Dangerous: ObjectInputStream with untrusted data
ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
Object obj = ois.readObject(); // RCE risk via gadget chains

Path Traversal

Path traversal vulnerabilities allow attackers to access files and directories outside the intended scope by manipulating file paths.

CWE-22: Path Traversal

Improper Limitation of a Pathname to a Restricted Directory

Path traversal occurs when an application uses user-supplied input to construct file system paths without properly validating that the resulting path stays within the intended directory. Attackers use sequences like ../ or encoded equivalents to escape the base directory and access arbitrary files on the server.

Impact: Reading sensitive files (configuration files, source code, credentials), writing to arbitrary locations (web shells, cron jobs), and in some cases achieving remote code execution.

Vulnerable pattern:

Go
// Dangerous: user input in file path without validation
func handler(w http.ResponseWriter, r *http.Request) {
    filename := r.URL.Query().Get("file")
    data, err := os.ReadFile("/var/uploads/" + filename)
    // Attacker sends ?file=../../../etc/passwd
}

Secure pattern:

Go
// Safe: validate path stays within base directory
func handler(w http.ResponseWriter, r *http.Request) {
    filename := r.URL.Query().Get("file")
    cleanPath := filepath.Clean(filename)
    fullPath := filepath.Join("/var/uploads", cleanPath)
    if !strings.HasPrefix(fullPath, "/var/uploads/") {
        http.Error(w, "Invalid path", http.StatusBadRequest)
        return
    }
    data, err := os.ReadFile(fullPath)
}

Server-Side Request Forgery

SSRF vulnerabilities allow attackers to induce the server-side application to make HTTP requests to arbitrary destinations.

CWE-918: Server-Side Request Forgery (SSRF)

Server-Side Request Forgery

SSRF occurs when an application makes HTTP requests to a URL that is fully or partially controlled by the attacker. This can be exploited to access internal services that are not directly accessible from the internet, read cloud metadata endpoints, scan internal networks, or bypass firewall restrictions.

Impact: Access to internal services and APIs, cloud credential theft via metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254), internal network scanning, bypass of network access controls, data exfiltration from internal systems.

Vulnerable pattern:

JavaScript
// Dangerous: user-controlled URL in server-side request
app.get('/fetch', async (req, res) => {
  const url = req.query.url;
  const response = await fetch(url); // Attacker sends internal URLs
  const data = await response.text();
  res.send(data);
});

Secure pattern:

JavaScript
// Safe: validate URL against allowlist
const ALLOWED_HOSTS = ['api.example.com', 'cdn.example.com'];
app.get('/fetch', async (req, res) => {
  const url = new URL(req.query.url);
  if (!ALLOWED_HOSTS.includes(url.hostname)) {
    return res.status(400).send('URL not allowed');
  }
  // Also block private IP ranges
  const response = await fetch(url.toString());
  const data = await response.text();
  res.send(data);
});

Cryptographic Issues

Cryptographic weaknesses undermine the confidentiality and integrity protections that applications rely on to secure sensitive data.

CWE-327: Use of a Broken or Risky Cryptographic Algorithm

Use of a Broken or Risky Cryptographic Algorithm

This weakness occurs when an application uses cryptographic algorithms that are known to be broken or insufficient for the required security level. Algorithms like MD5 and SHA1 for hashing, or DES and RC4 for encryption, have known vulnerabilities that allow attackers to reverse the protection they provide.

Impact: Data confidentiality breach through decryption of encrypted data, integrity bypass through hash collision attacks, credential compromise through rainbow table attacks on weak hashes.

Vulnerable patterns:

Java
// Dangerous: MD5 for password hashing
MessageDigest md = MessageDigest.getInstance("MD5");
byte[] hash = md.digest(password.getBytes());
Python
# Dangerous: DES for encryption
from Crypto.Cipher import DES
cipher = DES.new(key, DES.MODE_ECB)

Recommended alternatives: Use SHA-256 or SHA-3 for hashing. Use bcrypt, scrypt, or Argon2 for password hashing. Use AES-256-GCM for encryption.

CWE-330: Use of Insufficiently Random Values

Use of Insufficiently Random Values

This weakness occurs when an application uses non-cryptographic random number generators for security-sensitive operations. Functions like Math.random() (JavaScript), java.util.Random (Java), or rand() (PHP) produce predictable sequences that an attacker can reproduce, compromising any security mechanism that relies on their output.

Impact: Predictable session tokens, guessable password reset tokens, bypassable CSRF tokens, weak cryptographic keys.

Vulnerable pattern:

JavaScript
// Dangerous: Math.random() for security token
const token = Math.random().toString(36).substring(2);

Secure pattern:

JavaScript
// Safe: cryptographic random
const crypto = require('crypto');
const token = crypto.randomBytes(32).toString('hex');

CWE-798: Use of Hard-coded Credentials

Use of Hard-coded Credentials

Hardcoded credentials occur when passwords, API keys, tokens, or other authentication secrets are embedded directly in source code. Since source code is often stored in version control systems and may be accessible to many developers, contractors, or even publicly, hardcoded credentials are easily discovered and exploited.

Impact: Unauthorized access to external services, databases, or APIs. Credentials in version control history persist even after removal from the current codebase. Shared credentials across environments (development, staging, production) amplify the blast radius.

Vulnerable pattern:

Python
# Dangerous: hardcoded database password
DB_PASSWORD = "super_secret_password_123"
connection = psycopg2.connect(
    host="db.example.com",
    password=DB_PASSWORD
)

Access Control

Access control weaknesses allow users to act outside their intended permissions, leading to unauthorized data access, functionality use, or privilege escalation.

CWE-862: Missing Authorization

Missing Authorization

This weakness occurs when an application does not perform an authorization check before granting access to a resource or functionality. Any authenticated user (or in some cases, unauthenticated users) can access protected operations by directly requesting the corresponding URL or API endpoint.

Impact: Unauthorized access to administrative functionality, data belonging to other users, or operations that should be restricted to specific roles.

Vulnerable pattern:

Python
# Dangerous: no authorization check
@app.route('/admin/delete-user/<user_id>', methods=['POST'])
def delete_user(user_id):
    # Any authenticated user can delete any other user
    db.users.delete(user_id)
    return jsonify({"status": "deleted"})

CWE-863: Incorrect Authorization

Incorrect Authorization

This weakness occurs when an authorization check is present but implemented incorrectly, allowing it to be bypassed. This can happen due to logic errors in permission checks, incorrect role comparisons, or flawed conditional statements.

Impact: Privilege escalation, access to resources belonging to other users, bypass of business logic restrictions.

CWE-639: Authorization Bypass Through User-Controlled Key

Authorization Bypass Through User-Controlled Key (IDOR)

Insecure Direct Object Reference (IDOR) occurs when an application uses user-supplied input (such as a database ID, filename, or key) to directly access objects without verifying that the user is authorized to access the specific object. Attackers can enumerate or modify the key to access resources belonging to other users.

Impact: Unauthorized access to other users' data, modification of other users' resources, horizontal privilege escalation.

Vulnerable pattern:

JavaScript
// Dangerous: IDOR - no ownership check
app.get('/api/invoices/:id', (req, res) => {
  const invoice = db.invoices.findById(req.params.id);
  // Any user can access any invoice by changing the ID
  res.json(invoice);
});

Secure pattern:

JavaScript
// Safe: verify ownership
app.get('/api/invoices/:id', (req, res) => {
  const invoice = db.invoices.findOne({
    _id: req.params.id,
    userId: req.user.id  // Scope to current user
  });
  if (!invoice) return res.status(404).send('Not found');
  res.json(invoice);
});

XML

XML processing vulnerabilities arise from unsafe configuration of XML parsers, allowing attackers to exploit features of the XML specification for malicious purposes.

CWE-611: Improper Restriction of XML External Entity Reference (XXE)

Improper Restriction of XML External Entity Reference

XXE occurs when an XML parser is configured to process external entity declarations in the document type definition (DTD). Attackers can craft XML documents that reference external resources, allowing them to read local files, perform SSRF, or cause denial of service through recursive entity expansion (the "Billion Laughs" attack).

Impact: Reading arbitrary files from the server (including /etc/passwd, configuration files, and source code), SSRF to internal services, denial of service, and in some configurations remote code execution.

Vulnerable pattern:

Java
// Dangerous: XML parser with default settings (external entities enabled)
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(userInputStream);

Secure pattern:

Java
// Safe: disable external entities and DTDs
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(userInputStream);

Prototype Pollution

Prototype pollution is a JavaScript-specific vulnerability category that targets the language's prototype-based inheritance system.

CWE-1321: Improperly Controlled Modification of Object Prototype Attributes

Improperly Controlled Modification of Object Prototype Attributes

Prototype pollution occurs when an attacker can inject properties into JavaScript's Object.prototype (or other built-in prototypes) through unsafe object merging or property assignment operations. Once the prototype is polluted, the injected properties are inherited by all objects in the application, potentially affecting security-critical logic.

Impact: Denial of service, property injection affecting access control decisions, bypassing input validation, and in some cases remote code execution when combined with server-side template engines or other code evaluation mechanisms.

Vulnerable pattern:

JavaScript
// Dangerous: recursive merge without prototype check
function merge(target, source) {
  for (let key in source) {
    if (typeof source[key] === 'object') {
      target[key] = target[key] || {};
      merge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
}
// Attacker sends: {"__proto__": {"isAdmin": true}}
merge({}, JSON.parse(userInput));

Secure pattern:

JavaScript
// Safe: check for prototype pollution keys
function safeMerge(target, source) {
  for (let key in source) {
    if (key === '__proto__' || key === 'constructor' || key === 'prototype') {
      continue; // Skip dangerous keys
    }
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = target[key] || {};
      safeMerge(target[key], source[key]);
    } else {
      target[key] = source[key];
    }
  }
}

Other Weaknesses

Additional weakness types detected by Radar that do not fall neatly into the categories above.

CWE-94: Improper Control of Generation of Code (Code Injection)

Code Injection

Code injection occurs when user-controlled data is passed to functions that evaluate or execute code at runtime, such as eval(), Function() constructors, or template engines with code execution capabilities.

Impact: Remote code execution, full server compromise, data exfiltration.

Vulnerable pattern:

JavaScript
// Dangerous: eval with user input
app.post('/calculate', (req, res) => {
  const result = eval(req.body.expression); // RCE
  res.json({ result });
});

CWE-352: Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery

CSRF occurs when a web application does not verify that a state-changing request was intentionally submitted by the authenticated user. An attacker can create a malicious web page that submits requests to the vulnerable application using the victim's session cookies, causing unintended actions like changing passwords, transferring funds, or modifying account settings.

Impact: Unauthorized state changes on behalf of authenticated users, account takeover when combined with password change functionality, financial transactions.

Vulnerable pattern:

Python
# Dangerous: state-changing endpoint without CSRF protection
@app.route('/transfer', methods=['POST'])
def transfer():
    amount = request.form['amount']
    to_account = request.form['to']
    # No CSRF token validation
    process_transfer(current_user, to_account, amount)

CWE-1333: Inefficient Regular Expression Complexity (ReDoS)

Inefficient Regular Expression Complexity

Regular Expression Denial of Service (ReDoS) occurs when an application uses regular expressions with patterns that exhibit exponential backtracking behavior. When a crafted input string is matched against such a pattern, the regex engine can consume excessive CPU time, effectively causing a denial of service.

Impact: Application hangs or becomes unresponsive, CPU exhaustion, denial of service for all users of the affected application.

Vulnerable pattern:

JavaScript
// Dangerous: regex with catastrophic backtracking
const emailRegex = /^([a-zA-Z0-9]+)*@example\.com$/;
// Input like "aaaaaaaaaaaaaaaaaaaaaaaaaaaa!" causes exponential backtracking
emailRegex.test(userInput);

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Information Exposure

This weakness occurs when an application reveals sensitive information to users who are not authorized to see it. This includes stack traces, database error messages, internal file paths, server versions, or debugging information exposed in production environments.

Impact: Information disclosure aids attackers in crafting targeted exploits, reveals internal architecture and technology stack, may expose credentials or configuration details.

CWE-209: Generation of Error Message Containing Sensitive Information

Sensitive Information in Error Messages

A more specific form of CWE-200, this weakness occurs when error messages include sensitive data such as SQL query fragments, file system paths, stack traces with source code references, or configuration values. These details are valuable to attackers during reconnaissance.

Impact: Exposure of internal implementation details, database schema information, file system structure, and potentially credentials or tokens included in error context.

Vulnerable pattern:

Python
# Dangerous: detailed error returned to user
@app.errorhandler(Exception)
def handle_error(e):
    return jsonify({
        "error": str(e),
        "traceback": traceback.format_exc()  # Exposes internals
    }), 500

How Radar Maps CWEs

Each SAST finding in Radar includes one or more CWE identifiers, visible as clickable badges in the finding detail panel. The CWE mapping works as follows:

  1. Detection - when Radar's analysis engine identifies a vulnerability pattern, it determines which CWE best describes the weakness
  2. Classification - the finding is tagged with the primary CWE identifier and any related secondary CWEs
  3. Display - CWE badges appear in the finding detail panel's General tab, alongside the OWASP Top 10 mapping
  4. Filtering - use the CWE filter in the SAST tab to find all instances of a specific weakness type across your codebase

CWE identifiers link directly to the MITRE CWE database, where you can access the full description, related weaknesses, and additional references for each identifier.

ByteHide Radar SAST finding detail showing CWE-22 and OWASP A01:2021 badges with confidence score and Create PR to fix buttonClick to expand

Continuously Expanding Coverage

For the complete and up-to-date CWE catalog, visit MITRE CWE. Radar's detection capabilities are continuously expanded with new CWE coverage as new weakness types emerge and existing detection rules are refined.

Next Steps

OWASP Top 10

How Radar maps findings to OWASP Top 10 categories.

View SAST Findings

Navigate and filter findings using CWE filters.

Triage and Remediation

Review, prioritize, and resolve SAST findings.

Previous
Triage and Remediation
Next
Overview