Anonymous to Superadmin in Under 60 Seconds
A capability showcase from a Watch Owl Labs production engagement.
Critical platform compromise identified.
A complete, unauthenticated attack chain was discovered allowing any anonymous internet user to achieve Superadmin status in under 60 seconds. This exploit vector provided unrestricted access to all user PII and records, sensitive personal and health data, and administrative database operations.
Authentic findings. Identities removed.
This document constitutes a capability showcase produced by Watch Owl Labs. It presents authentic findings derived from a genuine security engagement conducted against a production application in April 2026.
All identifying information has been systematically removed or replaced:
- Client name, company, and industry are withheld from disclosure.
- Actual URLs have been substituted with fictional domains ([REDACTED].com).
- User emails, UUIDs, and any personally identifiable information have been redacted.
- Sensitive content (including crisis messages and health data) is described but not reproduced herein.
The vulnerability descriptions, attack methodologies, structure of HTTP evidence, and remediation guidance remain authentic and unaltered. Every finding within this document was validated with a functional proof-of-concept HTTP request executed against the live production system during the designated assessment period.
Operator-led. Hoot-leveraged.
Every Watch Owl Labs engagement is led by a senior security operator with extensive offensive security expertise. Hoot — our proprietary autonomous offensive security agent — is the force multiplier that lets one operator move at the speed of a five-person team without losing the judgment that separates a real engagement from a scanner report.
Every finding in this document was reviewed and validated by a senior Watch Owl Labs operator before it reached the client. The agent finds. The operator decides.
Scope, methodology, and final report sign-off all sit with a senior Watch Owl Labs operator. Hoot accelerates the work — it does not replace the operator's judgment.
Hoot follows signals, builds attack chains, and escalates confirmed vulnerabilities the way a senior pentester would — then surfaces them for the operator to direct.
Hoot validates each finding with a real request/response pair before recording it. No theoretical findings. No scanner noise. The operator then reviews every record before it leaves the engagement.
Hoot runs an adversarial verifier on every HIGH/CRITICAL finding — a second independent agent that attempts to disprove the result. The operator then makes the final call on what reaches the client.
When related findings are discovered, Hoot proposes attack chains showing real-world impact of combined vulnerabilities. The operator validates exploitability before the chain is published.
The numbers from this engagement.
Five critical. Two medium. All validated.
All 5 Critical findings were independently confirmed by the adversarial verifier with confidence scores of 0.90 or higher. Every finding includes a working proof-of-concept.
From anonymous to full compromise.
The individual findings do not exist in isolation. They form a complete, chained attack path that allows any anonymous attacker to fully compromise the platform in under 60 seconds:
Complete platform compromise achievable by any anonymous internet user in under 60 seconds.
Five critical findings. Five working PoCs.
Each finding below was validated against the live production system. Severity scoring uses CVSS v3.1. OWASP mappings reference the OWASP Top 10 (2021).
Unauthenticated User Enumeration via Exposed Development Endpoint
Description
The production API exposed a development-only endpoint that returned a complete dump of all user accounts in the database with no authentication required. The endpoint's own inline documentation warned "DEV ONLY - WARNING: No authentication - remove before production!" yet it remained active and publicly accessible.
What Was Exposed
The response returned full user records including: UUIDs, email addresses, full names, privilege roles (including superadmin accounts), authentication providers, account status flags, and creation timestamps for all platform users.
Business Impact
Any unauthenticated attacker on the internet could enumerate the complete user database in a single HTTP GET request, harvesting email addresses and superadmin UUIDs for use in targeted follow-on attacks. On a healthcare or mental-wellness platform, the mere knowledge of who the users are constitutes a significant privacy violation.
GET /dev/list-users HTTP/2
Host: api.[REDACTED].com
HTTP/2 200 OK
Content-Type: application/json
{"success":true,"count":[REDACTED],"users":[
{"id":"[UUID-REDACTED]","email":"[admin@REDACTED]","role":"superadmin",...},
{"id":"[UUID-REDACTED]","email":"[user@REDACTED]","role":"user",...},
... ([REDACTED] total users)
]}Remediation
- IMMEDIATE: Remove or disable all
/dev/*endpoints in the production deployment. - Add authentication middleware to any remaining debug routes.
- Conduct a full codebase audit to identify other DEV ONLY endpoints.
- Implement a CI/CD pipeline check that blocks deployment if any
/dev/*routes are detected in production code.
Unauthenticated Privilege Escalation to Platform Administrator
Description
A development endpoint designed to promote any user to the highest privilege role was exposed in production with no authentication, no authorization check, and no rate limiting. Any registered user — or an attacker who just self-registered — could call this endpoint to become a platform superadmin.
What Was Exposed
The endpoint accepted a target email address as a query parameter and immediately updated the database role. The endpoint's own description read: "DEV ONLY: Promote user to superadmin - WARNING: No authentication - remove before production!"
Business Impact
Complete privilege escalation in a single HTTP request. An attacker can achieve maximum platform access in under 60 seconds from an anonymous starting position using only publicly available registration and this unauthenticated endpoint.
POST /dev/promote-to-superadmin?email=attacker@evil.com HTTP/2
Host: api.[REDACTED].com
HTTP/2 200 OK
{"success":true,"message":"User promoted to superadmin"}
# Subsequent login returns superadmin JWT:
{"access_token":"eyJ[REDACTED].eyJyb2xlIjoic3VwZXJhZG1pbiJ9.[SIG-REDACTED]"}Remediation
- IMMEDIATE: Remove all
/dev/*endpoints from production. - Rotate all existing superadmin credentials.
- Audit server logs to identify if this endpoint was accessed by unauthorized parties prior to discovery.
- Implement an approval workflow requiring an existing superadmin to grant elevated roles via an audited action.
Complete Attack Chain: Anonymous to Superadmin with Full Data Exfiltration
Description
A complete, fully unauthenticated privilege escalation chain was confirmed in production. An anonymous attacker with no prior credentials can achieve superadmin access to the platform in three steps totaling under 60 seconds, then exfiltrate all platform data.
What Was Exposed
The attack chain was fully executed during the assessment. A test account was registered, promoted to superadmin, and used to enumerate all platform users, access sensitive records, and confirm write access to administrative endpoints.
Business Impact
Full platform compromise: access to all user PII, sensitive health or personal records, institution configurations, and administrative database operations. The superadmin JWT obtained grants access to every /api/v1/admin/* endpoint without restriction.
STEP 1 — Self-register (no auth):
POST /api/v1/auth/register
{"email":"watchowl-test@proton.me","password":"[REDACTED]"}
→ HTTP 201 Created
STEP 2 — Promote to superadmin (no auth):
POST /dev/promote-to-superadmin?email=watchowl-test@proton.me
→ HTTP 200: {"success":true}
STEP 3 — Login and access all users:
GET /api/v1/admin/users
Authorization: Bearer [SUPERADMIN-JWT-REDACTED]
→ HTTP 200: {"users":[... [REDACTED] records with full PII ...]}Remediation
- IMMEDIATE: Disable
/dev/promote-to-superadminon production. This single action breaks the chain. - SHORT TERM: Implement server-side authorization on all
/api/v1/admin/*endpoints. - SHORT TERM: Add email verification before any account can be used or promoted.
- LONG TERM: Implement anomaly detection to alert when any account gains superadmin privileges.
Unauthenticated Mass Exposure of Sensitive User Data via Debug Analytics Endpoint
Description
A debug analytics endpoint exposed the entire platform database — conversations, messages, emotion analytics, risk scores, and crisis alerts — in a single unauthenticated HTTP GET request downloading over 400KB of sensitive personal information.
What Was Exposed
The response contained: conversation records with titles revealing sensitive personal disclosures, full message bodies, per-message emotion analytics records with user_id attribution, topic analysis records including crisis detection, and real-time risk alerts with verbatim excerpts of user messages flagged for self-harm risk.
Business Impact
Complete unauthenticated breach of every user's most sensitive personal records. A malicious actor could identify and potentially target vulnerable individuals. Constitutes a reportable data breach under HIPAA, GDPR, and applicable national data protection laws.
GET /dev/analytics-debug HTTP/2
Host: api.[REDACTED].com
(No authentication headers)
HTTP/2 200 OK — [REDACTED KB] bytes
{
"success": true,
"summary": {
"total_conversations": [REDACTED],
"total_messages": [REDACTED],
"total_emotion_analytics": [REDACTED],
"total_risk_alerts": [REDACTED]
},
"conversations": [
{"id":"[UUID-REDACTED]","title":"[SENSITIVE-REDACTED]",...},
...
],
"risk_alerts": [
{"risk_level":"critical","risk_score":0.95,
"description":"[SENSITIVE-CONTENT-REDACTED]",...}
]
}Remediation
- IMMEDIATE: Take the debug analytics endpoint completely offline.
- Assess server logs to determine if unauthorized access occurred prior to this assessment.
- Initiate breach notification assessment per applicable regulatory requirements.
- Implement data classification — tag sensitive user-generated content as highest sensitivity tier with additional access controls and audit logging.
Critical Mass Assignment: Self-Registration as Platform Superadmin
Description
The user registration endpoint accepted a user-supplied role field without any server-side validation. Any anonymous visitor could register a new account with role: superadmin in the request body, and the server persisted that role directly to the database. This finding is independent of all /dev/* endpoints — the standard public registration API is itself the attack vector.
What Was Exposed
The resulting JWT and server-side /me profile both returned role: superadmin, confirming server-side persistence. The superadmin account then successfully accessed all administrative endpoints including full user records, institution configurations, and sensitive data endpoints.
Business Impact
Any anonymous internet user can register as superadmin in a single unauthenticated API call and immediately gain full control of the platform. This vector requires no knowledge of debug endpoints, making it independently exploitable even after /dev/* endpoints are removed.
POST /api/v1/auth/register HTTP/2
Host: api.[REDACTED].com
Content-Type: application/json
{"email":"attacker@evil.com","password":"[REDACTED]",
"role":"superadmin","full_name":"Attacker"}
HTTP/2 201 Created
{"email":"attacker@evil.com","role":"superadmin","id":"[UUID-REDACTED]"}
# Server-side /me confirmation:
GET /api/v1/auth/me → {"role":"superadmin"} ← persisted in DB
# Admin access confirmed:
GET /api/v1/admin/users → HTTP 200 — [REDACTED] user records
GET /api/v1/admin/institutions → HTTP 200 — [REDACTED] institutionsRemediation
- IMMEDIATE: Remove the
rolefield from the UserCreate registration schema. Role assignment must NEVER be accepted from user-supplied input during self-registration. - New users must always receive
role: userserver-side, regardless of request body content. - Add an allowlist of user-writable fields to the registration handler and reject any extra fields.
- Audit all PATCH/PUT endpoints for similar mass assignment vulnerabilities.
- Add integration tests verifying that role escalation through registration is impossible.
One missing CI/CD gate. Two compounding bugs.
All seven findings share a single root cause: development and debug endpoints were deployed to production without authentication. This is a process failure — specifically a missing deployment gate in the CI/CD pipeline.
The secondary root cause is mass assignment in the registration endpoint, a common vulnerability in applications that use ORM frameworks without an explicit field allowlist.
- →Fast-moving development teams often use
/dev/*routes for convenience during testing. - →Without automated checks, these routes get deployed to production unintentionally.
- →ORM frameworks like SQLAlchemy, Prisma, or TypeORM will persist any field provided unless explicitly blocked.
- →The combination of open registration + mass assignment + exposed dev routes creates compounding risk.
Four changes close 100% of these findings.
These four changes are straightforward to implement and require no architectural redesign. They can be completed in hours.
Remove all /dev/* endpoints from the production build.
Remove /run-migrations-emergency and /reset-database-emergency from production.
Remove the role field from the user registration schema.
Add a CI/CD check that blocks deployment if /dev/* routes are detected in production code.
Prevention of regulatory fines.
The critical findings in this report — particularly F-004 (unauthenticated mass exposure of sensitive user data) and the overall platform compromise chain — confirm a systemic failure to protect sensitive personal and health information (PHI/PII). Had these vulnerabilities been exploited, the client would have faced mandatory reporting and severe financial penalties under applicable data privacy regulations. By identifying and validating this complete breach path, Watch Owl Labs provided the client with the immediate actionable intelligence necessary to avert a catastrophic, reportable data breach.
The cost of a security engagement is demonstrably minimal compared to the potential fines and reputational damage prevented by the timely discovery of these critical flaws. Our report allows the client to implement the necessary four remediation steps immediately, bringing their platform back into compliance and preventing a multi-million dollar regulatory event.
Want findings like this in your stack?
Watch Owl Labs runs offensive security engagements for fintech, healthtech, and AI companies. Typical engagement: 5 business days, time-to-first-critical under 30 minutes. Findings come with working HTTP proof and remediation guidance.