Month of Apache Bugs (MoAB) - Operation: Binary Chaos

There is a long tradition of "Month of" bug projects: Month of Browser Bugs, Month of Apple Bugs, Month of Kernel Bugs, Month of PHP Bugs: "A month of bugs is a strategy used by security researchers to draw attention to the lax security procedures of commercial software corporations." - Wikipedia - Month of bugs. I really wanted to see how fast one can discover 0days with the help of AI-SAST tool against Open Source Software (OSS), specifically in projects from Apache Software Foundation (ASF). I wanted to point that same lens at one target and see what fell out. So I ran a Month of Apache Bugs and called it Operation: Binary Chaos. This meant that I had to release a bug every day within one month. The discovery pass took five days. I started on 13 August 2026, and by the 18th all 36 confirmed 0-days in 36 different projects/codebases were triaged and reported. One man, one desire, one foundation, and a question I kept coming back to: how deep does the canary go across the ASF's enormous, uneven, frequently half-abandoned project universe?

Deep enough to fill a release calendar, it turns out. I went through roughly 345 Apache projects and components and opened 40 numbered advisory tracks in that first week. The long tail was disclosure, not discovery: reporting to each PMC, working with the teams that answered, waiting on the ones that never did, and publishing 36 advisories (ZSL-2026-6003 through ZSL-2026-6038) between 11 September and 30 October 2026, the day I closed the operation out. That stretch ran about fifty days, better than one shipped advisory every two. Nine CVEs came out of the pile. Every finding followed the one rule I set on day one: trace it in the real released source, then actually stand it up and trigger it before I let myself call it confirmed or "Green-GO".

By the numbers

Here is the severity distribution of the 36 published advisories, using the rating published with each ZSL advisory. A lot of these are deploy-gated or gadget-gated and carry a wider range in the finding itself, so read the bar as a shape, not a verdict:

The three Criticals are all remote code execution: HugeGraph (sandbox escape), Submarine (auth bypass), and SystemDS (unauthenticated federated-worker deserialization). The long Medium-and-Low tail is mostly memory-safety DoS in the native-C corner of Apache: RocketMQ-C++, ActiveMQ-CPP, Qpid Proton-C, MiNiFi C++, NuttX. That corner is under-audited, and it paid out over and over.

What kind of bugs

Severity is only half the picture, and honestly the less interesting half. Here is the spread by vulnerability class: one foundation handed up ten distinct bug families in five days.

The slice I did not expect to be writing up: that "memory corruption" wedge includes a kernel-space out-of-bounds write in the NuttX RTOS 6LoWPAN decompressor (ZSL-2026-6019). A real kernel 0-day, inside an Apache project, from a desk (sometimes a sofa), in under a week. The other two in that wedge are an out-of-bounds read in the RocketMQ C++ client and a heap overflow in Celix's EDEF parser.

AI in the loop: fast triage, hard verification

If this writeup is about one thing beyond the bugs, it is AI in offensive security research: what the model is genuinely for, where it lies, and who stays accountable for the verdict.

