Security Vulnerability Database

A critical vulnerability where attackers can write files to arbitrary locations on the file system by controlling file paths in Node.js file operations. This can lead to overwriting critical system files, configuration files, or placing malicious files in web-accessible directories, potentially resulting in remote code execution, privilege escalation, or complete system compromise.

A critical security vulnerability where AWS access keys, secret access keys, session tokens, and other cloud credentials are hardcoded in Python configuration files, source code, or accidentally exposed through version control systems. This exposure allows unauthorized access to AWS resources, potential data breaches, and can lead to significant financial costs from resource abuse.

A significant availability and data integrity vulnerability where Amazon DynamoDB tables are configured without Point-in-Time Recovery (PITR), leaving the database vulnerable to permanent data loss from accidental deletions, corruption, or malicious attacks. Without PITR, there is no way to restore table data to any point within the last 35 days, making data recovery impossible after destructive operations. This can result in business continuity issues, compliance violations, and permanent loss of critical application data.

A critical authentication vulnerability where Amazon ElastiCache Redis clusters are configured without authentication tokens (AUTH), allowing unauthorized access to cached data. This enables attackers who gain network access to execute Redis commands, read sensitive cached information, modify application state, and potentially disrupt service operations. Without authentication, Redis clusters are vulnerable to unauthorized data access, cache poisoning, and command injection attacks.

A critical security vulnerability where Amazon ElastiCache Redis clusters are configured without at-rest encryption, leaving cached data, snapshots, and backups unprotected. This exposes sensitive application data stored in Redis including session tokens, user data, application state, and cached database queries to unauthorized access if storage systems are compromised. Without encryption, data remains in plaintext during disk operations, memory swaps, and backup storage to S3.

A critical authorization vulnerability where IAM policies grant permissions using wildcard (*) resources instead of specific ARNs, creating overly broad access that violates the principle of least privilege. This allows principals to perform actions on unintended resources across the entire AWS account, enabling privilege escalation, unauthorized data access, and potential account compromise. Wildcard resources in IAM policies can lead to unintended permissions that allow access to sensitive resources, cross-service privilege escalation, and compliance violations.

A critical availability vulnerability where Amazon RDS database instances are configured without deletion protection, making them vulnerable to accidental or malicious deletion. This can result in permanent data loss, business disruption, and costly recovery efforts. Without deletion protection, RDS instances can be deleted through the console, CLI, or API calls without additional safeguards, potentially causing irreversible damage to production databases containing critical business data.

A critical security vulnerability where Amazon S3 buckets or AWS accounts are configured without Block Public Access settings, allowing potential public exposure of sensitive data through bucket policies, ACLs, or access points. This creates a significant risk of data breaches, unauthorized access, and compliance violations when bucket policies or ACLs inadvertently grant public access to private data. Without Block Public Access controls, misconfigurations can expose entire buckets containing sensitive business data, personal information, or confidential documents to the internet.

A critical security vulnerability where Amazon SQS queues are configured without server-side encryption, leaving sensitive message data unprotected at rest. This exposes message contents, metadata, and potentially sensitive application data to unauthorized access if AWS storage systems are compromised or accessed improperly. SQS messages may contain authentication tokens, personal information, financial data, or business-critical information that requires encryption protection.

A medium-severity security vulnerability where C code uses atoi, atol, or atoll functions that lack error reporting and can overflow or misparse input, yielding undefined behavior and incorrect values. These functions can't distinguish between legitimate zero values and parsing errors, and they don't detect integer overflow conditions. When these incorrect values propagate into logic, size computations, or security checks, they can enable buffer overflows, logic bypass, authentication bypass, or information disclosure attacks.

Double free vulnerabilities occur when the same dynamically allocated memory pointer is freed twice without being reset or having clear ownership. This can corrupt the heap allocator's internal structures, leading to crashes, memory corruption, and potentially enabling remote code execution through heap exploitation techniques.

A critical memory safety vulnerability where C/C++ code passes previously freed pointers to functions, creating use-after-free conditions that can enable memory corruption, crashes, data corruption, or remote code execution. When an attacker can influence heap layout and reuse the freed memory, they may be able to control program execution flow or corrupt critical data structures, leading to arbitrary code execution or privilege escalation.

Remote code execution (RCE) is possible if attackers overflow buffers using gets(), hijack control flow, and execute arbitrary code. The gets() function reads input without bounds checking, allowing buffer overflows that can overwrite return addresses and other critical memory. Denial of service and data corruption are also likely.

Format string vulnerabilities occur when user-controlled input is used directly as the format string in printf-family functions. This allows attackers to read arbitrary memory, write to arbitrary memory locations, and potentially achieve remote code execution by exploiting format specifiers like %x, %n, and %s.

A critical memory safety vulnerability where C code uses scanf family functions with unbounded format specifiers like %s without width limits, enabling stack buffer overflow attacks. When scanf reads input without enforcing buffer boundaries, attackers can provide input larger than the allocated buffer, overwriting adjacent memory including return addresses, function pointers, and other critical data structures. This can lead to arbitrary code execution, privilege escalation, or complete system compromise.

A critical memory safety vulnerability where C code uses strcat or strncat functions without ensuring destination buffer size and remaining capacity, enabling buffer overflow attacks. These functions append strings without bounds checking, allowing attackers to write past buffer boundaries when the combined length of destination and source strings exceeds the allocated buffer size. This can lead to stack corruption, arbitrary code execution, denial of service, or complete system compromise.

A critical denial of service vulnerability where C code reads from OS random devices (/dev/random or /dev/urandom) without properly checking return values or handling errors. This can lead to file descriptor exhaustion, resource leaks, and application hangs when random data generation fails. Unchecked read() operations on random devices can cause unpredictable behavior, partial data reads, and system resource depletion under error conditions.

Use-after-free vulnerabilities occur when code dereferences a pointer after the memory it points to has been freed. This can enable memory corruption, crashes, data corruption, or remote code execution when freed memory is reallocated and controlled by an attacker. The dangling pointer may point to reclaimed memory containing attacker-controlled data.

Ansible apt tasks configured with force: yes bypass signature validation and downgrade protections, allowing installation of untrusted, tampered, or malicious packages. This creates a critical attack vector where malicious actors can compromise hosts by injecting tampered packages that execute arbitrary code during installation or runtime, leading to full system compromise and persistent attacker control.

Information disclosure: Public users can read bucket objects, exposing sensitive data and enabling unauthorized data harvesting and reconnaissance.

Remote code execution (RCE) could let attackers brute-force or exploit SSH to gain server control, pivot within the VPC, and exfiltrate data.

A critical security vulnerability where Amazon SQS queues are configured without server-side encryption, leaving sensitive message data unprotected at rest. This security check specifically identifies SQS queues that lack KMS-backed encryption configuration, exposing message contents to unauthorized access if AWS storage systems are compromised. SQS messages often contain authentication tokens, personal information, financial data, or business-critical information that requires encryption protection according to compliance standards.

A critical availability and data protection vulnerability where Amazon DynamoDB tables are created without Point-in-Time Recovery (PITR) enabled. This leaves databases vulnerable to permanent data loss from accidental deletions, malicious attacks, or application bugs. Without PITR, there is no continuous backup mechanism to restore data to any point within the retention period, making it impossible to recover from destructive changes or corruption.

AWS ElastiCache Redis clusters configured without at-rest encryption leave cached data and backup files unprotected on disk. This exposes sensitive cached information including session data, authentication tokens, user profiles, and business-critical data to unauthorized access if storage systems are compromised, lost, or improperly decommissioned.

AWS RDS database instances configured without deletion protection can be accidentally or maliciously deleted, causing permanent data loss and service disruption. Without this safeguard, a single API call or console action can immediately destroy production databases and all their data, with no recovery option beyond point-in-time restore from backups.

A critical authentication vulnerability where Amazon ElastiCache Redis clusters are configured without Redis AUTH tokens, allowing unauthenticated access to cached data. This leaves sensitive cached information including session data, authentication tokens, user profiles, and business-critical data accessible to anyone who can reach the Redis cluster through network connectivity. Without AUTH protection, attackers who gain network access can execute arbitrary Redis commands and access all cached data.

AWS IAM policies that use wildcard (*) in the Resource field for actions that support resource-level permissions create overly broad access that can lead to unauthorized operations across all AWS resources. This violates the principle of least privilege and enables potential authorization bypasses.

A critical security vulnerability where Amazon S3 Block Public Access settings are not configured to restrict public bucket policies. This leaves S3 buckets vulnerable to accidental or malicious public exposure through permissive bucket policies that could grant public or cross-account access to sensitive data. Without RestrictPublicBuckets enabled, bucket policies can override access controls and expose private data to unauthorized external access.

Authorization bypass enabling any API action, leading to privilege escalation, data tampering, resource deletion, or service abuse across the account.

AWS EC2 instances using Instance Metadata Service version 1 (IMDSv1) are vulnerable to Server-Side Request Forgery (SSRF) attacks. IMDSv1 allows unauthenticated HTTP GET requests to retrieve sensitive instance metadata including IAM role credentials, enabling privilege escalation and lateral movement within AWS environments.

SSRF could expose instance metadata and IAM role credentials, enabling privilege escalation, lateral movement, and unauthorized AWS API access.

Azure Cognitive Services accounts configured to allow public network access expose AI endpoints and keys to the internet, enabling unauthorized access, data theft, abuse, and potential brute-force attacks. This vulnerability allows attackers to access AI services without proper network restrictions.

Azure Kubernetes Service (AKS) clusters with enabled local admin accounts create security vulnerabilities by providing static, unrestricted administrative credentials that bypass Azure AD integration and RBAC protections. These accounts can be compromised and provide full cluster control without proper audit trails.

Attackers using leaked or shared local admin credentials can gain full cluster control, bypassing Azure AD integration and RBAC protections.

