Agentic Fuzzing Across Multiple Open Source Projects Bright Securitys 2026 Findings

Fuzzing has been finding serious software bugs for decades, but much of the effort still sits around the engine itself. Teams need to decide what to test, build a harness that reaches the right code, verify that the harness works, and then make sense of whatever the fuzzer finds.

STAR Fuzzer is designed to automate more of that surrounding work. Bright Security ran it against multiple open-source projects for two days and found High or Critical issues in 45% of the projects tested, with published findings ranging from decompression bombs and stack overflow to out-of-bounds access, null-pointer access, type confusion, and memory corruption.

Some of the most striking results came from very small inputs. A 35-byte GIF pushed scrimage toward roughly 2 GB of allocation, a 38-byte DDS file triggered a multi-gigabyte allocation in TwelveMonkeys ImageIO, and a 436 KB PNG expanded to roughly 562 MB in Fider.

The research also found that 37% of the vulnerable projects were already enrolled in Google’s OSS-Fuzz program. That result makes harness coverage especially interesting because new harnesses can open up functions and paths that were not previously being exercised.

Bright Security found High or Critical issues in 45% of the open-source projects tested during a two-day agentic fuzzing run.

37% of the vulnerable projects were already enrolled in Google’s OSS-Fuzz program, showing how additional harnesses can extend fuzzing into different parts of the same codebase.

STAR Fuzzer found that a 436 KB PNG expanded to roughly 562 MB in memory in Fider, with the issue identified in 12 minutes.

A 35-byte GIF caused scrimage to attempt an allocation of roughly 2 GB, while another variant exceeded 8 GB.

A 38-byte DDS file forced a multi-gigabyte allocation in TwelveMonkeys ImageIO.

The published findings span resource exhaustion, stack overflow, out-of-bounds access, null-pointer access, type confusion, and memory corruption.

What Is Agentic Fuzzing?

Agentic fuzzing uses AI agents to select which functions to test, write and verify harnesses, and triage results, while a engine mutates inputs to trigger faults. The underlying fuzzing process still depends on coverage, mutation, and repeated execution, but more of the surrounding setup and analysis can be automated.

In practice, that means the agent can help identify useful targets, generate harnesses, confirm that those harnesses reach the intended functions, and sort through the failures produced by the fuzzing run. The fuzzing engine can then spend its time exploring the target rather than relying on a manually prepared harness for every function.

Bright’s current Fuzzing Mode uses coverage-guided evolutionary fuzzing and supports structure-aware parsing for formats including JSON, XML, GraphQL, protobuf, and common binary formats.

Bright Fuzzing Mode documentation:

Why Fuzzing Harnesses Matter

A fuzzing engine can only explore code that its harness allows it to reach. The harness takes fuzzed input and passes it into a specific function or code path, which means the quality and breadth of those harnesses directly affect the surface available for testing.

A large project may already have fuzzing coverage and still contain parsers, decoders, or internal functions that are not represented by its existing harnesses. Creating a new harness can therefore expose a very different part of the same codebase without changing the underlying fuzzing engine.

STAR Fuzzer generates a harness for each selected function and checks that it actually works before beginning the fuzzing run. The seed input must execute cleanly, and coverage must show that the harness reaches the intended target rather than stopping in unrelated code.

That verification step keeps the fuzzing effort focused on the function that was selected. It also reduces the risk of spending compute time on a harness that compiles correctly but never reaches anything useful.

How Bright Security Conducted The Research

Bright Security ran STAR Fuzzer against multiple open-source projects for two days. The workflow covered target selection, harness generation and verification, coverage-guided fuzzing, fault confirmation, triage, and validation of the resulting findings.

The process starts before the first mutation is generated. STAR identifies input-handling functions that are worth testing, creates a direct path into those functions, checks that the path works, and then allows the fuzzing engine to begin exploring.

How STAR Fuzzer Chooses And Reaches Targets

STAR Fuzzer looks for functions where unexpected input is likely to produce useful security signals. These can include parsers, decoders, serializers, compression routines, binary-format handlers, native bindings, and other code that processes data an attacker may be able to influence.

For each selected function, STAR generates a standalone harness that sends fuzzed input directly into the target. This makes it possible to test internal processing code without requiring the complete application to be deployed or exposed through an external interface.

That direct access is especially useful for image decoders, file parsers, compression libraries, protocol handlers, and similar components. These functions may sit several layers below a web or API interface, even though they still process attacker-controlled or user-supplied data.

How The Fuzzing Run Works

Before a generated harness is accepted, STAR checks that the seed input executes without faulting and that the harness produces coverage showing it reached the intended target. If the check fails, the harness is rebuilt rather than passed directly to the fuzzing engine.

