We’re partnering with Endor Labs to help security and engineering teams stop chasing theoretical risk and start fixing what attackers can actually reach and exploit.

The idea is simple. Endor Labs tells you which vulnerabilities are reachable in your code. Bright STAR proves which of those are exploitable in your running application. Put together, mutual customers get one prioritized list backed by two independent forms of proof, instead of two disconnected reports they have to reconcile on their own.

Two sides of the same question

Bright Security is the developer-first application security testing platform behind Bright STAR, which brings together DAST, API security testing, and Agentic Offensive Security with AI-driven runtime validation. Bright STAR tests running applications and APIs the way an attacker would, generating context-aware payloads and confirming exploitability before anything gets reported. The result is a false positive rate under 3%, in a category where legacy DAST tools routinely land above 30%.

Endor Labs is an agentic application security platform built on its code context graph, a continuously updated model of how an application behaves across first-party code, open source dependencies, and containers. Its full-stack reachability analysis traces the path from input to the vulnerable function, which helps customers cut SAST, SCA, and container scanning noise by roughly 95% on average. Endor Labs secures more than 5 million applications for teams at companies like Atlassian, Cursor, Dropbox, Robinhood, Rubrik, and Snowflake.

What teams get

• Dynamic testing focused on what’s reachable. Endor Labs flags which vulnerabilities in first-party code, open source, and container images sit on a call path from untrusted input. Bright STAR then confirms which of those are exploitable, instead of testing everything a static scanner surfaced or leaning on EPSS as a guess.
• Prioritization backed by runtime proof. When Bright confirms a finding is exploitable, it moves to the top automatically. Teams get a list supported by static evidence and a live proof of concept, not a severity score alone.
• Lower token and compute costs for AI remediation. Verified, machine-readable evidence from both platforms lets AI coding and remediation agents spend their reasoning on real problems, not on re-deriving reachability or re-checking unconfirmed findings.

In their words

“Security teams don’t need another disconnected stream of findings. They need evidence they can act on. By pairing Endor Labs’ reachability intelligence with Bright’s AI-driven runtime validation, we help teams focus remediation on vulnerabilities that are both reachable and demonstrably exploitable, so developers and AI agents can fix what matters with confidence.”

Gadi Bashvitz, CEO, Bright Security

“The future of AppSec isn’t more findings; it’s better evidence. Reachability tells you whether a vulnerability can matter in your application, and runtime validation proves whether it can actually be exploited. Together, Endor Labs and Bright give developers and AI agents the context to prioritize real risk and remediate with confidence.”

Varun Badhwar, Co-Founder and CEO, Endor Labs

Someone always pays for the noise

AppSec tooling was built for a world where humans wrote the code and humans triaged the findings. That world is gone. Pull requests are up triple digits year over year, more of them are AI-generated, and the agents reviewing and fixing that code burn tokens on every finding they touch.

So a false positive isn’t just a wasted afternoon anymore. It’s wasted inference, wasted tool calls, and an agent reasoning in circles about a flaw that was never exploitable. Endor Labs’ own benchmarking found that an agent without deterministic security context needed roughly 12x more tokens to answer the same reachability and exploitability questions as one that had verified evidence in hand.

We see the same tax from the runtime side. When an AI fix agent “resolves” a false positive, it has spent real compute on a problem that didn’t exist. When it patches an unvalidated finding the wrong way, it can introduce a regression that costs more to unwind than the original issue.

Static reachability and dynamic validation each cut noise on their own. Together they cut it twice, once on the theoretical side and once on the exploitable side. That’s the difference between a backlog that shrinks by 90% and one that shrinks by closer to 99%.

How the integration works

1. Endor Labs narrows the list. Function-level reachability analysis flags which open source vulnerabilities and code flaws sit on a call path from untrusted input, and filters out everything that can’t be reached.
2. The findings hand off to Bright. Endor Labs passes that reachable candidate list to Bright as a SARIF file.
3. Bright STAR confirms exploitability. STAR tests the running application and validates which reachable findings can actually be exploited.
4. One prioritized list. Reachable and confirmed exploitable comes first, reachable but unproven comes next, and the noise neither tool flagged as urgent stays out of the way.

Teams can also run Endor SAST and Bright STAR together as a CI gate. Vulnerable code gets caught and proven exploitable before it ever reaches the production branch, so developers and their AI coding agents only spend time on issues that are real.

