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