Common Software Vulnerabilities

Lead Summary

Software vulnerabilities are flaws in code, design, or configuration that attackers can exploit to gain unauthorized access, steal data, disrupt services, or escalate privileges. The challenge is not identifying that vulnerabilities exist — it is keeping up with their volume, prioritizing the right ones to fix, and building defenses that hold across an ever-widening attack surface. FIRST forecasts approximately 59,000 new CVEs in 2026 alone, making systematic triage not optional but operationally necessary.

This article covers the major vulnerability categories that dominate real-world attacks — broken access control, injection, cryptographic failures, and supply chain compromise — alongside the frameworks and tooling used to prioritize remediation. It also examines the emerging challenges posed by AI-generated code and post-quantum cryptography migration.

---

Classification & Taxonomy

The OWASP Top 10:2025 is the dominant industry reference for classifying web application vulnerability risk. The five categories most relevant to day-to-day development work are:

• Broken Access Control (A01) — failures to enforce who can do what, including IDOR, privilege escalation, and BOLA
• Cryptographic Failures (A04) — weak algorithms, unencrypted transmission, poor key management
• Injection (A05) — SQL injection, XSS, command injection, and the emerging class of prompt injection in AI systems
• Supply Chain Vulnerabilities — typosquatting, malicious packages, and dependency confusion
• Business Logic Vulnerabilities — application-specific flaws that automated scanners cannot detect

Beyond OWASP, the Common Weakness Enumeration (CWE) taxonomy provides finer-grained categories — the injection category alone maps to 37 distinct CWEs and over 51,000 CVEs.

---

Broken Access Control

Prevalence

Broken Access Control has held the #1 position in the OWASP Top 10 for two consecutive cycles, including the 2025 edition. Every application tested was found to have some form of broken access control vulnerability. This near-universal prevalence reflects how easy it is to implement authorization checks inconsistently across a large codebase, especially as new routes, endpoints, and features are added over time.

Horizontal and Vertical Escalation

Access control failures fall into two structural patterns:

• Horizontal privilege escalation — a user accesses another user's data at the same privilege level. The classic exploit involves changing a URL parameter: replacing ?id=123 with ?id=124 to read a different user's record without additional authentication. In 2015, a Facebook IDOR vulnerability demonstrated exactly this pattern.
• Vertical privilege escalation — a user accesses functions restricted to a higher role. For example, an unprotected /admin/deleteUser endpoint accessible to regular users because the authorization check was omitted or bypassed.

100% of applications tested in the OWASP Top 10:2025 data set had some form of broken access control vulnerability.

BOLA: The #1 API Security Risk

Broken Object Level Authorization (BOLA), also known as Insecure Direct Object References (IDOR), is the #1 API security risk since 2019 and accounts for approximately 40% of all API attacks. BOLA occurs when an API does not properly enforce authorization checks at the object level, allowing manipulation of resource identifiers to access unauthorized data.

What makes BOLA particularly dangerous is that it requires no sophisticated exploits — an attacker only needs to increment or modify an object ID. Notable real-world exploits include:

• Uber (2016): Attackers accessed driver and rider information by manipulating user IDs.
• Russia's Central Bank (2016): Unauthorized financial transfers were made by changing account IDs.
• Parler (2021): Researchers downloaded unprotected media files by incrementing object IDs.
• Kia and Hyundai (June 2024): Researchers discovered attackers could access authenticated APIs using only a license plate number or VIN, demonstrating the real stakes in safety-critical systems.

Mitigations

Role-Based Access Control (RBAC) combined with the principle of least privilege is the primary mitigation: enforce strict server-side validation before executing any privileged action, and grant users only the minimum permissions their role requires. Testing involves tools like Burp Suite and OWASP ZAP to probe authorization logic and verify that role restrictions hold.

An alternative architectural approach is capability-based security, where access rights are bound to unforgeable tokens held by programs rather than centralized access control lists. This design eliminates the ambient authority problem and the confused deputy problem by construction — programs cannot exercise permissions they are not explicitly holding.

---

Injection Vulnerabilities

Scope

The injection category encompasses 37 CWEs and over 51,000 CVEs. All injection flaws share a single root cause: untrusted input is passed to an interpreter without proper neutralization, allowing attackers to alter the intended command structure. Injection dropped from #3 (OWASP 2021) to #5 (OWASP 2025) due to the emergence of other critical categories in cloud environments, but it remains nearly universal — 100% of applications are screened for some form of injection.

