Gemini keeps suggesting old Python library versions with known CVEs: is this a known issue?

Gemini API
, ,
1

Hey everyone, wanted to share something I noticed while using Gemini for Python development that I think is worth discussing.

I’ve been asking Gemini to write Python code that uses common libraries like requests, flask, django, and cryptography. When I ask it to annotate the imports with a version comment, something like import requests # version==x.y.z, it consistently picks versions that are 1–2 years behind the current release. And a lot of them turn out to have known CVEs when I check against osv.dev.

A few examples I’ve hit:

  • requests==2.31.0 — shows up almost every time I ask for it, has multiple CVEs

  • pillow==10.0.0 — Gemini suggested this across several different tasks I tried, also has known vulnerabilities

  • flask==2.3.2 and flask==2.2.5 — both came up, both have CVEs

The frustrating part is that the code runs fine, installs without errors, and there’s zero indication anything is wrong unless you specifically run pip-audit afterward. So this is completely invisible to a developer who just accepts the suggestion.

I did some digging and checked how often this happens across a range of tasks . Roughly half of the Python tasks I tested had at least one Gemini-suggested version carrying a known CVE. And most of those CVEs were already publicly disclosed before Gemini’s training cutoff, so this isn’t purely a “the model didn’t know yet” situation.

The pattern seems to be that Gemini gravitates toward versions that were popular when the model was trained, which makes sense, since those versions have more coverage in documentation, Stack Overflow answers, etc. But those same popular versions are also the ones that have had time to accumulate unpatched CVEs.

A quick workaround I’ve tried: if you explicitly say something like “use the latest CVE-free version from pypi” in your prompt, Gemini cannot gain some notable changes, some external tools is needed.

Questions for the community (and hopefully Google):

  1. Has anyone else noticed this pattern?

  2. Is there any plan to integrate something like an OSV or GitHub Advisory check into version suggestions?

  3. Would it be feasible to add this as a Gemini API option — like a flag that says “prefer secure versions when generating dependency annotations”?

I think this is a pretty significant issue for anyone using Gemini to scaffold production Python code, especially since the code looks correct and the CI pipeline won’t catch it unless you’ve got pip-audit or Dependabot set up specifically for this.

Happy to share more specific examples if helpful.