Azure Kubernetes Service (AKS) clusters configured with automatic upgrade channel set to 'None' or no upgrade channel miss critical security patches and vulnerability fixes. This leaves Kubernetes components vulnerable to known exploits that could lead to remote code execution and cluster compromise.

Remote code execution (RCE) could occur if attackers exploit known vulnerabilities on outdated Kubernetes components lacking timely security patches.

Azure Key Vault configured with public network access enabled exposes secrets, keys, and certificates to internet traffic, enabling potential brute-force attacks, unauthorized access attempts, and exposure of sensitive cryptographic material. This vulnerability allows attackers to target Key Vault endpoints directly from the internet.

Azure Storage accounts configured to allow public access to blob containers enable anonymous access to stored data, exposing sensitive files, backups, and application data to unauthorized users. This vulnerability allows attackers to discover and download private data without authentication.

Azure Storage accounts configured to accept TLS 1.0 and TLS 1.1 connections are vulnerable to protocol downgrade attacks, man-in-the-middle attacks, and cryptographic weaknesses. These legacy TLS versions contain known security flaws that can expose data in transit between clients and storage endpoints.

Azure Storage accounts with blob public access enabled allow anonymous users to read blob contents without authentication, exposing sensitive data, enabling data scraping, secret leakage, and potential compliance violations. This vulnerability creates a pathway for unauthorized data access and information disclosure.

Azure Kubernetes Service (AKS) clusters with publicly accessible API servers and no IP access restrictions expose the Kubernetes API to internet scanning, brute-force attacks, and potential unauthorized access attempts. This increases the attack surface and provides opportunities for reconnaissance and exploitation.

Remote code execution (RCE) inside the container could grant full root privileges, enabling lateral movement, container escape attempts, and host impact via mounted volumes or the Docker socket.

Docker containers built with unpinned base image tags like 'latest' or no tag specification create security vulnerabilities by potentially pulling vulnerable, outdated, or malicious images unpredictably. This nondeterministic behavior can introduce known CVEs and compromise container security during automated builds.

Docker containers running as the root user create severe security vulnerabilities by providing unnecessary elevated privileges to application processes. If the application is compromised, attackers gain full container control with root access, enabling easier container escape attempts, filesystem manipulation, and potential host system compromise through volume mounts or exposed Docker socket.

Google Cloud SQL instances configured without TLS enforcement allow unencrypted database connections, enabling attackers to intercept queries, data, and credentials through man-in-the-middle attacks. This vulnerability exposes sensitive database traffic and authentication information over plaintext connections.

Information disclosure via eavesdropping or MITM; attackers can read queries, data, and credentials over plaintext database traffic.

A critical security vulnerability where Google Kubernetes Engine (GKE) nodes are configured with the legacy metadata endpoint enabled without proper access controls. This exposes sensitive instance metadata including service account credentials, node information, and potentially cluster secrets to any process running in pods. The legacy endpoint lacks authentication and authorization controls, allowing SSRF attacks and credential theft from compromised or malicious pods.

Kubernetes deployments using 'latest' image tags or no tag specification create security vulnerabilities by potentially deploying untested, vulnerable, or malicious container images. The mutable nature of 'latest' tags means deployments can unpredictably pull different images over time, introducing known CVEs without proper review.

Remote code execution (RCE) could let attackers control the host, escape isolation, access devices, and alter system configuration.

Kubernetes pods configured with allowPrivilegeEscalation set to true or not explicitly set to false enable container processes to gain more privileges than their parent process through setuid binaries, capabilities inheritance, or other privilege escalation mechanisms. This creates authorization bypass vulnerabilities that can lead to container escape and host compromise.

Kubernetes containers running with writable root filesystems enable attackers to persist malicious code, modify system binaries, alter runtime behavior, and facilitate lateral movement after compromising applications. This vulnerability allows persistent attacks and makes forensic analysis difficult by enabling evidence tampering.

Kubernetes containers running as root (uid 0) present a significant security risk, as any code execution vulnerability within the container immediately grants root privileges. This enables container breakout attempts, filesystem tampering, lateral movement, and broader cluster compromise.

Attackers who gain code execution inside the container obtain root privileges, enabling container breakout attempts.

Kubernetes containers running with NET_RAW capability enabled can craft and sniff network packets, perform ARP spoofing, conduct network reconnaissance, and bypass network security controls. This capability enables attackers to perform lateral movement, data exfiltration, and network-based attacks within the cluster environment.

Kubernetes pods and containers deployed without explicit securityContext configuration inherit insecure defaults including root user execution, privilege escalation permissions, broad Linux capabilities, writable root filesystems, and unconfined security profiles. This creates multiple attack vectors for container escape, privilege escalation, and lateral movement.

Azure Kubernetes Service (AKS) clusters with the Kubernetes Dashboard add-on enabled introduce a privileged web interface that can expose cluster credentials, secrets, and sensitive information. The dashboard presents an additional attack surface that can be targeted for unauthorized access, privilege escalation, and cluster compromise.

Information disclosure could expose sensitive data and enable tampering via man-in-the-middle attacks when requests are sent over cleartext HTTP.

Ansible uri tasks configured with HTTP URLs transmit requests without TLS encryption, enabling attackers to intercept, read, and modify data in transit through man-in-the-middle attacks. This vulnerability exposes sensitive data, API keys, authentication tokens, and application data transmitted to web services, allowing attackers to capture credentials, inject malicious responses, and compromise downstream systems.

Information disclosure could expose sensitive data and enable tampering via man-in-the-middle attacks when requests are sent over cleartext HTTP.

Ansible get_url tasks configured with HTTP URLs download files without TLS encryption, enabling attackers to intercept, modify, and inject malicious content through man-in-the-middle attacks. This vulnerability allows attackers to replace legitimate files with malware, capture sensitive downloads, steal credentials transmitted during file transfers, and compromise systems that consume the downloaded content.

Information disclosure could let attackers read or modify files, inject malware, or capture credentials via man-in-the-middle on unencrypted HTTP.

Information disclosure could let attackers read or modify files, inject malware, or capture credentials via man-in-the-middle on unencrypted HTTP.

Remote code execution (RCE) is possible by installing tampered packages, leading to full system compromise and persistent attacker control.

Ansible dnf tasks configured with disable_gpg_check: true bypass GPG signature verification, allowing installation of tampered, unsigned, or malicious packages. This creates a critical supply chain attack vector where malicious actors can inject compromised packages that execute arbitrary code during installation or runtime, leading to complete system compromise, data exfiltration, and persistent attacker control over target systems.

Remote code execution (RCE) is possible by installing tampered packages, leading to full system compromise and persistent attacker control.

AWS Route 53 public hosted zones without DNSSEC enabled are vulnerable to DNS spoofing, cache poisoning, and man-in-the-middle attacks. Without cryptographic signatures on DNS responses, attackers can forge DNS records to redirect traffic to malicious servers, enabling credential theft, data interception, and service impersonation attacks.

Authorization bypass can let attackers assume administrative roles, escalate privileges, and access or modify any AWS resources, including disabling logging and exfiltrating data.

AWS IAM policies that grant broad administrative permissions (such as iam:*, *, or AdministratorAccess) enable complete account takeover by allowing principals to assume any role, escalate privileges, access any resource, and disable security controls. This creates an extreme security risk where compromised credentials can lead to total AWS account compromise.

Authorization bypass can let attackers assume administrative roles, escalate privileges, and access or modify any AWS resources, including disabling logging and exfiltrating data.

AWS KMS keys created without explicit key policies rely on default IAM-based access controls that may grant overly broad permissions through existing IAM policies. This creates a security risk where unintended principals could gain access to encryption keys, enabling unauthorized data decryption, key management operations, privilege escalation, and potential data exposure across encrypted resources.

Unrestricted or unintended principals may use, decrypt, or manage the key, enabling data exposure, privilege escalation, or destructive key operations.

Dockerfiles that use APK package manager with --allow-untrusted flag disable signature verification, enabling installation of unsigned or tampered packages that could contain malicious code. This creates a supply chain attack vector where malicious actors can compromise container images by injecting backdoors, malware, or vulnerable packages that execute arbitrary code during build or runtime, leading to container escape, data exfiltration, and infrastructure compromise.

Attackers could introduce tampered packages that execute malicious code during build or runtime, compromising containers, pipelines, and dependent images.

Authorization bypass could let attackers escalate privileges by acting as other users, including admins, enabling unauthorized cluster operations and access to sensitive resources.

Kubernetes RBAC configurations that grant impersonation permissions to ServiceAccounts or Node identities create severe authorization bypass vulnerabilities. Attackers who compromise these identities can impersonate other users, including cluster administrators, enabling unauthorized cluster operations and access to sensitive resources without proper authentication or audit trails.

Information disclosure: Attackers using that identity can exfiltrate all secrets, pivot across namespaces, and compromise services.

Kubernetes RBAC configurations that grant cluster-wide Secret read permissions to ServiceAccounts or Node identities create severe information disclosure vulnerabilities. Attackers who compromise these identities can access all secrets across all namespaces, including database credentials, API keys, certificates, and other sensitive data, enabling lateral movement and broader system compromise.

A critical security vulnerability where Route 53 public hosted zones lack DNSSEC (DNS Security Extensions) configuration, allowing attackers to perform DNS spoofing, cache poisoning, and traffic hijacking attacks. Without DNSSEC, DNS responses are not cryptographically signed, enabling malicious actors to inject false DNS records and redirect users to malicious websites or intercept sensitive communications.

AWS KMS keys created without explicit key policies rely on IAM-based access controls that may grant unintended broad access. Without explicit policies, any principal with appropriate IAM permissions can use the key for encryption, decryption, and management operations, potentially allowing unauthorized data access and privilege escalation.

AWS Application Load Balancer (ALB) listeners configured with SSL policies that allow weak TLS versions (1.0 and 1.1) or outdated cipher suites, exposing client connections to downgrade attacks, man-in-the-middle attacks, and eavesdropping. Weak TLS protocols have known cryptographic vulnerabilities that can be exploited to intercept or decrypt data in transit.

