Bright Security’s STAR Fuzzer Automates Harnesses and Reproduces Security Bugs

Automating the work around fuzzing

Fuzzing can expose failures that code review and request-level security tests miss, but it has long depended on specialists to choose targets, build harnesses and sort useful crashes from noise. Bright Security’s STAR Fuzzer aims to remove that setup burden: it identifies security-critical functions, creates and checks a harness for each, then searches for faults and packages confirmed findings with the exact input that triggers them.

The product is available as a mode of Bright STAR at brightsec.com/fuzzer. Its fuzzing engine is based on an evolutionary system first released in 2018. Bright Security says the tool found High or Critical issues in 45% of projects in an initial open-source research run. In its first month of availability, it generated ten published findings across eight projects, including the Crystal standard library, htop and RIOT OS.

The division of labor matters. AI agents handle target selection, harness generation and initial triage; an evolutionary search engine generates and tests inputs. That keeps the bug search grounded in how compiled software actually behaves, rather than asking a language model to predict where defects might be.

Testing code beneath the HTTP layer

Coverage-guided tools such as AFL++ and libFuzzer have established records, and projects such as Google’s OSS-Fuzz have demonstrated their value. Their adoption still requires engineers to write and maintain a harness for each target and investigate the resulting crashes. That work can limit fuzzing to teams with the right expertise and time.

Other security testing methods cover different ground. Dynamic application security testing (DAST) sends requests to a running application, usually over HTTP; it may not reach the parsing and processing functions that handle untrusted data internally. LLM-based penetration testing can identify familiar vulnerability patterns, but it works from learned expectations rather than repeatedly executing a target against a large body of test inputs.

STAR Fuzzer is designed to test security-critical functions along untrusted-input paths without a running application. It can target code that processes uploads, images, documents, archives, serialized data and binary protocols, as well as software outside web applications, including embedded systems, desktop programs and backend services. Its place is alongside other testing approaches: DAST examines application behavior from the outside, while fuzzing exercises functions directly.

For traditional fuzzers, engineers typically supply the harness and triage crashes themselves. STAR Fuzzer says it generates a harness for each selected function and checks that the harness reaches its target. It also assesses reachability and impact, then can deliver results in a pull request with the affected file, function and byte-exact reproducer. Teams can replay that payload after a fix to check whether the failure is gone.

Search by execution, not prediction

Bright Security CTO Bar Hofesh has argued that language models and fuzzers answer different questions. A model can reason about source code and known bug patterns; a fuzzer runs the compiled target, observes the result and uses feedback to decide which inputs to explore next. That distinction is particularly relevant for mature parsers, where familiar defects may already have been addressed and remaining problems can depend on unusual input combinations.

Bright Security’s comparison puts the scale difference in concrete terms. A fuzzing campaign may run one million to ten million inputs against a target. At roughly 2,000 tokens for a reasoned test case, the company estimates that matching one million executions with LLM-generated cases would require about two billion tokens for one target—and those cases would still be predictions.

A persistent fuzzing harness, the company says, can execute hundreds to a few thousand inputs per second per worker, with multiple workers running in parallel. A million executions can therefore take minutes to tens of minutes, while a reasoning pass for each of a million hypotheses could take months. More fundamentally, execution can reveal behavior such as a sanitizer detecting a heap read one byte beyond a buffer. A model has to infer details including struct layouts, integer widths, allocator behavior and build flags.

Coverage feedback gives the search another concrete signal. Bright Security reports that its libxml2 harness reached about 13,600 code regions during a run of five million executions. Inputs that reach previously unexplored code can become starting points for further search. The company says its fuzzer does not need a prior idea of which code contains a bug: target behavior determines which inputs merit more exploration.

Harnesses, structured inputs and replay

STAR Fuzzer runs a target through a small harness over inter-process communication. The target can be written in C, C++, Rust, Go, Java, Kotlin, Crystal, Node or another language that can accept input and return a result. Bright Security lists support for C/C++, Rust, Go, Java/Kotlin, .NET, Node, Python and Crystal.

