A05:2025 - Injection: The Persistent Threat That Continues to Plague Modern Applications

Injection has dropped two positions from number three in the 2021 OWASP Top 10 to number five in 2025, but this shift doesn't indicate reduced risk. Rather, it reflects the emergence of new critical threats in the modern application landscape. What makes this ranking particularly concerning is that injection affects one hundred percent of tested applications in some form, making it the most universally present vulnerability category.

The category encompasses 37 different Common Weakness Enumerations (CWEs) and has generated more than 51,000 CVEs, making it the category with the greatest number of reported vulnerabilities. From SQL injection with over 14,000 CVEs to Cross-Site Scripting with more than 30,000 CVEs, injection vulnerabilities represent a massive attack surface that continues to be actively exploited.

What Are Injection Attacks?

An injection vulnerability occurs when untrusted user input is sent to an interpreter as part of a command or query without proper validation or sanitization. The interpreter—whether it's a database, browser, operating system shell, or template engine—cannot distinguish between legitimate commands and malicious input, leading it to execute attacker-controlled code.

The fundamental problem lies in failing to keep data separate from commands and queries. When applications concatenate user input directly into SQL queries, system commands, or HTML output, they create opportunities for attackers to break out of the data context and inject their own commands that the system will execute with the application's privileges.

The Spectrum of Injection Attacks

SQL Injection: Low Frequency, High Impact

SQL injection allows attackers to manipulate database queries by inserting malicious SQL code through application inputs. Despite having fewer total CVEs compared to XSS, SQL injection is characterized as low frequency but high impact because successful exploits can lead to complete database compromise.

Consider a vulnerable login form that constructs queries like this:

SELECT * FROM users WHERE username = ' + userInput + ' AND password = ' + passwordInput + '

An attacker can input admin' -- as the username, transforming the query into:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

The double dash comments out the password check, allowing the attacker to log in as admin without knowing the password. More sophisticated attacks can use UNION statements to extract data from other tables, stacked queries to modify data, or time-based blind injection to exfiltrate information even when direct output is not visible.

Recent incidents in 2025 demonstrate that SQL injection remains actively exploited. A PostgreSQL vulnerability discovered in February 2025 (CVE-2025-1094) with a CVSS score of 8.1 bypassed supposedly safe string escaping routines. In May 2025, a government portal was breached via SQL injection, exposing sensitive citizen data. The Marriott International breach, which began in 2014 but was only discovered in 2018, compromised 500 million guest records through SQL injection combined with network infrastructure weaknesses.

Cross-Site Scripting: High Frequency, Lower Impact

Cross-Site Scripting has generated over 30,000 CVEs, making it the most frequently occurring injection type. XSS occurs when applications include untrusted data in web pages without proper validation or encoding, allowing attackers to inject client-side scripts that execute in victims' browsers.

XSS vulnerabilities come in three main forms. Reflected XSS occurs when malicious scripts are immediately returned in responses to HTTP requests, typically through URL parameters or form submissions. Stored XSS (also called persistent XSS) happens when injected scripts are permanently stored on target servers in databases or file systems, then retrieved and executed by other users. DOM-based XSS exists in client-side code where JavaScript processes user input in unsafe ways without proper validation.

While individual XSS attacks may have lower impact than SQL injection, they enable serious consequences when chained with other vulnerabilities. Attackers can steal session cookies for account takeover, perform actions on behalf of authenticated users, deploy keyloggers to capture credentials, redirect users to phishing sites, or deliver malware. Microsoft's security research in November 2025 highlighted how XSS can be weaponized through chaining with open redirects, CSRF vulnerabilities, weak Content Security Policies, and insecure postMessage implementations to achieve remote code execution.

Recent XSS vulnerabilities continue to surface across major platforms. Citrix NetScaler ADC and Gateway disclosed CVE-2025-12101 in November 2025, a reflected XSS flaw with CVSS 5.9 that could lead to session hijacking and credential theft. Cisco's IOS XE Software had a reflected XSS vulnerability in its Web Authentication feature, allowing attackers to steal user cookies. Even modern applications remain vulnerable, as demonstrated by a stored XSS vulnerability in Homarr that allowed privilege escalation to full administrative access through malicious SVG uploads.