A single human cannot read 345 Apache codebases in five days. This includes me :P. What made the pace possible was pairing an AI assistant (Anthropic's Claude) with a verification protocol I refused to bend. The AI did the part it is genuinely good at: fan out across unfamiliar source trees and recognize dangerous shapes. An unfiltered ObjectInputStream. A new File(dir, entry.getName()) with no canonical check. A recursive-descent parser with no depth cap. A servlet route that quietly never reaches the auth filter. It flags them, ranks them, and then a human goes and chases them.

But a static flag is a hypothesis, not a verdict. That is the same lesson our tuktam / LightFTP work turned on, and I did not forget it here. Nothing shipped on a model's say-so. Every finding got traced to the sink in the exact released version, then live-triggered against the real artifact: the pinned Maven jar on a harness, the compiled C binary under a sanitizer, the container running the actual service. That protocol is exactly what caught both false positives. The AI, and a public PR, called Avro-C a crash; the real libavro returned ENOMEM and never faulted. The model makes you fast. It does not get to decide what is true.

And it failed in both directions, which is the part worth sitting with. It quit on real bugs: it decided OzHera's SQL sink "wasn't reachable" when it plainly was, and Doris took a second pass before it would believe its own finding. It was also certain about bugs that were not there, the two retractions above, which it would have sworn on. A model is a superhuman generator of hypotheses and a subhuman judge of them. Infinite confidence, zero calibration, and the whole job was being the calibration.

Where the bugs actually were

The hardened core of Apache is a fortress. Struts, Shiro, the Dubbo and PDFBox cores: everyone attacks them, git blame is wall-to-wall CVE fixes, and I found almost nothing there. The bugs clustered in three softer places, and once I saw the shape I went looking for it on purpose:

• Brand-new subprojects: shiny code bolted onto an old foundation and reviewed by fewer eyes. Bigtop Manager, SeaTunnel, HugeGraph, SystemDS, Ambari's mpack feature.
• Freshly written security code: the bug living in the very code meant to secure the old code. Submarine's User-Agent auth check, Dubbo Admin's JWT, AsterixDB's auth asymmetry, Karaf's LDAP filters.
• The C/C++ wire-parser tail: native decoders nobody re-audits. Celix, RocketMQ-C++, ActiveMQ-CPP, the Qpid recursion pair, and the NuttX kernel.

Two of the projects I reported against, Submarine and jclouds, were retired to the Apache Attic during the research window. Retirement does not un-deploy software: a freshly-retired project with a live unauthenticated RCE still sitting on Maven is exactly the supply-chain shape this whole thing was about.

Most of these need no framework to fire. The DevLake SSRF, for one, is the entire exploit:

No token, no session. The server resolves and fetches the cloud-metadata endpoint, then reflects the body back in its own JSON error (ZSL-2026-6037, CWE-918). That is the mundane end of the range. The fun end was a Groovy Finalizer thread strolling out of HugeGraph's SecurityManager sandbox to pop a live shell, and a crafted 802.15.4 frame writing past a static buffer in the NuttX kernel. One curl to one kernel write, same week.

The security-model shield

The most repeated pattern of the whole operation was not a bug class. It was a sentence. Over and over, a genuinely reachable vulnerable path got waved off as "by design", not because the code was safe, but because a threat model had decided the attacker was out of scope. Nine of my findings were declined this way, and in every one of them the vulnerable code still ships in the latest release:

• SystemDS: my unauthenticated federated-worker Java-deserialization report actually pushed the project to write its first SECURITY.md, and then the report was declined under the brand-new document, on the grounds that federated peers are "trusted parties on a trusted network." The worker is still unauthenticated, with SSL off by default.
• Doris, SeaTunnel, IoTDB: file read, unauthenticated RCE and SSRF respectively, each declined as a "trusted operator" or "trusted interface" capability.
• Commons JCS, Commons Digester: unauthenticated deserialization and XXE-by-default, both declined under the blanket Commons line that libraries may assume trusted input.
• Avatica: JDBC connection-property injection. The allow-list they conceded shipped, but it is opt-in and off by default, so the current release is still exposed out of the box.
• Paimon: CDC arbitrary file read, declined as a trusted-operator capability. To their credit, the PMC agreed the passthrough is unsafe and said they would harden it.
• MiNiFi C++: uncontrolled allocation DoS, declined as trusted-peer, TLS-gated defense in depth.

A threat model is a real and useful thing. But "the attacker is assumed trusted" is a scoping choice, not a property of the code, and it does not make readObject on an attacker-controlled stream safe. I published these reframed, honestly, as insecure-default / missing-authentication issues, because the operator who only reads the changelog will never learn that the default leaves them exposed. The ASF is entitled to its triage opinion. The vulnerable byte sequence is still in the jar.

CVEs, silent fixes, and the PR trail

Nine CVE IDs attach to the batch. Eight of them credit ZSL directly. One, Impala, is an independent-analysis duplicate of an earlier report, June 10, by zhaokaifei. o/

• CVE-2026-78243: YuniKorn (LDAP group-provider panic DoS - fixed 1.10.0)
• CVE-2026-80277: OzHera (authenticated SQL injection)
• CVE-2026-82331: BuildStream (tar symlink arbitrary file write - fixed 2.8.1)
• CVE-2026-88763: Qpid Dispatch / skupper-router (AMQP parser recursion DoS)
• CVE-2026-90979: Karaf (JAAS LDAP filter injection - fixed 4.4.12)
• CVE-2026-105042: Qpid Proton-C (AMQP decoder recursion DoS)
• CVE-2026-113504: Airflow (secrets-masker deep-nesting leak)
• CVE-2026-115721: MINA Vysper (unbounded XML buffer pre-auth OOM)
• CVE-2026-65181: Impala (insufficient-authorization RCE - fixed 4.5.2)

Not every outcome was a clean assignment. Qpid Proton-C got silently fixed in 0.41.1 before any advisory existed; the PMC only confirmed the vulnerability after I published against the already-released fix, and the CVE landed later still. PDFBox was quietly capped with no CVE at all. On the better side, BuildStream merged a fix and turned my PoC into a credited regression test, and I offered hardening PRs to a few projects whose maintainers declined the vuln but took the patch (Doris, Avatica's allow-list, a review of Paimon's fix). A couple of those contribution threads are still open as I write this.

The HugeGraph finding earns its own line. It is a live, end-to-end sandbox escape, a residual of CVE-2024-27348 that walks straight past the thread-name guard the original fix added, without ever touching reflection. The mechanism is written up in full in our HugeGraph SecurityManager sandbox-escape paper.

Still open: 0-days, silence, and unfinished threads

A month of bugs ends on a deadline. The vulnerabilities do not. As I publish this:

• Ratis, AsterixDB, CarbonData: traced, triggered, reported, and met with silence. These are effectively live 0-days in current releases, with no fix and, in some cases, no acknowledgement.
• Ambari and DevLake: published on the lapsed disclosure window after the PMC went quiet. Both are released projects, and a CVE request is outstanding on each.
• NuttX: the 6LoWPAN HC06 decompressor kernel out-of-bounds write is reported to the PMC with a CVE request pending; the one-line fix is in the report.
• Celix: PMC-accepted and embargoed, details held until the fix ships, CVE likely.
• Pony Mail (Foal): acknowledged but unreleased (git only), so there is no CVE and nothing shipped. The right move there is a code contribution, not a disclosure.
• Several of the by-design declines stay unpatched in the latest release, by the vendor's own choice, as described above.

The full ledger

All 36 published advisories, in publication order. The Shield column marks whether the vendor sheltered vulnerable code behind a security-model or "by design" decision instead of fixing it.

Withdrawn as false positives (not shipped): Derby LDAP filter injection (the released source escapes correctly; I had tested a stale mirror) and Avro-C negative-length write (unreachable; real libavro returns ENOMEM, and the "crash" was AddressSanitizer-only).

Takeaways

Three things the operation made concrete for me. First, AI collapses the discovery timeline: thirty-six confirmed 0-days across hundreds of codebases in five days was not realistic two years ago. But that only holds when it is chained to real-artifact verification, which is also the thing that keeps it honest enough to print retractions. Second, "by design" is carrying an enormous amount of weight in Apache triage, and a threat model that assumes the attacker away is a scoping choice the operator running the default config inherits as risk. Third, the native-C periphery of Apache is under-watched and keeps paying out memory-safety bugs. Whatever the security model says, the code is still vulnerable.

References

• Month of bugs (Wikipedia)
• HugeGraph SecurityManager sandbox-escape paper
• The Apache project universe
• Zero Science Lab Advisories