Then again, I once submitted a bug report to my bank, because the login method could be switched from password+pin to pin only, when not logged in, and they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password. (And that's not even getting into the difference between real two-factor authentication the some-factor one-and-a-half-times they had implemented by adding a PIN to a password login.) I've since learned that anything heavily regulated like hospitals and banks will have security procedures catering to compliance, not actual security.
Assuming the host of the bug bounty program is operating in good faith, adding some kind of barrier to entry or punishment for untested entries will weed out submitters acting in bad faith.
Honestly bug bounties are kind of miserable for both sides. I've worked on the recieving side of bug bounty programs. You wouldnt believe the shit that is submitted. This was before AI and it was significant work to sort through, i can only imagine what its like now. On the other hand for a submitter, you are essentially working on spec with no garuntee your work is going to be evaluated fairly. Even if it is, you are rolling the dice that your report is not a duplicate of an issue reported 10 years ago that the company just doesn't feel like fixing.
* Spend ages trying to find someone to submit a report to.
* Waste a whole load of time fighting through the generic contact and support desks to try and get your report to someone who understood it.
* Get completely ignored by the developers.
* Spend time reporting a bug only for them to silently fix it without even bothering to respond to you, let alone acknowledge you.
* Get legal threats for making a good-faith bug report, even if you found it in an locally deployed instance of the software.
* Get called a black hat and more legal threats when you give up and just go down the full disclosure route.
Sadly, yeah. And will do anything only if they believe they can actually be caught.
An EU-wide bank I used to be customer of until recently, supported login with Qualified Electronic Signatures, but only if your dongle supports... SHA-1. Mine didn't. It's been deprecated at least a decade ago.
A government-certified identity provider made software that supposedly allowed you to have multiple such electronic signatures plugged in, presenting them in a list, but if one of them happened to be a YubiKey... crash. YubiKey conforms to the same standard as the PIV modules they sold, but the developers made some assumptions beyond the standard. I just wanted their software not to crash while my YubiKey is plugged in. I reported it, and they replied that it's not their problem.
That adds an extra layer of complexity to the cURL maintainers, handling other people’s money and whatnot. It was considered.
Daniel (cURL’s lead) has been discussing this for months. Whatever “quick and easy” solution you think of, it’s already been suggested and thought about and rejected for some reason.
If I have to pay money to submit a vulnerability to the developers with no guarantee that I'll even get refunded for a high quality and good faith report, let alone any actual payout, there's much less incentive for me to do so compared to selling them to someone else who won't charge me money for the privilege.
We wanted to encourage white hat security researchers to look at our domain rather than other domains so we could collect more data on the kinds of vulns that appeared in our domain to help prioritize efforts that would fix the root causes of recurring bug patterns.
I've also submitted bug bounties and received rewards and I've worked with a bunch of other people who have done this. At no point did I even consider selling on the black market and I suspect that my friends from grad school were the same way.
Maybe the $1,000,000 bounties for zero click rce on iphones or whatever exist to discourage selling on the black market, but I'm not even sure that is true. "Well, I'll just find a way to sell this to the russian mob" is not exactly something that is on the radar of the vast majority of security researchers.
If you're trying to protect your own website and servers, those markets won't be a concern for you. If you ship a widely used product that's an attractive target (like web browser, mobile device, network kit, etc) then they definitely are.
I refer to this as the Notion-to-Confluence cost border.
When Notion first came out, it was snappy and easy to use. Creating a page being essentially free of effort, you very quickly had thousands of them, mostly useless.
Confluence, at least in west EU, is offensively slow. The thought of adding a page is sufficiently demoralizing that it's easier to update an existing page and save yourself minutes of request time outs. Consequently, there's some ~20 pages even in large companies.
I'm not saying that sleep(15 * SECOND) is the way to counter, but once something becomes very easy to do at scale, it explodes to the point where the original utility is now lost in a sea of noise.
Ironically, the cordless vacuum is even better than vacuum robots in this regard! I was surprised to hear from some friends and acquaintances that they prefer the manual vacuum to robotic one, and find it a better time/effort saver - but I eventually realized they're right, simply because the apps for controling the robotic vacuums are all steaming piles of shit, and their bad UI alone turns activating the robot into primary activity. It may be a brief activity, but it still requires full focus.
I keep having to get it from progressively more inconvenient locations to which it has been banished in order to humor my wife’s delusion that the roomba or the handhold do anything.
I can make multiple passes with the handheld to get 80% of the crumbs in a small area, troubleshoot why the robot didn’t run yesterday in order to hope it will get the crumbs tomorrow, or just get the corded vacuum out and actually clean a whole room.
Work involves cables. Any product that promises something different is a lie.
Our cordless, on the highest suction setting, is bordering on unusable. The effort to move it across carpet becomes quite high. Trying to roll it on an area rug tends to cause it to drag the rug around, and if you pick it up while on it will pull the rug up off the floor.
I have done some _very_ scientific testing here, vacuuming a section of carpet on the lowest section (doing lines where each pass half-overlapped the previous so each part of the carpet got touched once in each direction), emptying the vacuum, then going back over doing the same on high. Didn't see anything else come up. Shop vac didn't pull anything else out either that I could see.
I used to be in a similar boat of "these are a stupid class of product", but end of the day even if it takes eight passes my wife was going to use it anyway. The effort for her to set the time aside to drag around the heavier corded vacuum which is a substantial effort for her, etc, would be more than doing eight passes with a cordless. So got a good one and I'm sold on it now--it is quite convenient, and it does work.
Only thing I will say is the battery definitely can't do an entire carpeted house on a charge. We don't have that much carpet, so don't have any problem cleaning all the floors and a couple area and entry-way rugs on a charge.
The quote from example from early in the article stuck with me for years:
Think about this for a second. The human longing for freedom of information is a terrible and wonderful thing. It delineates a pivotal difference between mental emancipation and slavery. It has launched protests, rebellions, and revolutions. Thousands have devoted their lives to it, thousands of others have even died for it. And it can be stopped dead in its tracks by requiring people to search for "how to set up proxy" before viewing their anti-government website.
(Now this is more poetic, but I suppose the much more insightful example that also stuck with me is given later - companies enticing you to buy by offering free money, knowing well that most customers can't be arsed to fill out a form to actually get that money.)
--
[0] - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...
We have tons of Confluence wikis, updated frequently.
As someone working on Confluence to XWiki migration tools, I wish this was remotely true, my life would be way easier (and probably more boring :-)).
I personally came to that conclusion thanks to the GrapheneOS situation regarding device attestation. Insecure devices get full features from some apps because they are certified, although they cite security, while GrapheneOS get half featured apps because it's "insecure" (read, doesn't have the Google certification, but are actually the most secure devices you can get, worldwide)
It's not about securing your device from external threats or bad actors; it's about securing the organization from any blame / wrongdoing.
Most organizations today are looking high and low to shove the blame to others instead of taking responsibility.
And then you have banks such as Boursobank (a French online bank) that has weak traditional authentication (and a faulty app, but they do not care) and out of the blue also provides passkeys. Making it at the same time horribly bad and wonderfully good.
The worst part is that they hide behind regulations when in fact there are only few of them.
Other instiytutions such as SWIFT are as bad and equally arrogant.
I wonder if a better model would be to make the platform pay to entry, but not the specific bugs? So you have to pay a fee to gain access to a platform like HackerOne, and if your signal:noise ratio gets too bad then your account gets revoked? That would make it feel like less of a gamble than having to pay for every individual bug - but still has the same problem that it's putting a big barrier in front of legitimate good-faith researchers.
Ugh, I hate this. I've seen it in other places. Just waiting for them to decide that actually it should be an SMS or a phone call...
There have been plenty of instances where I tried to log in somewhere, and the first attempt to contact my mail server was twenty minutes later. And of course they then deliver all five retries at once.
Unlikely to happen but it seems fun to extend email [clients] with uri's. It is just a document browser, who cares how they are delivered.
Your bank would not. Nor would mine, or most retail banks.
If the upfront cost would genuinely put off potential submitters, a cottage industry would spring up of hackers who would front you the money in return for a cut if your bug looked good. If that seems gross, it's really not - they end up doing bug triage for the project, which is something any software company would be happy to pay people for.
It's credit cards that have to reimburse for fraud, but they charge the merchant for it, plus fees, so they have absolutely no incentive to prevent fraud, if not an incentive to outright encourage fraud. That would explain why their implementation of the already compromised EMV was further nerfed by a lack of a PIN in the US.
At a bank? No way. They are some of the most customer-hostile organizations I've interacted with. Dealing with payment accounts is a necessary evil for them, and they are very much aware of the effort required to switch to a different bank, and of the massive regulatory moat preventing consumer-friendly competition from popping up.
A bank doesn't care about screwing over a handful of customers. As long as it's not common enough to draw the attention of the press and/or a regulatory agency, they are not going to spend any money on improving.
It would also stop a lot of genuine submissions unfortunately, as some literally can't pay not just won't pay (for both technical or financial reasons), and adds complexity¹. Each project working this way will need to process a bunch of payments and refunds on top of the actual bounty payments, which is not admin free nor potential financially cost free.
I can't think of an easy answer that would work for more than a very short amount of time. As soon as there is money involved and an easy way to use tooling rather than actual effort/understanding to be involved, many will try to game the system ruining it for those genuine participants. Heck, even if the reward is just credit² rather than money, that will happen. Many individual people are honest and useful, people as a whole are a bunch of untrustworthy arseholes who will innocence you and the rest of the world for a penny or just for shits & giggles.
> Assuming the host of the bug bounty program is operating in good faith
This is a significant assumption. One that is it harder to not be paranoid about when you are putting money down.
> they closed it as "works as intended", because they had decided that an optional password was more convenient than a required password
This does not surprise me. My primary bank (FirstDirect, UK) switched the way I authenticate from “between 5 and 9 alphanumeric characters”³ to a 5-digit pin, and all their messages about it assured me (like hell!) that this was “just as secure as before”…⁴
--------
[1] Needing a payment processing option that is compatible with both the reporter and reportee, at the point of submission. At the moment that can be arranged after the bounty is awarded rather than something a project like curl needs to have internationally setup and supported before accepting submissions.
[2] ref: people submitting several simple documentation fixes, one misplaced comma or 'postrophe per pull request, to game some “pull requests accepted” metric somewhere.
[3] which wasn't ideal to start with
[4] I would accept the description “no less secure than before” if they admitted that the previous auth requirements were also lax.
If a PR is submitted by someone who is then known to submit slops, they can be easily ignored by the maintainers.
EDIT: Or may be something like SponsorBlock for youtube. There could be a browser extension that will collectively tag sloppers the sameway and can help identify sloppers.
Could people who think they found a bug but not sure be turned off by the up front cost / risk of finding out they are wrong or not technically finding a bug?
You still need to complete a SMS auth to do anything other than view records though, like transfer money.
Even when you have something fully exploitable and valid, they will many times find some way to not pay you or lower the severity to pay you very little.
The catch-all excuse is something along the lines: "although this is vulnerable, it doesn't impact the business".
I've gotten this excuse, even when I could prove it was a production server with customer information that I could access.
Sites like Hackerone can help, but in the end, it comes down to the company running the bug bounty program.
The problem is that bug bounty slop works. A lot of companies with second-tier bug bounties outsource triage to contractors (there's an entire industry built around that). If a report looks plausible, the contractor files a bug. The engineers who receive the report are often not qualified to debate exploitability, so they just make the suggested fix and move on. The reporter gets credit or a token payout. Everyone is happy.
Unless you have a top-notch security team with a lot of time on their hands, pushing back is not in your interest. If you keep getting into fights with reporters, you'll eventually get it wrong and you're gonna get derided on HN and get headlines about how you don't take security seriously.
In this model, it doesn't matter if you require a deposit, because on average, bogus reports still pay off. You also create an interesting problem that a sketchy vendor can hold the reporter's money hostage if the reporter doesn't agree to unreasonable terms.
If filing a bad report costs money, low quality reports go down. Meanwhile anyone still doing it is funding your top notch security team because then they can thoroughly investigate the report and if it turns out to be nothing then the reporter ends up paying them for their time.
For some reason they either didn’t notice (e.g. there’s just too many people trying to get in on it), or did notice, but decided they don’t care. Deposit should help here: companies probably will not do it, so when you see a project requires a deposit, you’ll probably stop and think about it.
And likely even if they DO move on, there’s a thousand more right behind them having bought a “get rich quick” kit from someone.
It's not like this sort of hustling didn't exist prior to LLMs but the volume has ballooned massively.
From my failed attempt, I remember that
- Students had to find a project matching their interests/skills and start contributing early.
- We used to talk about staying away from some projects with a low supply of students applying (or lurking in the GitHub/BitBucket issues) because of the complexity required for the projects.
Both of these acted as a creative filter for projects and landed them good students/contributors, but it completely goes away with AI being able to do that at scale.
There are a lot of things to be sad about AI, but this is not it. Nobody has a right to a business model, especially one that assumes nobody will compete with you. If your business model relies on the rest of the world bring sucky so you can sell some value-added to open-core software, i'm happy when it fails.
The what now? Open source doesn't have a business model, it's all about the licensing.
FOSS is about making code available to others, for any purpose, and that still works the same as 20 years ago when I got started. Some seem to wake up to what "for any purpose" actually mean, but for many of us that's quite the point, that we don't make choices for others.
Like I said, there is a part that should be illegal, and then part where that's used to additionally harm one of the ways that OSS can be sustainable. The second part on its own is not illegal but adds to damages and is perfectly okay to condemn.
Open source software can have business models, it's one of the ways it can be sustainable. It can work like, for example, the code is made available (for any purpose) and the core maintainer company provides services, like with Nginx (BSD). Or there is an open-source software, and companies create paid products and services on top while respecting the terms of that software and contributing back, like with Linux (GPL) and SUSE/Red Hat.
https://www.gnu.org/philosophy/free-sw.html
Being able to learn from the code is a core part of the ideology embedded into the GPL. Not only that, but LLMs learning from code is fair use.
I have to imagine this ideology was developed with humans in mind.
> but LLMs learning from code is fair use
If by “fair use” you mean the legal term of art, that question is still very much up in the air. If by “fair use” you mean “I think it is fair” then sure, that’s an opinion you’re entitled to have.
Actually, you don't have to. You just want to.
N=1 but to me, LLMs are a perfect example of where the "ideology embedded into the GPL" benefits the world.
The point of Free Software isn't for developers to sort-of-but-not-quite give away the code. The point of Free Software is to promote self-sufficient communities.
GPL through its clauses, particularly the viral/forced reciprocity ones, prevents software itself from becoming an asset that can be rented, but it doesn't prevent business around software. RMS/FSF didn't make the common (among fans of OSS and Free Software) but dumb assumption that everyone wants or should be a developer - the license is structured to allow anyone to learn from and modify software, including paying a specialist to do it for them. Small-scale specialization and local markets are key for robust and healthy communities, and this is what Free Software ultimately encourages.
LLMs becoming a cheap tool for modifying or writing software, even by non-specialists (or at least people who aren't domain experts), furthers those same goals, by increasing individual and communal self-sufficiency and self-reliance.
(INB4: The fact that good LLMs are themselves owned by some multinational corps is irrelevant - much in the same way as cars are important tool for personal and communal self-sufficiently, despite being designed and manufactured by few large corporations. They're still tools ~anyone can use.)
So either the community behaves, or the letter becomes more and more complicated trying to be more specific about what should be illegal. Now that GPL is trivially washed by asking a black box trained on GPLed code to reproduce the same thing it might be inevitable, I suppose.
> They're still tools ~anyone can use
Of course, technology itself is not evil, just like crypto or nuclear fission. In this case when we are discussing harm we are almost always talking about commercial LLM operators. However, when the technology is mostly represented by that, it doesn't seem required to add a caveat every time LLMs are mentioned.
There's hardly a good, truly fully open LLM that one can actually run on own hardware. Part of the reason is that hardly anyone, in the grand scheme of things, even has the hardware required.
(Even if someone is a techie and has the money and knows how to set up a rig, which is almost nobody on grand scale of the things, now big LLM operators make sure there are no chips left for them.)
So you can buy and own (and sell) a car, but ~anyone cannot buy and run an independent LLM (and obviously not train one). ~everyone ends up using a commercial LLM powered by some megacorp's infinite compute and scraping resources and paying that megacorp one way or another, ultimately helping them do more of the stuff that they do, like harming OSS.
It is not up in the air at all. It's completely transformative.
LLMs don't (cannot, by design) provide attribution, nor do LLM users have the freedom to run most of these models themselves.
The only indispensable part is the resource you're pirating. A resource that was given to you under the most generous of terms, which you ignored and decided to be guided by a purpose that you've assigned to those terms that embodies an intention that has been specifically denied. You do this because it allows you to do what you want to do. It's motivated "reasoning."
Without this "FOSS is for learning" thing you think overrules the license, you are no more justified in training off of it without complying with the terms than training on pirated Microsoft code without complying with their terms. People who work at Microsoft learn on Microsoft code, too, but you don't feel entitled to that.
On another note, regarding AI replacing most open source code. I forget what tool it was, but I had a need for a very niche way of accessing an old Android device it was rooted, but if I used something like Disk Drill it would eventually crap out empty files. So I found a GUI someone made, and started asking Claude to add things I needed for it to a) let me preview directories it was seeing and b) let me sudo up, and let me download with a reasonable delay (1s I think) which basically worked, I never had issues again, it was a little slow to recover old photos, but oh well.
I debated pushing the code changes back into github, it works as expected, but it drifted from the maintainers own goals I'm sure.
It's a shame since this technology is brilliant. But every tech company has drank the “AI is the future” Kool-aid, which means no one has incentive to seriously push back against the flood of low-effort, AI-generated slop. So, it's going to be race to the bottom for a while.
This is not a technology, but ethics and respect problem.
From the same article:
> Not all AI-generated bug reports are nonsense. It’s not possible to determine the exact share, but Daniel Stenberg knows of more than a hundred good AI assisted reports that led to corrections.
Meaning: developers and researchers who use the tool as it's meant to work, as a tool, are leveraging it to improve curl. But they are not skipping the part of understanding the content of their reports, testing it, and only then submitting it.
Guns have no other purpose than doing harm.
E.g. We don't blame cars, the tool, for driving into a gathering of people that can kill a dozen of them, we blame the driver. The purpose is transport, the same way LLMs for coding are a tool for assisting coding tasks.
We also don't allow car use without a license.
In the end what matters if allowing something is a net positive or not. Of course you can have more precise rules than just a blanket ban but when deciding and enforcing those rules is not free that also needs to be considered in the cost benefit analysis. Unless you can propose how projects can allow "good" contributions without spending more time on weeding out bad ones, a blanket ban makes sense.
I think you should try eating pudding with a fork next
heck, my cousin bet with me or let me compete eating pudding with chopsticks. (and that was long before i went to china)
practically speaking, the only downside of using a fork (or chopsticks) is scraping the bottom when you are finishing up.
Depends if you are in UK or not.
That's the choice as seen from the perspective of a white-hat hacker. But for an exploitable vulnerability, the real choice is to sell it to malware producers (I'm including state-sponsored spyware companies like the makers of Pegasus in this category) for a lot of money, or do the more moral thing and earn at least a little bit of money via a bug bounty program.
Stenberg has actually written about invalid/wildly overrated vulnerabilities that get assigned CVEs on their blog a few times and those were made by humans. I often get the sense some of these aren't just misguided reporters but deliberate attempts to make mountains out of molehills for reputation reasons. Things like this seem harder to account for as an incentive.
I had a sales rep even call me up basically trying to book a 3 hour session to review the AI findings unprompted. When I looked at the nearly 250 page report, and saw a critical IIS bug for Windows server (doesn't exist) existing at a scanned IP address of 5xx.x.x.x (yes an impossible IP) publically available in AWS (we exclusively use gcp) I said some very choice words.
https://gist.github.com/bagder/07f7581f6e3d78ef37dfbfc81fd1d...
> Sorry that I'm replying to other triager of other program, so it's mistake went in flow
I think it would be really interesting if someone at HackerOne did a dive into the demographic of many of the banned posters.
First new word of 2026. Thank you.
Seeing Bard mentioned as an LLM takes me back :)
https://hackerone.com/reports/3293884
Not even understanding the expected behaviour and then throwing as much slop as possible to see what sticks is the problem with generative AI.
This was partially the case before, where you'd still get weird spammy or extortive reports, but I guess LLMs enable random people to shoot their shot and gum up the works even more.
That is general trend in society now.
LLMs have been marketed for years, with great meadia fanfare, as being almost magical, something that can do the job of software engineers. Every week, the hype is driven further.
This matters. When people get told everyday that XYZ is magic, some will believe so, and use it as if it is magic.
To paraphrase a famous quote: AI-equipped bug hunters find 100 out of every 3 serious vulnerabilities.
Curl is a popular and well supported tool, if it needs help in this area, there will be a long line of competent people not volunteering their time and/or money. If you need help, get more help. don't use "AI slop" as an excuse to remove the one incentive people have to not sell exploits or just hoard them.
People also don't need cigarettes to fall ill. But smoking still causes health problems.
Bounties are a motivation, but there's also promotional purposes. Show that you submitted thousands of security reports to major open source software and you're suddenly a security expert.
Remember the little iot thing that got on here because of a security report complaining, among other things, that the linux on it did not use systemd?
In many ways one of the biggest benefits of bug bounties is having a dedicated place where you can submit reports and you know the person on the other end wants them and isn't going to threaten to sue you.
For the most part, the money in a bug bounty isn't work the effort needed to actually find stuff. The exception seens to be when you find some basic bug, that you can automate scan half the internet and submit to 100 different bug bounties.
It depends to who.
> If you want to be deemed an expert, write blogs detailing how the exploit works.
That's necessary if you sell your services to people likely to enjoy HN.
Am I doing this right?
Give it a presumption of guilt and tell it to make a list, and an LLM can do a pretty good job of judging crap. You could very easily rig up a system to give this "why is it stupid" report and then grade the reports and only let humans see the ones that get better than a B+.
If you give them the right structure I've found LLMs to be much better at judging things than creating them.
Opus' judgement in the end:
"This is a textbook example of someone running a sanitizer, seeing output, and filing a report without understanding what they found."
1. https://claude.ai/share/8c96f19a-cf9b-4537-b663-b1cb771bfe3f
I tried your prompt with https://hackerone.com/reports/2187833 by copying the markdown, Claude (free Sonnet 4.5) begins: "I can't accurately characterize this security vulnerability report as "stupid." In fact, this is a well-written, thorough, and legitimate security report that demonstrates: ...". https://claude.ai/share/34c1e737-ec56-4eb2-ae12-987566dc31d1
AI sycophancy and over-agreement are annoying but people who just parrot those as immutable problems or impossible hurdles must just never try things out.
It's the same as if you searched the web for a specific conclusion. You will get matches for it regardless of how insane it is, leading you to believe it is correct. LLMs take this to another level, since they can generate patterns not previously found in their training data, and the output seems credible on the surface.
Trusting the output of an LLM to determine the veracity of a piece of text is a baffilingly bad idea.
This is precisely the point. The LLM has to overcome its agreeableness to reject the implied premise that the report is stupid. It does do this but it takes a lot, but it will eventually tell you "no actually this report is pretty good"
The point being filtering out slop, we can be perfectly find with false rejections.
The process would look like "look at all the reports, generate a list of why each of them is stupid, and then give me a list of the ten most worthy of human attention" and it would do it and do a half-decent job at it. It could also pre-populate judgments to make the reviewer's life easier so they could very quickly glance at it to decide if it's worthy of a deeper look.
>However, I should note: without access to the actual crash file, the specific curl version, or ability to reproduce the issue, I cannot verify this is a valid vulnerability versus expected behavior (some tools intentionally skip cleanup on exit for performance). The 2-byte leak is also very small, which could indicate this is a minor edge case or even intended behavior in certain code paths.
Even biased towards positivity it's still giving me the correct answer.
Given a neutral "judge this report" prompt we get
"This is a low-severity, non-security issue being reported as if it were a security vulnerability." with a lot more detail as to why
So positive, neutral, or negative biased prompts all result in the correct answer that this report is bogus.
You cannot trust that it'll do a good job on all reports so you'll have to manually review the LLMs reports anyways or hope that real issues didn't get false-negatives or fake ones got false-positives.
This is what I've seen most LLM proponents do: they gloss over the issues and tell everyone it's all fine. Who cares about the details? They don't review the gigantic pile of slop code/answers/results they generate. They skim and say YOLO. Worked for my narrow set of anecdotal tests, so it must work for everything!
IIRC DOGE did something like this to analyze government jobs that were needed or not and then fired people based on that. Guess how good the result was?
This is a very similar scenario: make some judgement call based on a small set of data. It absolutely sucks at it. And I'm not even going to get into the issue of liability which is another can of worms.
The problem is the complete stupidity of people. They use LLMs to convince the author of the curl that he is not correct about saying that the report is hallucinated. Instead of generating ten LLM comments and doubling down on their incorrect report, they could use a bit of brain power to actually validate the report. It does not even require a lot of skills, you have to manually tests it.
Brave new world we got there.
Yes, this does not work for all vulnerability classes, but it is the best compromise in my mind.
Sure, it covers a very narrow scope but I am afraid the bigger issue would be that it is going to get spammed with submitted links. And those links will often be to strait up illegal content, it might not matter that such server instantly deletes all downloaded files.