PRATIMĀNA SECURITY — offensive testing, measured to a standard

Every attack surface has an edge.
We measure exactly where it is.

Pratimāna Security runs the same calibrated methodology across pen testing, red teaming, and product security — so what comes back is a senior-reviewed, exploit-verified baseline. Not a scanner printout with a logo on it.

PMS‑2026‑0142 High Sample · redacted
CVSS 8.6CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Authentication bypass on the API gateway permits full account takeover

Asset
https://api.redacted.example/v2/session/refresh
Reproduction
  1. Authenticate as a low-privilege test account and capture the refresh token.
  2. Replace the sub claim with the target account identifier; leave the signature intact.
  3. Replay to the refresh endpoint. A valid access token is returned for the target account.
Re-test
✓ Confirmed closed — re-tested 9 days after fix, no charge
Read the full finding
Summary
The refresh endpoint validates the signature of the supplied token but never checks that the subject claim matches the session presenting it. Any authenticated user can mint a valid access token for any other account.
Impact
Verified end to end against a seeded test account: full read and write access to another tenant's data, including billing records. Exploitable without user interaction from the public internet.
Remediation
Bind the refresh token to the authenticated session server-side and reject any token whose subject does not match. Patch and rotation guidance supplied with the finding.
Services

What we test, and which service covers it.

Find what you need tested in the first column. The service lines to its right are the ones that cover it.

What you need testedPentest as a ServiceRed Teaming as a ServiceProduct Security as a Service
Web applicationsWeb Application Penetration Testing——
Mobile applicationsMobile Application Penetration Testing——
APIsAPI Penetration Testing——
Thick-client applicationsThick Client Application Penetration Testing——
NetworksNetwork Penetration Testing——
IoT devicesIoT Device Penetration Testing——
Cloud configuration——Cloud Security Assessment
Source code——Secure Code Review
Build and release pipeline——DevSecOps
Detection and response—Internal Red TeamingExternal Red Teaming—
Across every release——Vulnerability ManagementContinuous Penetration Testing

Pentest as a Service

Manual, hacker-led penetration testing that goes beyond what a scanner catches — every engagement is scoped, exploited, and verified by a senior tester before a finding reaches your report.

Red Teaming as a Service

A full-scope, adversary-style simulation that tests whether your team can actually detect and respond to an intrusion — not just whether a vulnerability exists on paper.

Product Security as a Service

Security built into how your product ships — from source code to cloud configuration — so issues are caught before release, not discovered after.

The method maps to the frameworks your auditors and your engineers already recognise:

OWASP WSTG OWASP MASVS MITRE ATT&CK PTES NIST SP 800-115 CVSS v4.0
The methodology

Every finding here was earned by hand.

Scanner output is where our work starts, never where it ends. A senior tester maps the surface, exploits the issue to prove it is real, then comes back and re-tests the fix. Anything that fails that path does not reach your report.

01 — SCOPE

Baseline the attack surface

Every asset in scope is mapped and measured first — endpoints, entry points, and trust boundaries — so nothing gets tested blind.

02 — EXPLOIT

Prove impact, don't assume it

Findings are manually exploited to confirm real-world impact — not just flagged by a scanner and left for you to triage.

03 — RETEST

Close the gap, verify it's closed

Every finding ships with reproduction steps and a fix path, then gets re-tested — so a patched CVE doesn't reappear next release.

Engagement terms

Every engagement includes

  • Manual exploitation — nothing ships unverified
  • Senior tester sign-off on every finding
  • Reproduction steps your engineers can run
  • Fix guidance specific to your stack
  • A free re-test once you've patched
  • A live tracker, not a static document

Told straight

If we find nothing exploitable, the report says so — with the surface we covered and how. A clean result you can trust is worth more than a padded one.

Know your real exposure.

Talk to a Pratimāna Security engineer about your attack surface — no generic pitch, just your scope.

Worth having for the first call

  • What is in scope: domains, apps, APIs and IP ranges
  • Which environment we test, with a test account for each role
  • A testing window, and who to call if something breaks
  • Anything that is off limits, in writing