Command Injection: Direct System Compromise

Operating system command injection enables attackers to execute arbitrary commands on servers running vulnerable applications. This vulnerability type is particularly dangerous because successful exploitation often grants attackers complete control over the underlying system.

Command injection occurs when applications invoke system commands with user-supplied input without proper validation. Attackers insert shell metacharacters like semicolons, pipes, ampersands, and backticks to chain additional commands or redirect execution.

The U.S. CISA and FBI issued a Secure by Design Alert in January 2026 highlighting that OS command injection vulnerabilities remain preventable yet continue to surface in critical infrastructure. Recent well-publicized campaigns exploited command injection defects in network edge devices including CVE-2024-20399, CVE-2024-3400, and CVE-2024-21887, allowing unauthenticated actors to remotely execute code.

In December 2025, JPCERT confirmed active exploitation of a command injection vulnerability in Array Networks AG Series secure access gateways since August 2025. Attackers exploited the DesktopDirect feature to drop web shells on susceptible devices. Palo Alto Networks disclosed two command injection vulnerabilities in June 2025 (CVE-2025-4230 and CVE-2025-4231) affecting PAN-OS software, enabling authenticated administrators to bypass restrictions and execute arbitrary commands as root.

Other Injection Types

Beyond the major categories, injection attacks target numerous other interpreters. LDAP injection manipulates directory service queries to bypass authentication or extract directory information. XML injection and XXE (XML External Entity) attacks exploit XML parsers to read local files, perform SSRF attacks, or cause denial of service. Template injection abuses server-side template engines to execute arbitrary code. NoSQL injection targets document databases like MongoDB through improper query construction. Email header injection inserts malicious headers to send spam or phishing emails through vulnerable mail forms.

Why Injection Persists in 2025

Given that injection vulnerabilities have been well-understood since the late 1990s, why do they continue to plague modern applications? Several factors contribute to this persistence.

• Developer Convenience Over Security
  • Developers often choose convenience over correctness. Concatenating strings to build queries feels natural and requires less initial effort than using parameterized queries or prepared statements. Many developers don't fully understand the security implications until after an incident occurs. Even when using Object-Relational Mapping tools that provide protection by default, developers sometimes bypass these safeguards by dropping down to raw query construction for complex operations.
• Framework Misuse
  • Modern frameworks and ORMs provide protection against injection when used correctly, but improper usage creates vulnerabilities. For example, Sequelize, a popular JavaScript ORM, clearly documents that parameters should not be embedded in strings: "Don't put parameters in strings." Yet developers frequently make this exact mistake, negating the protection the framework provides. Similarly, stored procedures can introduce SQL injection vulnerabilities when they use dynamic SQL construction with string concatenation instead of parameterized queries.
• Legacy Code and Technical Debt
  • Organizations maintain vast codebases with legacy components built before security best practices were widely adopted. Refactoring these systems to eliminate injection vulnerabilities requires significant time and resources that organizations are often reluctant to invest until after a breach occurs.
• Complexity of Modern Applications
  • Modern applications involve multiple layers of technology including front-end frameworks, API gateways, microservices, and various backend systems. Injection vulnerabilities can exist at any of these layers, and the interaction between components can create unexpected attack surfaces. Data that appears safe at one layer might become dangerous when passed to a different interpreter downstream.
• Insufficient Security Training
  • Many development teams lack comprehensive security training. Computer science curricula often treat security as an elective rather than a core requirement, leading to graduates who can build functional applications but don't understand fundamental security principles. Without ongoing security training and awareness programs, developers repeat the same mistakes generation after generation.

Real-World Impact and Consequences

The consequences of injection vulnerabilities extend far beyond technical system compromise. Organizations face massive financial losses, regulatory penalties, reputational damage, and legal liability.

• Financial Impact
  • The Sony Pictures hack in 2013 used SQL injection to steal employee personal information, internal communications, executive pay data, unreleased films, and future plans. The attack cost the company an estimated 15 million dollars in IT remediation alone, not counting lost business, legal fees, and reputational damage.
