Researchers have since concluded that this vulnerability, and at least five more from the same source, were in fact false and referred to non-existent problems. They were also all flagged by Gptzero as highly likely being generated by an LLM. [1]

Assessment

The verification system for vulnerability exploits is under severe strain. One reason is that the use of LLM to detect new vulnerabilities in code has flooded the verification systems with vulnerabilities that often are of dubious quality. At the same time the US administration has fired a significant part of the US cybersecurity agency CISA workforce. CISA has been a key player in the system for verifying new vulnerabilities.

The result appears to be that the organizations involved in verifying vulnerabilities are cutting corners in their verification process, leading to LLM-generated “slop” being accepted. This is also an example of how processes not adapted to handle the speed with which LLM can generate content risk being overwhelmed. The lack of unified responsibility for vulnerability verification also makes it harder for authorities to respond to these developments.

This doesn’t mean that the overall threats from cyber actors exploiting vulnerabilities have significantly increased, at least not yet. There are now tools being released that allow software developers to use LLM to verify code even before production, so the overall balance between offense and defense may not be significantly altered. It is also worth noting that while the number reported vulnerabilities continue to rise, there is no corresponding rise in reports of vulnerabilities known to exploited in the wild (KEV).

It does mean, however, that until a solution is found to the deluge of LLM-generated vulnerability reports, the CVE and CVSS score system may not be as reliable as it has been in the past for determining which vulnerabilities to patch first.

References

[1] https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/