Once the harness passes verification, the engine starts mutating its inputs and measuring coverage. Inputs that reach new code are retained and mutated further, allowing the to move deeper into execution paths that have not yet been explored.

The engine watches the behavior of the target rather than looking only for predefined vulnerability signatures. Crashes, hangs, sanitizer violations, fatal runtime errors, abnormal memory use, and other unexpected behavior can all indicate that the target is mishandling a particular input.

Where supported, sanitizers such as ASan and UBSan provide another layer of visibility into unsafe memory behavior. This helps turn subtle faults into reproducible signals that can be investigated further.

How Findings Were Confirmed

Not every crash or memory spike should be treated as a confirmed vulnerability without additional validation. Resource-exhaustion findings are a good example because memory usage observed over a long process lifetime needs to be tied back to a specific input.

Bright’s current implementation replays suspected resource findings in fresh processes so the triggering payload can be tested on its own. Findings then go through triage to confirm reachability, impact, and whether the fault belongs to the target rather than the generated harness.

Severity was based on the classification assigned by the maintainer of the affected repository. Bright Security did not apply a separate normalized severity scale across the published findings, so the reported severity reflects the assessment used by each project when reviewing and disclosing the issue.

What STAR Fuzzer Found

After two days of testing, Bright Security found High or Critical issues in 45% of the projects tested. Of the projects where vulnerabilities were found, 37% were already enrolled in Google’s OSS-Fuzz program.

The disclosed findings cover a broad mix of software behavior. Some involved extreme memory amplification from tiny files, while others exposed recursion problems, pointer faults, bounds errors, and parser-state issues.

The range of findings is important because it shows that the research was not centered on one vulnerability pattern. The same overall workflow reached allocation issues, recursion faults, pointer errors, bounds problems, and other forms of unsafe parser behavior.

What The Findings Reveal Parser And Memory Safety

One of the clearest patterns in the results is that input size says very little the amount of work a parser may perform after receiving it. Several of the smallest files in the study produced some of the largest resource effects.

That matters because many applications naturally think uploads in terms of file size. The more important question in these cases is what the parser does once it begins interpreting the contents.

Tiny Inputs Can Cause Very Large Allocations

In scrimage, a 35-byte GIF was enough to trigger an attempted allocation of roughly 2 GB , while a second variant pushed the attempted allocation above 8 GB . The raw input was tiny, but the values interpreted by the parser produced a completely different memory footprint.

TwelveMonkeys ImageIO showed the same broad pattern through another file format. A 38-byte DDS file caused the parser to attempt a multi-gigabyte allocation, again creating a huge gap between the size of the input and the resources needed to process it.

Fider involved a larger file, but the amplification remained substantial. A PNG of roughly 436 KB expanded to around 562 MB once decoded, approximately 1,290 times its compressed size.

These cases show why validating only the size of an uploaded file does not tell you how expensive that file will be to process. Dimensions, counts, compressed structures, and other values inside the input can all influence the amount of memory a parser eventually requests.

The Bugs Went Well Beyond Decompression Bombs

The remaining findings show how much broader the testing surface was. Crystal’s XML implementation contained a type-confusion condition that could end in a SIGSEGV, while its YAML parser had an 88-byte self-referencing anchor and alias cycle that could drive uncontrolled recursion until the process exhausted its stack.

The libsolv campaign produced 10 findings across five parsers , including out-of-bounds reads, a null dereference, uncontrolled loops, overlapping memcpy parameters, and integer-overflow undefined behavior. That is a useful example of how one repository can expose several distinct failure modes once multiple parsers are exercised.

Elsewhere, htop had an out-of-bounds read, universal-ctags reached null-pointer member access, and RIOT contained an off-by-one write. Taken together, the findings show the variety of faults that can emerge when unexpected inputs are driven directly into parsing and transformation code.

Four Findings In Detail

The headline percentages show how frequently significant findings appeared during the run, but the individual vulnerabilities provide a clearer view of what the generated harnesses were able to reach. Each of the examples below exposes a different assumption inside the target code.

They also show why the input itself is only part of the story. The security impact depends on what happens after that input reaches the parser, decoder, or function that ultimately handles it.

Fider: A 436 KB PNG Expanded To Roughly 562 MB

Fider checked the compressed size of uploaded images before accepting them. The vulnerable path then fully decoded the image before resizing it, creating a substantial gap between the size accepted at upload and the amount of memory required during processing.

STAR Fuzzer found a PNG of roughly 436 KB that expanded to approximately 562 MB , around a 1,290x increase . The finding took 12 minutes , making it one of the clearest examples in the study of how quickly a small input can turn into a much larger resource problem.

