Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical vulnerability in LangChain – CVE-2025-68664

cyata.ai

Post reply on HN
Print view View original

51–60 of 93 posts

Re: Critical vulnerability in LangChain – CVE-2025-68664

#51

Post by blcknight »

anonzzzies wrote: post #24
prodigycorp wrote: post #6

The best part about this is that you know the type of people/companies using langchain are likely the type that are not going to patch this in a timely manner.

Yep, not sure why anyone is using it still.

What would you use instead?

I built an internal CI chat bot with it like 6 months ago when I was learning. It’s deployed and doing what everyone needs it to do.

Claude Code can do most of what it does without needing anything special. I think that’s the future but I hate the vendor lock in Anthropic is pushing with CC.

All my python tools could be skills, and some folks are doing that now but I don’t need to chase after every shiny thing — otherwise I’d never stop rewriting the damn thing.

Especially since there’s no standardizing yet on plugins/skills/commands/hooks yet.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#52

Post by nostrebored »

majormajor wrote: post #23
teruakohatu wrote: post #17

Earlier quoted context omitted.

JSON Structured Output from OpenAI was released a year after the first LangChain release. I think structured output with schema validation mostly replaces the need for complex prompt frameworks. I do look at the LC source from time to time because they do have good prompts backed into the framework.

IME you could get reliable JSON or other easily-parsable output formats out of OpenAI's going back at least to GPT3.5 or 4 in early 2023. I think that was a bit after LangChain's release but I don't recall hitting problems that I needed to add a layer around in order to do "agent"-y things ("dispatch this to this specialized other prompt-plus-chatgpt-api-call, get back structured data, dispatch it to a different spec…

Can guarantee this was not true for any complicated extraction. You could reliably get it to output json but not the json you wanted

Even on smallish ~50k datasets error was still very high and interpretation of schema was not particularly good.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#53

Post by wilkystyle »

prodigycorp wrote: post #15
wilkystyle wrote: post #7

Earlier quoted context omitted.

Can you elaborate? Fairly new to langchain, but didn't realize it had any sort of stereotypical type of user.

No dig at you, but I take the average langchain user as one who is either a) using it because their C-suite heard about at some AI conference and had it foisted upon them or b) does not care about software quality in general. I've talked to many people who regret building on top of it but they're in too deep. I think you may come to the same conclusions over time.

Thanks for the reply, and no offense taken. I've inherited some code that uses LangChain, and this is my first experience with it.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#54

Post by llmslave2 »

gcr wrote: post #37
int_19h wrote: post #26

Earlier quoted context omitted.

I'll admit that I haven't looked it in a while, but as originally released, it was a textbook example on how to complicate a fundamentally simple and well-understood task (text templates, basically) with lots of useless abstractions that made it all sound more "enterprise". People would write complicated langchains, but then when you looked under the hood all it was doing is some string concatenation, and the result…

What do you suggest instead? Handrolled code with “import openai”? BAML?

Oh gosh, not that legacy "hand rolled code"

Re: Critical vulnerability in LangChain – CVE-2025-68664

#55

Post by llmslave2 »

crote wrote: post #13
iamacyborg wrote: post #4

Earlier quoted context omitted.

> WHY on earth did the author of the CVE feel the need to feed the description text through an LLm? Not everyone speaks English natively. Not everyone has taste when it comes to written English.

I would rather read succinct English written by a non-native speaker filled with broken grammar than overly verbose but well-spelled AI slop. Heck, just share the prompt itself! If you can't be bothered to have a human write literally a handful of lines of text, what else can't you be bothered to do? Why should I trust that your CVE even exists at all - let alone is indeed "critical" and worth ruining Christmas over?

It's actually far more preferable to read broken English written by a human because each language imposes their own unique "flavour" in English making it preferable to AI slop.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#56

Post by llmslave2 »

iinnPP wrote: post #22
crote wrote: post #18

Earlier quoted context omitted.

