San Rafael, United States, October 19th, 2026, CyberNewswire
Built on an evolutionary engine first released in 2018, STAR Fuzzer by Bright Security finds crashes, memory exhaustion and memory-safety bugs in security-critical code without a running application. In its first open source research run, it found High or Critical issues in 45% of the projects tested, and in its first month of availability it produced ten published findings in eight projects, including the Crystal standard library, htop and RIOT OS.
Bright Security, the Agentic Offensive Application Security company, today announced the official launch of STAR Fuzzer, an agentic application fuzzer that automatically identifies security-critical functions, generates a fuzzing harness for each one, searches for faults with an evolutionary algorithm, and delivers every confirmed finding with a byte-exact payload that reproduces it. STAR Fuzzer is a self-contained mode of the Bright STAR platform and is available now at brightsec.com/fuzzer.
Agentic fuzzing applies AI agents to the parts of fuzzing that have traditionally required a specialist: choosing what to test, writing the harness, and deciding which crashes matter. STAR Fuzzer uses AI for those steps and an evolutionary search engine for the fuzzing itself, so the parts that need judgment are automated and the search stays fast, repeatable and evidence based.
Why Fuzzing Needed a New Approach
Coverage-guided fuzzers such as AFL++ and libFuzzer are proven and widely used, and programs like Google's OSS-Fuzz have shown how much they can find. But they depend on people to write and maintain a harness for every target and to triage the crashes that come back. That cost has kept fuzzing concentrated in specialist teams and a subset of critical projects.
Other testing approaches don't fill the gap. Dynamic application security testing (DAST) tests what an attacker can reach over HTTP, so it rarely exercises the parsing and processing code behind input validation. LLM-based pentesting is effective at known vulnerability patterns but tends to look where a model expects bugs to be. The result is a class of outage-level and memory-safety defects, often triggered by tiny malformed inputs, that most AppSec programs never test for.
How STAR Fuzzer compares with traditional coverage-guided fuzzers (such as AFL++ and libFuzzer) and DAST:
What it Tests: Traditional fuzzers test functions exposed through a hand-written harness. DAST tests running applications over HTTP. STAR Fuzzer tests security-critical functions on untrusted-input paths, chosen automatically.
Harness: Traditional fuzzers need harnesses written and maintained by engineers. DAST doesn't use one. STAR Fuzzer generates a harness per function with AI, then verifies it reaches its target.
Search: Traditional fuzzers use coverage-guided mutation. DAST sends request-level attack payloads. STAR Fuzzer uses a structure-aware evolutionary search guided by coverage and multiple fitness signals.
Running App Needed: Traditional fuzzers, no. DAST, yes. STAR Fuzzer, no.
Triage: Manual for traditional fuzzers and built into the scanner for DAST. STAR Fuzzer triages automatically for reachability and impact.
Output: Traditional fuzzers return crash inputs and logs. DAST returns a vulnerability report. STAR Fuzzer delivers the file, function and byte-exact payload in a pull request.
Fix Validation: Traditional fuzzers need a manual re-run and DAST needs a rescan. With STAR Fuzzer, teams replay the payload.
Finding the Bugs LLMs Miss
Ask an LLM to audit a parser and it will find the bug classes it already knows from training. The zero-days that survive for years in mature, widely deployed code are the ones that match no known pattern. STAR Fuzzer uses AI to choose targets and build harnesses, but the search that finds the bugs is not an LLM. It doesn't read the code or guess where a bug might be. It runs the program millions of times, observes what actually happens, and keeps whatever pushes the target into code it hasn't reached yet.
In Back to the Fuzzer II: Finding the Bugs LLMs Miss, Bright Security CTO Bar Hofesh gives four reasons LLM code review does not replace fuzzing for zero-day discovery:
Scale: A single fuzzing campaign runs 1 million to 10 million concrete inputs against the compiled target. At about 2,000 tokens per reasoned test case, matching one million executions with an LLM would take about two billion tokens for one target, and each of those test cases would still be a prediction.
Speed and Ground Truth: A persistent harness runs hundreds to a few thousand inputs per second per worker, across several parallel workers, so one million executions take minutes to tens of minutes. One LLM reasoning pass over one hypothesis takes several seconds, so one million would take months. The fuzzer also observes real behavior, such as a sanitizer reporting a heap read one byte out of bounds. An LLM has to predict how compiled code behaves, including struct layouts, integer widths, allocator behavior and build flags that aren't visible in the source.
Coverage: STAR Fuzzer's libxml2 harness reaches about 13,600 code regions in a 5-million-execution run. Coverage feedback shows which regions each input reached, and inputs that reach new code become starting points for deeper search. Code review has no equivalent signal for how much of a large parser it has actually covered.
The Unexpected: LLMs, code reviewers and static analyzers look for the same known patterns, so in mature code most of those bugs are already fixed. The fuzzer has no expectations about where a bug should be. The target's own behavior decides what is interesting.
Reproducibility is the other difference. Many plausible-looking LLM findings don't reproduce, and maintainers need a reproducer before they can act. A fuzzer finding is a reproducer by construction, and Bright Security replays every one in a fresh container before filing it.
How STAR Fuzzer Works
STAR Fuzzer's search engine drives any target through a small harness over IPC, so the code under test can be written in C, C++, Rust, Go, Java, Kotlin, Crystal, Node or any language that can read an input and report back.
Structure-aware parsing with no per-target grammar: Every seed is parsed into a typed tree of fields by a format-agnostic parsing layer, and the tree serializes back to the original bytes exactly. No grammar or dictionary file is written per target, and each format added to the parsing layer improves every target that uses it.
Mutations that get past the first check: Byte-level mutation mostly produces inputs a parser rejects at its first sanity check. Mutating the fields of a valid structured input keeps most executions past framing and validation, so the testing budget is spent on the deeper logic behind them.
Evolution with exact replay: Each organism in the population carries a genome, an ordered list of mutations. Each epoch, organisms mutate, run and are scored. Improvements are kept, unproductive changes are reverted, and organisms breed. Replaying a genome reproduces its payload exactly, so every result can be regenerated from a logged random seed.
Results from Open-Source Testing
Before release, Bright Security ran STAR Fuzzer for two days in an automated pipeline against multiple open source projects, from libraries and applications to low-level binary parsers. 45% of the projects tested had High or Critical issues, and 37% of the vulnerable projects are part of Google's OSS-Fuzz program.
In its first month of availability, STAR Fuzzer produced ten published findings in eight projects written in C, Go, JVM languages and Crystal. Each was replayed in a fresh container before filing:
TwelveMonkeys: In the DDS reader, the mipMapCount header field sizes an uncapped array, so a 38-byte file forces a multi-gigabyte allocation (CWE-789). GHSA-fwp7-38wp-mmxw, fixed in 3.15.0.
Fider: Upload validation checks an image's compressed size, then fully decodes it, so a 436 KB PNG expands to about 562 MB. Any authenticated user can trigger it (CWE-409). STAR Fuzzer found it in about 12 minutes, in a release already benchmarked by multiple AI pentesting vendors. GHSA-7cw3-7xh9-529r, fixed in 0.38.0.
Crystal standard library (XML): XML::Node#namespace type confusion. ENTITY_DECL is missing from an allowlist, so a field of libxml2's xmlEntity struct is read as an xmlNs* (CWE-843). GHSA-c267-9cqj-hv9f, fixed in Crystal 1.21.1.
Crystal standard library (YAML): YAML::Any#hash overflows the stack on a self-referencing anchor and alias cycle. An 88-byte input causes an uncatchable SIGSEGV (CWE-674). GHSA-fj8w-2r88-5v7w, fixed in Crystal 1.21.1.
libsolv: Two vulnerabilities, CVE-2026-104621 and CVE-2026-104622. Details are under embargo.
htop: An out-of-bounds read in the /proc/PID/stat parser, caused by a missing bounds check on field 22 (CWE-125). Fixed (#2101).
universal-ctags: A null-pointer member access in foreachEntriesInScope (CWE-476). Fixed in commit 780bd7a (#4497).
scrimage: An uncapped width-times-height pixel count lets a 35-byte GIF trigger allocation attempts of about 2 GB, and over 8 GB in a second variant (CWE-789). Fixed in 4.6.8 (#893).
RIOT OS: An off-by-one in _dirlist_cb (link_format.c). The bounds check runs after the write, so a NUL byte lands one past the buffer (CWE-193). Fix submitted in PR #22879.
Several of these bugs sit in code that looks correct on review. The Fider upload has a size limit, but it measures compressed size. The TwelveMonkeys field reads as image metadata, not as a length. The Crystal allowlist looks complete. The YAML hash function is correct for trees, and the bug is a cycle in the input.
The full methodology and results are published in two parts: Part I on brightsec.com, and Back to the Fuzzer II: Finding the Bugs LLMs Miss by Bar Hofesh.
Where STAR Fuzzer Fits Best
STAR Fuzzer by Bright Security is designed for teams whose code handles untrusted input below the HTTP layer, including:
Applications that process uploaded files, images, documents or archives
Parsers, serialization code and raw binary protocols
Non-web software such as embedded and IoT firmware, desktop applications and backend services
Codebases with a growing share of AI-generated code that needs testing beyond pattern matching
Security teams that want to confirm static analysis (SAST) findings by exercising the flagged functions live
It supports C/C++, Rust, Go, Java/Kotlin, .NET, Node, Python and Crystal, and runs inside the customer's environment with no running application, cloud scanner or authentication required. In persistent mode, harness execution is about 51 times faster than running a new process per input.
Executive Perspectives
"Fuzzing has always found the bugs that matter most, the ones that take a service down or corrupt memory, but it has been too expensive for most teams to run," said Bar Hofesh, Co-founder and CTO of Bright Security. "The search was never the bottleneck. The harnesses and the triage were. STAR Fuzzer automates both, so the evolutionary engine we built in 2018 can finally run across a whole codebase.""When Nevada opened the Boulder City Bypass in 2018, it took navigation apps months to start sending drivers down it," Hofesh added. "LLMs auditing code work the same way. They find the bugs they've already seen. The zero-days that have lived for years in mature code are the ones nobody has seen before, and that's exactly where a fuzzer shines.""Security teams are being asked to keep up with code written faster than ever, much of it by AI," said Gadi Bashvitz, Co-founder and CEO of Bright Security. "Testing that only looks where bugs are expected won't keep pace. STAR Fuzzer looks everywhere else, and it hands developers the proof they need to fix what it finds.""AppSec teams keep asking us the same thing: if AI is writing more of our code, what's testing the parts AI can't, see?" said Eyal Dror, CMO of Bright Security. "STAR Fuzzer is our answer. In its first month it found ten real bugs in mature open-source projects, and everyone came with the exact input that triggers it. That's proof a developer can act on the same day, not another alert to argue about."
Availability
STAR Fuzzer is available now as a mode of Bright STAR. Learn more and book a demo at brightsec.com/fuzzer.
Frequently Asked Questions:
What is Agentic Fuzzing?
Agentic fuzzing uses AI agents to automate the judgment-heavy steps of fuzzing: selecting which functions to test, writing and verifying harnesses, and triaging results. The fuzzing itself is performed by a search engine that mutates inputs to trigger faults.
How is STAR Fuzzer Different from AFL++ or libFuzzer?
AFL++ and libFuzzer are fuzzing engines that need engineers to write a harness for each target and to triage crashes by hand. STAR Fuzzer by Bright Security selects targets, generates and verifies harnesses, triages faults for reachability and impact, and delivers findings in a pull request with a reproducing payload.
Can LLMs Find Zero-Day Vulnerabilities in Parsers?
LLMs are effective at known bug classes, such as an unchecked memcpy length or string-built SQL, but they look where their training says bugs should be. In mature code, the bugs that survive are the ones that match no known pattern, which is where evolutionary, coverage-guided fuzzing is strongest.
Why Use a Fuzzer Instead of LLM Code Review?
A fuzzing campaign runs millions of real executions against compiled code and observes what happens, while an LLM predicts behavior from the source. Matching one million executions with LLM reasoning would take about two billion tokens per target. Every fuzzer finding also comes with an input that reproduces it.
How are STAR Fuzzer Findings Verified?
Every finding comes with a byte-exact payload that reproduces it, and Bright Security replays each one in a fresh container before filing it. Any result can also be regenerated from a logged random seed.
Does STAR Fuzzer Need Grammars or Dictionary Files?
No. A format-agnostic parsing layer turns each seed into a typed tree of fields, so no per-target grammar or dictionary is required.
Does STAR Fuzzer Replace DAST?
No. DAST tests a running application from the outside in, over HTTP. STAR Fuzzer tests security-critical functions from the inside out, without a running application. Bright STAR runs both, with the same agent and the same pull-request output.
What Kinds of Bugs Does STAR Fuzzer Find?
Crashes, hangs, out-of-memory conditions and unbounded allocations, memory-safety bugs such as out-of-bounds reads and off-by-one writes, type confusion, stack overflows from recursive input structures, and algorithmic-complexity blow-ups, including decompression bombs triggered by inputs of a few dozen bytes.
Which languages does STAR Fuzzer Support?
C/C++, Rust, Go, Java/Kotlin, .NET, Node, Python and Crystal.
About Bright Security
Bright Security is the Agentic Offensive Application Security company, helping organizations secure software at the speed of AI-driven development. Its AI-powered Bright STAR platform integrates security directly into the development lifecycle, automating detection, remediation and validation across web applications, APIs and code, and fitting into both developer and AppSec workflows. Formerly known as NeuraLegion, Bright Security is headquartered in California. Learn more at brightsec.com.
Contact
CMO
Eyal Dror
Bright Security Inc
eyal.dror@brightsec.com