Offensive security research lab
We find the paths
scanners miss.
Finding alerts is easy. Proving what is actually exploitable is the research. RootXLabs discovers and validates real attack paths across applications, AI systems, cloud infrastructure, open-source software and emerging technology.
- CVEs assigned
- 5 CVEs assigned
- Vendors that acknowledged findings
- 8 vendors acknowledged
- Bugcrowd global rank
- Bugcrowd #700 globally
Research • Exploit validation • Attack-path analysis
[ How we think ]
Finding patterns is easy.
Understanding the exploit chain is the research.
A scanner stops at the signal. We keep going — through the context it sits in, the trust boundary it crosses, and the chain that turns a handful of individually weak behaviours into something with real impact. Only the last step is worth an engineer's attention.
- 1
Signal
A scanner alert, an odd response, an assumption in the docs. On its own it means nothing.
- 2
Context
Where does it sit? What calls it, what trusts it, what runs with more privilege than it should.
- 3
Trust boundary
The line the design assumes an attacker cannot cross. Most real bugs live in how that line is enforced.
- 4
Exploit chain
Weak behaviours, linked. One reachable from the next, until the sequence reaches something that matters.
- 5
Real impact
Data read, identity assumed, control gained — reproduced safely, with the exact steps to reproduce it.
[ Capabilities ]
Research across the modern attack surface
Five domains, one method: understand the architecture, find the trust boundary, and prove the path across it. Each surface breaks differently — the reasoning that reaches the bug does not.
Application security
Complex web apps, APIs, authentication and the business logic underneath — where a request that is individually valid becomes an exploit in sequence.
- Authentication & session logic
- Authorization & tenant isolation
- Business-logic abuse
- API & GraphQL surface
AI security
LLM applications and agentic systems, where the trust boundary moves at runtime — a model decides which tool to call, and the tool reaches an internal system.
Cloud security
IAM, service boundaries and identity chains — how a single over-scoped role or a reachable metadata endpoint turns one foothold into everything.
Open-source security
Source audits, dependency chains and package ecosystems — reading the fix as carefully as the bug, because the patch is where the next variant hides.
Emerging technology
Browsers, desktop apps, devices and firmware — new attack surfaces where the trust model is still being written, and the interesting bug is architectural.
[ Research methodology ]
From attack surface to proven impact.
The same five moves on every engagement, whatever the surface. No step is skipped, because the interesting bug almost always lives in the one a checklist would skip.
Map
Understand the architecture, assets, identities and exposed surface — the system as it actually is, not as the diagram claims.
Reason
Identify the trust assumptions, authorization boundaries and behaviours that are individually odd but not yet exploitable.
Chain
Connect weak behaviours into a path an attacker could actually walk — each step reachable from the one before it.
Validate
Reproduce the issue safely on a clean build, with a negative control proving the vulnerable path is the one that fired.
Report
Deliver a reproduction a triager can re-run cold, the realistic impact, and the remediation — no CVSS theatre.
[ Signal over noise ]
Less noise.
More proof.
A scanner hands you a queue and calls it a result. We hand you the two or three chains that actually reach something, each one walked end to end. The rest was never the work.
Every dot is someone's afternoon: open it, decide if it's reachable, decide if it matters. Most are neither.
- 1Public endpointinternet-facing
- 2Authorization gaptrust boundary
- 3Internal servicenot meant to be reachable
- 4Privilege boundaryrole escalation
- 5Sensitive operationproven impact
[ Security research ]
Research that survives real-world validation.
Findings reported by RootXLabs and confirmed by the vendor. Published advisories link to their CVE record; work still under coordinated disclosure is listed only once a fix has shipped.
RXL-2026-002
CVSS 7.4
Microsoft
PowerShellPublished advisory. Technical detail is on the linked CVE record.
RXL-2026-001
CVSS 7.8
Microsoft
PowerShellPublished advisory. Technical detail is on the linked CVE record.
RXL-2026-003
High
AXIS Communications
Camera StationAdvisory details withheld by the reporter.
RXL-2026-004
CVSS 6.5
Apple
WebKitPublished advisory. Technical detail is on the linked CVE record.
RXL-2026-005
CVSS 8.8
Microsoft
PowerShellPublished advisory. Technical detail is on the linked CVE record.
Coordinated disclosure on every finding · No detail published that would help reach an unfixed system.
[ Hall of Fame ]
Research acknowledged by the organizations that ship it
Every logo below is an organization that independently reproduced a RootXLabs finding and credited it — the calibre of software our research holds up against. Not customers, not endorsements: acknowledgements, which are not ours to award.
[ Research areas ]
The classes we go deep on
Not a taxonomy for its own sake — these are the bug classes where the gap between “a scanner flagged it” and “it is exploitable” is widest, and where careful reasoning pays off.
[ Attack-path demo ]
One weakness rarely tells the whole story.
A mock environment. Walk the chain — each node is a step an attacker takes, and the same node reads differently depending on where you are standing. Hover, tap, or step through it.
Public API
edge · internet-facing
- Entry point
- An unauthenticated endpoint that echoes a request parameter into a downstream call.
- Observation
- The gateway forwards a client-supplied identifier without re-checking who the caller is.
- Trust assumption
- “The internal service trusts anything that reached it through the gateway.”
- Exploit primitive
- Request forgery into the internal network path.
- Impact
- Foothold: the attacker can now speak to services never meant to be reachable from outside.
[ Who we work with ]
When tooling reaches its limit,
deeper reasoning begins
The teams we do our best work with have already automated the easy part. What is left is the reasoning a scanner cannot do — and that is the whole job.
Engineering teams
Shipping fast on a surface that outgrew the last review. You want to know what an attacker reaches, not a list of linter warnings.
Security teams
Already running the scanners. You need a second set of hands for the exploit chains automation cannot reason about.
AI companies
Models wired to tools and internal systems. The trust boundary moved at runtime and the old threat model no longer covers it.
Cloud-native platforms
Identity chains, service meshes and metadata endpoints, where one over-scoped role is the whole attack path.
Open-source maintainers
A patch that needs a second reader, or a report that arrived and you want it validated before you act on it.
Product security teams
Browsers, desktop apps, firmware — surfaces where the interesting bug is architectural and needs a manual eye.
[ Engagements ]
Three ways to put us on your surface
Whether you need one hard question answered or a standing adversary who tracks your surface as it changes, the method is the same and the output is proof.
Offensive security assessment
We take a defined target and attack it the way a motivated adversary would — architecture first, then the chains. You get validated attack paths and reproductions, not a scanner export.
- Web, API, cloud, AI or native scope
- Attack-path reasoning, not checklists
- Every finding reproduced safely
- Remediation guidance that fits your stack
Security research
Deep research against a specific product, protocol or dependency — source audit, patch analysis, variant hunting — carried through to a working proof and coordinated disclosure.
- White-box source review
- Patch-bypass & variant analysis
- Working proof-of-concept
- Disclosure handled end to end
Continuous research partnership
An ongoing relationship where we track your surface as it changes — new services, new models, new dependencies — and keep pressure-testing the boundaries between them.
- Recurring, scoped engagements
- Coverage that follows your roadmap
- Named point of contact
- Findings routed where your team works
[ Responsible research ]
Credibility, not certification theatre
We hold access to systems that would hurt if we were careless with them. These are the constraints the work runs under — no badges we have not earned.
Coordinated disclosure
The vendor hears first, always. Nothing is published that would help someone reach a system still running the vulnerable version.
Evidence-driven findings
A finding is not a finding until it reproduces. If we cannot prove it, it does not leave the lab.
Manual validation
Automation reads everything; a human decides when a story is too neat. The exploit is stood up by hand.
Clear reproduction
Every report includes steps a triager can re-run cold, with a negative control showing which path actually fired.
Impact-focused reporting
Severity is what the impact supports — not what the report would be worth if it were higher.
Secure handling of research data
Scope is sacred and access is least-privilege. We take the minimum needed to prove it, and drop it when the work is done.
[ Research notes ]
What we can show you: the method
The findings are under coordinated disclosure. The way they were produced is not — and it is the part worth judging us on.
Work with us
Have a system worth breaking before attackers do?
Tell us what you want us to look at. We will tell you honestly whether it is the kind of target our research reaches — and if it is, what a first engagement would prove.
Scoped & authorized testing only · Coordinated disclosure on every finding