Full disclosure: I'm a researcher at CyberArk Labs.

This is a technical deep dive from our threat research team, no marketing fluff, just code and methodology.
Static analysis tools like CodeQL are great at identifying "maybe" issues, but the signal-to-noise ratio is often overwhelming. You get thousands of alerts, and manually triaging them is impossible.

We built an open-source tool, Vulnhalla, to address this issue. It queries CodeQL's "haystack" into GPT-4o, which reasons about the code context to verify if the alert is legitimate.

The sheer volume of false positives often tricks us into thinking a codebase is "clean enough" just because we can't physically get through the backlog. This creates a significant amount of frustration for us. Still, the vulnerabilities remain, hidden in the noise.
Once we used GPT-4o to strip away ~96% of the false positives, we uncovered confirmed CVEs in the Linux Kernel, FFmpeg, Redis, Bullet3, and RetroArch. We found these in just 2 days of running the tool and triaging the output (total API cost <$80).
Running the tool for longer periods, with improved models, can reveal many additional vulnerabilities.
Write-up & Tool:

• Technical Blog:https://www.cyberark.com/resources/threat-research-blog/vulnhalla-picking-the-true-vulnerabilities-from-the-codeql-haystack
• GitHub:https://github.com/cyberark/Vulnhalla

We've just released a tool that fixes a particularly annoying problem for those trying to fuzz HTTP/3.

The issue is that QUIC is designed to prevent network bottlenecks (HOL blocking), which is beneficial, but it disrupts the fundamental timing required for exploiting application-level race conditions. We tried all the obvious solutions, but QUIC's RFC essentially blocks fragmentation and other low-level network optimizations. 🤷‍♂️

So, we figured out a way to synchronize things at the QUIC stream layer using a technique we call Quic-Fin-Sync.

The gist:

1. Set up 100+ requests, but hold back the absolute last byte of data for each one.
2. The server gets 99.9% of the data but waits for that last byte.
3. We send the final byte (and the crucial QUIC FIN flag) for all 100+ requests in one single UDP packet.

This one packet forces the server to "release" all the requests into processing near-simultaneously. It worked way better than existing methods in our tests—we successfully raced a vulnerable Keycloak setup over 40 times.

If you are pentesting HTTP/3, grab the open-source tool and let us know what you break with it. The full write-up is below.

What’s the most frustrating thing you’ve run into trying to test QUIC/HTTP/3?

Disclosure: I work at CyberArk

The research shows that Chrome’s AppBound cookie encryption relies on a key derivation process with limited entropy and predictable inputs. By systematically generating possible keys based on known parameters, an attacker can brute-force the correct encryption key without any elevated privileges or code execution. Once recovered, this key can decrypt any AppBound-protected cookies, completely undermining the isolation AppBound was intended to provide in enterprise environments.

We broke Chrome’s AppBound cookie encryption used in enterprise environments. Using timing-based attacks against the WebView lifecycle, we were able to recover encryption keys and decrypt secure cookies — no root or sandbox escape required. This affects managed Android profiles using MDM and AppBound mode.

[Disclosure: I work at CyberArk and was involved in this research]

We've completed a security evaluation of the Model Context Protocol and discovered several concerning attack patterns relevant to ML practitioners integrating external tools with LLMs.

Background: MCP standardizes how AI applications access external resources - essentially creating a plugin ecosystem for LLMs. While this enables powerful agentic behaviors, it introduces novel security considerations.

Technical Findings:

• Tool Poisoning: Adversarial servers can define tools that appear benign but execute malicious payloads
• Context Injection: Hidden instructions in MCP responses can manipulate model behavior
• Privilege Escalation: Chained MCP servers can bypass intended access controls
• Authentication Weaknesses: Many implementations rely on implicit trust rather than proper auth

ML-Specific Implications: For researchers using tools like Claude Desktop or Cursor with MCP servers, these vulnerabilities could lead to:

• Unintended data exfiltration from research environments
• Compromise of model training pipelines
• Injection of adversarial content into datasets

Best Practices:

• Sandbox MCP servers during evaluation
• Implement explicit approval workflows for tool invocations
• Use containerized environments for MCP integrations
• Regular security audits of MCP toolchains

This highlights the importance of security-by-design as we build more sophisticated AI systems.

tps://www.cyberark.com/resources/threat-research-blog/is-your-ai-safe-threat-analysis-of-mcp-model-context-protocol