Built for the agents doing the fixing

An AI agent is only as good as the evidence it’s given. Ask a coding agent to fix “a SQL injection vulnerability” with no reachability context and no runtime confirmation, and it will do what an under-informed human would do: ignore it, or over-fix it into a regression.

Verified, machine-readable evidence changes that. When a finding arrives with a call path from Endor Labs and a confirmed exploit path from Bright, a remediation agent has enough grounding to write a fix scoped to the actual problem. It also has enough evidence to skip the findings that don’t need touching at all.

The same thinking extends to AI-specific risk. Endor Labs covers the OWASP LLM Top 10 in AI SAST, and Bright dynamically tests LLM-powered applications for issues like prompt injection and insecure output handling. That’s static and dynamic evidence for the new risks in your applications, not only the traditional ones.

Security stops being a report someone reads on a Friday. It becomes intelligence an agent can act on the moment code is written and the moment it runs.

Get started

If you’re figuring out how static reachability and dynamic validation fit into an AI-accelerated SDLC, or you’re the one paying the token bill for an agent second-guessing findings nobody confirmed, we’d love to talk. Contact us to see the Endor Labs and Bright integration in action.

Marc Andreessen is famously quoted saying that “being too early is the primary reason why qualified startups fail, not being too late”. This was almost the case for Bright 8 years ago, but we were able to pivot and build a real business providing value for many customers. Now, technology has caught up to our original vision and we are reintroducing the Bright STAR Fuzzer. 

In 2018 after around a year of covert research on bio-mimicry and evolutionary behavior Bright (at that time NeuraLegion), released our product, an AI guided fuzzer way before AI was cool. This was before LLMs were a thing, and was around the time neural networks became a new fashion for visual analysis and text\speech recognition. 

In our research we proved something interesting, security issues and bugs can be converged into, not discovered by accident, and behavior of a system can slowly degrade leading into a fault. Armed with this new understanding we created a generic structural fuzzer that needs no dictionary and uses an advanced evolutionary algorithm to converge into the most complex and hard to uncover issues.

The solution was live, we generated significant interest and won 1st place as The Most Interesting Technology in Israel’s CyberTech 2019 conference (“Winners of CyberTech competition as most innovative and disruptive solution, NexPloit is the world’s first AI-powered Application Security Testing solution”).

The only problem was, the world was not yet ready.

Conducting root cause analysis in a pre-LLM world meant digging into code that sometimes was a 3rd party library, it meant manually writing the harness by hand and deciding on what levers to pull. 

The pivot wasn’t just about technical challenges. Our tool succeeded beyond expectations, attracting security agencies and offensive security firms, while we wanted to build for enterprise teams. So we listened to our customers and shifted toward developer-centric DAST.

The world finally caught up

2026 is nearing its end, and with it, the ability to automate root cause analysis, harness creation and runtime, and application containment on the fly has becaome a reality, and not just a reality, one that can actually scale up across an organization’s codebase.

With thoese new realities we decided to revisit our core technology and with careful consideration for the power and capabilities of what we built we created an automated harness around the algorithm and code, combining our fuzzer with Bright’s STAR agentic harness.

No longer would developers need to manually dig into root cause, they would not need to write their own fixes or understand complex low level handling, the pure power of Bright’s fuzzer just became a single click autonomous solution. 

But before we could share it with the world, we needed to test it ourselves and prove that it works, and so we did.

Welcome to the ZeroDay Factory

We started by running the Fuzzer on multiple opens-ource solutions in an automated pipeline we created for two days. This included various , from libraries to applications, from web based technologies to low level binary parsers. 

But as our CEO likes to say: words are words – and numbers are numbers, so let’s back up our claims: 

Out of the projects we tested 45% had High or Critical issues, those span different vulnerability families from memory corruptions (read and write) to denial of service (memory bombs and process death) and others vulnerabilities including path traversal and escapes. 

37% of the vulnerable projects are in Google’s own OSS-fuzz list, which means a decade of constant fuzzing and issue hunting still proves a viable “hunting” finding grounds for the Bright Fuzzer.

We already have a number of published advisories are already available for those who are interested at:

