Recently, while testing the application's role-based access control, I discovered an interesting authorization flaw that allowed a ReadOnly user to download sensitive exports that had been created earlier while the same account had Vault Admin privileges.

The issue wasn't about creating a new export.

It was about what happened after the user's permissions changed.

Understanding the Permission Model

The application organizes data inside Vaults, where users can have different roles such as:

Vault Admin ReadOnly

A Vault Admin can generate and download ELN exports containing data from the vault.

A ReadOnly user, however, should never be able to export or download those files.

That sounded straightforward…

…until I started testing what happens after a privilege downgrade.

The Idea

Whenever I test role-based permissions, I don't only verify whether a lower-privileged user can access an endpoint.

I also ask another question:

What happens if permissions change after sensitive resources have already been created?

Many applications validate permissions when creating a resource but forget to validate them again when the resource is later accessed.

This is exactly the scenario I wanted to test.

I prepared two accounts.

Account A >>> Vault Owner/Admin

Account B >>> Initially assigned the Vault Admin role

Using Account B, I navigated to the ELN entries page and generated an export.

Once the export finished processing, clicking Download triggered a request similar to:

GET /orgs/{org_id}/exports/{export_id}

Instead of downloading the file directly, the application responded with an HTTP 302 Redirect pointing to a temporary Amazon S3 pre-signed URL.

At this point everything looked completely normal.

Changing the User's Role

Now came the interesting part.

Using Account A, I downgraded Account B from:

Vault Admin to ReadOnly

At this point I expected every download attempt to fail because the account no longer had permission to access exports.

Instead of generating a new export, I simply replayed the previously captured request.

GET /orgs/{org_id}/exports/{export_id}

Unexpectedly…

The server returned another 302 Redirect.

The redirect contained a brand-new Amazon S3 pre-signed URL.

Although the signature changed every time, opening the new URL successfully downloaded the complete export ZIP file.

The user's current role was ReadOnly, yet the download still succeeded.

Root Cause

The backend verified permissions only when the export was created.

When downloading the export later, the application failed to verify whether the requesting user still had permission to access it.

Instead, it generated a fresh S3 pre-signed URL solely because the user knew the export identifier.

In other words:

• Permission was checked during export creation. — Permission was not checked during export download.

This created an authorization gap whenever user privileges changed.

Security Impact

• Exposure of confidential ELN records. — Continued access after privilege revocation. — Bypass of role-based authorization. — Potential compliance issues involving regulations such as GDPR or HIPAA.

The vulnerability effectively allowed sensitive data to remain accessible even after administrative access had been revoked.

Happy Hacking ! Special thanks to Yahya Hammam for discovering this vulnerability and writing the original research behind this article.