SQL Injection

SQL injection has generated over 14,000 CVEs and persists because the antipattern is remarkably easy to introduce. When a developer writes "SELECT * FROM users WHERE id = " + userId, an attacker who supplies "1; DROP TABLE users; --" can delete the entire table. The fix is equally straightforward:

• Parameterized queries and prepared statements — the SQL structure is compiled before any user input is inserted; the database engine can then never interpret the data as code. This is documented in the OWASP SQL Injection Prevention Cheat Sheet.
• ORM frameworks (SQLAlchemy, Hibernate, Entity Framework) — handle queries through type-safe abstractions that parameterize data automatically.

Cross-Site Scripting (XSS)

XSS is the most frequently occurring injection type with over 30,000 CVEs. XSS occurs when untrusted input is included in web pages without proper encoding, allowing injected scripts to execute in other users' browsers.

Prevention requires context-aware output encoding. The same user data needs different encoding depending on where it appears:

• HTML body → HTML encoding (< becomes <)
• JavaScript context → JavaScript encoding (escaping quotes and line terminators)
• URL parameters → URL encoding
• CSS properties → CSS encoding

A common mistake is applying only HTML encoding when data is used in JavaScript, leaving an XSS vector open because the HTML parser and the JavaScript engine operate at different layers.

For DOM manipulation, using textContent and innerText instead of innerHTML ensures user input is always treated as text, never as HTML markup.

Modern frameworks (React, Angular, Django, Spring) provide built-in output encoding applied automatically by their templating systems — using framework utilities reduces the risk of encoding errors in custom implementations.

Command Injection

Command injection vulnerabilities continue to affect network edge devices in 2024–2025, including CVE-2024-20399, CVE-2024-3400, and CVE-2024-21887, which allowed remote code execution on network appliances without authentication. The U.S. CISA and FBI issued a Secure by Design Alert in January 2026 highlighting that OS command injection vulnerabilities are preventable yet continue to surface in critical infrastructure.

Prompt Injection: An Emerging Class

Prompt injection is a new injection vulnerability class that emerged in 2025 with the widespread deployment of large language models. The structural pattern is identical to traditional injection: untrusted input is concatenated into a command (the prompt) sent to an interpreter (the LLM), which cannot distinguish between the original system prompt and injected attacker instructions.

A notable example is CVE-2025-53773, which affected GitHub Copilot and allowed remote code execution through prompt injection, potentially compromising millions of developer machines.

Input Validation Principles

Across all injection types, the same defensive philosophy applies:

1. Server-side validation is mandatory — client-side validation provides user experience benefits but can be trivially bypassed by manipulating DOM elements, disabling JavaScript, or making raw HTTP requests.
2. Allowlisting over denylisting — defining what is acceptable (a 10-digit numeric ID) is more reliable than attempting to block all known dangerous patterns. Denylists are inherently incomplete and attackers continually discover new bypass patterns.
3. Layered defense — combining input validation with output encoding provides redundancy; if one layer has an edge case, the other continues to protect.

---

Cryptographic Failures

OWASP Top 10:2025 lists Cryptographic Failures as A04, encompassing a consistent set of patterns: unencrypted data transmission, deprecated algorithms, hardcoded keys, missing authenticated encryption, and predictable random values.

Deprecated Algorithms

Deprecated algorithms — MD5, SHA-1, RC4, DES, RSA with 1024-bit keys, SSL/TLS 1.0/1.1 — must be eliminated from new systems and phased out from existing ones. These algorithms have known practical attacks: MD5 and SHA-1 suffer collision vulnerabilities, RC4 has keystream biases, DES has inadequate key size, and older TLS versions lack forward secrecy.

Modern replacements: AES-GCM or ChaCha20-Poly1305 for symmetric encryption, SHA-2 or SHA-3 for hashing, RSA-2048+ or ECC for asymmetric operations, TLS 1.2 or 1.3 for transport.

Authenticated Encryption

AEAD (Authenticated Encryption with Associated Data) algorithms — AES-GCM and ChaCha20-Poly1305 — should be the default choice, replacing the outdated pattern of separate encryption and MAC operations. AEAD combines encryption and authentication in a single operation, preventing entire classes of cryptographic weaknesses. ChaCha20-Poly1305 is standardized in RFC 7539 and offers superior performance on mobile devices without AES-NI hardware acceleration.

Hardcoded Keys and Secrets Management