> I prefer reading the LLM output for accessibility reasons. And that's completely fine! If you prefer to read CVEs that way, nobody is going to stop you from piping all CVE descriptions you're interested in through a LLM. However, having it processed by a LLM is essentially a one-way operation. If some people prefer the original and some others prefer the LLM output, the obvious move is to share the original with th…

Yes, framed as you stated it is indeed a win-win. However, there will be cases where lacking the LLM output, there isn't any output at all. Creating a stigma over technology which is easily observed as being, in some form, accessible is expected in the world we live. As it is on HN. Not to say you are being any type of anything, I just don't believe anyone has given it all that much thought. I read the complaints and…

Im sorry but I don't buy the argument that we should be accepting of AI slop because it's more accessible. That type of framing is devious because you frame dissenters as not caring about accessibility. It has nothing to do with accessibility and everything to do with simply not wanting to consume utterly worthless slop.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#57

Post by llmslave2 »

small_scombrus wrote: post #12
dorianmariecom wrote: post #9

Earlier quoted context omitted.

you can use chatgpt to reverse the prompt

ChatGPT can generate you a sentence that plausibly looks like the prompt

Rather it estimates a potential prompt. I could do the same and it would be no more or less accurate.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#58

Post by minitech »

croemer wrote: post #30
fn-mote wrote: post #29

> The blast radius is scale Ugh. I’m a native English speaker and this sounds wrong , massaged by LLM or not. “Large blast radius” would be a good substitute. I am happy this whole issue doesn’t affect me, so I can stop reading when I don’t like the writing.

It's definitely LLM generated. I came here to post that, then you saw you had already pointed it out. Giveaway for me: 'The most common real-world path here is not “attacker sends you a serialized blob and you call load().” It’s subtler:' It's not, it's; bolded items in list. Also no programmer would use this apostrophe instead of single quote.

> Also no programmer would use this apostrophe instead of single quote.

I’m a programmer who likes punctuation, and all of my pointless internet comments are lovingly crafted with Option+]. It’s also the default for some word processors. Probably not wrong about the article, though.

Re: Critical vulnerability in LangChain – CVE-2025-68664

#59

Post by phyzome »

int_19h wrote: post #26
wilkystyle wrote: post #7

Earlier quoted context omitted.

Can you elaborate? Fairly new to langchain, but didn't realize it had any sort of stereotypical type of user.

I'll admit that I haven't looked it in a while, but as originally released, it was a textbook example on how to complicate a fundamentally simple and well-understood task (text templates, basically) with lots of useless abstractions that made it all sound more "enterprise". People would write complicated langchains, but then when you looked under the hood all it was doing is some string concatenation, and the result…

Huh, kind of sounds like they used LLMs to design it. :-)

Re: Critical vulnerability in LangChain – CVE-2025-68664

#60

Post by avaer »

babyshake wrote: post #48
peab wrote: post #41

Earlier quoted context omitted.

Langchain is great because it provides you an easy method to filter people out when hiring. Candidates who talk about langchain are, more often than not, low quality candidates.

Would you say the same for Mastra? If so, what would you say indicates a high quality candidate when they are discussing agent harnessing and orchestration?

I somewhat take issue as a LangChain hater + Mastra lover with 20+ years of coding experience and coding awards to my name (which I don't care about, I only mention it for context).

Langchain is `left-pad` -- a big waste of your time, and Mastra is Next.js -- mostly saving you infrastructure boilerplate if you use it right.

But I think the primary difference is that Python is a very bad language for agent/LLM stuff (e.g. static typesystem, streaming, isomorphic code, strong package management ecosystem is what you want, all of which Python is bad with). And if for some ungodly reason you had to do it in Python, you'd avoid LangChain anyway so you could bolt on strong shim layers to fix Python's shortcomings in a way that won't break when you upgrade packages.

Yes, I know there's LangChain.js. But at that point you might as well use something that isn't a port from Python.

> what would you say indicates a high quality candidate when they are discussing agent harnessing and orchestration?

Anything that shows they understand exactly how data flows through the system (because at some point you're gonna be debugging it). You can even do that with LangChain, but then all you'd be doing is complaining about LangChain.

Post reply on HN