Unauthenticated self-registration on ████████ grants full access to internal supplier procurement portal and vendor data

How it was found

Summary:

The program i open scope so i did ASN enumeration and found the following subdomains is owned by Essity ████████ . while checking the JavaScript file found that there is endpoint hidden from GUI but found in the code ████████/Account/Register . access it and found it publicly accessible and fully functional , despite not being linked from the login page or any other part of the application. It requires no invitation, no approval, no client or supplier code, and performs no verification that the registrant is affiliated with Essity or with an existing supplier.

Using hackerone alias email i was able to register account and access the fully website

The application's own API calls fired automatically on login: GET /vendor/Vendors returned HTTP 200 with a JSON array of real vendor numbers and names, confirming that the account is not sandboxed or limited to empty data. GET /vendor/Regions and GET /vendor/definitions also returned live data.

This means any unauthenticated party on the internet can provision themselves an account on an internal Essity procurement system and read supplier data.

Steps To Reproduce:

[add details for how we can reproduce the issue]

1. Navigate directly to ████████/Account/Register

   Note: this page is not linked from the login page at /Account/Login, nor from anywhere else in the application. It was discovered by requesting standard ASP.NET Identity controller routes directly. The endpoint returns HTTP 200 and serves a fully functional registration form.

2. Complete the form with arbitrary values. No email domain restriction, supplier code, invitation token, or approval step is enforced. The values I used:

   Email: [email protected] First Name: Ouss Last Name: ki Phone Number: (arbitrary digits, not validated against any record) Company Name: HackerOne Security Research

   Submit the form.

3. A confirmation email is delivered from ████████ containing a link to /Account/ConfirmEmail?userId=<guid>&code=<token>. Open it. The application responds with "Thank you for confirming your email."

The account is now active. Note that the registration form contains no password field, so the account exists without credentials at this point.

4. Navigate to /Account/ForgotPassword, enter the same email address, and submit. A password reset email is delivered.

5. Open the reset link and set a password via /Account/ResetPassword.

6. Log in at /Account/Login with the email and the password set in step 5. Result: authenticated session on the ████████. The header displays "Welcome Ouss from HackerOne Security Research" — the values supplied at registration, with no vetting applied. The navigation bar exposes Home, Purchase Orders/Deliveries, Payments, Blanket Orders, and Glossary, plus a "Purchase Order #" search field.

7. Observe the application's own XHR calls in proxy history, issued automatically on login with no further interaction:

   GET /vendor/Vendors → 200, application/json, 1719 bytes GET /vendor/Regions → 200, application/json GET /vendor/definitions → 200, application/json GET /release/statuses → 500, text/html, 4391 bytes

   /vendor/Vendors returns a JSON array of live vendor records in the form [{"VendorNumber":"<redacted>","VendorName":"<redacted>"}, ...], confirming the account is granted real data access rather than an empty or sandboxed view.

Supporting Material/References:

████████

████████

████████

Impact

Any unauthenticated party on the internet can provision themselves a working account on an internal Essity procurement system, with no invitation, no approval, no supplier code, and no verification of affiliation. The only requirement is access to an email inbox.

An attacker with a supplier-facing account could also use it as a credible pretext for social engineering against Essity procurement staff, or against the suppliers whose identities the portal discloses.

The resulting account is not sandboxed. On login, the application's own API returned live vendor records (GET /vendor/Vendors, HTTP 200, JSON array of vendor numbers and names), along with reference data from /vendor/Regions and /vendor/definitions. The portal interface exposes Purchase Orders/Deliveries, Payments, and Blanket Orders, plus a Purchase Order search that queries the backend a search I submitted returned "please narrow your search," indicating the query reached a populated data set rather than an empty one.

I want to be precise about what I did and did not establish: I confirmed that vendor data is returned to a self-registered account, by observing the application's own automatic API calls. I did not browse, search, export, or open any records, and I did not test for write access or authorization flaws on any endpoint. The impact described above is based on what the application itself surfaced within seconds of login.