Hardcoded cryptographic keys (CWE-321) directly undermine encryption security. Once a hardcoded key is discovered — trivially, even in compiled binaries via entropy analysis — the corresponding ciphertext can be decrypted. Modern SAST tools can detect 170+ types of credentials across 60+ programming languages, and pre-commit hooks can prevent secrets from entering version control.

Cryptographic keys and secrets should be managed through dedicated secrets management systems (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) or Hardware Security Modules, with centralized access controls and audit logging.

Passwords

Passwords must be stored using computationally slow hashing functions — bcrypt, scrypt, or Argon2 — rather than fast algorithms like MD5 or SHA-256. Weak password storage enables rapid offline attacks: an attacker who gains database access can crack all passwords using pre-computed rainbow tables when fast, unsalted hashes are used.

Randomness

Weak pseudo-random number generators (CWE-338) in cryptographic contexts are a common failure pattern. All cryptographic operations — key generation, nonce creation, initialization vectors — must use cryptographically secure random number generators (CSPRNGs) provided by the operating system or vetted libraries. Reusing nonces in stream ciphers completely breaks confidentiality.

Post-Quantum Cryptography Migration

NIST has finalized two post-quantum standards:

• ML-KEM (FIPS 203) for key encapsulation. ML-KEM-768 is the practical starting point for most enterprise deployments, balancing size overhead with NIST Category 3 security margins.
• ML-DSA (FIPS 204) for digital signatures. ML-DSA-65 is appropriate for enterprise applications; ML-DSA-87 is required under CNSA 2.0 for U.S. national security systems.

The recommended transitional approach for TLS is hybrid key exchange — combining classical algorithms (X25519, P-256) with post-quantum algorithms (ML-KEM-768) in a single handshake. Modern browsers already support X25519MLKEM768. An adversary must compromise both classical and post-quantum algorithms to decrypt traffic, significantly reducing the HNDL risk during the migration window.

Cryptographic agility — the ability to swap algorithms without rewriting application logic — is now a first-class design requirement per NIST Cybersecurity White Paper 39 (2025). A system built with hardcoded RSA-2048 in 2026 will require major rewrites during post-quantum migration; a system with algorithm-agile design can migrate through configuration changes.

---

Supply Chain Vulnerabilities

Scale of the Problem

Over 454,600 malicious packages were identified across npm, PyPI, and other package ecosystems in 2025, employing techniques including typosquatting, namespace confusion, toolchain masquerading, staged payloads, credential theft, and self-replicating malware. This represents a 73% increase in malware detections over the prior year.

Typosquatting

PyPI removes hundreds of malicious typosquatting packages every month. The crossenv attack (2017) compromised over 700 hosts by exploiting confusion with the legitimate cross-env package. Earlier research in 2016 demonstrated that uploading malicious packages with slightly misspelled names across PyPI, npm, and RubyGems could infect over 17,000 machines — establishing typosquatting as a systematic attack vector with demonstrated real-world impact.

Credential Theft and Developer Account Compromise

Supply chain compromises consistently begin with compromised developer credentials and OAuth tokens. CISA's September 2025 advisory specifically recommends phishing-resistant MFA on all developer accounts. Hardware keys and Windows Hello prevent the credential replay attacks that SMS/TOTP-based MFA cannot defend against.

Regulation

CISA and NTIA mandate Software Bill of Materials (SBOM) adoption for U.S. government contractors and critical infrastructure providers, using standardized formats (CycloneDX, SPDX) integrated into CI/CD pipelines. The EU Cyber Resilience Act (CRA), operative September 2026, shifts liability from open-source developers onto software manufacturers who distribute or integrate those components — creating financial incentives for vendors to invest in supply chain security and dependency management.

---

Business Logic Vulnerabilities

Business logic vulnerabilities exploit legitimate workflows in unintended ways. They are not CVE-trackable and are largely invisible to automated security scanners — requiring domain-aware manual testing rather than pattern matching to detect.

There has been a 59% year-over-year increase in API attacks exploiting business logic flaws, indicating that attackers increasingly target application logic rather than traditional technical vulnerabilities.

Real-World Examples

• Coupon stacking: Payment systems that fail to atomically mark single-use coupons as redeemed can be exploited via concurrent requests — submitting the same coupon in rapid parallel calls before the first redemption is recorded. A race condition in Stripe's discount system illustrated how an initial fix can still fail without proper atomicity guarantees.
• Stripe race condition: Researchers demonstrated that even after Stripe added a redemption check, concurrent requests could still bypass it, showing how business logic fixes require atomic operations not just sequential validation.

