curl / Docs / curl CVEs / Bogus report filed by anonymous


Bogus report filed by anonymous

Project curl Security Dismissal, January 30 2024 - Permalink


None. CVE-2023-52071 was filed and made public by an anonymous person due to incompetence or malice. We cannot say which and the distinction does not matter to us.

The original description said:

tiny-curl-8_4_0, curl-8_4_0 and curl-8_5_0 were discovered to contain an off-by-one out-of-bounds array index via the component tool_cb_wrt.


CVE-2023-52071 was published on January 30 2024. Its existence was reported to us the same day.

The CVE references a git commit that fixes an assert. The assert itself accesses a stack based buffer one byte out of boundary. This code is only included in debug builds and never in release-builds. Even in debug builds it is not a security problem.

The referenced bug was introduced in a commit done on April 4 2023 (shipped in 8.3.0), later fixed again in a commit merged on September 13 2023 (shipped in 8.4.0).


It does not affect any version. It is not a security problem. It was a bug that we fixed in September 2023.


Relax. Use curl as usual.

The curl security team first tried to get this CVE rejected. The MITRE system unfortunately makes that impossible. We can only make this CVE get marked DISPUTED, which we are not satisfied with but have to accept under protest.

In spite of that, MITRE eventually (after the email below), changed status for this CVE to REJECTED anyway.


First we of course think that the "burden of proof" would be on the person that insists that there is a problem. The one saying that this is a CVE should provide the necessary details to explain "beyond reasonable doubt" that the identified problem is a vulnerability. There are no such details or explanations provided in the existing CVE. There is nothing there that identifies a vulnerability.

I am convinced someone just grepped commit messages for this and submitted a CVE and there was nothing and no one that even tried to confirm or check that this was actually legitimate. There was no filter in place and it was incorrectly let through. That is why it should be rejected. Saying it is "disputed" hints that there can be different views on this subject.

So, you are asking me to explain how this not identified vulnerability is actually not identifying a vulnerability.

Let me try:

The claimed issue identifies a bug in curl that

  1. only existed in debug-builds (thus disqualified)

  2. even in debug-builds, a bad access does at worst cause a crash, which is also what the assert itself does when triggered. Thus having the same end result. Not a vulnerability.

  3. in most situations, the bad access does not cause any problems at all, even in debug-builds (because the accessed stack memory is readable)

My claims can easily be verified and double-checked by simply reading the code. It is not complicated.

/ Daniel


Do not blindly trust the CVE system. It is full of cracks and bogus reports such as CVE-2023-52071.


This CVE was made public on January 30 2024. We were notified about it on January 30.


Thanks a lot!