Hey @drh, A couple of things. First, for the CVEs that the community questions, take a look at the links [here](https://cve.mitre.org/cve/update_cve_entries.html). For the CVEs that need correction, follow the link for the [CVE Request web form](https://cveform.mitre.org/) and select "Request an update to an existing CVE Entry" and fill out the relevant information. If you have a PGP key, great. If not, don't worry about it. If you do not get an adequate response, please let me know. The other thing to consider is going down the path of having the SQLite community become its own [CVE Numbering Authority (CNA)](https://cve.mitre.org/cve/cna/rules.html). This would give you and the community much more control over what CVEs get published for SQLite. For example, you would have first right of refusal. You would also have the ability to directly control the contents of CVEs. It doesn't come with zero effort, but it is something you might want to consider. If this sounds attractive, let me know and we can discuss how it can happen. Finally, Peter is completely right about the statement about the SQLITE_DEBUG option above. I didn't mean to imply that statement should go into the CVE itself. That's not the appropriate place. But it would be good for there to be a statement as such somewhere relevant on the SQLite site so that users of the binaries from the SQLite site who see the CVE might have an answer to the question of if they are affected.