IAM policies grant data-exfiltration actions (s3:GetObject, ssm:GetParameter, secretsmanager:GetSecretValue, rds:*Snapshot) with wildcard resource permissions, allowing principals to read sensitive data from unintended resources and enabling unauthorized data access and privilege escalation.

Application Load Balancers (ALBs) that do not drop invalid HTTP headers can forward malformed headers to backend services, potentially enabling header injection attacks, cache poisoning, and bypassing security controls. This vulnerability occurs when the ALB is configured to forward non-RFC-compliant headers rather than dropping them at the load balancer level.

Amazon Elastic Container Registry (ECR) repositories without KMS encryption at rest expose container images and metadata to potential unauthorized access. When ECR repositories are not configured with customer-managed KMS keys, they rely on AWS-managed encryption which provides less control over access auditing, key rotation, and fine-grained permissions for container image data.

AWS MQ brokers running outdated or deprecated engine versions are exposed to known security vulnerabilities that have been patched in newer releases. These vulnerabilities can be exploited by attackers to read or alter messages, escalate privileges, cause denial of service, or gain unauthorized access to the message broker system, compromising the confidentiality, integrity, and availability of message data.

AWS Elasticsearch domains configured with weak TLS security policies allow legacy TLS versions (1.0/1.1) and insecure cipher suites, making connections vulnerable to downgrade attacks, man-in-the-middle attacks, and eavesdropping. This vulnerability enables attackers to intercept or modify data in transit between clients and the Elasticsearch cluster, compromising the confidentiality and integrity of search data and administrative communications.

Amazon SNS topics without server-side encryption (SSE) store message contents and metadata in plaintext at rest, exposing sensitive information to potential unauthorized access if AWS storage systems are compromised or improperly accessed. Without KMS encryption, SNS messages lack fine-grained access controls, audit trails, and key rotation capabilities, increasing the risk of data exposure in distributed messaging systems.

EC2 instances allowing access to the Instance Metadata Service version 1 (IMDSv1) without requiring session tokens enable Server-Side Request Forgery (SSRF) attacks where malicious applications can access instance metadata, IAM role credentials, and sensitive configuration data through simple HTTP requests to 169.254.169.254, leading to privilege escalation and lateral movement.

Cloud Identity and Access Management (IAM) roles and policies configured with excessive permissions that violate the principle of least privilege. This includes roles with administrative access, wildcard permissions, or broad resource access that increases the attack surface and potential for privilege escalation across AWS, Azure, and Google Cloud Platform.

A high-severity security vulnerability where cloud security groups, network ACLs, and firewall rules are configured with overly broad permissions, allowing unrestricted or excessive network access to cloud resources. This includes rules that allow traffic from any source (0.0.0.0/0), open dangerous ports, permit protocols beyond requirements, or grant access to administrative interfaces from the internet.

A critical security vulnerability where cloud storage buckets (AWS S3, Google Cloud Storage, Azure Blob Storage) are configured with public read or write permissions, exposing sensitive data to unauthorized access. This misconfiguration allows anyone on the internet to list, read, or modify bucket contents, leading to data breaches, intellectual property theft, and compliance violations.

Command injection vulnerabilities occur when user-controlled input is passed directly to exec.Command without proper validation, allowing attackers to inject malicious shell commands and execute arbitrary code on the server.

A critical security vulnerability where sensitive information such as database passwords, API keys, authentication tokens, and encryption keys are passed to containers through environment variables. These secrets become visible in process lists, container inspection commands, orchestration platform UIs, logs, and crash dumps. Environment variables are inherited by child processes and can be accessed by any process running within the container.

LDAP injection vulnerabilities occur when untrusted input is concatenated into LDAP filters without proper escaping, allowing attackers to modify query logic. This can lead to authentication bypass, unauthorized access to directory entries, information disclosure, and privilege escalation within Active Directory or other LDAP systems.

LDAP injection vulnerabilities occur when untrusted user input is concatenated into LDAP filters or distinguished names without proper escaping. Attackers can modify LDAP query logic to bypass authentication, access unauthorized directory entries, extract sensitive information, or escalate privileges within Active Directory or LDAP systems.

XPath injection vulnerabilities occur when user-controlled strings are concatenated into XPath expressions without proper validation or escaping. This allows attackers to manipulate XML query logic to bypass authentication, access unauthorized data, or extract sensitive information from XML documents.

Remote code execution vulnerability in .NET applications where user-controlled template strings are passed to Razor.Parse, which compiles and executes template expressions, enabling server-side template injection and arbitrary code execution on the server.

A critical cryptographic vulnerability where .NET applications use Electronic Codebook (ECB) cipher mode for encryption, which reveals patterns in plaintext data and enables cryptanalytic attacks. ECB mode encrypts identical plaintext blocks to identical ciphertext blocks, allowing attackers to infer information about the original data structure and content. This vulnerability also lacks authentication, permitting undetected modification of encrypted data.

XPath injection vulnerabilities occur when user-controlled strings are concatenated into XPath expressions without validation or escaping. This allows attackers to manipulate XML queries to bypass authentication, access unauthorized data, or extract sensitive information from XML documents.

A critical security vulnerability where ASP.NET applications use user-controlled URL parameters in redirect operations without proper validation. This allows attackers to redirect users to malicious external domains, enabling phishing attacks, credential theft, session token leakage, and loss of user trust. Open redirects are commonly exploited in social engineering attacks and can bypass security awareness training.

SQL injection vulnerability in C# applications using ADO.NET where user input is concatenated into SQL strings without proper parameterization, allowing attackers to manipulate database queries.

A critical XML External Entity (XXE) vulnerability where .NET applications parse untrusted XML input using XmlDocument with DTD processing enabled. This allows attackers to read local files, perform Server-Side Request Forgery (SSRF) attacks, cause denial of service through entity expansion bombs, and potentially execute arbitrary code. XXE attacks can expose sensitive configuration files, credentials, and internal network resources.

Server-Side Template Injection (SSTI) vulnerabilities occur when user-controlled input is passed to Razor.Parse() or similar template compilation methods. Razor templates can contain C# code that gets compiled and executed on the server, allowing attackers to execute arbitrary code, read sensitive files, access databases, or fully compromise the application.

SQL injection vulnerability in C# applications using ADO.NET where user input is directly concatenated into SQL query strings without proper parameterization or validation.

XML external entity (XXE) vulnerabilities occur when XML parsers process external entities in user-controlled input without proper configuration. In .NET applications using XmlReaderSettings with DtdProcessing.Parse enabled, attackers can exploit XXE to read local files, perform Server-Side Request Forgery (SSRF), or cause denial of service through entity expansion attacks.

CSV injection, also known as Formula injection, occurs when untrusted user input is included in CSV files without proper sanitization. When these CSV files are opened in spreadsheet applications like Microsoft Excel, Google Sheets, or LibreOffice Calc, malicious formulas can execute, potentially leading to remote code execution, data exfiltration, or local file access on the user's system.

Critical security vulnerabilities that arise from improper database configuration settings. These misconfigurations can amplify the impact of other vulnerabilities like SQL injection, expose databases to unauthorized access, and create opportunities for data theft or system compromise through overprivileged users, weak authentication, and inadequate access controls.

PHP applications that hardcode database connection strings containing usernames, passwords, and sensitive connection parameters directly in source code expose database credentials to anyone with access to the codebase, version control history, or server files, potentially leading to unauthorized database access and data breaches.

A critical security vulnerability where database connection credentials including usernames, passwords, connection strings, and database URLs are hardcoded directly in Java source code. This exposes sensitive database access information to anyone with access to the codebase, version control history, or compiled bytecode, potentially leading to unauthorized database access and data breaches.

A critical security vulnerability where untrusted serialized Java objects are deserialized without proper validation, allowing attackers to execute arbitrary code. This occurs when applications accept serialized objects from untrusted sources and deserialize them using ObjectInputStream, enabling exploitation through gadget chains in the application's classpath.

A critical security vulnerability where Docker containers are executed with the --privileged flag, granting them root-level access to the host system. This breaks container isolation, allowing containers to access all devices, mount filesystems, load kernel modules, and potentially escape to the host system. Privileged containers essentially run with the same security context as the Docker daemon itself.

Docker containers using mutable image tags like 'latest' or unspecified tags instead of pinned, immutable references create unpredictable deployments where the actual container image can change over time without explicit updates. Mutable tags can pull different image versions across environments, making deployments non-deterministic and vulnerable to supply chain attacks where malicious images could be pushed with the same tag.

A critical vulnerability where Python applications inadvertently log environment variables containing sensitive information such as database passwords, API keys, and authentication tokens. This commonly occurs through debug logging, error handling, or system diagnostics that dump environment variables to log files, console output, or monitoring systems.

A critical security vulnerability where user-controlled input is passed to JavaScript's eval() function, Function() constructor, or similar dynamic code execution mechanisms without proper sanitization. This allows attackers to execute arbitrary JavaScript code in the application context, potentially leading to data theft, session hijacking, DOM manipulation, or complete client-side compromise.

A critical security vulnerability in Node.js applications where user-controlled input is passed to child_process.exec() or similar functions without proper sanitization. This allows attackers to execute arbitrary system commands on the server, leading to complete system compromise, data theft, or remote code execution. The child_process.exec() function uses the system shell to execute commands, making it particularly dangerous when combined with user input.

Cross-site scripting (XSS) vulnerability in Express.js applications where HTML is manually constructed using template literals or string concatenation with unescaped user input.

SQL injection vulnerability in Express.js applications where user input from request parameters, body, and query strings is directly concatenated into SQL queries without proper parameterization.

A critical vulnerability where attackers circumvent file upload restrictions by manipulating MIME types, file extensions, or content headers. Applications that rely solely on client-provided content types or basic extension checking can be bypassed, allowing malicious files to be uploaded and potentially executed, leading to remote code execution or other security compromises.