1. TwelveMonkeys DDS OutOfMemoryError (38-byte file forces a multi-GB allocation) – GHSA-fwp7-38wp-mmxw, published, fixed in 3.15.0
2. Fider image decompression-bomb OOM (436 KB PNG expands to about 562 MB) – GHSA-7cw3-7xh9-529r, published, fixed in 0.38.0

A few have been opened as public issues due to no disclosure policy:

1. htop out-of-bounds read in the /proc/PID/stat parser – htop-dev/htop#2101, fixed
2. universal-ctags null-pointer access in foreachEntriesInScope – universal-ctags/ctags#4497, fixed
3. scrimage GIF decompression bomb (35-byte GIF forces a multi-GB OOM) – sksamuel/scrimage#893, fixed in 4.6.8

Most of the issues the fuzzer found are still undisclosed and will be shared and published when fixes will be published.

Numbers are great, but let’s for a second dig into the talk about Fider finding.

Fider has been the battle ground for AI PT companies showing their skills. A recent article from Doyensec compared XBOW v.s Aikido against the Fider app, each found its own share of issues and ran for hours and even days against the target using smart LLMs to find and detect all kind of vulnerabilities both from the web side and by code analysis.

After all of those findings Doyensec contacted Fider and reported the issues which were all fixed, a few more companies then followed suit which brought even more issues to be disclosed and fixed as well. 

We took the latest version, the one which was battle tested against multiple companies using advanced LLMs and AI products and gave our fuzzer a run. It took around 12 minutes for it to find a 0day in the imaging processing logic which allows a tiny few bytes image to overload the server memory with GBs of allocations and take down a whole instance.

And this is the biggest point, while LLM based Pentesting solutions hunt for the mundane and expected, our fuzzer hunts for the unexpected and hard to find vulnerabilities, because in the new age of LLMs in which Pentesting has become a commodity, and AI can easily find vulnerabilities with a simple prompt, the unexpected which the AI fails to identify and detect becomes the new frontier of security research and testing.

To add a bit more here, the Bright fuzzer is conceptually an AFL fuzzer with many additional capabilities. It systematically generates inputs and executes software to discover crashes and other observable failures. In comparison, LLM based solutions like Codex, Claude and others can understand code, reason about potential vulnerabilities, write tests, execute tools and attempt to exploit weaknesses. These are very different capabilities that find different vulnerabilities. 

Better Together, With STAR

Bright’s STAR provides an autonomous harness for vulnerability detection, remediation and validation, all in one flow. And this is where the fuzzer fits perfectly.

The new fuzzing mode in STAR uses Bright’s fuzzer to uncover deep and complex issues easily, detect and identify the root cause, fix the issues, then validate they are indeed fixed using the fuzzer replay functionality. 

It can also validate SAST findings by live fuzzing of functions and parts of the target in the harness, ensuring real behavior handling and security issue focus instead of just noise and false positives from SAST analysis.

* Fider findings – PR view, full details showing the exploitation impact and payloads.

We will start sharing all the Bright fuzzer findings on a regular basis so follow Bright on all social channels to receive ongoing updates and stay tuned for my post next week.

Detecting MCP Session Management Attacks with DAST

The Model Context Protocol (MCP) gave language-model agents a standard way to talk to servers that expose tools, resources, and prompts. To keep those conversations coherent across many HTTP requests, the streamable-HTTP transport introduces a session: the server issues an Mcp-Session-Id on initialization, and the client echoes it back on every subsequent call. That one header carries a lot of weight. It binds an otherwise stateless HTTP request to server-side context, and in many implementations it silently becomes the mechanism that determines a caller’s identity and the scope of their authorization.

Session identifiers are one of the oldest problem areas in web security, and MCP inherits every one of those problems without the decades of hard-won defaults that mature web frameworks ship with. An MCP server author is often writing session handling from scratch, inside a protocol that is only a couple of years old, against a spec that leaves several safety-critical choices to the implementer. That is exactly the environment where predictable identifiers, missing authentication, and sessions that never die tend to appear.

DAST is the natural way to find these flaws, because each is a property of the running server rather than of any single message: none are visible from a request in isolation, and several cannot be seen in source at all. This article covers three such weaknesses the Bright scanner detects automatically — MCP Predictable Session ID, MCP Session ID as Authentication, and MCP Session Not Invalidated.

Why the MCP session is a target

