What is Agent-as-a-Service pentesting?

Agent-as-a-Service (AaaS) pentesting lets you chat with autonomous pentesting agents that scan your application on demand. Instead of waiting weeks for a manual engagement, you talk to specialized agents — pen-scout (recon and surface mapping), pen-recon (deeper enumeration), pen-triage (validates and prioritizes findings), pen-fixer (remediation guidance), and pen-compliance (OWASP/standards mapping). Findings are validated with proof-of-concept and re-test, not just flagged. You start with 150 free credits, no credit card.

What are credits and how do they work?

Credits are how you run agent scans. Each scan or agent action consumes credits based on its depth. New accounts get 150 free credits with no card required. After that you can buy one-time credit packs ($29, $79, or $199) for pay-as-you-go use, or subscribe to a monthly tier ($49, $149, or $399/mo) for continuous, on-demand pentesting. The agents pen-scout, pen-recon, pen-triage, pen-fixer and pen-compliance all draw from the same credit balance.

Yes. Every new account gets 150 free credits with no credit card required — enough to chat with the pentesting agents and run real scans against your app. There is also a free security headers scan at sable.somoswilab.com/free-scan and a sample report at sable.somoswilab.com/sample-report. The free tier runs on OpenRouter models so you can evaluate the autonomous agents before paying.

What is penetration testing for startups?

Penetration testing (pentesting) is a simulated cyberattack against your application to find security vulnerabilities before real attackers do. For startups, we focus on the issues that matter most at your stage: authentication flaws, data exposure, API security, and common mistakes in modern stacks like Next.js, Supabase, and Firebase.

How much does a pentest cost?

Traditional pentests cost $10,000-$50,000+. SableOffensive starts at $29 for a Pre-Launch Check covering OWASP Top 10 and secrets detection. Founder Shield ($79) adds IDOR testing, auth bypass, and a debrief call. Scale Secure ($199) is a full-scope assessment. Every plan includes a professional report with remediation steps.

How long does a security scan take?

Pre-Launch Check reports are delivered within 24-48 hours. Founder Shield and Scale Secure may take 2-3 business days depending on the complexity of your application.

What do I need to provide?

At minimum, just your application URL. For more comprehensive testing, we may ask for staging credentials, API documentation, or GitHub repository access. We sign NDAs for all engagements.

What is OWASP Top 10?

OWASP Top 10 is the industry standard list of the most critical web application security risks. It includes injection attacks, broken authentication, cross-site scripting (XSS), server-side request forgery (SSRF), and security misconfigurations. Every SableOffensive assessment tests against the full OWASP Top 10.

Do you test AI-generated code?

Yes. Code generated by AI tools like Cursor, GitHub Copilot, and v0 often contains subtle security issues: hardcoded secrets, missing input validation, insecure API patterns, and overly permissive access controls. We have specific testing procedures for AI-generated codebases.

How do you secure Supabase and Firebase apps?

For Supabase, we audit Row Level Security (RLS) policies, test for direct table access, and check for exposed service keys. For Firebase, we review security rules, test Firestore/RTDB access patterns, and check Cloud Functions for vulnerabilities.

What if you find zero vulnerabilities?

50% money back guarantee. If our scan finds zero security issues, you get half your money back.

Is there a free pentesting option?

Yes. SableOffensive offers a free security headers scan at sable.somoswilab.com/free-scan. It instantly checks your website for 8 critical security headers (HSTS, CSP, X-Frame-Options, and more) and gives you an A-F grade with copy-paste fixes. No signup or payment required.

Can I get a free vulnerability scan?

Our free security headers check scans your website instantly and grades your security posture. For a deeper free assessment, contact us — we occasionally offer complimentary scans for early-stage startups and open source projects.

CVE-2026-42271: How a Popular AI Gateway Became an RCE Vector

The Vulnerability

On May 8, 2026, BerriAI disclosed CVE-2026-42271, a command-injection flaw in LiteLLM — one of the most widely deployed open-source AI gateways. The vulnerability scored CVSS 8.8 and affects every release from version 1.74.2 to before 1.83.7. By June 9, CISA had added it to the Known Exploited Vulnerabilities (KEV) catalog, confirming active exploitation in the wild.

The root cause lives in two MCP-server preview endpoints: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These endpoints accept a full server configuration in the request body — including the command, args, and env fields used by the stdio transport. When an authenticated user (or an attacker who chains this with the separate Starlette host-header bypass, CVE-2026-48710) sends a crafted payload, the injected command executes on the host with the privileges of the LiteLLM process. No sandboxing. No allowlist. Direct OS-level command execution.

Why This Matters for AI-Heavy Teams

LiteLLM has become the default glue layer for teams building AI-powered products. It normalizes API calls across OpenAI, Anthropic, Google, and dozens of open-weight models. If you've deployed an LLM feature in the last 12 months, there's a non-trivial chance LiteLLM sits somewhere in your stack — in front of your RAG pipeline, your agent framework, or your internal tool-calling layer.

That popularity is exactly what makes this an attack-surface problem, not just a single-CVE problem. The MCP (Model Context Protocol) integration that the vulnerable endpoints serve is the same pattern teams use to connect LLMs to external tools: databases, code execution sandboxes, file systems, APIs. Every MCP server you plug in via stdio transport carries its own command and args. If the gateway doesn't strictly validate those fields, the tool-calling feature becomes a command-injection feature.

The Hacker News reported that the flaw chains to unauthenticated RCE when combined with the Starlette host-header bypass — meaning an attacker who can reach the LiteLLM HTTP interface doesn't even need valid credentials.

What to Audit in Your AI Stack Right Now

If you run LiteLLM (or any AI gateway that proxies model calls and manages tool integrations), here's a concrete checklist:

Version check: Are you on LiteLLM ≥ 1.83.7? If not, upgrade immediately. This is a one-line fix in the stdio transport handler.
Endpoint exposure: Are /mcp-rest/test/connection and /mcp-rest/test/tools/list reachable from untrusted networks? If you don't use MCP server preview, disable or remove these endpoints entirely.
Authentication boundary: Even though CVE-2026-42271 requires authentication on its own, the Starlette bypass (CVE-2026-48710) removes that barrier. Treat the entire LiteLLM HTTP surface as public-facing until both are patched.
Process privileges: What user does the LiteLLM process run as? If it's root (common in containerized deployments that haven't been hardened), command injection means full container escape. Run as a non-root user with minimal capabilities.
MCP server inventory: List every MCP server your gateway is configured to call. Review the command and args for each. If any accept user-controlled input, that's a second-order injection risk.

The Bigger Pattern: AI Tooling Is Now Supply Chain

This isn't the first time an AI infrastructure component has turned into an attack vector, and it won't be the last. The Hugging Face ecosystem saw two critical CVEs in May 2026 (CVE-2026-0599 and CVE-2026-25874). The pattern is consistent: open-source AI tooling moves fast, security reviews lag, and the resulting components end up in production with the same trust level as a battle-tested web server — without the same hardening.

For early-stage teams especially, the lesson is not "don't use open-source AI tools." It's: every dependency in your AI pipeline needs the same scrutiny you'd give a database driver or an auth library. That means version pinning, CVE monitoring, least-privilege deployment, and network segmentation between your AI gateway and the rest of your infrastructure.

LiteLLM patched this in 1.83.7. The fix is already out. The question is whether your deployment is running it.