SQL injection vulnerability in Flask applications where user input from form data and query parameters is directly concatenated into SQL queries using f-strings or string formatting without parameterization.

Embedding template variables directly into JavaScript code within HTML templates creates a cross-site scripting (XSS) vulnerability. HTML escaping is insufficient for JavaScript contexts, allowing attackers to inject malicious scripts through user-controlled data. This can lead to session hijacking, data theft, unauthorized actions, and complete compromise of the user's browser session.

SQL injection vulnerability where fields from the Lambda event are concatenated into SQL strings instead of using parameters, potentially allowing attackers to read, modify, or delete data, escalate privileges, and run unintended queries against the database by altering the query structure through attacker-controlled input.

SQL injection vulnerability in Go AWS Lambda functions where event fields are concatenated or formatted into SQL strings instead of using parameterized queries, allowing attacker-controlled tokens to alter SQL structure.

A critical security vulnerability where unvalidated input is written to a spawned process stdin, which may be interpreted as executable commands. Command injection could let attackers execute arbitrary system commands with application privileges, leading to complete system compromise, data exfiltration, or remote code execution.

A critical security vulnerability where user-controlled strings build the command or arguments for exec.Command, or run via sh -c, without strict validation or allowlisting. Command injection could execute arbitrary system commands, enabling remote code execution and full server compromise.

A critical security vulnerability where dynamic command or arguments come from user-controlled input and are passed to syscall.Exec/ForkExec, sometimes via a shell -c, allowing injected tokens to be executed. Command injection could let attackers execute arbitrary system commands, exfiltrate data, or take over the host process, leading to full system compromise.

SQL injection vulnerabilities occur when user input is concatenated or formatted into SQL queries using fmt.Sprintf() or string concatenation instead of parameterized queries. This allows attackers to inject malicious SQL code that can read, modify, or delete data, potentially compromising the entire database.

XSS vulnerabilities occur when formatted strings containing user input are passed to template.HTML, which bypasses Go's automatic HTML escaping. This allows attackers to inject malicious scripts that execute in users' browsers, steal sessions, manipulate DOM content, or perform unauthorized actions.

XSS could let attackers execute scripts, hijack sessions, or alter pages by injecting JavaScript through crafted HTML attribute values.

XSS vulnerabilities occur when template.JS is used with dynamic or user-controlled content in Go templates. template.JS marks strings as safe JavaScript and disables automatic escaping, allowing attackers to inject malicious scripts that execute in users' browsers, steal sessions, manipulate DOM content, and perform unauthorized actions.

XSS vulnerabilities occur when untrusted data is passed to template.URL, which bypasses URL escaping. Attackers can inject malicious URL schemes like javascript: or data: that execute scripts when users click links or when URLs are loaded in iframes, leading to session theft, phishing, and data exfiltration.

XSS vulnerability in Go net/http applications where untrusted URL query parameters are formatted into HTTP responses using fmt.Printf-style functions without HTML escaping, allowing raw HTML/JavaScript injection that can execute attacker-controlled scripts in user browsers.

SQL injection vulnerability in Go applications using the standard database/sql package where variables are concatenated into SQL strings without parameterization, allowing attackers to manipulate database queries.

SQL injection vulnerability where non-literal variables are concatenated or formatted into SQL strings instead of parameter binding in go-pg ORM operations, potentially allowing attackers to read, modify, or delete database data and escalate privileges.

SQL injection vulnerability where the SQL is built with string concatenation or fmt.Sprintf, inserting variables directly instead of using placeholders and bound parameters, potentially allowing attackers to read or modify data, run arbitrary SQL, and compromise database integrity through injected SQL syntax.

SQL injection vulnerability in Go applications using the pgx PostgreSQL driver where SQL statements are built with string concatenation or fmt.Sprintf, allowing attackers to embed untrusted values directly into query text.

XSS vulnerability in Go net/http applications where untrusted data is written directly to http.ResponseWriter.Write without HTML escaping, bypassing html/template auto-encoding and allowing malicious scripts to execute in user browsers.

XSS vulnerability in Go net/http applications where fmt.Printf output is written to http.ResponseWriter without HTML escaping, rendering user-controlled data directly into pages and allowing malicious scripts to execute in user browsers.

Path traversal vulnerabilities occur when applications use filepath.Clean() as a security control, mistakenly believing it prevents directory traversal. filepath.Clean() only normalizes paths but does NOT enforce directory boundaries, allowing attackers to access files outside intended directories using '../' sequences or absolute paths.

XSS vulnerabilities occur when Go applications manually construct HTML using fmt.Sprintf() or string concatenation with user input, bypassing html/template's automatic escaping. This allows attackers to inject malicious scripts that execute in users' browsers, steal sessions, manipulate page content, or perform unauthorized actions.

SQL injection vulnerability in Go applications using database/sql where HTTP request data is inserted into SQL via string concatenation or formatting instead of parameters, allowing injection through user-controlled input.

Server-side request forgery (SSRF) vulnerabilities occur when applications allow user input to control the destination host for HTTP requests, enabling attackers to make the server contact arbitrary hosts and potentially access internal services.

A critical vulnerability that occurs when Go applications using the go-pg ORM library construct SQL queries by concatenating user input directly into WHERE clauses, ORDER BY clauses, or raw SQL queries. This bypasses the ORM's built-in protections and allows attackers to inject malicious SQL code, potentially leading to data theft, database corruption, or unauthorized access.

SQL injection vulnerability in Go applications using the pgx PostgreSQL driver where user input is directly concatenated into SQL queries without proper parameterization.

A critical vulnerability that occurs when Go applications using the standard database/sql package construct SQL queries by concatenating user input directly into query strings. This allows attackers to inject malicious SQL code, potentially leading to data theft, database corruption, or unauthorized access.

A critical vulnerability that occurs when Go applications using the html/template package inappropriately use template.HTML to bypass auto-escaping mechanisms. By wrapping user input with template.HTML, developers disable the built-in XSS protections, allowing attackers to inject malicious HTML and JavaScript code directly into web pages.

A critical vulnerability that occurs when Go applications using the html/template package inappropriately use template.HTMLAttr to bypass auto-escaping for HTML attributes. This allows attackers to inject malicious HTML attributes containing JavaScript code, potentially leading to XSS attacks through attribute injection.

A critical security vulnerability where encryption keys, cryptographic salts, initialization vectors (IVs), or other cryptographic secrets are hardcoded directly in source code. This exposes the cryptographic foundation of security systems, allowing attackers to decrypt data, forge signatures, and bypass authentication mechanisms.

HTTP response splitting occurs when untrusted user input is used to construct HTTP response headers without proper validation or encoding. Attackers can inject carriage return (CR) and line feed (LF) characters to manipulate HTTP responses, inject additional headers, perform cache poisoning, cross-site scripting (XSS), or conduct session hijacking attacks.

A critical vulnerability where attackers upload malicious image files containing embedded executable code, polyglot files, or exploit image processing vulnerabilities to achieve remote code execution. This can occur through various vectors including metadata injection, polyglot file creation, image parser exploits, or by bypassing validation to upload disguised executable files.

Sensitive information such as API keys, passwords, certificates, and configuration secrets accidentally committed to version control systems. This exposure can lead to unauthorized access to infrastructure, services, and data, especially when repositories are public or accessed by unauthorized individuals.

A critical vulnerability that occurs when JavaScript applications directly assign user input to the innerHTML property of DOM elements without proper sanitization. This allows attackers to inject malicious HTML and JavaScript code that gets executed in the browser, leading to cross-site scripting (XSS) attacks.

A critical security vulnerability where cloud instance metadata services (AWS EC2 IMDS, GCP metadata server, Azure IMDS) are accessible without proper restrictions, allowing attackers to steal temporary credentials, IAM roles, and sensitive instance information. This commonly occurs through Server-Side Request Forgery (SSRF) attacks, remote code execution, or when applications make unvalidated HTTP requests that can be redirected to metadata endpoints.

A critical vulnerability where applications use weak, predictable, or pseudo-random number generators for cryptographic operations like key generation, token creation, session IDs, nonces, or initialization vectors. Predictable randomness can lead to session hijacking, key prediction, and complete cryptographic system compromise.

A critical vulnerability where applications use cryptographic keys that are too short to provide adequate security against modern computational attacks. Insufficient key lengths make encrypted data vulnerable to brute force attacks, especially with advances in computing power and specialized hardware like GPUs and quantum computers.

SQL injection vulnerability where untrusted Lambda event fields are concatenated into SQL strings (e.g., StringBuilder or String.format) instead of using parameterized statements, potentially allowing attackers to read, modify, or delete database records, escalate privileges, or run destructive queries.

SQL injection vulnerability where Lambda event fields are concatenated into SQL strings executed by JDBC without parameterization or proper binding, potentially allowing attackers to read or modify data, dump tables, or alter schema via crafted Lambda event payloads.

Apache HttpClient's DefaultHttpClient is deprecated and lacks support for modern TLS protocols (TLS 1.2, 1.3). This client may negotiate weak TLS versions, use insecure cipher suites, or have inadequate hostname verification, making HTTPS connections vulnerable to man-in-the-middle attacks that can intercept or modify sensitive data in transit.

Triple DES (3DES/DESede) is a deprecated encryption algorithm with a 64-bit block size, making it vulnerable to birthday attacks like SWEET32. After encrypting ~32GB of data with the same key, collision attacks become feasible, allowing attackers to recover plaintext. Modern applications must use AES encryption instead of 3DES for adequate cryptographic strength.

Hostname verification vulnerabilities occur when Java applications implement HostnameVerifier that always returns true or use NoopHostnameVerifier, skipping critical hostname validation checks. This allows man-in-the-middle attackers to present valid certificates for different domains and successfully intercept HTTPS traffic, exposing sensitive data and credentials.