• Data Breach Scale
  • Modern injection attacks can expose data on a massive scale. The Marriott breach compromised 500 million guest records including names, addresses, phone numbers, email addresses, passport numbers, and payment card information. The Target breach in 2013 exposed 40 million credit card numbers, partly enabled by inadequate encryption allowing attackers to intercept unencrypted data through injection vulnerabilities.
• Regulatory Consequences
  • Under regulations like GDPR, organizations face fines of up to 4% of annual global turnover or 20 million euros (whichever is higher) for data breaches involving inadequate security measures. Injection vulnerabilities that could have been prevented through basic security practices make it difficult for organizations to argue they implemented appropriate technical measures.
• Operational Disruption
  • Beyond data theft, injection attacks can modify or delete critical data, disrupt business operations, and require expensive incident response and recovery efforts. Organizations may need to rebuild compromised systems, conduct forensic investigations, notify affected customers, provide credit monitoring services, and deal with class-action lawsuits.

Detection and Testing Strategies

Identifying injection vulnerabilities requires a comprehensive testing approach combining automated tools, manual testing, and code review.

• Automated Security Testing
  • Static Application Security Testing (SAST) tools analyze source code to identify potential injection vulnerabilities before deployment. These tools can detect unsafe coding patterns like string concatenation in query construction, unvalidated input being passed to system commands, and missing output encoding. Dynamic Application Security Testing (DAST) tools probe running applications by injecting various payloads and observing responses to identify exploitable vulnerabilities.
  • Tools like Burp Suite, OWASP ZAP, and SQLMap can systematically test for injection vulnerabilities across different attack surfaces. Burp Scanner automatically flags potential SQL injection, XSS, and command injection vulnerabilities through both static and dynamic analysis. SQLMap specifically targets SQL injection with advanced techniques including blind injection, time-based attacks, and automatic database enumeration.
• Manual Testing Techniques
  • Automated tools miss many injection vulnerabilities, particularly those involving complex business logic or unusual data flows. Manual testing by skilled security professionals remains essential. Penetration testers systematically manipulate every input field, URL parameter, HTTP header, and cookie value with injection payloads designed to trigger errors, modify application behavior, or extract data.
  • For SQL injection testing, this includes submitting single quotes to trigger syntax errors, using boolean conditions to test for blind injection, employing time delay functions to detect inference-based vulnerabilities, and attempting UNION-based attacks to extract data from other tables. For XSS testing, testers inject various script tags, event handlers, and encoding variations to bypass filters. For command injection, testers insert shell metacharacters and attempt to execute commands that produce observable effects.
• Code Review Best Practices
  • Security-focused code reviews examine source code for injection vulnerabilities by identifying all locations where external input enters the application, tracing data flow from input to output or execution, verifying that proper validation and encoding occurs at appropriate points, and checking that security controls cannot be bypassed.
  • Reviewers should pay particular attention to database query construction, system command execution, HTML output generation, file operations with user-supplied paths, and integration points with external systems. Code review checklists specific to each programming language and framework help ensure consistent coverage.
• Security Testing Integration
  • Security testing should be integrated throughout the software development lifecycle rather than being an afterthought. This includes running SAST tools as part of the build process, performing DAST scans against development and staging environments, requiring security sign-off before production deployment, and conducting periodic penetration tests by external security firms.

Modern DevSecOps practices embed security testing into CI/CD pipelines so that new vulnerabilities are detected and fixed before they reach production. Fail-fast mechanisms can block deployments that introduce high-severity vulnerabilities.

Prevention: Building Injection-Resistant Applications

Preventing injection attacks requires a defense-in-depth approach combining multiple complementary security controls.

• Primary Defense: Separate Data from Code
  • The most effective defense against injection is using APIs and constructs that enforce separation between data and commands. For SQL queries, this means using parameterized queries or prepared statements. Instead of:
  • query = "SELECT * FROM users WHERE id = '" + userId + "'"
  • Use:
  • query = "SELECT * FROM users WHERE id = ?" statement.setString(1, userId)
  • The database driver handles proper escaping and ensures that user input cannot break out of the data context to modify the query structure. This approach works for all major database platforms and programming languages.
  • For command execution, avoid invoking system shells entirely when possible. Use language-specific APIs that directly perform the required operation. For example, instead of using system calls to delete a file, use the language's native file deletion function. When system commands are unavoidable, use APIs that accept commands and arguments as separate parameters rather than single strings that get passed to a shell.
