Finding and Patching a CPython 0day in Hours: CVE-2026-6100
Here is the timeline of a Xint Code security researcher finding a critical vulnerability in CPython to getting it patched with AI-native autonomous code auditing.
Thursday, April 9: morning
Our researcher reached out to friends in the cybersecurity community volunteering to run fast scans via Xint Code on projects they suggested. One of the suggestions was Python's tarfile module.
Normal security code audits can take weeks to scope, schedule, and complete, and usually these audits exclude large portions of code due to time constraints.
In contrast, for the CPython scan that found this, our researcher just grabbed the latest version of the entire CPython source, scanned it with the Xint Code app in Fast mode without even including an operator prompt, and 30 minutes later this was the highest severity bug in the finished report:
Our researcher then copied the report into an AI coding assistant and successfully crashed Python on the first attempt.
Friday, April 10, 1:02pm PT
Our researcher reports the bug to the Python Software Foundation (maintainers for CPython). The CPython developer patching it discovered that it had a larger scope than the report (affected the bz2 and zlib compression formats instead of just lzma). Due to the detailed Xint report, they had enough information to create a patch in minutes.
Friday, April 10, 1:33pm PT
CPython developer pushes a patch for all three decompressors - half an hour after receiving the report!
Monday, April 13: morning.
In summaryâŠfor this whole process, the two slowest steps were:
Our researcher was busy Thursday evening, so they didn't report it until the next day.
It was fixed on Friday but the disclosure didn't go out until Monday (probably due to the weekend).