NebuSec/CyberMeowfia: a CVE proof-of-concept repository for kernel, browser and Nginx exploits
PoCs and exploits for CVEs discovered by NebuSec.
At a glance
- What is it?
- CyberMeowfia collects the exploit source code behind NebuSec's published CVEs, with per-target directories for Linux kernel LPEs, Chrome V8, Firefox SpiderMonkey and Nginx. It is a research archive, not a toolkit, and it is meant to be read alongside the writeups.
- Who is it for?
- CyberMeowfia is for vulnerability researchers, exploit developers and detection engineers who want the actual source behind a published CVE and are willing to read the matching writeup first. It is not for production patching, not a scanner, and not a substitute for vendor advisories, because the repository ships no build system, no version manifest and no release artefacts.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What CyberMeowfia is, and who it is actually for
CyberMeowfia is the public source drop for CVEs that NebuSec discovered and disclosed. The README frames it as a research index: each entry pairs a CVE identifier with the affected component (Linux Kernel, Chrome V8, Firefox SpiderMonkey, Nginx), a link to a writeup on nebusec.ai, and a link into a directory of this repository. The primary language is C, which matches the subject matter: kernel LPEs, JIT bugs, and heap corruption in an HTTP server are all written up at the memory level.
The audience is narrow and the README does not pretend otherwise. If you are a security researcher reproducing a published exploit, a detection engineer writing a signature for a specific CVE, or a vendor engineer checking whether a patch actually closes the hole, the source is the interesting artefact. If you want a tool that scans your fleet, this is the wrong repository. There is no CLI, no daemon, no configuration file, and no install target anywhere in the README. The only entry points are directories.
The breadth is worth noting. The README lists kernelCTF wins for CVE-2026-43501 and CVE-2026-23274, an Android 17 root chain under IonStack, two Nginx RCEs (CVE-2026-42530 and CVE-2026-9256), Chrome V8 work including CVE-2026-6307 and CVE-2026-5865, and a SpiderMonkey JIT issue in CVE-2026-10702. There is also an N-day section with CVE-2026-64560 and CVE-2026-43074, and a list of other Linux kernel LPEs pinned to specific distributions.
How the repository is organised: one directory per target and build
The layout is the mechanism. Top-level entries are IonStack/, Nginx-PoolSlip/, Nginx-QuicBurst/, security-research/ and the LICENSE. Under security-research/ the README points to two families: named research directories such as Linux-CVE-2026-43501-kernelCTF and Chrome-CVE-2026-5865, and an Ndays/ subtree holding Android-CVE-2026-64560 and Android-CVE-2026-43074.
The naming convention carries the important metadata. Many kernel entries encode the distribution and kernel version directly in the directory name: Linux-CVE-2026-43042-Debian-6.12.101, Linux-CVE-2026-52923-RHEL-6.12.0-211.7.3.el10_2, Linux-CVE-2026-52929-Ubuntu-7.0.0-28, Linux-CVE-2026-31678-Fedora-6.19.10-300. That is a deliberate signal. A kernel exploit is bound to a build, and the directory name tells you which build the author targeted. Read it before you read a single line of C.
The IonStack directories are split by CVE rather than by distribution: IonStack/CVE-2026-10702 for the SpiderMonkey JIT issue and IonStack/CVE-2026-43499 for the stack use-after-free described in the README as affecting all Linux distributions for 15 years. Nginx-PoolSlip and Nginx-QuicBurst sit at the top level, outside security-research/, which suggests the Nginx work was treated as a separate track from the kernel and browser research. The README does not explain that split, and no build files, Makefiles or dependency manifests are described, so the repository reads as source for study rather than source for compilation.
Reproducing a CyberMeowfia PoC: what the README actually gives you
The README gives no installation procedure. There is no package, no build command, no dependency list, and no environment setup. What it gives is a pointer from a CVE to a directory. So the honest first step is to clone the repository and read the tree.
git clone https://github.com/NebuSec/CyberMeowfia.git
cd CyberMeowfia
ls security-researchYou should see the per-CVE directories named in the README, including the distribution-tagged kernel entries and the Ndays/ subtree. From there, pick the directory that matches your target build, for example the Debian 13 entry:
ls security-research/Linux-CVE-2026-43042-Debian-6.12.101The README does not state what files that directory contains, so treat the listing as the first thing you verify rather than something to assume. The same applies to the Nginx and browser tracks: Nginx-PoolSlip/ and Nginx-QuicBurst/ exist at the top level, and IonStack/CVE-2026-43499 holds the Android 17 GhostLock material, but the README does not document a build step, a run command, or an expected output for any of them.
This is the point where the writeups matter. Every research entry in the README links to a writeup on nebusec.ai, and those writeups are where the exploitation narrative lives. The repository supplies the code; the writeup supplies the reasoning. Using one without the other means reconstructing the author's intent from C by hand.
The limitation that matters: no build system, no version manifest, no releases
The most concrete constraint is that the repository has no releases. The README describes directories and writeups, nothing else. There is no tagged version, no changelog, no compatibility matrix, and no statement about which compilers or libc versions the code expects. If a PoC fails to build, the repository itself gives you no baseline to compare against.
The second constraint is version coupling. Kernel exploit code is not portable across builds, and the directory names admit it: the same class of LPE appears multiple times with different distribution suffixes, such as Linux-CVE-2026-52912-Fedora-6.19.10-300 and Linux-CVE-2026-52933-Fedora-6.19.10-300 both targeting Fedora 44, alongside Debian 13, RHEL 10 and Ubuntu 26.04 variants. Running the wrong one against the wrong kernel is not a near miss; it is a different target.
The third constraint is that this is offensive tooling by design. A working LPE or an Nginx RCE in a repository is useful to researchers and equally useful to attackers, and the README offers no usage policy, no responsible-disclosure note and no warning about running the code outside an isolated lab. That omission is a real gap, not a stylistic one. Anyone cloning this should assume the code is meant for a lab machine and treat it that way.
How CyberMeowfia differs from exploit-db and Metasploit modules
The closest alternatives are public exploit archives such as Exploit-DB and the module collections shipped with Metasploit. The difference is in what each one optimises for.
Exploit-DB is a broad index. It accepts submissions from many authors, covers a very wide range of software, and its value is coverage and searchability. CyberMeowfia is the opposite: a single research group's output, organised around the CVEs that group found and wrote up. You will not find third-party exploits here, and you will not find a search interface. What you get instead is provenance. Every directory traces back to a named writeup and a specific disclosure, which makes it easier to judge whether the code matches the analysis you are reading.
Metasploit modules are packaged for execution. They ship with a framework, a module interface, options, and a runtime that handles delivery. CyberMeowfia ships raw C with no framework around it. That means more work for the user and more fidelity to the original research: nothing is normalised away to fit a module API. For someone studying how a bug was actually turned into a primitive, the unpackaged form is the point. For someone who wants to fire an exploit at a host with two commands, it is a poor fit, and Metasploit or a similar framework is the better starting place.
Maintenance, licensing and what to check before relying on it
The repository is not archived, and the last push was on 2026-09-08. That is recent enough that the project is still being updated, but the README gives no roadmap, no commit policy and no statement about how long a given exploit directory will be kept current. Treat each directory as a snapshot tied to the CVE it names, not as a maintained module.
Upgrade cost is therefore low in the traditional sense and high in the practical sense. There is nothing to upgrade: no dependency graph, no version pinning, no release channel. The cost shows up when you move to a new kernel or browser build, because the existing directory was written for the old one. You either wait for a new directory or adapt the code yourself, and the README offers no guidance on the latter.
The licence is Apache-2.0, with a LICENSE file at the repository root. Apache-2.0 permits use, modification and redistribution with the usual conditions around notices and attribution, and it includes an explicit patent grant. It does not, however, say anything about the legality of running the code. Offensive security code sits under computer misuse and export control rules that vary by jurisdiction, and the repository does not address that. Whether you may use a given PoC against a given system is a question for your own legal counsel, not something the licence answers.
Editorial conclusion
CyberMeowfia is for vulnerability researchers, exploit developers and detection engineers who want the actual source behind a published CVE and are willing to read the matching writeup first. It is not for production patching, not a scanner, and not a substitute for vendor advisories, because the repository ships no build system, no version manifest and no release artefacts. Before adopting anything from it, open the directory for your exact target, confirm the kernel or browser build named in the path matches yours, and check the Apache-2.0 LICENSE at the repository root.
Frequently asked questions
What is NebuSec/CyberMeowfia?
It is the public repository of proof-of-concept and exploit source code for CVEs discovered by NebuSec. The README organises entries by affected component (Linux Kernel, Chrome V8, Firefox SpiderMonkey, Nginx) and links each one to a writeup on nebusec.ai. The primary language is C.
How do I build or install a CyberMeowfia exploit?
The README does not document an install or build step, and there is no package, Makefile or dependency list described in it. The only entry point given is the directory for a specific CVE, such as security-research/Linux-CVE-2026-43042-Debian-6.12.101. You clone the repository and read the directory that matches your target build.
Which Linux kernel version does a CyberMeowfia LPE target?
The distribution and kernel version are encoded in the directory name, for example Linux-CVE-2026-52923-RHEL-6.12.0-211.7.3.el10_2 or Linux-CVE-2026-52929-Ubuntu-7.0.0-28. The README lists separate directories for Debian 13, Fedora 44, RHEL 10 and Ubuntu 26.04, so you need the one matching your build.
What licence does NebuSec/CyberMeowfia use?
The repository is licensed under Apache-2.0, with a LICENSE file at the top level. The licence covers use and redistribution of the code but says nothing about the legality of running offensive tooling, which is governed by separate rules.
Community notes