Its input layer parses seeds into typed trees of fields and serializes those trees back into the original bytes. Bright Security says this format-agnostic approach avoids writing a separate grammar or dictionary file for each target. Mutating fields within structured inputs can also get past the initial framing and validation checks more often than arbitrary byte changes, leaving more executions for deeper logic.

The search uses a population of organisms, each carrying a genome: an ordered list of mutations. During each epoch, candidates are changed, executed and scored. Successful changes are retained, while unproductive ones are reverted and candidates can breed. A logged random seed and genome allow a result to be recreated with the same payload. Bright Security says it replays every reported finding in a fresh container before filing it.

Findings across established projects

Before release, Bright Security ran STAR Fuzzer for two days in an automated pipeline against open-source libraries, applications and binary parsers. It reports that 45% of the projects tested had High or Critical issues, and that 37% of the vulnerable projects were part of Google’s OSS-Fuzz program.

The first-month findings span resource exhaustion, memory safety, type confusion and malformed recursive structures. In TwelveMonkeys, an uncapped mipMapCount field in the DDS reader can make a 38-byte file trigger a multi-gigabyte allocation (CWE-789). The issue, GHSA-fwp7-38wp-mmxw, was fixed in version 3.15.0.

In Fider, upload validation checked an image’s compressed size before fully decoding it. A 436 KB PNG could expand to about 562 MB, and any authenticated user could trigger the behavior (CWE-409). Bright Security says the fuzzer found the flaw in about 12 minutes. It was fixed in version 0.38.0 under GHSA-7cw3-7xh9-529r.

The Crystal standard library had two reported issues, both fixed in Crystal 1.21.1. In its XML handling, an allowlist omitted ENTITY_DECL, leading to a field in libxml2’s xmlEntity structure being read as an xmlNs pointer (CWE-843; GHSA-c267-9cqj-hv9f). In YAML::Any#hash, a self-referencing anchor and alias cycle caused a stack overflow: an 88-byte input could produce an uncatchable SIGSEGV (CWE-674; GHSA-fj8w-2r88-5v7w).

Other findings included an out-of-bounds read in htop’s /proc/PID/stat parser because field 22 lacked a bounds check (CWE-125), fixed in #2101; and a null-pointer member access in universal-ctags’ foreachEntriesInScope (CWE-476), fixed in commit 780bd7a (#4497). In scrimage, an uncapped image width-times-height count let a 35-byte GIF prompt an allocation of about 2 GB, with a second variant exceeding 8 GB (CWE-789); the fix shipped in 4.6.8 (#893).

RIOT OS had an off-by-one error in _dirlist_cb in link_format.c: its bounds check ran after the write, allowing a NUL byte to land just beyond the buffer (CWE-193). A fix was submitted in PR #22879. Bright Security also reports two libsolv vulnerabilities, CVE-2026-104621 and CVE-2026-104622; details remain under embargo.

These examples show why reproducing a failure matters. A size check can inspect compressed bytes while the decoder allocates for expanded content; a metadata field can control allocation size; and code that handles ordinary trees can fail on cyclic input. The reported payload gives maintainers a concrete way to see the condition and verify a correction.

Deployment and availability

STAR Fuzzer runs inside the customer’s environment and does not require a cloud scanner, authentication or a live application. Bright Security says persistent mode executes harnesses about 51 times faster than starting a new process for every input. The company positions the tool for teams handling untrusted input and for security teams that want to exercise functions flagged by static analysis.

Bright Security has published its research methodology and results in Part I of its open-source testing report. Hofesh’s discussion of the distinction between model-based review and fuzzing appears in Back to the Fuzzer II: Finding the Bugs LLMs Miss.

The practical test for agentic fuzzing is whether it can broaden coverage without making developers absorb a flood of hard-to-reproduce alerts. STAR Fuzzer’s early results make harness automation and replayable evidence the central claims to watch as teams put it against their own parsers and input-handling code.