• Input Validation: Defense in Depth
  • While input validation alone cannot prevent injection attacks, it provides valuable defense in depth. Implement positive validation (allow-lists) that explicitly defines acceptable input rather than trying to block known bad patterns. For example, if an input should be numeric, verify it contains only digits. If it should be alphanumeric, reject any special characters.
  • Validation should occur server-side even if client-side validation exists, since client-side controls can be easily bypassed. Apply validation as close to the input source as possible, but recognize that validation requirements may differ at different layers. Data that's safe in one context may be dangerous in another, so context-specific validation is essential.
• Output Encoding: Preventing XSS
  • For XSS prevention, encode output based on the context where it will be used. HTML entity encoding escapes characters like less-than, greater-than, ampersand, and quotes to prevent them from being interpreted as markup. JavaScript encoding handles data being inserted into JavaScript code. URL encoding applies to data included in URLs. CSS encoding protects data used in stylesheets.
  • Modern template engines like React, Angular, and Vue provide automatic output encoding by default. However, developers must avoid using dangerous functions that bypass these protections such as dangerouslySetInnerHTML in React or direct DOM manipulation. When these unsafe patterns are necessary, ensure the data has been passed through an appropriate sanitization library.
• Content Security Policy: Additional XSS Protection
  • Implementing a strong Content Security Policy provides defense-in-depth against XSS attacks. CSP allows you to specify which sources of content browsers should allow to execute. A strict CSP can block inline scripts, require scripts to have cryptographic nonces or hashes, and prevent eval and similar dangerous JavaScript functions.
  • While CSP doesn't prevent XSS vulnerabilities, it significantly limits what attackers can accomplish when they do find injection points. Even if an attacker injects a script tag, if it doesn't have the correct nonce or hash, the browser won't execute it.
• Least Privilege Principle
  • Applications should run with the minimum privileges required to perform their functions. Database connections should use accounts with limited permissions restricted to only the tables and operations needed. Web application processes should run with non-privileged system accounts. This limits the damage attackers can cause even if injection vulnerabilities are exploited.
  • For example, if a web application only needs to read from certain database tables, the database account should not have write, update, or delete privileges. This way, even if attackers achieve SQL injection, they cannot modify or destroy data.
• Web Application Firewalls: Runtime Protection
  • Web Application Firewalls provide runtime protection by inspecting HTTP traffic and blocking requests containing injection attack patterns. While WAFs should not be relied upon as the primary defense, they provide valuable additional protection, particularly for legacy applications that cannot be quickly remediated.
  • Modern WAFs use machine learning to identify attack patterns and can provide virtual patching for known vulnerabilities while patches are being developed and deployed. However, organizations should not become complacent because they have a WAF. Determined attackers often find ways to bypass WAF protections, making underlying application security essential.

Framework and Language-Specific Guidance

Different programming languages and frameworks have specific best practices for preventing injection attacks.

• Python
  • Use parameterized queries with database adapters. Never use string formatting or concatenation to build SQL queries. For command execution, avoid os.system and use subprocess with the shell=False parameter. When shell=True is absolutely necessary, validate inputs extremely carefully and consider using shlex.quote to properly escape arguments.
• Java
  • Use PreparedStatement for all database queries. Never use Statement with string concatenation. Avoid Runtime.exec when possible. If Runtime.exec is necessary, understand that unlike C's system function, it does not invoke a shell by default, but developers sometimes inadvertently invoke shells by passing commands as single strings. Use ProcessBuilder with separate command and argument lists.
• JavaScript/Node.js
  • Use parameterized queries with database libraries like mysql2 or pg. For MongoDB, use the driver's query methods rather than constructing query objects with string interpolation. Avoid eval, Function constructor, and setTimeout/setInterval with string arguments. For XSS prevention, use framework-provided escaping mechanisms and never use innerHTML with untrusted data.
• PHP
  • Use PDO or MySQLi with prepared statements. Never use mysql_* functions which were deprecated and removed. For command execution, avoid exec, system, shell_exec, and backticks when possible. If command execution is necessary, use escapeshellarg to properly quote arguments, but recognize this is error-prone. Consider using libraries that provide safer abstractions.