A critical security vulnerability where command strings are built via concatenation or String.format with variables, allowing user-controlled values to alter executed commands or inject additional arguments. Command injection could run arbitrary OS commands with application privileges, exfiltrate data, modify files, or take over the host.

SQL injection vulnerability in Java applications where SQL strings are built using String.format() or similar formatting methods with user-controlled values, bypassing prepared statement protections.

SQL injection vulnerability in Java Spring applications using JdbcTemplate where SQL strings are built by concatenating or formatting user-controlled data instead of using parameterized queries, compromising database integrity and confidentiality.

Unsafe deserialization vulnerabilities occur when ObjectInputStream.readObject() processes untrusted data without filtering or validation. Attackers can craft malicious serialized objects containing gadget chains from libraries in the classpath that execute arbitrary code during deserialization, leading to complete system compromise.

Information disclosure vulnerabilities occur when Cross-Origin Resource Sharing (CORS) is configured to allow any origin (*) or null origin to access resources, potentially exposing sensitive data to malicious websites.

Remote code execution vulnerabilities occur when untrusted user input is passed to ScriptEngine.eval(), allowing attackers to execute arbitrary code by injecting malicious scripts into the evaluation context.

SQL injection vulnerability where SQL uses concatenated or formatted variables executed via Statement without parameters, potentially allowing attackers to read or modify database data and execute dangerous operations.

SQL injection vulnerability in Java applications using JPA where SQL strings are built with concatenated or formatted variables and executed via EntityManager, bypassing prepared statement protections.

Command injection vulnerabilities occur when HTTP request data is passed to ProcessBuilder or Runtime.exec() without proper validation, allowing attackers to execute arbitrary operating system commands.

Environment variable injection vulnerabilities occur when HTTP request data is used to set environment variables for subprocess execution. Attackers can manipulate PATH, LD_LIBRARY_PATH, or other environment variables to hijack command execution, inject malicious libraries, or alter subprocess behavior, potentially leading to arbitrary code execution.

Remote code execution vulnerabilities occur when untrusted XML data is deserialized using XMLDecoder, which can invoke arbitrary constructors and methods during the deserialization process.

Path traversal vulnerabilities occur when HTTP request parameters are used to construct file paths without proper validation, allowing attackers to access files outside intended directories using sequences like '../../../etc/passwd' to escape the base directory and read sensitive files.

XSS vulnerability in Java web applications where untrusted data from HttpServletRequest is written directly to HttpServletResponse without context-appropriate HTML encoding or escaping, allowing attackers to inject malicious scripts that execute in user browsers.

XML External Entity (XXE) vulnerabilities occur when XMLInputFactory is configured to enable external entities or DTD support, allowing attackers to read local files, perform SSRF attacks, or cause denial of service. When XMLInputFactory processes untrusted XML with external entities enabled, attackers can craft payloads that access the file system, make network requests, or cause exponential entity expansion.

XMLInputFactory configurations that allow external entity processing can lead to XML External Entity (XXE) attacks. This vulnerability enables attackers to read local files, perform Server-Side Request Forgery (SSRF), cause denial of service through entity expansion, and potentially execute remote code. XXE attacks exploit the XML parser's ability to process external entities defined in malicious XML documents.

XML External Entity (XXE) vulnerabilities occur when XML parsers process external entity references without proper security controls. This allows attackers to read local files, perform server-side request forgery (SSRF), cause denial of service, and potentially execute remote code by exploiting the XML parser's ability to resolve external entities.

NoSQL injection vulnerability where untrusted data is interpolated into the $where clause, which executes JavaScript on the MongoDB server, potentially allowing attackers to execute arbitrary JavaScript on the database, exposing or modifying data.

Remote code execution (RCE) vulnerability where code deserializes attacker-controlled bytes with ObjectInputStream without strict type filtering or authentication, enabling gadget chains during object reconstruction. Java deserialization is particularly dangerous because attackers can leverage existing classes in the application's classpath to construct gadget chains that execute arbitrary code during the deserialization process.

RMI deserialization vulnerabilities occur when RMI methods accept arbitrary Serializable objects as parameters. Attackers can send malicious serialized objects containing gadget chains that execute arbitrary code during deserialization. RMI services are particularly vulnerable because they automatically deserialize method parameters over the network.

Remote code execution vulnerabilities occur when RMI methods accept non-primitive object parameters that trigger deserialization of untrusted data, enabling gadget chain exploitation for arbitrary code execution.

Java RMI methods that accept arbitrary serializable objects can be exploited through deserialization attacks, allowing attackers to execute arbitrary code on the server by crafting malicious serialized objects that trigger gadget chains during unmarshalling.

Remote code execution (RCE): An attacker can execute arbitrary code by injecting malicious scripts, compromising data and the host running the application.

Cross-Site Request Forgery (CSRF) vulnerabilities occur when Spring Security CSRF protection is disabled via csrf().disable(). This allows attackers to craft malicious web pages that, when visited by authenticated users, can perform unauthorized state-changing actions like changing passwords, transferring funds, or modifying account settings using the victim's session.

Applications that disable CSRF protection in Spring Security configuration are vulnerable to Cross-Site Request Forgery attacks, where attackers can trick authenticated users into performing unintended actions by exploiting their active session cookies.

SQL injection vulnerability where a public method String parameter is concatenated into a raw SQL statement instead of using parameterized queries, potentially allowing attackers to read or alter data, escalate privileges, or run arbitrary database operations.

Applications that use untrusted HTTP request data directly as file paths without proper validation are vulnerable to path traversal attacks, allowing attackers to read, write, or delete arbitrary files on the server by using directory traversal sequences like '../' or absolute paths.

SQL injection vulnerability in Spring applications where untrusted request data is concatenated into SQL strings instead of using bound parameters, allowing attackers to alter queries and manipulate database operations.

A critical security vulnerability where untrusted request data is inserted into OS command strings or arguments and executed via Runtime.exec or ProcessBuilder without allowlisting or proper argument separation. Command injection lets attackers execute arbitrary OS commands, enabling data theft, malware installation, lateral movement, or full server compromise.

Applications that allow user input to control URL hosts in server-side requests are vulnerable to Server-Side Request Forgery (SSRF) attacks, enabling attackers to make unauthorized requests to internal services, cloud metadata endpoints, or external systems using the server's credentials and network access.

Hostname verification vulnerabilities occur when Java applications implement HostnameVerifier that always returns true or use NoopHostnameVerifier, skipping critical hostname validation checks. This allows man-in-the-middle attackers to present valid certificates for different domains and successfully intercept HTTPS traffic, exposing credentials, API keys, and sensitive data.

SQL injection vulnerability in Java applications using JDBC where user input is directly concatenated into SQL queries using Statement instead of PreparedStatement.

A critical security vulnerability where untrusted event fields are concatenated into command strings or arguments passed to exec/execSync/spawn without strict validation or allowlisting, allowing shell metacharacters and injected commands to run. Command injection could execute arbitrary system commands, exfiltrate data, or modify the environment, compromising the Lambda function and connected AWS resources.

SQL injection vulnerability where Lambda event data is concatenated into SQL strings passed to mysql/mysql2 query methods without parameterization, allowing crafted input to alter queries and potentially read or modify database data, bypass authorization, or execute destructive queries.

SQL injection vulnerability where untrusted AWS Lambda event fields are concatenated into SQL strings sent to pg without parameters or proper escaping, potentially allowing attackers to alter or read database data, execute arbitrary SQL, escalate privileges, or exfiltrate sensitive information.

SQL injection vulnerability where untrusted event fields are concatenated into SQL passed to sequelize.query without parameterization or proper binding, potentially allowing attackers to read or modify database data, escalate privileges, or run arbitrary queries via crafted Lambda event input.

SQL injection vulnerability where the Lambda handler builds SQL by concatenating user-controlled event fields, potentially allowing attackers to read or change database records, run unauthorized queries, or escalate privileges using crafted input that reaches dynamic SQL.

DOM-based XSS vulnerability in browser JavaScript where untrusted URL components are inserted into the page using document.write without HTML encoding or validation, enabling attackers to inject and execute malicious scripts in the victim's browser context.

Using eval() to execute dynamic strings containing user-influenced data creates severe security vulnerabilities, allowing attackers to execute arbitrary JavaScript code in the browser context, steal sensitive data, manipulate the DOM, and perform actions on behalf of the user.

Using dangerous DOM methods like innerHTML, outerHTML, and document.write() with untrusted user input creates XSS vulnerabilities, allowing attackers to inject and execute malicious scripts in the browser context.

Assigning untrusted user input directly to innerHTML properties creates XSS vulnerabilities, allowing attackers to inject malicious scripts that execute in the user's browser context, potentially stealing sensitive data, hijacking sessions, or performing unauthorized actions.

Path traversal vulnerabilities occur when user input is used directly as the template name in res.render() without validation. Attackers can use path traversal sequences to render unauthorized templates, potentially exposing sensitive views, administrative interfaces, or bypassing access controls.

Express applications without CSRF protection are vulnerable to Cross-Site Request Forgery attacks, where malicious websites can perform unauthorized actions on behalf of authenticated users by exploiting their active session cookies.

Express applications using serve-index middleware without proper restrictions expose directory contents to attackers, potentially revealing sensitive files, source code, configuration files, and other confidential information.

XXE vulnerabilities occur when Express applications use libxml or libxmljs to parse XML without disabling external entity processing. Attackers can craft malicious XML payloads containing external entity references that read local files, perform SSRF attacks, or cause denial of service through entity expansion.

XXE vulnerabilities occur when XML parsing with libxml inside VM2 or similar sandboxes fails to disable external entity processing. Even within sandboxed environments, XXE can read local files, perform SSRF attacks, or cause denial of service through billion laughs attacks, potentially escaping sandbox protections.

