Visma Case Study Part 2: Cross Tenant Account Takeover

In my previous disclosure, I detailed how Visma and Intigriti normalized critical data leaks. I promised I would continue to expose every report in this series until the systemic rot is laid bare. This is the second writeup, documenting a flaw that should have ended the partnership between these two entities.

The Vulnerability That Should Have Been Trivial

While the triage team was busy calling my previous reports AI hallucinations, they were actively ignoring a massive cross tenant account takeover vulnerability.

The flaw existed in the user creation and activation flow at ai-testing.maventa.com. By manipulating the company_id parameter in a POST request to /users/create, an authenticated user from one company could create and activate a user inside an entirely different company.

Reproduction Steps:

• Login as a user in Company A.
• Intercept the POST request to /users/create.
• Modify the request body by replacing the company_id with the target company UUID.
• Send the request.

The server returned a 200 OK and processed the request without ever validating that the company_id belonged to the authenticated user. The created user was immediately associated with the target tenant with administrative privileges.

The Administrative Gaslighting

When I provided clear reproduction steps, including specific account examples and the exact request manipulation required, the response from xsox_visma was not a fix, but a demand for more information, despite the vulnerability being fully reproducible. They claimed my PoC was unclear because of supposed domain confusion and email mismatches, which were nothing more than desperate attempts to avoid validating a critical flaw.

They did not want a fix. They wanted an excuse to archive the report.

Alexander Wren and the Culture of Corruption

Let us be clear about who is protecting these programs. Alexander Wren, the Head of Hackers at Intigriti, has built a career on pretending to champion researcher interests while acting as a corporate shield.

After months of Visma begging Alexander Wren to ban me, he finally did. My attempts to resolve this professionally were met with absolute silence. I tried reaching out to him directly on the Intigriti Discord server, but he refused to reply. He only engaged when his moderators and admins were present to insulate him. When forced to acknowledge my presence, Wren dodged every technical question and accountability point I raised, ultimately banning me from the server to silence the truth.

Wren did not talk to the developers about this report. He did not talk to them about any of the reports other the report in the first disclosure . He checked out the moment the first report hit his desk and chose to defend the vendor rather than the security of their thousands of clients. By refusing to enforce the basic requirements of independent log audits and technical verification, Wren is not just failing his job; he is complicit in the culture of negligence that defines Intigriti triage.

When the Head of Hackers refuses to intervene in obvious cases of administrative malpractice and hides behind a ban hammer, he is effectively endorsing the corruption of the entire platform.

Why This Matters

This is not a theoretical bug. It is a fundamental break in tenant isolation that allows for persistent unauthorized access to administrative functions.

I am moving forward with this named disclosure series because Visma and Intigriti have made it impossible to achieve a professional resolution. They patched in silence and hoped I would go away. Instead, I am documenting their failures for the entire industry to see.

The audit logs exist. The architectural flaws are documented. And the industry now has the blueprint for how these programs operate when they think no one is watching.

If you require proof of these claims or want to discuss the findings in detail, reach out to me directly on Element: @pwnedl0l:matrix.org.