The CVE program itself is an unauthenticated remote DoS vulnerability [LWN.net]

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 15:58 UTC (Mon) by smoogen (subscriber, #97)
In reply to: The CVE program itself is an unauthenticated remote DoS vulnerability by geofft
Parent article: SQLite Critical CVEs or LLM Slop? (JFrog blog)

If you have any sort of policy that all CVEs have to be patched, as apparently many large companies do

I have found that a lot of this seems pushed from outside of the company.

You want to keep your business insurance for something? Make sure you have a full CVE patch policy
You want to keep your business access to banking? Make sure you have a full CVE patch policy
You want to keep your business access to certain customer markets? Make sure you have a...
You want to be able to sue someone because they reneged on the above...

The bigger businesses get the most audits from insurers, customers, regulators, etc because they also have the most contracts. They then start pushing this down the chain because it doesn't matter if it is a third level provider which was the initial cause of whatever event they are dealing with..

None of this invalidates (and really just emphasizes what @geofft also said:

I actually think that this is, essentially, a DoS vulnerability in the CVE process itself. Anyone can submit an entry into a database that gets insufficiently validated and causes other people to have to scramble and respond and maybe makes their automated systems break. That's unauthenticated input causing denial-of-service attacks!

to post comments

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 17:35 UTC (Mon) by linuxrocks123 (guest, #34648) [Link] (13 responses)

I'll _MAYBE_ buy insurance requirements and I'll _MAYBE_ buy clueless customers, particularly if the clueless customers are governments. If the clueless governments are from particularly clueless places like the EU, I wouldn't even be surprised.

But I will not buy banking access. Business checking accounts are extremely easy to open. They are not concerned with your internal IT infrastructure whatsoever. And, the implausibility of that claim makes me suspicious that the other claims are actually true, even if they are plausible.

Banking

Posted Aug 3, 2026 18:01 UTC (Mon) by corbet (editor, #1) [Link] (6 responses)

I am not the person you are replying to, so I may be way off but ... "banking" for a business goes way beyond opening a checking account. If you, for example, accept credit cards, they suddenly become far more interested in your security practices. I would not be surprised to learn that this happens for businesses seeking credit as well.

Banking

Posted Aug 3, 2026 19:15 UTC (Mon) by pizza (subscriber, #46) [Link] (5 responses)

> If you, for example, accept credit cards, they suddenly become far more interested in your security practices. I would not be surprised to learn that this happens for businesses seeking credit as well.

FYI, "banking" != "payment processing"

(you may see both provided under the same roof, but they are very different sets of services with very different requirements)

"Seeking credit" is also distinctly different.

Banking

Posted Aug 3, 2026 19:29 UTC (Mon) by corbet (editor, #1) [Link] (4 responses)

You know, when people start filling the space with tedious quibbles like this, I strongly regret having ever added the ability to post comments to LWN.

Is your real point that the original poster should have said "financial services" rather than "banking"?

Banking

Posted Aug 3, 2026 19:54 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> Is your real point that the original poster should have said "financial services" rather than "banking"?

I don't know if they had meant to use the word "banking" as a synonym for generic "financial services" or the more narrow "bank account" sense. Either way, they were factually incorrect, only certain types of financial service providers place any sort of obligations upon a business' internal IT practices.

The main ones that do are payment processors (the PCI-DSS is quite a beast, as I'm sure you are well aware) and providers of certain types of insurance looking to lessen the risk of taking you on as a customer. But simply opening or accessing bank accounts/lines of credit, most types of insurance, brokerages, etc etc? Nope.

Banking

Posted Aug 3, 2026 23:15 UTC (Mon) by WolfWings (subscriber, #56790) [Link] (1 responses)

For any company interacting with the internet they are all functionally one and the same. You are (accidentally I hope) XKCD/2501'ing here.

"Banking" access is a well-understood catchall for payment handling, payroll, etc, all of which are the source of many if not most audit requirements for any given company. And yes, all of those require opening an account, so technically that's rolled up in things too at some layer I suppose even.

Anyone that works B2B IT support runs into this constantly, doesn't matter if you're a cloud provider, storage vendor, networking gear, VoIP service, whatever, it's where easily 50% or more of the "Hey so our auditor reported these CVE's..." tickets come from if you inquire is just a non-technical "banking" response back.

Banking

Posted Aug 4, 2026 12:30 UTC (Tue) by pizza (subscriber, #46) [Link]

> "Banking" access is a well-understood catchall for payment handling, payroll, etc, all of which are the source of many if not most audit requirements for any given company.

As an entire blanket category, sure. But my entire point is that the sub-categories are *very* different and shouldn't be lumped together.

These are the entire "IT requirements" for most businesses that take credit cards:

* Working internet connection and power source for the payment-processor-supplied(+managed) payment terminal

Meanwhile, these are the entire "IT requirements" for nearly everything else:

* Internet-capable device with a relatively up-to-date web browser

That's it.

Now if you run things in-house instead of contracting it out to specialists (because this saves you money at larger scales), sure, there _may_ be additional requirements for _some_ sub-categories, but the specific details vary considerably. The critical question is "who is on the hook should $bad_thing occur". If it's an external entity (eg merchant/payment processor or insurance company) then they may contractually impose requirements as a condition of service.

Of course there's also increasing levels of regulatory crap you have to deal with the more stuff you do in-house, but that's imposed by the government, not a "financial services" provider.

(BTW, most of my career has been spent at small companies for whom *I* was effectively IT department. So I'm more than a little familiar with this crap)

Banking

Posted Aug 6, 2026 19:49 UTC (Thu) by smoogen (subscriber, #97) [Link]

My apologies Jonathan for starting this.. I should have been clearer about payment processing and financial services versus 'banking access'.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 3, 2026 18:19 UTC (Mon) by hunger (subscriber, #36242) [Link] (5 responses)

Most governments are way less clueless than you make them out to be. Companies have a way worse track record here.

Go and check the rules you need to follow when accepting credit card data from customers... you will be surprised how "banking" can be a challenge to IT departments.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 2:24 UTC (Fri) by linuxrocks123 (guest, #34648) [Link] (4 responses)

payment card processing != banking

Visa, Mastercard, American Express, and Discover are not banks. Discover is owned by a bank -- Capital One -- but that's only because Capital One acquired Discover, and the Discover Network is still its own "thing" inside of Capital One.

And, before you start to say otherwise, no, you do not have to have an agreement with a bank to take credit cards. You can just use Stripe. And send your funds to a brokerage account even instead of a normal bank account if that floats your boat.

Now, you _ARE_ correct that the payment card industry promulgates a bunch of really stupid IT requirements. Those idiotic requirements are one big reason I would never in 10 billion years take payment cards. The other big reason would be not wanting to lose over 3% of my gross revenue to bullshit card processing fees. Either reason alone would be sufficient for me to "nope" the fark right out of there if anyone ever tried to convince me to take payment cards.

Maybe LWN should stop taking payment cards and use Zelle instead. Instant 3% gross revenue increase unless subscribers decide it's too annoying. So to avoid that maybe keep taking the cursed cards but pass on your processing fees to us and let us avoid them by using Zelle or a check.

I get 4%+ cash back on everything I buy as a consumer, and that's great for me, but I'm not an idiot. I know that "cash back" money is coming out of merchants' pockets. I know payment cards are evil and would love to see merchants no longer have to suffer an invisible tax from taking them. Down with all four of the payment card networks, thieving bastards every one.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 2:47 UTC (Fri) by dskoll (subscriber, #1630) [Link] (1 responses)

Maybe LWN should stop taking payment cards and use Zelle instead

Zelle is USA-only. So LWN would still need to take cards (or find other ways) for non-US subscribers to pay.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 4:28 UTC (Fri) by linuxrocks123 (guest, #34648) [Link]

Early Warning Services is working on fixing that: https://www.prnewswire.com/news-releases/zelle-heads-to-i...

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 7, 2026 6:02 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Zelle does not have proper customer _and_ merchant protection. It also does not have a proper payment story (how do you link a Zelle transaction?).

> Zelle® Heads to India, Unveils ZelleUSD℠ Stablecoin For Other Markets

It's dead. Cryptocrap kills everything.

The CVE program itself is an unauthenticated remote DoS vulnerability

Posted Aug 8, 2026 2:59 UTC (Sat) by NYKevin (subscriber, #129325) [Link]

In general, Zelle is highly questionable for almost all purposes. The banks like to pretend[1] that Regulation E does not apply to Zelle, which in plain English means "no chargebacks, no refunds, and we specifically don't want to hear about how you thought he really was the deposed prince of Nigeria." I wouldn't touch Zelle for anything other than giving money to a personal friend or family member.

[1]: See https://www.bitsaboutmoney.com/archive/regulation-e/ for a more precise explanation of what the banks claim and how legally plausible it is. But note that the average consumer is not in a great position to start a legal battle with the average bank.