Open redirect vulnerabilities occur when Express applications redirect users to URLs from untrusted sources without validation. Attackers can craft malicious URLs that redirect users to phishing sites or malicious domains, bypassing the trust users have in the legitimate domain. This is commonly exploited in phishing attacks where users trust the initial legitimate domain but are redirected to attacker-controlled sites.

Path traversal vulnerabilities occur when Express applications use path.join() or path.resolve() with user-controlled input without proper validation. Attackers can use '../' sequences to escape the intended directory and access sensitive files. While these functions normalize paths, they don't prevent traversal outside the base directory unless explicitly validated.

Path traversal vulnerabilities occur when user-controlled paths are passed to res.sendFile() without proper validation. Even though res.sendFile() has some built-in protections, attackers can bypass them using absolute paths or by exploiting misconfigurations, accessing files outside the intended directory and potentially exposing sensitive application files, configuration, or system files.

Using hard-coded session secrets in Express applications creates critical security vulnerabilities, allowing attackers who discover the secret to forge valid session cookies, hijack user accounts, and bypass authentication.

The Express.js application allows user-controlled input to influence server-side HTTP requests, potentially enabling attackers to access internal services, cloud metadata, or other restricted resources. This vulnerability occurs when user input is directly used in HTTP requests without proper validation and sanitization.

The Express.js application uses xml2json library with event handlers that are vulnerable to XML External Entity (XXE) attacks. This occurs when XML parsing is configured to process external entities, allowing attackers to read local files, perform SSRF attacks, or cause denial of service through entity expansion.

The Express.js application is vulnerable to remote property injection where user-controlled input can modify object properties, potentially leading to prototype pollution, access control bypass, or code execution. This occurs when user input is used to dynamically set object properties without proper validation.

The Express.js application is vulnerable to template injection through the res.render() method when user-controlled input is passed directly to template rendering without proper sanitization. This can lead to server-side template injection (SSTI), allowing attackers to execute arbitrary code or access sensitive data.

XSS vulnerability in Express.js applications where user-controlled data is directly written to the HTTP response using response.write() or response.end() without proper escaping, allowing script injection into the rendered page.

The Express.js application has improper Cross-Origin Resource Sharing (CORS) configuration that allows unauthorized cross-origin requests. This can lead to data exposure, CSRF attacks, or unauthorized API access from malicious websites.

The Express.js application contains vulnerabilities that allow unauthorized data extraction through various attack vectors such as SQL injection, directory traversal, or information disclosure. Attackers can exploit these weaknesses to access sensitive data, database contents, or internal system information.

The Express.js application uses the Expat XML parser in a way that allows XML External Entity (XXE) attacks. This vulnerability occurs when XML parsing is configured to process external entities, enabling attackers to read local files, perform SSRF attacks, or cause denial of service.

The Express.js application uses template engines in an insecure manner, potentially allowing server-side template injection (SSTI), XSS, or other template-related vulnerabilities. This occurs when user input is processed by template engines without proper sanitization or when dangerous template features are enabled.

The Express.js application uses PhantomJS for server-side rendering or PDF generation with user-controlled input, leading to command injection vulnerabilities. Attackers can inject malicious commands that get executed by the PhantomJS process, potentially leading to remote code execution.

The Express.js application uses Puppeteer for browser automation with user-controlled input, leading to code injection vulnerabilities. Attackers can inject malicious JavaScript code that gets executed in the browser context, potentially leading to data exfiltration, SSRF, or other security issues.

The Express.js application uses the vm2 library for JavaScript code sandboxing but is vulnerable to sandbox escape attacks. Attackers can exploit weaknesses in the vm2 implementation to break out of the sandbox and execute arbitrary code on the host system.

The Express.js application uses the xml2json library to parse XML input without properly disabling external entity processing, making it vulnerable to XXE attacks. Attackers can exploit this to read local files, perform SSRF attacks, or cause denial of service through entity expansion.

The Express.js application directly injects user-controlled content into HTML responses using string formatting or concatenation, leading to Cross-Site Scripting (XSS) vulnerabilities. This occurs when user input is embedded in HTML without proper encoding or sanitization.

SQL injection vulnerability in Express.js applications where user-controlled request data is concatenated into SQL strings instead of using parameters, allowing attackers to manipulate database queries and potentially access or modify sensitive data.

The Express.js application uses the deprecated 'request' library for HTTP requests, which is no longer maintained and may contain security vulnerabilities. The request library has been deprecated since 2020 and should be replaced with more secure and actively maintained alternatives.

The Express.js application has improper or missing X-Frame-Options header configuration, making it vulnerable to clickjacking attacks. This allows malicious websites to embed the application in iframes and trick users into performing unintended actions.

Information disclosure could occur via man-in-the-middle; attackers can read or modify RPC data, steal credentials, and impersonate services over plaintext connections.

The Node.js application establishes gRPC connections without proper TLS encryption, transmitting sensitive data over unencrypted channels. This vulnerability exposes communication between gRPC services to potential eavesdropping, man-in-the-middle attacks, and data interception.

The Node.js application uses the jwt-simple library to decode JWT tokens without proper signature verification, allowing attackers to forge or tamper with tokens. This vulnerability can lead to authentication bypass, privilege escalation, and unauthorized access to protected resources.

The JavaScript application uses dynamic or user-controlled input to construct filesystem paths for file operations, potentially leading to path traversal attacks. This vulnerability allows attackers to access files outside the intended directory structure, potentially reading sensitive files or overwriting critical system files.

The JavaScript application uses path.join() or path.resolve() with user-controlled input without proper validation, enabling path traversal attacks. Attackers can manipulate file paths to access files outside the intended directory structure using sequences like '../' to traverse up the directory tree.

SQL injection vulnerability where SQL strings are built by concatenating non-literal variables into mssql queries without parameters, potentially allowing attackers to alter queries, exfiltrate data, or run dangerous database functions.

SQL injection vulnerability where a function argument is embedded into SQL for mysql/mysql2 without parameters, potentially allowing attackers to read or modify database records, escalate privileges, or execute administrative operations through attacker-controlled content that alters the query structure.

SQL injection vulnerability where the SQL statement is built via string concatenation, inserting untrusted data directly into the query instead of using node-postgres parameter placeholders and bound values, potentially allowing attackers to read or alter data, run arbitrary queries, or escalate database privileges.

A critical security vulnerability where untrusted function parameters are used as commands or arguments to child_process exec/spawn without strict validation or with shell execution enabled. Command injection allows attackers to execute arbitrary system commands, leading to complete system compromise.

The JavaScript application establishes WebSocket connections using the insecure 'ws://' protocol instead of secure 'wss://', transmitting data over unencrypted channels. This vulnerability exposes real-time communication to eavesdropping, man-in-the-middle attacks, and data manipulation.

The Sequelize ORM configuration connects to databases without enforcing TLS encryption, potentially transmitting sensitive data over unencrypted connections. This vulnerability exposes database communications to eavesdropping and man-in-the-middle attacks.

XSS could execute attacker-controlled scripts in the browser, stealing sessions, altering page content, or performing actions as the user.

A critical vulnerability that occurs when Node.js applications using JavaScript construct SQL queries by concatenating or interpolating user input directly into query strings. Template literals and string concatenation in JavaScript make applications particularly vulnerable to SQL injection attacks when proper parameterization is not used.

A critical vulnerability that occurs when Python web applications using Jinja2 templating engine disable auto-escaping or improperly handle template rendering. When auto-escaping is disabled, user input is rendered directly into HTML without proper escaping, allowing attackers to inject malicious scripts and HTML content.

A critical security vulnerability where JSON Web Token (JWT) signing secrets are hardcoded in Node.js source code, configuration files, or accidentally exposed through logs and debugging information. Exposed JWT secrets allow attackers to forge valid tokens, impersonate users, escalate privileges, and completely bypass authentication mechanisms.

A high-severity security vulnerability where Kubernetes pods use the default service account which often has overly broad permissions or access to sensitive cluster resources. Default service accounts are automatically assigned to pods unless explicitly overridden, and they frequently inherit cluster-wide permissions that violate the principle of least privilege. This can lead to privilege escalation, unauthorized access to secrets, and potential cluster compromise.

Kubernetes pods deployed without proper security context configurations, allowing containers to run with excessive privileges, as root user, or with dangerous capabilities. These misconfigurations can lead to container escape, privilege escalation, and compromise of the underlying node and cluster.

Misconfigured Kubernetes Role-Based Access Control (RBAC) that allows users or service accounts to escalate privileges and gain unauthorized access to cluster resources. This includes overly permissive roles, wildcard permissions, and improper binding configurations that violate the principle of least privilege.

LDAP injection occurs when untrusted user input is used to construct LDAP queries without proper validation or escaping. Attackers can manipulate LDAP queries to bypass authentication, access unauthorized data, or perform directory traversal attacks in directory services like Active Directory, OpenLDAP, and other LDAP-based systems.

NoSQL injection attacks exploit vulnerabilities in NoSQL databases like MongoDB, CouchDB, Redis, and Cassandra by injecting malicious payloads into database queries. Unlike traditional SQL injection, NoSQL injection can involve JavaScript code execution, JSON manipulation, or operator injection depending on the database type and query structure.

The PHP application uses Doctrine DBAL to construct database queries with user-controlled input without proper parameterization or escaping, leading to SQL injection vulnerabilities. This occurs when raw SQL is built using string concatenation or interpolation with untrusted data.

A critical vulnerability that occurs when PHP applications directly echo or print user input from HTTP requests (GET, POST, COOKIE data) without proper HTML encoding or sanitization. This allows attackers to inject malicious HTML and JavaScript code that gets executed in users' browsers, leading to cross-site scripting (XSS) attacks.

The PHP application uses the base_convert() function with large numbers, which can lead to precision loss due to floating-point limitations. This vulnerability can cause incorrect calculations, authentication bypasses, or data corruption when dealing with cryptographic tokens, user IDs, or financial calculations.

