Public Audit Case Studies

98 findings across 3 projects
with 108K+ GitHub stars.

We audited popular open-source projects using the same AI-powered methodology available in our free tool and consulting engagements. Full reports published on GitHub.

98

Verified findings

6

Audits (web + CI/CD)

108K+

Combined GitHub stars

100%

Findings with fix guidance

Audit #1

maybe-finance

Open-source personal finance app

35K

GitHub stars

Ruby / Rails

Stack

34

Total findings

Audited: 2026-03-31 · All findings independently verified against live repo

maybe-finance is a popular open-source personal finance app that connects to bank accounts via Plaid and aggregates financial data. Our audit revealed critical credential storage issues in an application handling some of the most sensitive data users have.

CRITICAL

OTP Secret Stored in Plaintext in Database

CVSS: 9.1 OWASP: V2.8.4 CWE-312

The otp_secret column in the users table is stored as plaintext with no encryption. The User model does not use Rails' encrypts directive. Backup codes are also stored as plaintext arrays. An attacker with database access can extract OTP secrets and generate valid TOTP codes, completely bypassing MFA for all users.

Fix: Add encrypts :otp_secret, deterministic: false to the User model. Encrypt otp_backup_codes. Rotate all existing secrets after deploying the fix.

CRITICAL

Plaid Access Tokens Conditionally Encrypted — Plaintext in Self-Hosted

CVSS: 9.1 OWASP: V8.3.4 CWE-312

Plaid token encryption is conditional and only activates when active_record_encryption credentials are present. Self-hosted instances generate keys from SECRET_KEY_BASE but write them to a different config path, causing the check to evaluate to false. Plaid access tokens grant full read access to bank accounts, transactions, and balances.

Fix: Remove the conditional encryption check — always encrypt. Provide migration tooling to encrypt existing plaintext tokens.

Audit #2

Documenso

Open-source e-signing platform

8K

GitHub stars

TypeScript / Next.js

Stack

31

Total findings

Audited: 2026-03-28 · All findings independently verified against live repo

Documenso is an open-source alternative to DocuSign for e-signing documents. The core value proposition is trust and legal validity. Our audit found that the mechanism ensuring document integrity had been disabled, and webhook security was fundamentally broken.

CRITICAL

Encryption Key Validation Commented Out in Production

CVSS: 8.8 OWASP: V8.3.1 CWE-327

The entire encryption key validation block in packages/lib/constants/crypto.ts is commented out. The application can start without encryption keys. There is no guard against weak/default keys. Primary and secondary keys can be identical. The secondary key is used for webhook signature verification — without it, internal webhook endpoints can be spoofed.

Fix: Uncomment and enforce the validation. Add a startup check that fails hard if keys are missing or default. Use environment validation (e.g., Zod) at bootstrap.

HIGH

Webhook Secret Sent as Plaintext Header (No HMAC)

CVSS: 7.5 OWASP: V13.3.1 CWE-345

Webhook secrets are transmitted as static plaintext headers rather than HMAC signatures. The secret is sent in every request as a static value, vulnerable to MITM, logging, or proxy capture. An empty string is sent when no secret is configured. Consumers cannot verify payload integrity. For an e-signing platform, signing completion events could be forged.

Fix: Replace X-Documenso-Secret with X-Documenso-Signature: sha256=HMAC(secret, body). Provide client libraries for signature verification.

Audit #3

Hoppscotch

Open-source API development platform

65K

GitHub stars

TypeScript / Vue

Stack

33

Total findings

Audited: 2026-03-28 · All findings independently verified against live repo

Hoppscotch is one of the most popular open-source API development tools. Users save API requests with authentication tokens and production secrets. Our audit found authorization bypasses and a critical infrastructure takeover vector.

HIGH

IDOR in User History — Star/Delete Operations

CVSS: 7.5 OWASP: V4.2.1 CWE-639

The toggleHistoryStarStatus and removeRequestFromHistory methods accept a user UID parameter but never use it to filter queries. Operations query only by history entry ID, meaning any authenticated user can modify or delete any other user's history entries. History contains full API request data including auth tokens and API keys.

Fix: Add userUid to all where clauses: where: { id: id, userUid: uid }. Apply the same pattern to all user-scoped resources.

HIGH

Unauthenticated Onboarding Allows Full Infrastructure Reconfiguration

CVSS: 8.1 OWASP: V4.1.1 CWE-306

The POST /v1/onboarding/config endpoint allows complete reconfiguration without authentication. The only guard is checking usersCount === 0. On fresh deployments, anyone reaching the backend can configure OAuth with attacker-controlled credentials, set SMTP to attacker servers, and take over the instance. A race condition between docker compose up and first admin creation.

Fix: Add IP-based restrictions. Implement a setup token mechanism. Require DATA_ENCRYPTION_KEY as proof of server access.

Plus: 87+ findings on production fintech.

Beyond these public audits, AI-Sec's methodology was developed and battle-tested on a live, VARA-regulated cryptocurrency exchange over two full audit iterations. That engagement produced 87+ findings including critical authentication bypasses, access control failures, and compliance gaps.

87+

Findings

2

Full iterations

VARA

Regulated

Details of the production fintech engagement are confidential. The methodology, tooling, and audit depth are identical to what you get with AI-Sec consulting.

Our methodology.

The same approach is used across all engagements — from the free open-source tool to enterprise consulting.

1

Full codebase ingestion

AI reads the entire codebase — frontend, backend, API layer, infrastructure configs — and builds a holistic understanding of architecture, data flows, and trust boundaries.

2

OWASP ASVS L2 systematic audit

Every relevant control in the OWASP ASVS L2 checklist (286 verification requirements across 14 categories) is evaluated. Findings are tagged with CVSS severity scores and CWE identifiers.

3

Architectural reasoning

Not pattern matching. The AI reasons about auth flows, data access patterns, trust boundary crossings, and business logic. This catches IDORs, broken authentication, and logic flaws that scanners miss.

4

Actionable reporting

Every finding includes severity (CVSS), OWASP category, CWE identifier, detailed description, reproduction steps, and code-level fix guidance. Not a 200-page PDF — actionable output you can hand to your dev team or AI coding agent.

Your codebase deserves the same analysis.

Start free with the open-source tool, or book a call to scope your audit. Same methodology that found 98 findings across 108K+ GitHub stars.