Bright Security’s STAR Fuzzer Automates Harness Creation and Verifies Security Bugs

Automating the work around fuzzing

Fuzzing can expose failures that code review and request level testing miss, but putting it to work across a codebase has long required specialist effort. Bright Security’s STAR Fuzzer targets that bottleneck: it uses AI to identify security sensitive functions, build and verify fuzzing harnesses, and triage results. An evolutionary search engine then tests inputs against compiled code, with each confirmed finding delivered alongside a byte exact reproducer.

The product is available as a mode of Bright STAR and doesn’t require a running application. Bright Security says its engine grew from evolutionary technology first released in 2018. The distinction matters: AI handles target selection and harness work, while repeated executions and observed program behavior drive the search for faults.

In a two day automated research run before release, 45% of the open source projects tested had High or Critical issues. During STAR Fuzzer’s first month of availability, Bright Security says it generated ten published findings across eight projects, including Crystal’s standard library, htop and RIOT OS. Every finding was replayed in a fresh container before filing.

Why harnesses and triage matter

Established tools such as AFL++ and libFuzzer can find serious defects, but engineers still need to write and maintain a harness for each target and sort meaningful failures from the rest. That operational cost tends to concentrate fuzzing in specialist teams and selected projects.

Other security checks cover different ground. Dynamic application security testing exercises a running service through HTTP, which often leaves internal parsing and processing code untouched. LLM based code review can identify familiar vulnerability patterns, but it doesn’t execute millions of inputs against the compiled target. STAR Fuzzer combines automated harness work with execution based search, aiming to test functions that accept untrusted data before those functions are exposed through an application.

Bright Security describes its approach as structure aware: inputs are represented as typed trees of fields and serialized back to bytes. The company says this format agnostic layer avoids a separate grammar or dictionary for every target. Mutations can change fields while retaining enough valid structure to get beyond early parser checks and reach deeper logic.

The search engine runs targets through a small harness over interprocess communication. Bright Security lists support for C and C++, Rust, Go, Java and Kotlin, .NET, Node, Python and Crystal. A target needs to read an input and report back; it doesn’t need to run as a service.

Search by execution, with repeatable results

STAR Fuzzer’s evolutionary process keeps a population of candidate inputs. Each candidate carries an ordered list of mutations, or genome. The engine runs candidates, scores their results, retains changes that improve the search and lets promising candidates produce new variants. Coverage and other fitness signals help steer exploration toward code that earlier inputs didn’t reach.

That feedback gives the tool a practical advantage over source review for finding unexpected behavior: it can observe what the compiled program actually does. In one example, Bright Security says a STAR Fuzzer harness for libxml2 reached about 13,600 code regions in a run of five million executions. An LLM reviewing source can reason about possible behavior, but doesn’t get the same direct signal about which code paths those test cases exercised.

Scale is another difference. Bright Security estimates that a campaign runs one million to ten million concrete inputs. The company contrasts that with using an LLM to reason through test cases: at about 2,000 tokens per case, one million cases would require roughly two billion tokens for one target. It also says a persistent harness can run hundreds to a few thousand inputs per second per worker, making one million executions a matter of minutes to tens of minutes across workers.

Each finding comes with a payload that can be replayed exactly. The fuzzer records the random seed and mutation sequence, and Bright Security reruns reported bugs in a fresh container. That gives maintainers evidence they can use to reproduce and investigate a fault, rather than a report that depends on accepting a model’s prediction.

Published findings span parsers, uploads and system code

The first month’s published results include memory exhaustion, out of bounds access, type confusion and stack exhaustion. The examples show why small inputs can have consequences far beyond their size.

• TwelveMonkeys: A mipMapCount field in the DDS reader could trigger an uncapped array allocation. A 38 byte file prompted an attempted multi gigabyte allocation (CWE-789). The issue, GHSA-fwp7-38wp-mmxw, was fixed in version 3.15.0.
• Fider: Upload validation checked an image’s compressed size before fully decoding it. A 436 KB PNG expanded to about 562 MB, and an authenticated user could trigger the behavior (CWE-409). Bright Security says the fuzzer found the issue in about 12 minutes. GHSA-7cw3-7xh9-529r was fixed in version 0.38.0.
• Crystal standard library: In XML handling, an allowlist omitted ENTITY_DECL, allowing a field in libxml2’s xmlEntity structure to be read as an xmlNs pointer (CWE-843). A separate YAML issue caused YAML::Any#hash to exhaust the stack on a self referencing anchor and alias cycle. An 88 byte input triggered an uncatchable SIGSEGV (CWE-674). Both issues were fixed in Crystal 1.21.1: GHSA-c267-9cqj-hv9f and GHSA-fj8w-2r88-5v7w.
• htop: A missing bounds check on field 22 in the /proc/PID/stat parser caused an out of bounds read (CWE-125). The fix is tracked as #2101.
• universal-ctags: foreachEntriesInScope had a null pointer member access (CWE-476). The fix is commit 780bd7a, tracked as #4497.
• scrimage: An uncapped width times height calculation allowed a 35 byte GIF to prompt allocation attempts of about 2 GB, with a second variant exceeding 8 GB (CWE-789). The issue was fixed in version 4.6.8 (#893).
• RIOT OS: In _dirlist_cb in link_format.c, a bounds check occurred after a write, placing a NUL byte one position beyond the buffer (CWE-193). A fix was submitted in PR #22879.
• libsolv: Bright Security reported two vulnerabilities, CVE-2026-104621 and CVE-2026-104622. Details remain under embargo.

Bright Security says 37% of the vulnerable projects in its pre release testing were part of Google’s OSS-Fuzz program. The published examples also illustrate how a guard can exist yet fail to constrain the relevant resource: Fider checked compressed file size, while the image decoder allocated based on expanded content. In the DDS case, metadata controlled an allocation, and the YAML failure depended on a cyclic input structure.

The company published its research methodology in Part I of its open source findings. Bright Security CTO Bar Hofesh also discusses the distinction between fuzzing and LLM code review in Back to the Fuzzer II: Finding the Bugs LLMs Miss.

Where the approach fits

STAR Fuzzer is aimed at code that processes untrusted input below the HTTP layer: file uploads, image and document readers, archive handling, parsers, serialization routines and binary protocols. Bright Security also names embedded and IoT firmware, desktop software and backend services as potential targets. Teams can use it to exercise functions flagged by static analysis, and to test code that pattern based review may not reach.

The company says STAR Fuzzer runs inside a customer’s environment without a cloud scanner, authentication or an application process. In persistent mode, it reports harness execution about 51 times faster than starting a new process for each input. Bright STAR also includes DAST, which tests running applications from the outside; the fuzzer fills a separate role by exercising functions directly.

Bright Security co founder and CTO Bar Hofesh said harness creation and triage had been the expensive parts of fuzzing, rather than the search itself. CEO Gadi Bashvitz framed the tool as a way to test code produced at a faster pace, while CMO Eyal Dror pointed to the first month’s ten published findings and their reproducing inputs. Those are company perspectives, but the reported examples make the practical case: a useful fuzzing result is one a developer can trigger locally and investigate.

STAR Fuzzer is available now as a Bright STAR mode. Teams working with parsers, file formats or other input heavy code can review its product information. The key test for any automated fuzzer will be whether its target selection and harness generation make sustained execution practical across codebases that have never had dedicated fuzzing support.

About Bright Security

Bright Security, formerly known as NeuraLegion, is headquartered in California and develops the Bright STAR application security platform. The company says the platform supports security detection, remediation and validation across web applications, APIs and code. More information is available at brightsec.com.