Something I’ve noticed using Cursor for Python projects: when Cursor generates code or suggests a requirements.txt, the library versions it picks tend to be significantly older than current releases — often 12–24 months behind — and some of them have known vulnerabilities in the OSV database.
Concrete example: I’ve had django==6.0.1 and requests==2.31.0 suggested multiple times across unrelated projects. Both are on OSV with documented CVEs. They install without errors and the code works, so the issue is completely invisible.
This isn’t a Cursor-specific problem — it seems to be a general property of how LLMs learn version preferences from training data, where popular older versions are over-represented. But Cursor is in a good position to do something about it because it already has codebase context and tooling integration.
Would love to see something like:
-
A post-generation warning when a suggested version has a known CVE (Cursor already integrates with some security tooling)
-
Or an option in
.cursorulesto instruct: “always suggest the latest CVE-free version from OSV”
I ran a more systematic check and found that across 1,000 Python tasks, over 40% of LLM-generated code with version annotations had at least one CVE-carrying dependency — and 95% of those couldn’t be fixed by just bumping the patch number. The problem is structural, not a one-off.
Happy to share more details or the methodology if it’s useful for product planning.