The Path Forward: Eliminating Injection at Scale

Organizations serious about eliminating injection vulnerabilities need a comprehensive program that goes beyond individual fixes.

• Security Champions Program
  • Designate security champions within development teams who receive advanced security training and serve as security resources for their teams. These champions help review code for security issues, advocate for security best practices, and serve as a bridge between security and development teams.
• Secure Coding Standards
  • Develop and enforce organization-wide secure coding standards that explicitly prohibit dangerous patterns and require safe alternatives. Standards should be specific to the languages and frameworks the organization uses and should be backed by automated enforcement where possible.
• Security Training and Awareness
  • Provide regular security training for all developers covering injection vulnerabilities in depth. Training should be hands-on and include vulnerable code examples, exploitation demonstrations, and secure coding practice. Annual training should be supplemented with just-in-time training when developers work on particularly sensitive components.
• Secure Development Lifecycle
  • Integrate security requirements, design review, threat modeling, security testing, and security sign-off into the standard development process. Security should not be an afterthought but an integral part of how software is built from initial requirements through deployment and maintenance.
• Vulnerability Management Program
  • Establish a clear process for identifying, prioritizing, and remediating security vulnerabilities. This includes regular security testing, bug bounty programs to leverage external researchers, clear SLAs for fixing different severity levels of vulnerabilities, and metrics to track security improvement over time.

Advanced Attack Techniques and Emerging Threats

As defenses improve, attackers develop more sophisticated techniques to bypass protections.

• Second-Order Injection
  • In second-order injection attacks, malicious input is safely stored in a database but later retrieved and used in an unsafe way. The initial input point may have proper validation, but developers assume data from their own database is safe and use it without validation in subsequent operations. These attacks are particularly difficult to detect with automated tools.
• Polyglot Payloads
  • Polyglot payloads are crafted to be valid in multiple contexts simultaneously. For example, a single payload might work as both SQL injection and XSS, or exploit multiple different types of SQL injection. These payloads can bypass filters that check for specific attack patterns.
• Filter Evasion Techniques
  • Attackers employ numerous techniques to bypass input validation and filters including character encoding variations, case manipulation, whitespace insertion, comment insertion within payloads, and using alternative syntax that achieves the same result. Testing must account for these evasion techniques to ensure protections are robust.
• Prompt Injection in LLMs
  • A new class of injection vulnerabilities has emerged with Large Language Models. Prompt injection allows attackers to manipulate LLM behavior by crafting inputs that override system instructions. While this is discussed separately in the OWASP LLM Top 10 as LLM01:2025, it represents an evolution of injection concepts into AI systems.

Conclusion

✅ Injection vulnerabilities represent a fundamental failure to properly separate data from code, a problem that has plagued software development for decades. Despite being well-understood, injection attacks continue to successfully compromise applications worldwide, affecting one hundred percent of tested applications in some form.

✅ The persistence of injection vulnerabilities stems from developer convenience choices, framework misuse, legacy code, application complexity, and insufficient security training. However, injection is entirely preventable through proper application of secure coding practices including parameterized queries, input validation, output encoding, and separation of concerns.

✅ Organizations must move beyond treating injection as an individual bug to be fixed and instead adopt systematic approaches including security champions programs, secure coding standards, comprehensive training, integrated security testing, and strong vulnerability management. The goal should not be to find and fix injection vulnerabilities one at a time, but to build development practices and architectures that make injection vulnerabilities structurally impossible.

✅ As applications continue to evolve with new technologies, new variants of injection attacks will emerge. The fundamental principles of keeping data separate from commands, validating input, encoding output, and applying defense in depth remain constant. By embedding these principles into development culture and practices, organizations can finally eliminate this decades-old class of vulnerability.

✅ The resources exist, the knowledge is available, and the techniques are proven. What's required now is organizational commitment to prioritizing security, investing in developer training and tools, and building systems that are secure by design rather than secured as an afterthought. Only then can we move injection vulnerabilities from affecting one hundred percent of applications to being a historical footnote in the evolution of software security.