exploitarium: An archive of vulnerability PoCs from 12 repositories and 96 tracked entries
A Git archive for security researchers to inspect public vulnerability PoCs, preserving the original file contents of 12 repositories.
GitHub bikini/exploitarium Updated 2026-09-05 Branch main Stars 4.5K Forks 1.2K
Python C Rust Vulnerability Research Fuzzing Git GPT-5.3 Public PoCs

🧭 Decision Guide

Try it if you

  • You are researching public vulnerability PoCs for components such as c-ares, curl, Firefox, or libssh2.
    The README's “Exploitarium” section lists direct entries for c-ares, curl, Firefox, libssh2, and other components.
  • You need to verify whether an old repository archive preserves identical Git file contents.
    The README's “Consolidation Check” section describes Git tree comparisons requiring matching paths, object types, tree modes, and blob IDs.
  • You want to study the public research record describing GPT-5.3 in a fuzzing workflow.
    The README's “Statement” section says the author used GPT-5.3 for all fuzzing while hand-typing the actual PoCs.

Skip it if you

  • You need copyable installation, build, or execution commands for running a PoC.
    The README provides archive-verification details and entry names, but the supplied material contains no installation, build, or execution commands.
  • You need the complete issues, pull requests, releases, or original Git history.
    The README's “Consolidation Check” section explicitly says this repository-level metadata remains in the original repository histories.
  • Your workflow requires a specified open-source license or stable release.
    Project metadata lists the license as unspecified, with 0 releases and “No releases” as the latest version.

Requirements

  • The README only confirms GitHub-cloned content containing vulnerability PoCs and research notes; it lists no runtime versions, dependencies, or hardware requirements.
  • The README's “ABUSE” section requires that repository materials not be used maliciously.

Watch out

  • Issues, pull requests, and releases from the original repositories do not appear in this archive.
    The README's “Consolidation Check” section explicitly says this metadata remains in the original repository histories.
  • The README states that the project was incomplete when published, so PoC coverage should not be assumed to be complete.
    The original wording in the README's “Statement” section is “This repo was incomplete when published”.
  • The RustDesk material used AI assistance, and the README files are described as entirely AI-generated and then reviewed.
    The README's “Statement” section explicitly mentions RustDesk and AI-generated README files.

Not stated in the README

  • Specific dependencies, build steps, supported versions, and runtime environments for each PoC are unspecified.
  • CVE assignment, disclosure status, and vendor remediation status are unspecified.
  • The project license is unspecified, and redistribution rights for the PoCs and original files are unclear.
  • The README does not explain how to run these exploit PoCs safely in an isolated environment.
  • Per-entry test results, reproducibility rates, and affected version ranges are unspecified.

💡 Deep Analysis

6
No I maintain an open-source project and want to use the RustDesk and objdump-related PoCs to validate fixes, while confirming original attribution, vulnerability ownership, and redistribution rights. Is this repository sufficient as a merge source?
For: An open-source maintainer reviewing vulnerability attribution, licensing, and historical context, especially for RustDesk, objdump, and formerly standalone repositories

No: it should not be used directly as a merge or redistribution source because it preserves code content without establishing sufficient licensing or complete historical context.

  • The project data marks the license as Unknown and shows no formal releases, leaving the permissions for copying, modification, redistribution, and commercial integration unclear.
  • The Consolidation Check says that stars, issues, pull requests, releases, and separate Git history remain in the original repositories. The consolidated folders may therefore lack important discussions and timelines.
  • The Statement explicitly acknowledges that another researcher found the objdump issue first and links to 4D4J/objdump-Out-Of-Bounds-write, showing that attribution cannot be inferred from the current folder name alone.
  • The README also says RustDesk received AI assistance and distinguishes the PoCs from the AI-generated README files, so authorship, third-party code, and disclosure obligations must be checked separately.
  • Project data: license = “Unknown”; latest_release is empty; release_count = 0
  • Consolidation Check: stars, issues, pull requests, releases, and separate Git history were not retained in the consolidation
  • Statement: “someone beat me to the punch” and the `4D4J/objdump-Out-Of-Bounds-write` link
  • Statement: “I did use AI assistance for RustDesk”
Not stated in the README:The original copyright and license for code, dependencies, and documentation in each folder;Whether original authors authorized redistribution through this repository;The CVE mappings, disclosure timelines, and third-party contributor list for each PoC
Yes I am studying how GPT-5.3 participates in fuzzing workflows and want to compare the human-written portions of Python, Rust, and C PoCs. Can this project serve as a case study of AI-assisted vulnerability research?
For: A security research engineer studying a GPT-5.3-assisted fuzzing workflow while distinguishing AI-generated documentation from human-written PoCs