In the streamable-HTTP transport, the lifecycle is simple. The client sends an initialize request; the server responds with an Mcp-Session-Id header. From then on, the client attaches that header to every tools/call, resources/read, or prompts/get request, and the server uses it to look up the associated state. The MCP specification also describes an optional teardown: a client may send an HTTP DELETE to the endpoint with the session header to terminate the session.

Three assumptions have to hold for that design to be safe, and each maps to one of the attacks below:

• The session ID must be unpredictable, or an attacker can guess a valid one and hijack someone else’s session.
• The session ID must not be sufficient on its own to authorize actions, or the identifier becomes a bearer token and its disclosure enables account takeover.
• Termination must actually revoke the session server-side, or a compromised identifier remains valid well beyond its intended lifetime, leaving a persistent avenue for unauthorized access after the user has logged out.

All of these are the same session-fixation, session-hijacking, and session-lifetime concerns web applications have wrestled with for twenty years — resurfacing in a protocol that hands the identifier to an autonomous agent with access to tools and downstream systems.

Attack 1: Predictable session IDs

If session identifiers are guessable, the entire session boundary collapses. An attacker who can predict the next valid Mcp-Session-Id can attach it to their own requests and operate within a session the server attributes to another user, without ever obtaining a credential. Predictability manifests in several forms: monotonic counters, identifiers that embed a wall-clock timestamp, tokens built from a fixed template with only a handful of variable characters, or values whose entropy is low enough to fall to a modest brute-force search. 

Detecting this condition black-box requires collecting a representative sample and reasoning about its structure rather than trusting any single value. The Bright scanner initializes several fresh, isolated MCP sessions against the endpoint and gathers the issued session IDs, then evaluates them through a two-tier analysis that separates signals which are conclusive on their own from signals that are meaningful only in combination.

Strong signals report immediately. Certain observations constitute sufficient evidence on their own and require no corroboration:

• The same identifier issued for two distinct fresh sessions — a collision indicative of session fixation or a defective generator.
• Sequential numeric IDs, whether pure integers or a static prefix followed by a counter.
• A UUID version 1, which is time- and MAC-address-based and therefore substantially predictable, matched against the full RFC 4122 v1 layout.
• A high fixed-character mask: when most positions across a same-length sample are invariant and the few variable positions are themselves sequential or low-entropy, the ostensibly random identifier is in fact a template with a small guessable keyspace.

Weak signals are scored. Other properties — such as low estimated entropy, an embedded timestamp, or insufficient length and character variety — are suspicious but not conclusive in isolation. Rather than reporting on any one of these, the scanner assigns each a weight reflecting how strongly it indicates predictability and reports only when the accumulated evidence crosses a confidence threshold. This weighted approach ensures that a single soft indicator is not treated as a vulnerability while a combination of them is.

Keeping false positives low depends on how carefully those weak signals are measured. The entropy estimate is calibrated to the token’s own character set, so a short but genuinely random identifier is not mistaken for a weak one simply because it draws from a small alphabet. Timestamp detection is similarly conservative, flagging only values that fall within a narrow window of the current time and therefore plausibly encode a token’s creation moment. Together these precautions let the scanner weigh soft evidence without inflating it.

The result is a check that is both sensitive and low-noise. A single collision or an obvious counter is reported immediately, while weaker indicators must accumulate before they constitute a finding — so genuine weaknesses surface early without every incidental pattern becoming an alert.

Attack 2: Session ID as authentication

A session identifier establishes conversational continuity — which exchange a request belongs to. It must never serve as the sole basis for authorization. When a server treats the presence of a valid Mcp-Session-Id as proof of identity, any party who obtains that identifier — from a log, an intermediary proxy, a referer header, or a predictable generator — inherits the victim’s privileges in full.

The detection is a controlled A/B comparison designed around a single question: does the server continue to service a request after every application-level credential has been removed, leaving only the session header?

1. Establish a session with a normal, fully authenticated request and confirm the baseline call succeeds and carries no JSON-RPC error.
2. Rule out the trivially-public case first. If a freshly initialized session can be used with no application auth at all, the endpoint is simply public and using the session ID alone is expected there — so the scanner does not report.
3. Replay the exact same MCP call with authentication headers and cookies removed, keeping only the Mcp-Session-Id that the transport layer injects independently of auth.

