I've had positive experiences getting CVEs corrected, usually within a day or so of emailing NVD. I always try to keep in mind that the NVD analyst team is very busy and has to deal with a diverse range of vulnerabilities that they can't become experts in every product/component, and the occasional error happens. So my advice would be: * Be gracious * Stick to the facts * Describe what's wrong in the data, and propose a correction (follow and understand precedent from other entries in the NVD) * Provide links to supporting material when appropriate There is also a facility for vendors to make official statements; this doesn't change the CVE but will help users analyze within the context of their environment/application. More information about this process is at https://nvd.nist.gov/vuln/vendor-comments. An example where the CVE was disputed as actually in a pre-release version is https://nvd.nist.gov/vuln/detail/CVE-2007-4239. To Ryan's suggestion, I would consider it an error that the description of CVE-2020-11656 does not mention SQLITE_DEBUG -- it's an important constraint on the set of vulnerable systems. Stating that binaries provided by sqlite.org are not compiled with SQLITE_DEBUG would be better suited for a vendor statement, since SQLite is often compiled from source and any product in the universe might have SQLITE_DEBUG turned on. (A similar line of reasoning applies here as, for example, a hypothetical vulnerability in the rtree extension. Developers of products that use SQLite need to evaluate and decide whether an update/release is in order. If a product doesn't use rtree than that product isn't affected.)