For an application processing several uploads concurrently, that kind of expansion can create significant memory pressure. The issue was fixed in Fider 0.38.0 by placing a bound on image decode memory before resizing.

GitHub Security Advisory:

Scrimage: A 35-Byte GIF Triggered Gigabytes Of Allocation

The scrimage finding pushes the same idea to an even smaller extreme. A 35-byte GIF reached an uncapped allocation in GifSequenceReader, where image width and height could drive the number of pixels without a sufficient limit.

That tiny input was enough to trigger an attempted allocation of roughly 2 GB , while a second variant pushed the attempted allocation beyond 8 GB . An application using the affected processing path could therefore consume a large amount of memory while handling a file that is almost negligible in size on disk or over the network.

The issue was fixed on September 10, 2026 and released in scrimage 4.6.8 .

GitHub Issue #893:

TwelveMonkeys ImageIO: A 38-Byte DDS Triggered Multi-Gigabyte Allocation

TwelveMonkeys ImageIO had a similar resource-amplification problem in its DDS handling code. A 38-byte DDS file could influence a mipmap count that was then used to allocate a new dimensions array without an effective upper bound.

The result was a multi-gigabyte allocation attempt from a file smaller than a short text message. It demonstrates how little the original input size can tell you the work that happens deeper inside the parser.

The issue was fixed in TwelveMonkeys ImageIO 3.15.0 .

GitHub Security Advisory:

Universal-Ctags: Crafted Input Reached A Null-Pointer Access

Universal-ctags provides a useful contrast because the failure had nothing to do with memory amplification. Fuzzing reached a path in foreachEntriesInScope that produced null-pointer member access detected by UBSan.

The issue falls under CWE-476 and could terminate the affected process when the triggering input reached that code. It broadens the picture beyond oversized allocations and shows how the same fuzzing workflow can surface a very different kind of parser failure.

The project fixed the issue on September 8, 2026 in commit 780bd7a.

GitHub Issue #4497:

How Agentic Fuzzing Extends Application Security Testing

Fuzzing, DAST, and penetration testing work at different layers of the software stack. A DAST scanner approaches a running application through exposed interfaces, while a function-level fuzzer can operate directly on the parser, decoder, or transformation function underneath those interfaces.

That difference in access is what makes fuzzing especially useful for lower-level input-processing faults. It allows security testing to reach code that may sit several layers below the application boundary while still handling data influenced by users or attackers.

Bright describes Fuzzing Mode as complementary to its DAST testing for the same reason. Application-level testing can focus on exposed runtime behavior, while fuzzing can work directly with the functions that process complex or malformed input.

What The 37% OSS-Fuzz Overlap Shows

One of the more interesting results in the study is that 37% of the vulnerable projects were already enrolled in Google’s OSS-Fuzz program . The figure highlights how much fuzzing coverage depends on the specific targets and harnesses available inside a repository.

A project can contain many parsers, libraries, functions, and input paths, while its existing fuzz targets cover only part of that surface. Adding another harness changes what the fuzzer can reach and can expose behavior in functions that were not previously part of the testing path.

This makes the harness itself an important part of the coverage equation. Established fuzzing engines provide the mutation and capability, while broader target selection and additional harnesses expand where that capability can be applied.

What Agentic Fuzzing Changes

Coverage-guided fuzzing already has a long track record of finding serious vulnerabilities in parsers, protocol implementations, file handlers, browsers, operating systems, and native libraries. The opportunity here is to reduce the amount of manual work required to apply that capability across more of a codebase.

Engineers traditionally need to select targets, write the harness, make sure it reaches the right function, investigate the crash, and determine whether the result is real and security-relevant. That process is manageable for a small number of high-value targets, but it becomes much harder to scale as the number of candidate functions grows.

STAR automates more of that workflow. It can select candidate functions, generate a harness, verify that the harness reaches the target, run the fuzzing engine, confirm suspicious behavior, and help triage the results that come back.

Bright’s current workflow can also move into remediation by rebuilding the target after a fix, replaying the exact crashing input, and running another short fuzzing pass to check that the issue is no longer reproducible. This creates a more continuous path from selecting a function to validating what happens after a fix is applied.

The result is a broader practical testing surface without requiring the same amount of manual harness engineering and first-pass triage for every target. The fuzzing engine remains important, but more of the work needed to keep feeding useful targets into that engine can happen automatically.

Study Scope And Methodology Notes

The research was conducted over a two-day fuzzing window across multiple selected open-source projects. The reported 45% finding rate applies to this research run and represents the projects tested during that period.

