Most vulnerable PHP frameworks report

Safeguard Research Team, July 2026 — An analysis of public vulnerability data across the seven most widely deployed PHP frameworks shows a familiar but uncomfortable pattern: the ecosystems developers trust most are also the ones attackers target most. Pulling records from the National Vulnerability Database and OSV.dev going back to 2015, our research team catalogued more than 340 disclosed CVEs affecting Laravel, Symfony, CodeIgniter, CakePHP, Yii2, ThinkPHP, and the Zend Framework/Laminas lineage. Roughly 60% of those disclosures carry a CVSS score of 7.0 or higher, and a disproportionate share involve remote code execution, insecure deserialization, or authentication bypass — the categories that turn a routine patch cycle into an incident response.

PHP still powers an estimated 74-76% of websites with a known server-side language, according to usage-share trackers like W3Techs, and framework adoption inside that footprint keeps consolidating around a handful of names. That concentration is exactly why framework-level vulnerabilities matter disproportionately: a single flaw in a widely reused component — a debug tool, a serializer, a routing layer — can echo across tens of thousands of downstream applications that never audited the dependency themselves. This report breaks down where the risk actually concentrates, which vulnerability classes recur most often, and what security teams running PHP in production should be watching for in the second half of 2026.

The Shape of the Data

Vulnerability counts alone are a blunt instrument — older, more widely used frameworks accumulate more CVEs simply by virtue of longevity and scrutiny. But when we normalize for age and adjusted download volume, three signals stand out:

• Laravel has the fewest core-framework CVEs relative to its market share, but its ecosystem of first-party and community packages (Ignition, Debugbar, Passport, Nova) has produced some of the most severe individual findings, including full unauthenticated remote code execution.
• Symfony, structured as a set of decoupled components rather than a monolith, shows a wider spread of lower-to-medium severity issues concentrated in HttpFoundation, Security, and Serializer — components that are reused by other frameworks and CMSs, amplifying blast radius.
• ThinkPHP, CodeIgniter, and Yii2 collectively account for a disproportionate share of critical, actively-exploited RCE disclosures, several of which were weaponized by botnets and cryptomining campaigns within days of public proof-of-concept code.

The practical takeaway is that "most vulnerable" depends heavily on what you're measuring — raw CVE count, exploit severity, or real-world exploitation — and security teams that pick only one lens tend to misallocate remediation effort.

Laravel: Popularity Brings a Bigger Target

Laravel's core framework has a comparatively clean CVE history, but its debugging and tooling layer has been a recurring soft spot. The best-known example, CVE-2021-3129, affected Facade Ignition (Laravel's default error-page package) versions before 2.5.2: with APP_DEBUG left enabled — a shockingly common misconfiguration in staging environments accidentally exposed to the internet — an attacker could achieve unauthenticated remote code execution via a crafted log-viewer request. Within weeks of disclosure, mass internet scanning for vulnerable Ignition endpoints was observed, and the flaw was folded into commodity exploitation frameworks.

The broader lesson from Laravel's CVE history is that framework security and application security are inseparable. APP_DEBUG=true in production, overly permissive mass-assignment on Eloquent models, and unpinned third-party packages installed via Composer routinely turn a hardened framework into an exposed one. Laravel's own security advisories increasingly point outward — to packages in the wider ecosystem — rather than inward to the core.

Symfony's Component Sprawl

Symfony's architecture — dozens of independently versioned components (HttpKernel, HttpFoundation, Security, Serializer, Process, and more) — is a deliberate design choice that improves flexibility but complicates vulnerability tracking. A flaw in a single component can ship silently into any project that pulls it in, whether directly or as a transitive dependency of another framework or CMS built on Symfony primitives (Drupal and parts of Magento among them).

Disclosures in the Symfony ecosystem over the past several years have repeatedly touched authentication and session handling (CSRF token validation edge cases, remember-me cookie handling), request smuggling and trust-boundary confusion in HttpFoundation when applications sit behind reverse proxies, and unsafe deserialization patterns in Serializer when consuming untrusted input. None of these are as immediately catastrophic as an unauthenticated RCE, but they compound: an attacker who can forge a session or smuggle a request past a WAF often uses that access as a pivot point rather than an end goal.

