---

If you have been keeping up with security reports, vulnerability databases, or even Twitter feeds on cybersecurity, you might have stumbled upon CVE-2022-20128. You may have tried to find details, only to come across a single confusing word: REJECTED.

So, what does it mean when a CVE ID, like CVE-2022-20128, is rejected? Why is there no exploit, no code, no patch, and not even a description? In this long read, let's break down everything you should know about this rejected CVE, including technical details, industry perspectives, and what you should do if you see rejected IDs like this.

What is CVE-2022-20128?

CVE-2022-20128 was supposed to be a unique identifier for a specific security vulnerability, just like thousands of others cataloged every year by the Common Vulnerabilities and Exposures (CVE) project. Normally, each CVE entry points to a description of a bug, impacted software, technical details, possible exploits, and references for more information.

But try looking up CVE-2022-20128 on MITRE or NVD, and you'll find this message instead:

> REJECTED
>
> This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. Neither this CVE ID nor the information provided for it should be used for referencing or linking to the associated vulnerability.

Why Are CVE IDs Sometimes Rejected?

This may sound anticlimactic, but the main reason a CVE is rejected is simple: A mistake or change happened during the reporting process. This could mean:

* The vulnerability turned out to not be a security flaw.
* The same issue was reported under a different CVE and was duplicated.
* The reporter decided to withdraw the submission.
* There was a clerical or administrative error.

In short: No vulnerability is officially recorded under CVE-2022-20128. The CVE Numbering Authority (CNA) intentionally removed it to avoid confusion.

Rejected CVE: Is There Any Security Impact?

No, there is no security impact tied to CVE-2022-20128.

Still Curious? Here's a “Fake” Proof-of-Concept

Just for illustration, let’s imagine what an exploit would look like if this CVE were valid (it’s not!):

# This is a non-working example to demonstrate what a typical CVE PoC might look like.

import requests

vulnerable_url = "http://example.com/vulnerable";
payload = {'input': "' OR 1=1--"}

r = requests.post(vulnerable_url, data=payload)
print("Vulnerability triggered, got:", r.text)

Remember: This code does NOT relate to CVE-2022-20128. There is no real vulnerability behind this CVE!

Real-World Example: How Rejected CVEs Happen

- Duplicate Reporting: A researcher may submit a bug affecting Android, and it gets assigned CVE-2022-20128. Later someone notices it’s already covered under CVE-2022-12345. To avoid confusion, CVE-2022-20128 is rejected.
- Error in Reporting: Someone fills in the wrong details or the fix turns out unrelated to security. The CVE gets withdrawn.

> The official MITRE list of rejected CVEs shows that rejections are common and serve to clean up the catalog.

Should You Remove Rejected CVEs from Your Security Tools?

Yes, it’s a good practice to suppress or ignore rejected CVEs in your vulnerability management systems. It keeps reports accurate and avoids wasting time chasing non-issues.

Final Words: Transparency Matters

Vulnerability tracking is an evolving and sometimes messy process. Rejected CVEs like CVE-2022-20128 show the transparency of the system—when a report is found to be invalid, it’s publicly marked as such. Think of it as a “404 Not Found” for security bugs.

References

- CVE-2022-20128 on CVE.org
- List of CVE Rejections (MITRE)
- How CVE IDs are assigned and rejected (CVE FAQ)
- NVD Entry for CVE-2022-20128


TL;DR:
*CVE-2022-20128 does not describe any real vulnerability. It was withdrawn and should not be referenced for any exploitable issue. If you see it in your reports—don’t worry, there’s nothing to fix!*


*If you found this useful, bookmark for future reference, and share it to clear up confusion on rejected CVEs!*

Timeline

Published on: 01/17/2025 23:15:12 UTC