Allocation of Resources Without Limits or Throttling in psi-4ward/psitransfer


Reported on

May 26th 2021

✍️ Description

Hi, with PsiTransfer we can upload files and protect them with a password. However, there is an IDOR that let an attacker retrieve arbitrary files and get the AES encrypted data of these files. All is left is to perform an offline bruteforce to crack the password of this file and get the associated metadata of this file and to get the direct link like /files/sid++UUIDv4

If you protect a file with a password and you want to access it using : http://localhost:3000/2507a65aac91 you have to enter the correct password associated with the file in order to access the metada containing the direct link http://localhost:3000/files/2507a65aac91++dff0ccf6-4bef-4ab5-aef1-3e5da03f8926

Under the hood, the client is sending a request to retrieve http://localhost:3000/2507a65aac91.json which is publically accessible as long as we guessed the 6 bytes sid. Then an attacker can download the file and easily bruteforce the password.


app.get(`${ config.baseUrl }:sid`, (req, res, next) => {
  if (req.url.endsWith('.json')) {
    const sid = req.params.sid.substr(0, req.params.sid.length - 5);
      items: db.get(sid).map(data => {
        const item = Object.assign(data, { url: `${ config.baseUrl }files/${ sid }++${ data.key }` });
        if (item.metadata.password) {
          return AES.encrypt(JSON.stringify(data), item.metadata.password).toString();// IDOR
        } else {
          return item;
  } /**/

πŸ•΅οΈβ€β™‚οΈ Proof of Concept

http://localhost:3000/2507a65aac91 require a password

http://localhost:3000/2507a65aac91.json doesn't require a password, offline bruteforce is possible

πŸ’₯ Impact

Attackers could have the ability to crack the passwords of the protected files and retrieve the direct URL of the protected files and download them.


You should perform the decryption in the server side, that way, users can't access the encrypted data of other users.

Jamie Slome has marked this vulnerability as not applicable 2 years ago

Comments from maintainer:

You can limit the filesize but not the amount of buckets - thats correct. Probably one would create a PR for that?

In my opinion this is not really a security issue but more a vector for a DoS. Could also be solved on server-side (ie use a mount with limited space)

The disclosure bounty has been dropped
The fix bounty has been dropped
The researcher's credibility has decreased: -5
2 years ago


There was a little misunderstanding, the issue was reopened. And the maintainer submitted a PR ( regarding this issue

2 years ago


Jamie Slome
2 years ago

Thanks for the heads up @zer0h-bb πŸ‘

@psi-4ward - would you like me to re-open this report, so it can be marked as a legitimate security issue?

2 years ago


yes please, it case of buckets with long retention time and the probability of weak passwords the change should give more security

Jamie Slome
2 years ago

Report re-opened πŸ‘

Christoph Wiechert modified the Severity from High (7.4) to Medium (6.6) 2 years ago
The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
Christoph Wiechert validated this vulnerability 2 years ago
zer0h-bb has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Christoph Wiechert marked this as fixed in v2.1.0 with commit 1aeb6f 2 years ago
Christoph Wiechert has been awarded the fix bounty
to join this conversation