The Lazy Take Is Wrong
Flask has 71,767 GitHub stars, 400 listed contributors, and logged 56 commits in the past year. The tempting narrative: low commits equals unmaintained equals dangerous. That narrative is wrong, and publishing it would get picked apart by any security-literate reader in minutes.
Flask core has roughly a dozen CVEs across its entire history. Not 186 — that number, which appears in NVD keyword searches, sweeps in every Flask-AppBuilder, Flask-Security, Flask-CORS, and dozens of other community packages that happen to have “Flask” in the name. Flask itself — the Pallets project at pallets/flask — has a small, well-managed vulnerability history. The current release (3.1.x) is up to date, and critical issues get patched.
Low commit volume on a mature, feature-complete micro-framework is a sign of stability, not rot. The interesting question is not whether Flask is maintained. It is what happens around Flask.
The Extension Surface Is the Real Attack Surface
Flask is deliberately minimal. No ORM, no authentication, no form validation, no CSRF protection, no rate limiting. That is the design philosophy. The consequence is that every production Flask application is actually Flask plus 10 to 20 community extensions that provide the functionality Django and FastAPI include by default.
Each of those extensions has its own maintainer (or lack thereof), its own CVE history, its own release cadence, its own bus factor. When NVD keyword search returns 186 results for “flask,” it is measuring this sprawl — not Flask core. And that sprawl is where the unpatched vulnerabilities accumulate, outside any centralized security governance.
For a CISO, this creates a visibility gap. Django’s 294 CVEs are tracked against a single, well-governed project with a dedicated security team. Flask’s real vulnerability surface is distributed across dozens of independently maintained packages, many of which have no security disclosure process at all.
Slowing Stewardship
The commit count alone does not signal danger. But two other data points do. First, Flask shipped only 2 GitHub releases in the past 12 months. Django shipped more. FastAPI shipped 50. Flask’s release cadence is not rapid iteration — it is a project in “we consider this done” mode.
Second, Miguel Grinberg’s independent review of Flask’s development in 2025 found that the share of pull requests closed without merging jumped from roughly 30% historically to 72%. That is the clearest signal: community contributions are being turned away, not because they are low quality, but because the project’s scope is fixed. Stability, yes. But when a novel vulnerability lands, who responds — and how fast?
Bus Factor
“400 contributors” is GitHub’s all-time count. It means 400 people sent at least one pull request at some point in Flask’s history. It does not mean 400 people are maintaining the framework today. For any large open-source project — Django, Rails, React — the majority of all-time contributors are inactive. This is normal.
What matters is the active contributor count. For Flask, 56 commits from 400 listed contributors means an effective contribution rate of 0.14 commits per contributor per year. The actual maintenance is almost certainly concentrated in single-digit active contributors. The bus factor — the number of people whose departure would halt development — is the real risk metric, and for Flask it is likely very small.
The Honest Version of This Story
Flask is not a time bomb. It is a stable, mature micro-framework that does exactly what it was designed to do. Its core is secure and maintained. The danger is not in what Flask is — it is in what “lightweight” pushes outward: into the extensions, into the maintainers you cannot name, into the dependency surface that no single dashboard covers.
As AI-assisted tooling lowers the cost of weaponizing known CVEs, the framework with a logo and a security team is not your problem. The fifteen dependencies behind it — each with their own unmonitored attack surface — are. For every CTO running Flask in production, the question is not whether Flask is maintained. It is whether you have eyes on the whole dependency surface, or just the part with a name.