Yes: it is suitable as a case study because the README clearly describes the boundaries of AI use in fuzzing, Rust assistance, and documentation, but it is not a reproducible AI tooling package.

  • The Statement says the author used GPT-5.3 for “ALL the fuzzing” under a strict workflow, giving the repository value for studying an AI-assisted process.
  • The same section says, “None of the actual PoCs themselves were vibe-coded; I did, in fact, hand-type them,” separating AI-assisted discovery from PoC implementation.
  • The README specifically mentions AI assistance for RustDesk and says the README files were “entirely AI.” The project data also shows Python, Rust, C, JavaScript, and HTML, enabling cross-language comparison.
  • However, the project does not publish GPT-5.3 prompts, tool-call traces, model outputs, human-edit diffs, or reproducible fuzzing harnesses, so the experimental claims cannot be rigorously replayed from this repository alone.
  • Statement: “I used GPT-5.3 for ALL the fuzzing, as barely any ‘thought’ is necessary when provided with an efficient workflow.”
  • Statement: “None of the actual PoCs themselves were vibe-coded; I did, in fact, hand-type them.”
  • Statement: “I did use AI assistance for RustDesk”; “The README files are very clearly entirely AI”
  • Project data: Python, HTML, JavaScript, C, and Rust are the main languages
Not stated in the README:The exact GPT-5.3 prompts, context, and tool-calling method;Which findings were proposed by the model versus independently found by the author;What human validation was applied and whether failed samples were retained
It depends I handle product-security validation for Firefox, Postgres, OpenSSH, and QEMU, and my team needs to check patch coverage against public PoCs in isolated environments. Can I use this repository as a vulnerability-validation baseline?
For: A product-security engineer maintaining Firefox, Postgres, OpenSSH, and QEMU who wants to validate patch coverage against public PoCs in isolated environments

It depends: the repository can provide valuable validation samples, but it is insufficient as the sole formal vulnerability baseline or patch-coverage inventory.

  • It directly includes firefox-152.0.5-backup-nss-rce-poc, firefox-152.0.6-stock-page-native-calc-poc, postgres-ri-owner-switched-cast-poc, openssh-agent-lock-provider-bypass, and qemu-cxl-type3-mailbox-escape-poc, matching the products in scope.
  • The consolidation process checked 12 former repositories and 96 tracked entries using Git trees and blob IDs, which helps establish that the test materials match the archived source bytes.
  • However, the project insights state that it provides no unified vulnerability scanning, asset discovery, patch management, risk scoring, or enterprise reporting. The README also says that issues, pull requests, releases, and separate history may not have been preserved.
  • It can therefore support code-level or lab-level validation, but cannot independently establish affected versions, remediation status, attribution, or enterprise risk conclusions.
  • Consolidation Check: listed Firefox, Postgres, OpenSSH, and QEMU entries
  • Consolidation Check: “12 repos and 96 tracked entries with zero mismatches”
  • Project insights, usage_limitations: no unified scanning, patch management, risk scoring, or enterprise reporting
  • Consolidation Check: “Repository-level metadata such as stars, issues, pull requests, releases, and separate Git history remain in the original repository histories.”
Not stated in the README:The affected versions, fixing commits, and vendor-advisory mappings for each entry;The expected differences and success criteria before and after a patch;Whether the product-security team has authorization to run or redistribute the code
Yes I handle defensive testing for Nextcloud, NodeBB, Gogs, and Redis, and can only validate RCE, CSRF, token, and permission-boundary issues in isolated non-production environments. Is this archive suitable for selecting targeted test cases?
For: An application-security engineer conducting defensive testing for an enterprise using Nextcloud, NodeBB, Gogs, and Redis, with isolated non-production environments for RCE and privilege-boundary validation

Yes: it is suitable for selecting targeted defensive-testing samples, provided it is treated as a research archive rather than a validated enterprise security product.

  • The README lists nextcloud-federated-share-bearer-token-poc, nodebb-activitypub-attributedto-local-uid-spoof-poc, gogs-admin-csrf-git-hook-rce-poc, and redis-vset-duplicate-hnsw-id-rce-poc, matching token, identity, CSRF, and RCE scenarios.
  • The project insights describe mostly self-contained folders organized by vulnerability or target software, which can be read and copied into isolated lab environments. This is more convenient for topic-focused testing than searching multiple standalone repositories.
  • The ABUSE section explicitly prohibits malicious use and describes the work as good-faith, open-disclosure vulnerability research, aligning with defensive validation.
  • However, the README does not provide unified affected-version data, remediation status, reproduction criteria, or enterprise reporting. The presence of a folder alone cannot establish that a production asset is affected.
  • Consolidation Check: Nextcloud, NodeBB, Gogs, and Redis entries
  • Project insights, architectural_strengths: “目录级自包含结构降低了不同PoC之间的耦合”
  • ABUSE: “This is good-faith, open-disclosure vulnerability research”
  • Project insights, usage_limitations: no unified scanning, patch management, risk scoring, or enterprise reporting