The PHP application disables SSL peer verification in cURL requests by setting CURLOPT_SSL_VERIFYPEER to false, making it vulnerable to man-in-the-middle attacks. This configuration bypasses certificate validation, allowing attackers to intercept and manipulate HTTPS communications.

The PHP application uses the dangerous eval() function to execute code dynamically, which can lead to remote code execution if user input is processed. The eval() function treats strings as PHP code and executes them, making it extremely dangerous when handling untrusted input.

The PHP application uses FTP protocol for file transfers, which transmits data including credentials in plaintext over the network. This vulnerability exposes sensitive information to eavesdropping and man-in-the-middle attacks, as FTP does not provide encryption.

Cross-site scripting (XSS) lets attackers execute scripts, steal sessions, and exfiltrate data.

The PHP application uses user-controlled input to determine which functions or methods to call dynamically, leading to potential code execution vulnerabilities. This occurs when user input influences call_user_func(), call_user_func_array(), or variable function calls without proper validation.

A critical security vulnerability where untrusted request data is concatenated into shell command strings executed by exec/system/passthru/shell_exec without strict validation or safe argument handling. Command injection could enable remote code execution, data theft, and full server compromise, leading to service disruption and persistent attacker access.

SQL injection vulnerability in PHP applications where HTTP request data is concatenated into SQL query strings without parameterization or proper binding, allowing attackers to manipulate database operations and bypass application logic.

The PHP application makes HTTP requests to URLs controlled by user input without proper validation, enabling Server-Side Request Forgery attacks. Attackers can exploit this to access internal services, cloud metadata endpoints, or perform port scanning on internal networks.

The PHP application uses the phpinfo() function which exposes sensitive system information including configuration details, environment variables, loaded modules, and potentially sensitive data. This information can help attackers understand the system architecture and identify vulnerabilities.

A critical security vulnerability where untrusted request data is concatenated into shell commands and passed to exec-like functions without proper validation or escaping. Command injection could run arbitrary OS commands, exfiltrate data, and fully compromise the server.

The PHP application uses the unserialize() function to process untrusted data, which can lead to object injection attacks and remote code execution. When unserialize() processes malicious serialized data, it can instantiate arbitrary classes and trigger dangerous magic methods like __wakeup() or __destruct().

The Laravel application sets cookies without the HttpOnly flag, making them accessible to client-side JavaScript. This vulnerability exposes session cookies and other sensitive data to Cross-Site Scripting (XSS) attacks, allowing attackers to steal authentication tokens and session information.

The Laravel application sets cookies with excessively long expiration times, increasing the window of opportunity for session hijacking and unauthorized access. Long-lived cookies remain valid even after users expect their sessions to have expired, creating security risks if devices are compromised.

The Laravel application sets cookies with a null or unspecified domain, which can lead to unintended cookie sharing across subdomains or security issues in multi-domain environments. This configuration may allow cookies to be sent to unintended hosts or fail to properly restrict cookie scope.

The Laravel application sets cookies without the SameSite attribute or with an inappropriate value, making it vulnerable to Cross-Site Request Forgery (CSRF) attacks. The SameSite attribute controls when cookies are sent with cross-site requests, providing protection against CSRF and some forms of cross-site information leakage.

The Laravel application sets cookies without the Secure flag, allowing them to be transmitted over unencrypted HTTP connections. This vulnerability exposes sensitive session data and authentication tokens to potential interception during transmission over insecure networks.

SQL injection vulnerability where user input flows into raw SQL or dynamic identifiers without binding or whitelisting, bypassing Laravel escaping and enabling attacker-controlled SQL syntax, potentially allowing attackers to read or alter sensitive data, escalate privileges, or run destructive statements, causing data breaches and compromising system integrity.

SQL injection vulnerability in PHP applications using mysqli where user input is directly concatenated into SQL queries without proper parameterization or prepared statements.

A critical security vulnerability where user-controlled data is executed by eval/assert or selects callables for call_user_func without validation or an allowlist, enabling attacker-supplied code to run. Attackers can execute arbitrary PHP code on the server, leading to full compromise, data theft, or site defacement.

The WordPress plugin contains PHP object injection vulnerabilities through unsafe deserialization of user-controlled data. This occurs when plugins use unserialize() on untrusted input, potentially allowing attackers to execute arbitrary code, manipulate application logic, or perform other malicious actions through crafted serialized objects.

A critical security vulnerability in C# applications where user-controlled input is passed to PowerShell execution methods without proper sanitization. This includes using PowerShell.Create(), Process.Start() with powershell.exe, or PowerShell cmdlets with unsanitized user input. Attackers can execute arbitrary PowerShell commands, leading to complete system compromise, data exfiltration, privilege escalation, or remote code execution. PowerShell's extensive access to Windows systems and .NET framework makes this particularly dangerous.

A critical security vulnerability in Java applications where user-controlled input is passed to ProcessBuilder, Runtime.exec(), or similar process execution methods without proper sanitization. This allows attackers to execute arbitrary system commands on the server, potentially leading to complete system compromise, data exfiltration, or remote code execution. Java's process execution APIs can be particularly dangerous when command arguments are constructed from user input.

The AWS Lambda function uses the subprocess module to execute system commands with user-controlled input, potentially leading to command injection vulnerabilities. In the serverless environment, this can allow attackers to execute arbitrary commands, access AWS metadata, or compromise the Lambda execution environment.

The AWS Lambda function uses dangerous system call functions like os.system(), os.popen(), or eval() with user-controlled input, creating command injection and code execution vulnerabilities. In the Lambda environment, this can lead to compromise of the execution environment, unauthorized access to AWS services, or data exfiltration.

SQL injection vulnerability in Python AWS Lambda functions where event data is concatenated into MySQL queries without parameterization, allowing attackers to manipulate database operations through malicious Lambda payloads.

SQL injection vulnerability in Python AWS Lambda functions where event data is concatenated into SQL strings and passed to psycopg cursor.execute without parameterization, allowing attackers to manipulate PostgreSQL database operations.

SQL injection vulnerability in AWS Lambda functions where user-controlled event values are concatenated into SQL queries and passed to cursor.execute without parameters in pymssql, potentially allowing attackers to read or modify database data, execute dangerous queries, or compromise application integrity.

SQL injection vulnerability where untrusted AWS Lambda event fields flow into SQL strings passed to cursor.execute without parameters, allowing attacker-controlled tokens to alter query structure and potentially read or change data, run dangerous SQL functions, and expose sensitive information.

SQL injection vulnerability where event-derived values are concatenated or formatted into SQL strings passed to SQLAlchemy's execute() without parameter binding, allowing untrusted input to alter queries and potentially read, modify, or delete database data.

The AWS Lambda function executes user-controlled code through eval(), exec(), compile(), or similar functions, creating severe code injection vulnerabilities. This allows attackers to execute arbitrary Python code within the Lambda environment, potentially accessing AWS services, environment variables, or performing unauthorized operations.

The AWS Lambda function deserializes untrusted pickle data, which can lead to arbitrary code execution. Python's pickle module can instantiate arbitrary classes and call arbitrary functions during deserialization, making it extremely dangerous when processing untrusted data in the Lambda environment.

SQL injection vulnerability where user-controlled Lambda event fields are concatenated into SQL strings without parameters or proper validation, potentially allowing attackers to read, modify, or delete database data and exfiltrate sensitive information.

The Django application accesses foreign key relationships without proper optimization, leading to N+1 query problems that can cause performance degradation and potential denial of service. While primarily a performance issue, it can become a security concern when it enables resource exhaustion attacks.

The Django application uses insecure deserialization methods like pickle.loads(), yaml.load(), or eval() with untrusted data, potentially leading to remote code execution. Django applications should use safe serialization formats and avoid deserializing untrusted data that can instantiate arbitrary objects or execute code.

XSS vulnerability in Django applications where user-controlled data is directly written to HttpResponse without proper escaping, bypassing Django's automatic template escaping and allowing script injection.

XSS vulnerability in Django templates where the safeseq filter is applied to template variables, marking sequence items as safe and bypassing Django's automatic HTML escaping, allowing untrusted HTML content to be rendered directly into pages.

The Django application uses eval() function with user-controlled format strings, creating code injection vulnerabilities. This occurs when user input is inserted into format strings that are then evaluated, allowing attackers to inject malicious code through format string manipulation and execute arbitrary Python code.

The Django application uses the eval() function with user-controlled input, allowing attackers to execute arbitrary Python code. This vulnerability can lead to complete system compromise, data theft, privilege escalation, and unauthorized access to server resources.

The Django application uses the exec() function with user-controlled format strings, creating critical code injection vulnerabilities. This occurs when user input is incorporated into format strings that are then executed, allowing attackers to inject and execute arbitrary Python code with full application privileges.

A critical security vulnerability where untrusted HTTP request data is executed with Python exec. exec evaluates attacker-controlled strings as code, enabling arbitrary command execution within the application process. RCE lets attackers execute arbitrary Python code on the server, leading to full compromise, data theft, or lateral movement.

The Django application uses os.system() or similar functions with user-controlled input, leading to command injection vulnerabilities. Attackers can execute arbitrary system commands on the server, potentially gaining full control of the system, accessing sensitive files, or compromising the entire infrastructure.

A critical security vulnerability where user-controlled request data is passed to subprocess execution, often with shell parsing or dynamic command construction, enabling injection of additional commands or arguments. Command injection could let attackers run arbitrary OS commands, leading to server compromise, data exfiltration, and lateral movement.

The Django application uses os.path.join() with user-controlled input without proper validation, enabling path traversal attacks. Attackers can manipulate file paths to access files outside the intended directory structure using sequences like '../' to traverse up the directory tree and access sensitive system files.

The Django application uses the open() function with user-controlled file paths without proper validation, enabling path traversal attacks. Attackers can manipulate file paths to access files outside the intended directory structure using sequences like '../' to traverse up the directory tree and access sensitive system files, configuration data, or other restricted content.

