Yes, they are. Its unfortunate, but its also the reality of the world we live in at the moment. I’d also rather see LLM’s/“AI” be used to find CVE’s and help get things fixed than let the vulnerabilities sit and be abused.
I mostly draw the line at using LLM’s/“AI” to do all the coding from the start. I think as something like a ‘linter’ they’re mostly fine. It gets to be a bit problematic when you’re letting the bots write the code and you can’t really attribute copyright properly.
Yes, they are. Its unfortunate, but its also the reality of the world we live in at the moment. I’d also rather see LLM’s/“AI” be used to find CVE’s and help get things fixed than let the vulnerabilities sit and be abused.
Are any of these CVEs related to the vibecoded refactor of rsync?
(ETA: Only one of the high+ CVEs has an affected version range >= 3.4.1 (when, I think, vibecoding started getting added): CVE-2026-70455, with >= 3.4.2, <= 3.4.4 ; and, at first glance, it doesn’t look related to any vibecoding; it was a dragging PR from several years ago with only a single, relatively brief commit to the implementation.)
I mostly draw the line at using LLM’s/“AI” to do all the coding from the start. I think as something like a ‘linter’ they’re mostly fine. It gets to be a bit problematic when you’re letting the bots write the code and you can’t really attribute copyright properly.
IIRC, rsync made a point of doing a large refactor via LLMs. If that vibecoded code is, itself, vulnerable, then… LLMs aren’t exactly helping on the abused vulnerabilities front.
I don’t know, I don’t really use “rsync” these days as I mostly use OpenBSD (which includes its own version of rsync). But it has come out that the current maintainer of rsync has been using LLM’s to assist with maintenance so that they can spend more time on the beach (and yes I support OSS authors getting plenty of beach time).
I think only time will tell if LLM’s end up producing security churn. I suspect they will to an extent because they don’t really “know” anything and probably aren’t going to program with “secure programming practices”. But I don’t really use LLM’s for anything, so I can’t really speak to if they do that or not. If its code based on what its been trained on, and its prompted to look for specific vulnerabilities and then fix them its certainly possible for those fixes to include another issue. If the actual human pushing the fix for that vuln isn’t aware of secure coding practices then things could certainly slip under the rug.
Unfortunately, rsync updates are vibecoding related
score 1 · canonical
Yes, they are. Its unfortunate, but its also the reality of the world we live in at the moment. I’d also rather see LLM’s/“AI” be used to find CVE’s and help get things fixed than let the vulnerabilities sit and be abused.
I mostly draw the line at using LLM’s/“AI” to do all the coding from the start. I think as something like a ‘linter’ they’re mostly fine. It gets to be a bit problematic when you’re letting the bots write the code and you can’t really attribute copyright properly.
score 1 · canonical
Anthropic offers an indemnification arrangement, which should mean it’s only going to be a problem for Anthropic!
This is covered in section K of the commercial terms.
score 1 · canonical
Are any of these CVEs related to the vibecoded refactor of rsync?
(ETA: Only one of the high+ CVEs has an affected version range >= 3.4.1 (when, I think, vibecoding started getting added): CVE-2026-70455, with
>= 3.4.2, <= 3.4.4; and, at first glance, it doesn’t look related to any vibecoding; it was a dragging PR from several years ago with only a single, relatively brief commit to the implementation.)IIRC, rsync made a point of doing a large refactor via LLMs. If that vibecoded code is, itself, vulnerable, then… LLMs aren’t exactly helping on the abused vulnerabilities front.
score 1 · canonical
I don’t know, I don’t really use “rsync” these days as I mostly use OpenBSD (which includes its own version of rsync). But it has come out that the current maintainer of rsync has been using LLM’s to assist with maintenance so that they can spend more time on the beach (and yes I support OSS authors getting plenty of beach time).
I think only time will tell if LLM’s end up producing security churn. I suspect they will to an extent because they don’t really “know” anything and probably aren’t going to program with “secure programming practices”. But I don’t really use LLM’s for anything, so I can’t really speak to if they do that or not. If its code based on what its been trained on, and its prompted to look for specific vulnerabilities and then fix them its certainly possible for those fixes to include another issue. If the actual human pushing the fix for that vuln isn’t aware of secure coding practices then things could certainly slip under the rug.
score 1 · canonical