Preventing business logic vulnerabilities requires design-phase security planning — threat modeling, workflow analysis, and design-stage consideration of misuse cases — rather than implementation-level fixes alone.

---

Vulnerability Prioritization

The CVSS Problem

CVSS was architected to compare technical severity — answering "is this vulnerability worse than that one?" — not to answer "which vulnerability should we patch first?" CVSS 2.0 through 3.1 explicitly lacked exploitation likelihood metrics; CVSS 4.0 added exploitability factors but only 24–25.9% of 2025 CVEs had CVSS v4.0 scores, with major vendors (NVD, Microsoft, Red Hat, Cisco) still predominantly publishing v3.1.

More critically, only 2–3% of CVEs scored CVSS 7+ are ever exploited, while approximately 28% of actually-exploited vulnerabilities in Q1 2025 carried only medium CVSS scores. CVSS-only prioritization systematically deprioritizes what attackers are actively exploiting.

Multi-Metric Prioritization

Industry consensus has shifted to combining three complementary signals:

Signal	System	Question answered
Technical severity	CVSS	How bad could this be if exploited?
Exploitation probability	EPSS	How likely is this to be exploited in the next 30 days?
Confirmed exploitation	KEV	Is this being actively weaponized right now?

This composite approach reduces the urgent patch workload by approximately 95% compared to CVSS-alone triage.

EPSS v4 (released March 2025) consumes over 250,000 threat intelligence data points daily and can score CVEs before they appear in the National Vulnerability Database, enabling earlier prioritization.

CISA's Known Exploited Vulnerabilities (KEV) catalog lists CVEs with confirmed in-the-wild exploitation. Federal civilian agencies must remediate KEV-listed vulnerabilities under Binding Operational Directive (BOD) 22-01; CISA is exploring reducing patch deadlines from 2–3 weeks to 3 days.

Context Matters

Two vulnerabilities with identical CVSS scores can carry vastly different real-world risk: asset exposure, asset criticality, and available mitigations all change the effective priority. This is why Carnegie Mellon's Stakeholder-Specific Vulnerability Categorization (SSVC), adopted by CISA, uses role-based decision trees that output action-oriented outcomes — Track, Track*, Attend, Act — rather than numeric scores.

32.1% of exploited vulnerabilities in 1H 2025 were attacked on or before the day of CVE disclosure, demonstrating that defenders have extremely narrow response windows and that post-disclosure CVSS scoring alone is inherently reactive.

---

AI-Generated Code and Security

AI-assisted code generation introduces a new dimension to vulnerability risk. Security vulnerabilities appear in AI-generated code at 1.5–2.74x the rate of human-written code, with 29–45% of AI-generated code containing security vulnerabilities in studies. When prompted specifically for cybersecurity scenarios, GitHub Copilot produced security-related bugs in 40% of suggestions.

The most prevalent CWE categories in AI-generated code include OS Command Injection (CWE-78), Use of Insufficiently Random Values (CWE-330), and hardcoded credentials. Notably, the majority of security defects in open-source software — both human and AI-generated — are caused by semantic bugs, meaning application-logic flaws rather than memory-safety issues.

On the defense side, Google deployed hardened libc++ across its entire production server fleet with an average performance cost of 0.30%, uncovering more than 1,000 memory safety bugs and contributing to a 30% reduction in baseline segmentation faults — demonstrating that hardened standard library implementations provide measurable benefits at negligible cost.

---

Controversies & Debates

CVSS as the de facto standard: CVSS is widely used because it is well-known and tooling integrates with it, but empirical evidence consistently shows it predicts exploitation poorly. The debate in the industry is whether to augment CVSS with EPSS/KEV (the emerging consensus) or replace it entirely with frameworks like SSVC.

AI-generated code security: Some argue AI tools reduce vulnerability introduction by catching common antipatterns. Others point to empirical studies showing 1.5–2.74x higher vulnerability rates. The honest position is that current AI code generation tools do not reliably produce secure code in security-sensitive contexts.

PQC migration urgency: The commercial quantum computing timeline is uncertain, but the Harvest Now, Decrypt Later threat is not speculative — it operates on the assumption that adversaries are already collecting encrypted traffic. The debate is not whether to migrate but at what pace.