Bright Security Introduces STAR Fuzzer, Agentic Fuzzing That Writes Its Own Harnesses and Proves Every Finding – Latest Hacking News

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.