Not stated in the README:The product versions, configuration prerequisites, and remediation status for these entries;The resource, network, and privilege requirements for running each PoC in an enterprise lab;Whether any PoC modifies data, creates persistence, or affects the host system
It depends I teach Python, C, Rust, and JavaScript together and want to build exercises around real Firefox, Postgres, OpenSSH, nghttp2, and Nextcloud cases. Is this repository suitable as a student lab textbook?
For: An instructor preparing cross-language security-course and CTF material covering browser, database, and network-protocol vulnerabilities

It depends: the repository is useful for instructors selecting authentic cases and code fragments, but it is not a uniform, turnkey student-lab textbook.

  • The README positions the project as an archive of public exploit PoCs and vulnerability research writeups, with self-contained folders organized around vulnerabilities or target software, which helps instructors select individual topics.
  • Entries cover Firefox, Postgres, OpenSSH, nghttp2, Nextcloud, and NodeBB. The project data also shows Python, C, Rust, JavaScript, and HTML, supporting cross-ecosystem teaching.
  • However, the user insights indicate that build and execution methods vary by directory. Learners must understand each target’s version, build method, runtime state, and input format; the README provides no repository-wide installation command or course-lab workflow.
  • The README also explicitly says the repository was incomplete when published, while ABUSE says not to use the material maliciously. Therefore, each folder should not be assumed to be a complete, stable, independently audited exercise.
  • Exploitarium: “Most folders contain one of my former standalone PoC repos, preserved with its original README and tracked files.”
  • Consolidation Check: Firefox, Postgres, OpenSSH, nghttp2, Nextcloud, and NodeBB entries
  • Project data: Python, HTML, JavaScript, C, and Rust
  • ABUSE: “Do NOT, under any circumstances, use any material in this repository maliciously.”
Not stated in the README:Whether the course environment meets each PoC’s version and platform requirements;The expected output, grading criteria, and failure handling for each exercise;Which folders are suitable for beginners and what prerequisites they require
It depends I mainly use Python, C, and Rust for fuzzing and want to reproduce public PoCs involving libssh2, QEMU, Firefox, and libarchive in isolated virtual machines. Can this archive serve as a unified experiment corpus?
For: A security researcher using Python, C, and Rust for fuzzing and vulnerability reproduction, with isolated virtual machines for validating historical PoCs

It depends: the archive is suitable as a centralized source of PoC code and research notes, but not as a reproduction platform with a uniform build workflow.

  • The README calls it “A consolidated archive of my public proof-of-concept and vulnerability research writeups” and says that most former standalone repositories retain their original READMEs and tracked files, which supports selecting samples by target software.
  • The consolidation check covered 12 repositories and 96 tracked entries, requiring matching paths, Git object types, tree modes, and blob IDs. This is useful for confirming that tracked bytes were not altered during consolidation.
  • The archive includes libssh2-cve-2026-55200-poc, qemu-cxl-type3-mailbox-escape-poc, several Firefox PoCs, and libarchive-zip-debuginfod-size-boundary.
  • However, the README does not provide a repository-wide dependency manifest, build system, test entry point, or execution command; it also explicitly says the repository was “incomplete” when published.
  • Exploitarium: “A consolidated archive of my public proof-of-concept and vulnerability research writeups.”
  • Consolidation Check: “The check covered 12 repos and 96 tracked entries with zero mismatches.”
  • Consolidation Check: listed libssh2, QEMU, Firefox, and libarchive entries
  • Statement: “This repo was incomplete when published.”
Not stated in the README:The exact software versions, operating systems, compilers, and third-party dependencies required by each PoC;Whether each directory has its own build command, success criterion, and cleanup procedure;Whether the PoCs still reproduce against current target-software versions

✨ Highlights

  • 12 repositories and 96 entries were archived with zero mismatches
  • Covers Python, HTML, JavaScript, C, and Rust
  • The README discloses GPT-5.3 use for all fuzzing
  • 4,509 stars and 1,241 forks indicate substantial attention

🔧 Engineering

  • Consolidates public vulnerability PoCs and research notes for projects including c-ares, curl, and Firefox
  • Uses Git tree comparisons of paths, object types, modes, and blob IDs to verify the archive

⚠️ Risks

  • The README explicitly contains public exploit PoCs and forbids malicious use
  • The project states it was incomplete when published and provides no runtime versions or dependencies
  • The archive does not retain the original repositories' issues, PRs, releases, or separate Git histories

👥 For who?

  • Security researchers investigating components such as c-ares, libssh2, and Firefox
  • Developers learning vulnerability research from the GPT-5.3 fuzzing account and PoC source