The Django application reflects user-controlled data directly in HttpResponse without proper encoding or validation, creating cross-site scripting (XSS) vulnerabilities. When user input is returned in HTTP responses without sanitization, attackers can inject malicious scripts that execute in other users' browsers, potentially stealing session tokens, performing unauthorized actions, or redirecting users to malicious sites.

The Django application uses FileResponse with user-controlled file paths from request data without proper validation, enabling path traversal attacks. Attackers can manipulate file paths in requests to access files outside the intended directory structure, potentially exposing sensitive system files, configuration data, database files, or other restricted content through the FileResponse mechanism.

The Django application uses file write operations with user-controlled paths or content from request data without proper validation, enabling path traversal attacks and arbitrary file write vulnerabilities. Attackers can manipulate file paths and content to write files outside the intended directory structure, potentially overwriting critical system files, configuration files, or injecting malicious content into application files.

The Django application uses raw SQL queries with user-controlled input, creating SQL injection vulnerabilities. When user input is directly incorporated into raw SQL statements without proper parameterization, attackers can inject malicious SQL code to manipulate database queries, potentially accessing unauthorized data, modifying database contents, executing arbitrary database commands, or escalating privileges.

The Django application uses the ORM's extra() method with user-controlled input, creating SQL injection vulnerabilities. When user input is directly incorporated into extra() method parameters like select, where, or tables without proper sanitization, attackers can inject malicious SQL code to manipulate database queries, potentially accessing unauthorized data, modifying database contents, or executing arbitrary database commands.

SQL injection vulnerabilities in Django occur when user input is directly concatenated or interpolated into raw SQL queries without proper parameterization. This allows attackers to manipulate database queries, potentially leading to unauthorized data access, data modification, privilege escalation, and complete database compromise.

SQL injection vulnerability where untrusted request values are inserted into raw SQL strings without parameterization when calling QuerySet.raw(), potentially allowing attackers to read, modify, or delete database data and execute unintended SQL commands.

The Django application uses the requests library with user-controlled URLs without proper validation, creating Server-Side Request Forgery (SSRF) vulnerabilities. Attackers can manipulate URLs to make the server perform HTTP requests to internal resources, cloud metadata services, or arbitrary external systems, potentially accessing sensitive information, performing internal network reconnaissance, or bypassing security controls.

SQL injection vulnerability where user-controlled request data is interpolated into SQL strings instead of using parameters or the ORM, potentially allowing attackers to exfiltrate or corrupt data, escalate privileges, or destroy tables.

The Django application constructs URLs using user-controlled host values without proper validation, creating URL host injection vulnerabilities. Attackers can manipulate host parameters to redirect users to malicious domains, perform Server-Side Request Forgery (SSRF) attacks, or bypass security controls by injecting arbitrary hosts into URL construction, potentially leading to phishing attacks, credential theft, or internal network access.

The Flask application has debug mode enabled, which exposes sensitive information and creates security vulnerabilities in production environments. Debug mode provides detailed error messages, interactive debugger access, automatic code reloading, and stack traces that can reveal internal application structure, file paths, source code, and configuration details to attackers, potentially facilitating further attacks.

The Flask application directly returns format strings containing user input without proper escaping or validation, creating format string injection vulnerabilities. When user-controlled data is incorporated into format strings that are then returned in HTTP responses, attackers can inject format specifiers to access memory, read sensitive data, cause application crashes, or potentially achieve code execution through format string exploitation.

The Flask application trusts and uses the Host header from HTTP requests without proper validation, creating Host header injection vulnerabilities. Attackers can manipulate the Host header to perform cache poisoning attacks, password reset poisoning, Server-Side Request Forgery (SSRF), or bypass security controls that rely on hostname validation, potentially leading to unauthorized access, phishing attacks, or internal network reconnaissance.

XSS vulnerability in Flask applications where response content is built with make_response and renders untrusted data as HTML without auto-escaping or encoding, allowing attackers to execute scripts in users browsers.

The Flask application uses string formatting in API method handlers with user-controlled input without proper validation, creating format string injection vulnerabilities. When user input is incorporated into format strings within API methods, attackers can inject format specifiers to access memory, read sensitive data, cause application crashes, or potentially achieve code execution through format string exploitation in API responses or internal processing.

The Flask application uses os.system() or similar functions with user-controlled input, leading to command injection vulnerabilities. Attackers can execute arbitrary system commands on the server, potentially gaining full control of the system, accessing sensitive files, or compromising the entire infrastructure by injecting malicious commands through user input that gets passed to system command execution functions.

The Flask application uses the open() function with user-controlled file paths without proper validation, enabling path traversal attacks. Attackers can manipulate file paths to access files outside the intended directory structure using sequences like '../' to traverse up the directory tree and access sensitive system files, configuration data, source code, or other restricted content through the Flask application's file handling mechanisms.

The Flask application uses the requests library with user-controlled URLs without proper validation, creating Server-Side Request Forgery (SSRF) vulnerabilities. Attackers can manipulate URLs to make the server perform HTTP requests to internal resources, cloud metadata services, or arbitrary external systems, potentially accessing sensitive information, performing internal network reconnaissance, or bypassing security controls.

The Flask application uses the subprocess module with user-controlled input in an unsafe manner, leading to command injection vulnerabilities. When user input is passed to subprocess functions like subprocess.call(), subprocess.run(), or subprocess.Popen() with shell=True or without proper argument sanitization, attackers can execute arbitrary system commands on the server, potentially gaining full control of the system.

SQL injection vulnerability in Flask applications where user-controlled request data is concatenated or formatted into SQL strings without parameters, allowing attackers to inject arbitrary SQL commands.

Application accepts user-controlled input to construct URL hosts without proper validation or sanitization, enabling potential Host Header Injection attacks, open redirects, or SSRF vulnerabilities.

Application deserializes untrusted data using potentially unsafe methods like pickle, allowing attackers to execute arbitrary code through crafted serialized payloads.

XSS vulnerability in Flask applications where templates are rendered directly with raw Jinja2 without Flask's autoescaping or safe context handling, allowing malicious scripts to execute when untrusted data is rendered in user browsers.

XSS vulnerability in Flask/Jinja2 templates where the safe filter is used to disable autoescaping, rendering raw HTML content directly into pages. When user-controlled data is marked as safe, malicious scripts can execute in user browsers, leading to session theft and data compromise.

A critical vulnerability that occurs when Python applications use string formatting methods (%, f-strings, .format()) to construct SQL queries with user input. This allows attackers to inject malicious SQL code by manipulating the formatting parameters, potentially leading to data theft, database corruption, or unauthorized access.

Jinja2 templates are configured with autoescape disabled, allowing unescaped user input to be rendered directly into HTML, creating Cross-Site Scripting (XSS) vulnerabilities.

jsonpickle deserialization vulnerabilities occur when jsonpickle.decode() processes untrusted data. Unlike standard JSON, jsonpickle preserves Python object types and can reconstruct complex objects including invoking constructors and __reduce__ methods. Attackers can craft malicious payloads that execute arbitrary code during deserialization.

Application decodes JWT tokens without proper signature verification, allowing attackers to forge tokens and bypass authentication or authorization controls.

A critical vulnerability that occurs when AWS Lambda functions using Python and MySQL construct SQL queries by concatenating user input from Lambda events directly into query strings. This serverless environment vulnerability allows attackers to inject malicious SQL code through Lambda event parameters, potentially leading to data theft, database corruption, or unauthorized access to cloud resources.

A critical vulnerability that occurs when AWS Lambda functions using Python and psycopg (PostgreSQL adapter) construct SQL queries by concatenating user input from Lambda events directly into query strings. This serverless environment vulnerability allows attackers to inject malicious SQL code through Lambda event parameters, potentially leading to data theft, database corruption, or unauthorized access to PostgreSQL databases and cloud resources.

Application uses subprocess module in potentially dangerous ways that could lead to command injection vulnerabilities, especially when user input is involved in command construction.

Application uses subprocess with environment variables or arguments derived from user input, potentially allowing command injection or environment manipulation attacks.

Application uses system calls (os.system, subprocess, etc.) with environment variables or arguments derived from user input, potentially allowing command injection or privilege escalation attacks.

Application uses the eval() function which can execute arbitrary Python code, creating serious security risks including remote code execution when processing untrusted input.

Application uses the exec() function which can execute arbitrary Python statements, creating critical security risks including remote code execution when processing untrusted input.

SQL injection vulnerability in Python applications where SQL query strings are built via string formatting or f-strings before database execute() calls, allowing attackers to inject malicious SQL commands.

Application uses HTTP (unencrypted) connections within a requests session context manager, exposing data transmission to eavesdropping and man-in-the-middle attacks.

Application uses requests.Session() to make HTTP (unencrypted) connections, exposing sensitive data to eavesdropping, man-in-the-middle attacks, and data interception.

Application uses the requests library to make HTTP (unencrypted) connections, exposing transmitted data to eavesdropping, tampering, and man-in-the-middle attacks.

Application uses urllib.request.urlopen() with FTP URLs, which transmit data in plaintext including credentials, exposing sensitive information to network eavesdropping.

Application uses urllib.request.urlopen() or urllib2.urlopen() with HTTP URLs, exposing data transmission to eavesdropping and man-in-the-middle attacks.

Application uses urllib.request.urlretrieve() with FTP URLs to download files, transmitting data and credentials in plaintext over insecure FTP connections.

Application uses urllib.request.urlretrieve() with HTTP URLs to download files, exposing data transmission to eavesdropping and potential file tampering during transfer.

Application uses Mako templates which can execute arbitrary Python code if user input reaches template rendering, creating potential remote code execution vulnerabilities.

Application uses MD5 for password hashing, which is cryptographically broken and vulnerable to rainbow table attacks, collision attacks, and brute force attacks.

SQL injection vulnerability in Python async applications using aiopg where SQL queries are assembled using string concatenation or formatting with variables instead of bound parameters.