G8KEPR Red Team Run 4: What We Found and What We Fixed

Last month we completed Red Team Run 4 — a full external penetration test covering every attack surface in G8KEPR. We do this before major production milestones, not as a compliance checkbox but because we build a security product and we should be held to a higher standard than what we ask our customers to meet.

This post is the public writeup. We believe in open security posture. If you use G8KEPR to protect your APIs, you deserve to know exactly what a professional adversary found when they attacked ours.

Scope

The engagement was black-box and grey-box. The external firm received no source code and no internal documentation for the black-box phase. For the grey-box phase, they received the OpenAPI spec and a non-privileged test account — the same starting position a determined attacker with some recon would have.

• ▸All API endpoints (REST + WebSocket)
• ▸Authentication and authorization flows (API keys, JWT, OAuth, MFA)
• ▸MCP sandbox and tool-call handling
• ▸AI pipeline input/output processing
• ▸Tenant isolation and data boundary enforcement
• ▸Admin panel and internal tooling
• ▸HTTP headers, TLS configuration, CSP enforcement

Results Summary

The three Medium findings are the most instructive. None were exploitable in isolation — they all required a specific set of conditions to be useful to an attacker. But "requires specific conditions" is not the same as "acceptable." We resolved all five findings before the report was delivered.

PT-001: ReDoS in pattern_loader.py

The threat pattern loader in the backend accepts user-defined regex patterns for custom detection rules. The tester found that a crafted input containing deeply nested quantifiers (classic catastrophic backtracking patterns like `(a+)+b`) could cause the Python regex engine to spin for seconds per evaluation. At scale, this would allow an authenticated user to degrade detection performance for all tenants on the instance.

Fix

We capped all pattern inputs at 512 characters and substituted the standard `re` module with re2-safe evaluation for all user-defined patterns. The re2 engine uses a linear-time algorithm that cannot be forced into catastrophic backtracking. The fix was deployed within 4 hours of the finding.

PT-002: WebSocket IP Bypass via Forged X-Forwarded-For

The WebSocket endpoint used `X-Forwarded-For` headers as the authoritative source for client IP addresses — relevant for rate limiting and geo-blocking. An attacker who could send WebSocket traffic directly to the origin (bypassing Cloudflare) could forge this header and appear to come from any IP, effectively bypassing IP-based rate limits entirely.

Fix

Cloudflare sets `CF-Connecting-IP` with a header that cannot be spoofed by the client — it is injected at the edge after stripping any client-supplied value. We updated the WebSocket handler to use `CF-Connecting-IP` as the sole source of truth and strip `X-Forwarded-For` entirely at the edge WAF layer.

PT-003: CSP Nonce Not Propagated to Dynamically-Injected Scripts

Our Content Security Policy used nonce-based script allowlisting — each page load gets a fresh cryptographic nonce, and only scripts bearing that nonce can execute. The tester found that scripts injected dynamically via framework internals (specifically some Next.js third-party component initialisation paths) were not receiving the nonce, meaning they would be blocked by the CSP in browsers that enforce it strictly — but more importantly, it revealed a gap in the nonce propagation that could theoretically be exploited.

Fix

The nonce is now injected via a Next.js middleware wrapper that applies to all responses, and `strict-dynamic` is enforced — meaning dynamically-created scripts inherit trust from their parent rather than requiring an explicit nonce. All third-party scripts were audited and pinned with SRI hashes.

PT-004 + PT-005: Auth Endpoint 200s and Debug Mode Exposure

PT-004 found that 18 auth-related endpoints returned HTTP 200 with an empty body for non-existent resources instead of 404. This is a minor information leakage — an attacker can determine whether a resource exists before attempting to access it. PT-005 found that with debug mode explicitly enabled (not the default), stack traces were exposed in 500 responses. Neither was exploitable in production but both were cleaned up.

What We Learned

Run 4 confirmed what we expected: the core attack surfaces — authentication, tenant isolation, encryption — held up under sustained adversarial pressure. The findings were all at the edges: input handling quirks, header trust assumptions, and a configuration gap in CSP propagation. That pattern is typical of a mature codebase and reassuring compared to Run 1 and Run 2, where we found more substantive issues.

If you are evaluating G8KEPR for enterprise deployment and want the full NDA-protected report, contact us at security@g8kepr.com. We will turn it around within one business day.