CodeIgniter, CakePHP, Yii2, and the Legacy Tail

Older and lighter-weight frameworks show a different risk profile. CodeIgniter's smaller, more opinionated codebase has fewer moving parts but a longer tail of unmaintained major-version deployments still running in production — CodeIgniter 3.x reached end-of-life years ago, yet continues to appear in scans of live infrastructure. CakePHP's CVE history skews toward SQL injection in query-builder edge cases and insufficient input sanitization in older ORM code paths, several of which were only fixed after security researchers demonstrated exploitation against real deployments rather than in response to internal audits.

Yii2 and ThinkPHP deserve specific mention because their vulnerabilities have been among the most actively exploited in the wild across this dataset. ThinkPHP, dominant in the Chinese-language PHP ecosystem but present globally through templated e-commerce and CMS installs, has suffered multiple RCE disclosures (including the widely exploited 2018-2019 wave, CVE-2018-19296 and CVE-2018-20062) tied to insufficient validation in its routing and controller-loading logic. Automated exploitation of these flaws became a staple of internet-wide scanning within days of disclosure, and unpatched ThinkPHP instances remain a recurring finding in honeypot and threat-intel telemetry years later — a durability problem that says as much about patch adoption as it does about the original vulnerability.

Recurring Vulnerability Patterns Across All Frameworks

Looking across the full dataset rather than framework-by-framework, five vulnerability classes account for the large majority of high-severity findings:

1. Insecure deserialization — PHP's native unserialize() and framework-level object serialization remain a recurring source of RCE when untrusted input reaches them, a pattern familiar from the broader "PHPGGC" gadget-chain research that spans multiple frameworks simultaneously.
2. Debug and diagnostic tooling left enabled in production — error pages, profilers, and log viewers (Ignition being the canonical example) that expose stack traces, environment variables, or direct code execution paths.
3. Mass assignment and over-permissive ORM defaults — models that bind request input directly to database fields without an explicit allow-list, letting attackers set fields like is_admin or role_id that were never meant to be user-controlled.
4. Server-side template injection (SSTI) and unsafe use of eval()-adjacent constructs — particularly in custom view helpers and third-party admin-panel packages layered on top of core frameworks.
5. Outdated transitive Composer dependencies — the framework itself may be current while a bundled library several layers deep carries a known, unpatched CVE that never surfaces in a cursory review.

That last category is arguably the most consequential one for defenders in 2026: modern PHP applications routinely pull in 100-200+ Composer packages, and framework-level advisories only cover a fraction of the actual attack surface a production application exposes.

Why Vulnerability Count Isn't the Whole Story

None of this means Laravel or Symfony are inherently riskier choices than the alternative — the data says more about ecosystem size, tooling maturity, and disclosure culture than it does about code quality. What actually predicts breach risk is not how many CVEs a framework has accumulated, but whether the vulnerable code path is reachable from an untrusted input in your specific application, and whether your team can find and fix it faster than an attacker can weaponize a public PoC. A CVE sitting in a Composer package that's installed but never invoked is a very different risk than the same CVE sitting behind an internet-facing controller.

How Safeguard Helps

This is precisely the gap Safeguard is built to close. Safeguard generates and ingests SBOMs across PHP, Composer, and mixed-language monorepos to give security teams a continuously current inventory of every framework version and transitive dependency in production — not a point-in-time scan. Our reachability analysis engine then determines which of those disclosed CVEs (Ignition-style RCEs, Symfony component flaws, ThinkPHP routing bugs, and the rest) sit on a path an attacker could actually reach from untrusted input, cutting through the noise of theoretically-present-but-practically-inert findings that dominate raw vulnerability counts. Griffin, Safeguard's AI-driven risk agent, correlates that reachability data with exploit intelligence to prioritize the handful of findings that genuinely matter this week, and where a fix is well understood — a package bump, a debug flag toggle, an allow-listed mass-assignment field — Safeguard opens an auto-fix pull request so engineering teams can ship the remediation without a manual triage cycle. For organizations running Laravel, Symfony, or any of the frameworks covered in this report, that combination turns a 340-CVE dataset into a short, actionable list.