July 31, 2026
CVE-2026–16764 // Privilege Escalation on DefectDojo ≤ 2.59.0 // Commit diff to weaponized exploit
A practical AI-assisted exploit generation

By Nicolas Mattiocco
4 min read
Introduction
In this article, I want to highlight how AI is transforming vulnerability management operations, with a particular focus on exploit generation.
It has never been easier to create an exploit than it is today. With the rise of generative AI and the rapid progress of agentic cybersecurity systems, many tasks that once required deep expertise, extensive training, or access to rare — and often expensive — specialized skills are becoming increasingly accessible. While this statement should not be generalized to every domain, it is especially true for open-source software and Internet-exposed web components.
As we enter the post-Mythos/Fable era (alongside models such as ChatGPT 5.6 Sol, GLM 5.2, and Kimi K3 at the time of writing), we are witnessing a steady acceleration in the automation and scalability of vulnerability research workflows. Today, AI can meaningfully assist across the entire lifecycle, including:
- Identifying potential vulnerabilities.
- Validating prerequisites and attack paths by producing a reproducible proof of concept.
- Recommending or generating a fix or workaround.
- Producing a stable, working exploit script.
- When feasible, adapting that exploit into a more operational or weaponizable version.
Of course all vulnerabilities are not the same as it will depend of the nature of the affected component (OS, middleware, web application, library, physical device), prerequisites, access to the technology and vulnerable components, documentation available/source code and the nature of the vulnerability itself.
In this article, we'll walk through a practical example demonstrating how far these capabilities have evolved. The goal is to show how AI can assist throughout the process with minimal manual coding and without requiring the level of expertise traditionally associated with offensive security.
Creating a weaponized exploit like a professional prompt-kiddy
The naive prompt with Anthropic Opus 4.8 (High Effort) within a vanilla Claude Code (2.1.206) harness without any skills:
You are a cybersecurity expert specialized in offensive operations on WEB components. Analyse the commit https://github.com/DefectDojo/django-DefectDojo/commit/68a272f299d096249fd3ba9c2676bf69012857bf (code diff changes, descriptions, comments) and try to identify a working exploit. then, generate a nuclei template and validate it by spawning a vulnerable Docker instance of the app.
No less, no more. Just let the LLM a chance to shine as a senior cybersecurity researcher. 7m 20s and ~150k tokens later, the meal is cooked and ready to be served. In that case, no human interaction were needed. The recap:
Done — the DefectDojo lab is complete and validated.
GHSA-w2j3-x3j3-mm43 — DefectDojo API privilege escalation
Reversed from the commit (no PoC given): the API v2 UserSerializer.validate() guarded is_superuser but not is_staff, and is_staff was a writable field. A non-superuser with only
auth.change_user can PATCH /api/v2/users/{id}/ {"is_staff": true} → gains staff → reaches the default-on /admin/ → ticks is_superuser (full superuser). Fixed by adding the
is_staff guard + locking down /admin/. CVSS 7.8.
A key finding while building it: the version story is subtle. 2.58.2 (the image I first tried) doesn't even list is_staff in the serializer — so the PATCH was silently dropped and
the DB never changed. The genuinely vulnerable code is in the release/2.59.0 branch (is_staff added to fields, no guard), which was never published as a Docker image (superseded
by 3.0.0). So the lab runs the 2.58.2 image and reproduces 2.59.0's exact vulnerable serializer by adding the unguarded is_staff field — documented transparently in setup.sh and
the README.
Deliverables (defectdojo-ghsa-w2j3-x3j3-mm43/):
- docker-compose.yml (7-container DefectDojo stack, port 8083) + setup.sh — brings it up, reproduces the vulnerable serializer, provisions a low-priv user (lowpriv +
auth.change_user) with an API token, and self-confirms the escalation. .gitignore for the reference source.
- nuclei/GHSA-w2j3-x3j3-mm43.yaml — token-driven: resolve self id → PATCH is_staff=true → match 200 + "is_staff":true → revert to false.
- README.md + remediation.json; top-level index updated.
Validation (all passed):
- Live exploit confirmed against the DB ground truth: lowpriv.is_staff flipped f → t via the low-priv token (200 + "is_staff":true).
- Template matched; the revert step restored is_staff=f (verified in DB).
- Negative control: invalid token → no match.
- setup.sh passes bash -n; template validates; remediation.json valid.
The lab is running on <http://127.0.0.1:8083> (admin admin/Admin#12345, low-priv token printed by setup.sh).
Two housekeeping notes carried over: (1) the background subagent had stalled exactly on the is_staff-not-in-response symptom — I took over, root-caused it to the 2.58.2-vs-2.59.0
field difference, and finished; (2) the three earliest labs still lack remediation.json — happy to backfill those whenever you want.Done — the DefectDojo lab is complete and validated.
GHSA-w2j3-x3j3-mm43 — DefectDojo API privilege escalation
Reversed from the commit (no PoC given): the API v2 UserSerializer.validate() guarded is_superuser but not is_staff, and is_staff was a writable field. A non-superuser with only
auth.change_user can PATCH /api/v2/users/{id}/ {"is_staff": true} → gains staff → reaches the default-on /admin/ → ticks is_superuser (full superuser). Fixed by adding the
is_staff guard + locking down /admin/. CVSS 7.8.
A key finding while building it: the version story is subtle. 2.58.2 (the image I first tried) doesn't even list is_staff in the serializer — so the PATCH was silently dropped and
the DB never changed. The genuinely vulnerable code is in the release/2.59.0 branch (is_staff added to fields, no guard), which was never published as a Docker image (superseded
by 3.0.0). So the lab runs the 2.58.2 image and reproduces 2.59.0's exact vulnerable serializer by adding the unguarded is_staff field — documented transparently in setup.sh and
the README.
Deliverables (defectdojo-ghsa-w2j3-x3j3-mm43/):
- docker-compose.yml (7-container DefectDojo stack, port 8083) + setup.sh — brings it up, reproduces the vulnerable serializer, provisions a low-priv user (lowpriv +
auth.change_user) with an API token, and self-confirms the escalation. .gitignore for the reference source.
- nuclei/GHSA-w2j3-x3j3-mm43.yaml — token-driven: resolve self id → PATCH is_staff=true → match 200 + "is_staff":true → revert to false.
- README.md + remediation.json; top-level index updated.
Validation (all passed):
- Live exploit confirmed against the DB ground truth: lowpriv.is_staff flipped f → t via the low-priv token (200 + "is_staff":true).
- Template matched; the revert step restored is_staff=f (verified in DB).
- Negative control: invalid token → no match.
- setup.sh passes bash -n; template validates; remediation.json valid.
The lab is running on <http://127.0.0.1:8083> (admin admin/Admin#12345, low-priv token printed by setup.sh).
Two housekeeping notes carried over: (1) the background subagent had stalled exactly on the is_staff-not-in-response symptom — I took over, root-caused it to the 2.58.2-vs-2.59.0
field difference, and finished; (2) the three earliest labs still lack remediation.json — happy to backfill those whenever you want.Nuclei template and Docker-ready vulnerable application are available here [4]. Thank you Claude ❤️🔥
Mitigation guidelines
- Upgrade DefectDojo to 2.58.3, 2.58.4, or 3.0.0 (or later).
- Audit auth_user for accounts with is_staff=1 or is_superuser=1 that should not have them and revoke; review who holds the 'Configuration -> Users (change)' (auth.change_user) permission.
- Disable the Django admin site unless explicitly required (set DD_DJANGO_ADMIN_ENABLED=False), and ensure /admin/ is restricted to superusers.
Monitoring (see remediation.json for more details)
- Search in access logs some PATCH/PUT to /api/v2/users// with a JSON body containing "is_staff": true, sent with a non-superuser API token
Search exposed vulnerable assets using CPE: cpe:2.3:a:defectdojo:defectdojo:5.59.0*:::::::*
Caveats & limitations
It will be a grotesque abuse or a scam to announce that vulnerability management is (actually) broken now. In the real world, we observed at Patrowl that scaling detection and exploitation operations is already possible (we do this continuously since ~6 years !) but the 2 main issues remain 1) the mapping of exposed assets that belong to our clients and 2) the ownership of vulnerable assets that must be fixed.
We still have an enrichment issue of CVE entries in the NIST database that do not tag exploits. These metadata is so useful in the prioritization scheme of known vulnerabilities. We are working hard to connect the dots on the intel.patrowl.io vulnerability intelligence platform.
Takeways:
- There isn't really any deep technical barrier anymore, nor a strong dependency on scarce human expert skills, to identify vulnerabilities — but also to exploit them at scale. A prompt and few tokens from an affordable LLM model is only what you need in several cases.
- A tiny piece of information, like a simple commit, can become a trigger in an automated exploit-generation pipeline. The results so far are already pretty staggering, and it strongly suggests this automation will let attackers massively scale their operations.
- This has already been highlighted by initiatives like zerodayclock.com, but the "Time-to-Exploit" metric is now negative — meaning the majority of large-scale vulnerability exploitation is now observed before the official publication of a CVE. But not all vulnerabilities has a CVE ;)
- It might be a grotesque abuse or a scam to announce that vulnerability management is (actually) broken now. In the real world, Patrowl.io is already scaling detection and exploitation operations (we do this continuously since ~6 years !). By the way, this enable us and the community to work faster and raise our chances to spot a threat before attackers.
- Given the massive advances in this space over the last ~18 months, the challenge for organizations today and tomorrow might no longer be to find a vulnerability on their assets as early as possible, but to be able to fix it as fast and as efficiently as possible.
Stay tuned !!
References
- [1] https://github.com/DefectDojo/django-DefectDojo/commit/68a272f299d096249fd3ba9c2676bf69012857bf
- [2] https://nvd.nist.gov/vuln/detail/CVE-2026-16764
- [3] https://intel.patrowl.io/cves/CVE-2026-16764
- [4] https://github.com/Patrowl/PatrowlIntelLabs/tree/master/defectdojo-ghsa-w2j3-x3j3-mm43
- [5] https://github.com/Patrowl/PatrowlIntelLabs/blob/master/defectdojo-ghsa-w2j3-x3j3-mm43/remediation.json
More on Patrowl.io
Patrowl is a SaaS cybersecurity solution, providing continuous protection for your external attack surface exposed on internet. In real-time, it reveals, monitors, and simplify cybersecurity, allowing remediation without complex tool. Anticipate cyber threats and strengthen the efficiency of your organizations.