After receiving OpenAI’s cyber trusted access approval, our Product Security team started using GPT-5.5 as part of our vulnerability research workflow against Cribl products.
Cribl takes security seriously, and we’ve been able to find and fix several vulnerabilities using AI assisted research. This was not a novelty experiment where AI generated a pile of guesses and a human cleaned them up. The assistant became a real part of the research workflow. It traced code paths, connected product behavior across modules, generated proofs of concept, challenged assumptions, and helped turn early signals into issues that could be fixed.
That work produced several vulnerabilities that Cribl was able to fix, including two published CVEs: CVE-2026-56747 and CVE-2026-56748.
This also fits into Cribl’s broader vulnerability disclosure process. As a CVE Numbering Authority, Cribl can assign CVE IDs for in-scope vulnerabilities, coordinate responsible disclosure, and publish CVE records with the context customers need.
PSA: If you’re a Cribl customer, we highly recommend that you upgrade to a non-vulnerable version as outlined on our trust portal.
Why we tried this
Vulnerability research has a lot of necessary friction.
To do it well, you need a deep understanding of the code you are reviewing. That can be difficult across a large product surface where vulnerable behavior can appear in many places, including APIs, background jobs, configuration systems, product features, integrations, deployment models, etc.
You read unfamiliar code. You trace data through multiple layers. You build test cases. You discard weak leads. You keep asking whether user-controlled input can actually reach a sensitive operation in a way that creates security impact.
A lot of the work happens in that gap between something looking suspicious and something being proven. You may see a risky pattern, but still need to understand who can reach it, what assumptions protect it, whether those assumptions hold, and what impact is possible if they fail.
That is where AI became useful for us. It helped shorten the loop between code review and validation. Instead of treating every suspicious pattern as a long manual investigation from scratch, we could use the assistant to trace the path, identify the security question, and help build a focused test around it.
The workflow
Before asking the model to hunt for bugs, we gave it context.
That included product docs, architecture notes, threat-modeling assumptions, examples of meaningful findings, examples of false positives, testing constraints, and rules for responsible validation. The point was to make the assistant less generic and more aware of how Cribl products actually work.
This helped, but it did not make the model reliable on its own. It still needed direction. The better the context became, the better the research loop became.
The workflow was iterative:
read the relevant product code
trace how user-controlled data moved through the system
identify trust boundaries and sensitive operations
build a small proof of concept
validate the issue in an approved environment
document root cause, impact, and remediation
The better the context became, the better the research loop became. Instead of using AI as a generic code assistant, we were able to use it as a product-aware research partner.
What AI was good at
The strongest use case was call-path tracing. The assistant could move quickly through unfamiliar code, connect files, and explain how a request, configuration value, or imported artifact reached a sensitive operation.
It was also useful for building quick test harnesses and proof-of-concept scripts. That made it easier to test whether a lead was real instead of spending too much time debating it abstractly.
The last useful area was writing. Once a finding was validated, the assistant helped turn messy investigation notes into clear root cause, impact, and remediation language.
What still needed human work
The model produced plenty of false positives, especially early on.
Sometimes it has an overstated impact. Sometimes it misunderstood intended product behavior. Sometimes it treated a suspicious code pattern as a confirmed vulnerability before there was proof.
That is where human judgment mattered most. We had to steer the research, validate exploitability, check product intent, and make sure the proof matched the claim.
AI helped accelerate the work. It did not replace the responsibility to prove the work.
How you can help
If you are interested in helping Cribl improve our security, we encourage ethical security research and responsible reporting through our Vulnerability Disclosure Program.
Takeaways
The biggest shift was that AI moved from being a support tool to being part of the research loop.
With enough product context, the assistant was not just summarizing code or answering isolated questions. It could follow how data moved through the product, connect behavior across modules, identify places where trust boundaries mattered, and suggest concrete ways to test whether a pattern was actually exploitable.
That changed how we worked. Instead of spending most of the time manually stitching together code paths before we could even form a hypothesis, we could move more quickly from observation to test. The assistant helped turn “this looks suspicious” into a clear path through the code, an assumption to validate, and a proof of concept we could use to test it.
It also changed the quality of the iteration. Weak leads failed faster because we could test them sooner. Strong leads reached proof faster because the assistant could help refine the test case, look for related paths, and turn the result into a clear root cause and remediation writeup.
The result was not less rigorous research. It was a tighter research loop, with more hypotheses tested, more context carried forward, and less time lost between code reading, exploit validation, and fix-ready documentation.
