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-23918: Apache HTTP/2 Double-Free Flaw Lets Attackers Crash Servers and Potentially Execute Remote Code

What Happened

On May 6, 2026, the Apache Software Foundation released HTTP Server 2.4.67 to address a critical double-free vulnerability tracked as CVE-2026-23918 (CVSS 8.8) in the server's HTTP/2 implementation. The flaw can be triggered remotely by sending specially crafted HTTP/2 requests, potentially causing the server process to crash (denial of service) or, in certain configurations, enabling arbitrary code execution. Security Affairs first reported the patch, and the Center for Internet Security subsequently issued an advisory urging immediate patching. The Centre for Cybersecurity Belgium also flagged the vulnerability as part of a broader set of critical Apache flaws requiring urgent attention.

Technical Analysis

CVE-2026-23918 is a double-free bug in Apache's HTTP/2 stream handling code. When an HTTP/2 client sends a sequence of malformed or conflicting stream frames, the server can end up freeing the same memory region twice during connection cleanup. This class of vulnerability — use-after-free or double-free in memory management — is well-known for its potential to corrupt heap metadata and achieve code execution, though the exploitability depends on the server's memory allocator, operating system mitigations (ASLR, heap hardening), and whether the affected code path runs in a privileged context. SOC Prime's analysis confirms the flaw affects all Apache HTTP Server versions prior to 2.4.67 that have HTTP/2 enabled (the default in most modern deployments). PurpleOps rated the CVSS at 8.8, noting that while a reliable RCE chain has not been publicly demonstrated, the double-free primitive in a network-facing service is treated as critical by virtually every major vulnerability framework. Daily Security Review noted that denial-of-service exploitation is straightforward and reliable, making this an immediate availability risk even for organizations that assess the RCE path as unlikely.

Who's Affected

Apache HTTP Server powers an estimated 30% of all websites worldwide — roughly 400 million servers. Any deployment running Apache 2.4.x with HTTP/2 enabled (via the mod_http2 module) and a version below 2.4.67 is vulnerable. This includes cloud-hosted web applications, API gateways, reverse proxies, and embedded web interfaces on network equipment. The vulnerability is remotely exploitable without authentication, meaning any internet-facing Apache server is a potential target. Organizations running Apache behind load balancers or CDNs are still vulnerable if the origin server accepts HTTP/2 connections directly. The combination of massive attack surface, no-auth exploitation, and potential for RCE makes CVE-2026-23918 one of the most consequential Apache vulnerabilities disclosed in 2026.

How to Protect Yourself

1. Upgrade to Apache HTTP Server 2.4.67 immediately. This is the single most effective action. If you're on 2.4.66 or earlier, your HTTP/2 implementation is vulnerable. Package managers (apt, yum, brew) should have updated packages available within 24-48 hours of the release.

2. Verify HTTP/2 is actually enabled on your servers. Run apachectl -M 2>/dev/null | grep http2 or check your configuration for Protocols h2 h2c http/1.1. If mod_http2 is not loaded, you are not vulnerable to this specific flaw — but confirm this rather than assuming.

3. Apply defense-in-depth mitigations if patching is delayed. If you cannot patch immediately, consider disabling HTTP/2 temporarily by removing h2 and from your Protocols directive and restarting Apache. This forces clients to fall back to HTTP/1.1, which is not affected by this vulnerability. Also ensure your WAF or reverse proxy is configured to reject malformed HTTP/2 frame sequences.

4. Monitor for exploitation attempts. Look for HTTP/2 connection resets, abnormal stream cancellation patterns, or repeated 400/500 errors from Apache in your access logs. These may indicate active probing or exploitation attempts against CVE-2026-23918.

5. Audit your entire Apache footprint. Many organizations have forgotten or unmanaged Apache instances — staging servers, internal tools, development environments. Use your asset inventory to identify every Apache installation and verify its version. Unmanaged instances are the ones most likely to remain unpatched.

The Sable Angle

Memory corruption vulnerabilities in network-facing services are the holy grail of offensive security — and they're exactly the class of flaw our red team looks for during infrastructure penetration tests. A double-free in a service handling unauthenticated HTTP/2 traffic is about as close to an ideal attack primitive as an adversary can hope for: no credentials required, massive target surface, and the potential for full remote code execution. At Sable, we routinely find that organizations have internet-facing web servers running outdated versions with known critical CVEs — not because they don't patch, but because they don't have a complete inventory of what's running.

The Apache project's response here was fast — the patch was released within days of discovery, and the advisory is clear. The risk now shifts to the operational side: how quickly can your organization identify every Apache instance, verify HTTP/2 is enabled, and push 2.4.67? If that process takes more than 48 hours, you should be asking whether your asset management and patch deployment pipeline is fit for purpose. Our research team tracks exactly these kinds of high-impact infrastructure vulnerabilities to help defenders prioritize what to patch first when the next critical CVE drops.