Here is a small, almost domestic horror story. You open PyCharm, you start typing a few lines that make an HTTP request, and the editor — helpfully, in soft grey, the way it has offered to finish your sentences a thousand times before — suggests this:


urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
http = urllib3.PoolManager(cert_reqs='CERT_NONE', ...)

If you accept it, you have just told your program to stop verifying TLS certificates and to stop warning you about it. Your HTTPS is now HTTPS in costume. Anyone sitting on the network between you and the server can read and rewrite the traffic, and your code will smile and call it secure.

The detail that turns this from a curiosity into a genuinely instructive case is who found it. Seth Larson, the Python Software Foundation's Security Developer-in-Residence, wrote it up on 10 June. Larson is a maintainer of urllib3 — the most-downloaded package on PyPI, north of ten billion installs. So the tool suggested switching off the safety features of the exact library the person reading the suggestion helps maintain. It is as if the locksmith's own apprentice handed a customer a note reading "the deadbolt is optional, here's how to remove it."

What actually happened (and what didn't)

Let me be precise, because precision is the whole game here. The feature is Full Line Completion — a small deep-learning model that ships bundled with PyCharm for Python, runs entirely on your machine, and is on out of the box. This is not the cloud-based AI Assistant you sign up for and consciously invoke. It is the ambient one, the one that's just there, finishing your lines as you type whether or not you ever opted into "using AI." Larson reports the behaviour persisted across versions — he names 253.29346.142 and the much later 261.24374.152 — so this isn't a one-off glitch in a single build.

And here's the part I want to sit with: Larson reported it to JetBrains, and JetBrains said it was not a "direct security vulnerability," asked him not to publicise it under their coordinated-disclosure policy, and — by his account — went roughly ninety days without a substantive response.

Now, the easy move is to read that as a villain's line and pile on. I don't think it is. I think JetBrains is, narrowly, correct — and that the correctness is exactly what makes this interesting.

The layer question

A vulnerability, classically, is a defect in a system that lets an attacker do something they shouldn't. The TLS-disabling snippet isn't that. PyCharm didn't exfiltrate your keys. It didn't run the insecure code. It suggested it, in grey, and waited for a human to press Tab. The defect — if we even want that word — is that the suggestion is bad, and a tired developer at 4pm might accept it without reading.

So where does the bug live? This is the question Basil-readers will recognise, because it's the same question I keep circling from different doors. With SymJack, the failure was that the approval prompt described one operation while the kernel performed another — the human and the machine disagreed about what was being authorised. With the Claude Code source-leak finding, it was behaviour the user could never have reviewed because the specification was never disclosed. The recurring lesson: most of the loud arguments about AI tooling are actually arguments about which layer a problem belongs to, conducted by people who haven't agreed on the layers.

Here, there are at least three candidate floors, and the snippet touches all of them:

  • The model layer. The completion model learned this pattern because the public corpus is full of it. CERT_NONE and disable_warnings are what exhausted developers paste from Stack Overflow at midnight to make the red squiggle go away. The model is a mirror; it is reflecting our own worst Tuesday back at us. Larson says as much: the behaviour is latent in code-generation models broadly, with JetBrains merely the instance he happened to catch.
  • The product layer. JetBrains chose to ship that model bundled and enabled, finishing security-sensitive lines by default, without — as far as I can tell — a guardrail that says don't autocomplete the off-switch for transport security. That's a product decision, not a model inevitability. A spellchecker that cheerfully completes misspellings is the vendor's problem, not the dictionary's.
  • The human layer. Someone has to press Tab. The completion is a suggestion, not a command. The accountability for shipped code is still, legally and morally, the developer's.

JetBrains is standing on the first and third floors — the model reflects the corpus, and the human accepts the suggestion — to argue it isn't their vulnerability. Larson, crucially, agrees it shouldn't be a CVE. His own words: "I don't think using CVEs for this purpose is appropriate or helpful for users, either." This is what makes the piece worth your time. Set aside the picture of a researcher demanding a CVE and a vendor refusing one — that's not what happened. What happened is rarer: both parties agreed the existing vocabulary doesn't fit, and then nothing happened, because "not a CVE" quietly became "not our problem," and the gap between those two phrases is where the actual issue lives.

Why "it's not a CVE" is the trap, not the answer

The CVE system is a magnificent machine built for a specific shape of problem: a discrete defect, in a versioned artefact, with a clear before-and-after that a patch resolves. An insecure completion has none of those edges. There's no version where the model is "fixed" in the binary sense; there's a statistical tendency that's better or worse. There's no single line to patch; there's a distribution to nudge. CVE is a filing cabinet, and this is a fog. You cannot file a fog.

But — and this is the bit that should make the hair on your neck stand up — the absence of a filing cabinet drawer has been doing real argumentative work. "It's not a direct security vulnerability" is true, and it functions as a release valve: no CVE means no advisory, no advisory means no tracker entry, no tracker entry means no deadline, no deadline means ninety quiet days. The taxonomy gap isn't neutral. It's load-bearing. The same dynamic showed up when bug bounties were paid but no advisory was published — the disclosure infrastructure simply has no slot for the thing, so the thing falls through the floor.

The honest fix is the one Larson points at: address it at the source, at the product layer, because that's the only floor with both the visibility and the leverage. The model can't be trusted to never learn the bad pattern; the human can't be trusted to never be tired. The vendor is the one party that can put a thumb on the scale — suppress completions that disable transport security, flag them, refuse to autocomplete the specific incantations that turn off verification. That's not a CVE. It's product hygiene. It's the spellchecker declining to confidently finish a slur.

What to actually do about it

If you're a team lead, this is small and concrete:

  • Know what's autocompleting your security-sensitive code, and whether you turned it on. Full Line Completion is enabled by default. Most of your developers did not make a decision to let a local model finish their TLS configuration. That's worth a five-minute conversation, not because the feature is evil — it's often genuinely useful — but because defaults are policy, and you should know your policy.
  • Treat completion output the way you'd treat a confident junior's first draft: useful, fast, and not to be merged unread — especially around the four perennial danger zones: TLS/cert handling, auth, subprocess/shell, and anything touching secrets. A linter rule that fails the build on CERT_NONE and disable_warnings costs an afternoon and catches this class regardless of which AI suggested it. Bandit already flags exactly these.
  • Don't wait for a CVE to tell you something's wrong. This is the durable habit. The most interesting failures in AI tooling right now are precisely the ones the advisory system can't represent — the foggy ones, the statistical ones, the "technically a suggestion" ones. If your security posture only reacts to things with a CVE number attached, you are blind to the entire category this case belongs to.

Larson found this because he happens to maintain the library being misused and so the bad pattern leapt out at him like a wrong note in a familiar song. Most developers won't have that ear. The completion will arrive in soft, friendly grey, in a tool they trust, finishing a line they were already going to write — and the only question that matters is whether anyone built a layer that's paying attention when the suggestion is to turn off the locks.

Which layer in your stack is supposed to catch the confident, helpful, wrong suggestion — and have you actually checked that it's awake?