Should AI Code Generators Get CVEs for Insecure Suggestions?

AI-assisted development has transitioned rapidly from a novelty to an everyday dependency. But as developers increasingly rely on large language models (LLMs) and local deep learning engines to speed up their workflows, a critical question is emerging: when an AI tool suggests blatantly insecure code, who is responsible, and does that suggestion constitute a reportable security vulnerability?

Security researcher Seth Larson recently highlighted this gray area in an analysis of PyCharm, JetBrains' popular Python IDE. His findings probe the boundaries of coordinated disclosure and raise difficult questions about how the industry should classify and mitigate insecure AI code generation.

The Experiment: Silencing Warnings and Disabling TLS

Larson's investigation focused on PyCharm’s "Full Line Completion" plugin, a feature designed to run locally on the developer's machine to suggest entire lines of code.

While testing the plugin (specifically version v253.29346.142), Larson imported the popular HTTP client library urllib3 and began typing. The local model immediately offered a completion to disable warnings:

import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

Accepting this suggestion would silence any warnings about insecure HTTP requests. Larson then went a step further, instantiating a connection manager. The IDE's local model prompted him to complete the line by disabling certificate verification entirely:

import urllib3
urllib3.PoolManager(
    cert_reqs='CERT_NONE',
)

By accepting these two sequential suggestions, a developer would write code that is highly susceptible to monster-in-the-middle (MITM) attacks, while simultaneously disabling the library's built-in mechanism to warn them of the mistake.

The Disclosure Loop

Recognizing the risk of silent, AI-driven security regressions, Larson reported the behavior to JetBrains. The response from the IDE vendor highlighted the industry's current confusion regarding AI safety boundaries.

According to Larson, JetBrains support staff seemed uncertain about how to classify the report. While they ultimately confirmed that the behavior did not constitute a "direct security vulnerability," they nonetheless requested that Larson refrain from publicizing his findings, pointing him instead to PyCharm’s Coordinated Disclosure Policy.

Larson observed a standard 90-day disclosure window before publishing his findings. Upon re-testing the behavior on a newer version of the plugin (v261.24374.152), he found that the model's behavior remained unchanged, suggesting the exact same insecure patterns.

Does an Insecure Suggestion Warrant a CVE?

The core of the debate is whether this behavior warrants a Common Vulnerabilities and Exposures (CVE) identifier.

Traditionally, a CVE is assigned to a distinct, exploitable flaw in a software product. In this scenario, the software component generating the code (PyCharm's local model) is operating as designed—it is predicting likely code sequences based on its training data, which unfortunately includes vast amounts of legacy, insecure, or boilerplate code found across public repositories.

Larson himself argues that using the CVE system for AI code generation issues is likely inappropriate and unhelpful. However, treating these issues as mere "user error" ignores the subtle shift in the developer-tool relationship. Developers often trust their IDEs to provide sensible, safe defaults. When an autocompletion engine actively steers a developer toward disabling critical security controls like TLS verification, the tool becomes an active vector for introducing vulnerabilities into downstream applications.

Without a formal security classification like a CVE, however, vendors may lack the incentive or structured triage pipelines to prioritize retraining or filtering their local models. For now, developers must remain vigilant: just because an IDE can write the next line of code doesn't mean it should be trusted to write it securely.