Severity classifications were assigned by the maintainers of the affected repositories rather than through one standardized Bright Security scoring framework. The severity labels reported here therefore follow the classifications used by the individual projects during review and disclosure.

Public reporting also follows coordinated-disclosure requirements. Findings that have been fixed and disclosed can be described in detail, while unresolved or undisclosed findings are intentionally excluded from the published examples.

Fuzzing coverage varies across repositories depending on the functions, input formats, and harnesses being exercised. The findings in this report reflect the targets reached during this specific research run and the disclosed vulnerabilities that resulted from that testing.

Frequently Asked Questions Agentic Fuzzing

What Is Agentic Fuzzing?

Agentic fuzzing uses AI agents to select which functions to test, write and verify harnesses, and triage results, while a engine mutates inputs to trigger faults. The agent handles more of the setup and analysis around fuzzing, while the underlying engine continues to perform the coverage-guided and input mutation.

This makes it possible to move from one candidate function to the with less manual harness engineering. The underlying fuzzing techniques remain familiar, but more of the workflow around them can be automated.

How Is Agentic Fuzzing Different From Traditional Fuzzing?

Traditional fuzzing often relies on engineers to decide what to test, build the harness, verify that it reaches the target, and then investigate whatever the engine finds. Those steps can require substantial effort when a repository contains many potential targets.

Agentic fuzzing automates more of that surrounding work. In STAR Fuzzer, agents help select input-handling functions, generate and verify per-function harnesses, and triage the faults produced by the fuzzing engine.

Can You Fuzz Software Without Running The Full Application?

Yes. A harness can invoke a selected function directly without starting the complete application around it, which is particularly useful for parsers, decoders, libraries, and other internal components.

STAR Fuzzer can therefore exercise these functions without requiring an HTTP endpoint, authentication flow, or complete deployed environment. That allows testing to focus on the code responsible for handling the input itself.

What Does The OSS-Fuzz Overlap Tell Us?

Bright found that 37% of the vulnerable projects in this study were already enrolled in OSS-Fuzz. The result shows how additional harnesses can expand the parts of a repository available to fuzzing.

Coverage depends on which functions are exposed through existing fuzz targets. Generating new harnesses can make additional parsers and code paths reachable even when the project already has continuous fuzzing in place.

What Types Of Vulnerabilities Can Agentic Fuzzing Find?

The published findings in Bright Security’s 2026 research include resource exhaustion, stack overflow, out-of-bounds access, null-pointer access, type confusion, uncontrolled recursion, off-by-one writes, and other parser-related failures.

The common thread is unexpected process behavior after unusual input reaches code that handles or transforms that input. Different targets can therefore produce very different classes of findings within the same fuzzing campaign.

Can Agentic Fuzzing Find Denial-Of-Service Vulnerabilities?

Yes. Several findings in this research involved inputs that forced the target into extreme or uncontrolled resource consumption, including very small files that led to gigabytes of attempted memory allocation.

Examples include the 436 KB PNG that expanded to roughly 562 MB in Fider, the 35-byte GIF that caused roughly 2 GB of allocation in scrimage, and the 38-byte DDS file that triggered a multi-gigabyte allocation in TwelveMonkeys ImageIO.

How Does Agentic Fuzzing Fit Alongside DAST And Penetration Testing?

These approaches operate at different layers and can cover different security questions. DAST tests running applications through exposed interfaces, while harness-level fuzzing can exercise lower-level input-processing functions directly.

That makes fuzzing particularly useful for parser crashes, memory-safety faults, resource-amplification issues, and similar problems deeper in the code. Used together, these approaches extend testing from the application boundary into the components processing the underlying input.

Research Data And Citation

The disclosed findings referenced in this research include the project advisories, issues, and fixes listed below. These links provide the project-level context for the vulnerabilities discussed in the report.

TwelveMonkeys ImageIO advisory, GHSA-fwp7-38wp-mmxw

Fider advisory, GHSA-7cw3-7xh9-529r

Crystal XML advisory, GHSA-c267-9cqj-hv9f

Crystal YAML advisory, GHSA-fj8w-2r88-5v7w

htop issue #2101

universal-ctags issue #4497

scrimage issue #893

RIOT PR #22879

Suggested Citation: Bright Security. Agentic Fuzzing Across Multiple Open Source Projects: 2026 Results. 2026.

STAR Fuzzer is the agentic fuzzing mode of Bright STAR, combining automated target selection, harness generation and verification, coverage-guided fuzzing, triage, and fix validation. It gives teams a way to extend fuzzing deeper into input-handling code without requiring the complete application to be deployed for every target.

Join the world’s leading companies securing the big cyber frontier with Bright STAR.