If that stripped-auth replay still returns a successful, error-free response, the session ID is functioning as a credential: the server authorizes the action on the strength of the identifier alone, which constitutes the finding. Because the test requires an application authentication scheme to remove, it runs only against entry points that have an associated auth flow — stripping credentials from an endpoint that never enforced any would yield no meaningful signal.

The public-endpoint guard is the critical nuance. Many MCP servers are intended to be publicly accessible, and on those the session-ID-only pattern is correct rather than vulnerable. By first confirming that an unauthenticated fresh session is rejected, the scanner establishes that the endpoint genuinely enforces authentication, and only then interprets a surviving stripped-auth request as evidence that the session ID is being trusted as an authentication token.

Attack 3: Session not invalidated after termination

A logout that fails to terminate the session is a well-known and consequential defect. In MCP, the client-initiated teardown is an HTTP DELETE to the endpoint carrying the session header. Support for DELETE is optional under the specification, so its absence alone does not constitute a defect. The defect is a server that accepts the termination — responding to the DELETE with a 2xx status — yet continues to honor the session it purported to end. Any identifier disclosed prior to termination remains valid, and the user’s assumption that the session was closed is incorrect.

The scanner exercises the full lifecycle end to end, using an isolated session so that the probe does not disturb a cached session another concurrent test may depend on:

4. Initialize a fresh, isolated session and confirm a baseline call on it succeeds without a JSON-RPC error, establishing that the session is genuinely live.
5. Send an HTTP DELETE with that session’s header to request termination. If the server does not answer with success, DELETE is unsupported or refused and the test stops — there is nothing to report.
6. DELETE was accepted, so re-issue the original request on the same session ID and observe the outcome.

If the post-deletion request still succeeds and returns no error, the server acknowledged a termination it did not perform. The session survived its own deletion, and the scanner files the finding. Anchoring the entire sequence to a session the scanner created ensures the result is trustworthy: the reused identifier is one whose complete history — creation, use, deletion, and attempted reuse — the scanner controls and has observed directly.

Security impact

Session hijacking. A predictable identifier enables session prediction: an attacker brute-forces or derives a valid Mcp-Session-Id and assumes an authenticated user’s session, inheriting that user’s privileges and tool access through the agent. The attack requires no phishing or malware, only offline computation against a weak identifier-generation scheme.

Authorization bypass. When the session ID is accepted as a credential, it becomes a bearer token, and a single disclosed identifier is sufficient for account takeover. Session identifiers are frequently exposed through channels not intended to protect secrets, so treating them as an authentication factor turns routine identifier leakage into full account compromise.

Insufficient session expiration. A session that is not invalidated on termination cannot be revoked, defeating the user’s primary control for terminating access. Any previously disclosed identifier remains valid indefinitely, extending the window of exploitation well beyond the intended session lifetime.

Expanded attack surface through the agent. In each of these cases the session holder is an autonomous agent with authorized access to tools, data, and connected systems. A session-management weakness that would already be high-severity in a conventional web application is amplified here, because a hijacked session grants the attacker the agent’s ability to invoke tools and reach downstream systems on the victim’s behalf.

Defenses and takeaways

For teams building or integrating MCP servers:

• Generate session IDs from a cryptographically secure random source. Aim for at least 128 bits of real entropy, and never derive an identifier from counters, timestamps, or fixed templates. If it has a pattern, it is guessable.
• Do not allow the session ID to authenticate. Require an independent credential on every privileged request, and scope the session to conversational continuity rather than authorization. The session should confer no access in the absence of independent authentication.
• Ensure termination is enforced. When accepting an HTTP DELETE, invalidate the server-side state immediately and reject any subsequent use of the identifier.
• Regenerate the session ID on authentication and privilege change to prevent session fixation, and enforce idle and absolute timeouts to minimize the useful lifetime of any captured identifier.

The common thread across all three checks is that session security resides in the behavior of the running server, not in any individual message. Assessing it requires sampling, comparison, and probing of the full lifecycle — precisely the capabilities an enterprise level DAST scanner provides.

Conclusion

MCP inherits the classic session-management weaknesses, but binds them to an autonomous agent with access to tools and downstream systems, amplifying their impact. Because each is a runtime property of the live server, DAST is the right approach to detect them. By collecting real session identifiers, replaying calls with credentials removed, and exercising the termination lifecycle, the Bright scanner turns these into precise, automated checks against the MCP surfaces agents depend on.