Hey, amazing hackers!

My name is Momen Samir (0xmannaf). Today, I’ll be discussing four bugs that I recently found on a public target on Bugcrowd. We’ll refer to it as target.com.

I have a monitoring service that collects new subdomains for several targets and immediately notifies me when it finds one.

One day, it discovered a new subdomain on my favorite target:

https://cognitive.target.com

The first time I opened this subdomain, I realized that it looked like it had been built using vibe coding because of its styling, features, and overall design.

But before telling you about the four bugs I found, let me first explain what this subdomain is and what service it provides.

It’s a pricing research and customer intelligence platform. Its purpose is to help the company understand how customers value its products and services, how much they are willing to pay, and which product configurations or service options they prefer.

Let’s get into the findings!

F1 — Unauthenticated Persistent Study Injection in Internal Pricing Research Platform P3

The agent found an endpoint named /saveFirstForm that uses a POST request.

Normally, this endpoint creates a study from one of the 12 existing study templates (users can choose only one template at a time) so participants can provide their opinions about the company’s products.

The agent found a parameter named studyName with a value of null.

By changing this parameter to any value, the submitted name would be saved and rendered in the UI for other users as a trusted study.

But it was still low-hanging fruit, so I continued manually from there.

I found another parameter named businessJustification. Its value was displayed throughout the study process to users, and it also rendered URLs as clickable links.

For example, I could insert an attacker-controlled URL:

https://evil.com

The report was initially triaged as P4, but I contacted the customer directly and explained the impact. They updated the priority from P4 to P3.

And I got $750!

F2 — Unauthenticated Study Status Change on target Pricing Research Platform P2

After the previous bug was resolved, I went back to retest the target.

The fix was that they restricted the study creation process to specific users who received invitations from an admin. The admin would then review the study and approve or reject it.

This bug was quite simple.

The agent found an endpoint:

GET /api/conjoint-studies

It returned the studies’ data and their current statuses:

• Approved
• Rejected
• Finished
• Submitted

By changing the request method to PUT, the agent was able to change the status of any study from Approved to Rejected, an operation that required admin privileges.

The vulnerable endpoint was:

PUT /conjoint/study-status

With a request like:

{
  "FormId": "<study-id>",
  "status": "Rejected"
}

The server accepted the request and persisted the status change without requiring authentication.

I submitted the report and got $1,500!

F3 — Injection of Fake Pricing Data Into target Production Surveys P3

The agent found this bug during the same session in which it found the previous one.

As I mentioned earlier, the fix restricted the study creation process to specific users. However, participant verification was still missing.

An external user could create their own participant ID and submit responses without proving they were a legitimate survey participant.

The process involved several API endpoints:

1. Retrieve active studies

GET /api/conjoint-studies

Returns available production studies and their IDs.

2. Reserve a participant slot

POST /reservation/{FormId}

By sending an arbitrary participantId, the server returned a valid groupId without verifying the participant's identity.

3. Retrieve pricing options

GET /getTaskAndOptionByGroupId/{groupId}

Returns the pricing options associated with the reserved study.

4. Submit fabricated responses

PUT /conjoint/makeSelectedBatch

The attacker could submit their own selections using the generated groupId and participantId.

The server accepted the submission and returned:

{
  "ok": true,
  "totalRowsAffected": 18,
  "fulfilled": true
}

This confirmed that the backend had processed the submitted responses and marked the participant group as completed.

An attacker could introduce fabricated responses into legitimate research, potentially influencing pricing analysis, customer preference measurements, and other business insights derived from the collected data.

Unfortunately, this report was marked as a duplicate two days later.

F4 — Unauthenticated Access to Live Audience-Align Completion & Termination Credentials for Every Approved Pricing Study via POST /redirect P2

The agent found that the company’s pricing research platform allowed unauthenticated users to obtain valid survey completion and termination credentials for every approved study.

The first endpoint allowed us to enumerate the available study combinations:

GET /api/form-url-combinations

The vulnerable endpoint was:

POST /redirect

By providing an approved study’s formId and requesting either complete or terminate, the server returned a credential without requiring authentication or a valid participant session.

The credentials were also static: repeating the same request returned identical values.

To verify their validity, I tested them against Audience-Align’s external respondent API:

POST /webservices/user/updateRespondentData

The external platform recognized the two credential types differently:

• resstatus: 1 — Completion.
• resstatus: 2 — Termination.

I was able to obtain both credential types for all four approved studies identified during testing.

This confirmed that the credentials weren’t just arbitrary redirect values; the external platform actually recognized them.

Impact

An external attacker could obtain credentials recognized by the external survey platform as completion or termination signals, potentially allowing unauthorized interference with survey workflows and compromising the integrity of the research process.

The root cause was missing authentication and participant-level authorization when generating these credentials.

I verified the credential recognition using a dummy respondent ID; the final respondent credit or incentive state was not established.

And I got another $1,500!

in the end i can’t stop saying:

Thank god | الْحَمْدُ لِلَّهِ

Hey amazing hackers, my name is Momen Samir (0xmannaf). Today I’ll be discussing a bug that I recently found on a target on Bugcrowd. We will refer to it as target.com.

This ATO was very tricky, and I reported it twice to finally get it triaged.So happy reading

First, after fuzzing, I found a subdomain named create.target.com, but this subdomain responded with no content.

So I went to the Wayback Machine and found some URLs, and I noticed a create account URL:

https://create.target.com/flow/target/create26/register-interest/createaccount

After registering, it redirected me to the home page and it didn’t ask for verification. I tried many things here, but none of them worked.

So I stuck with the subdomain for a few days, testing the functions and trying to understand what it does. I found that this subdomain is for company events and has two user options:

1- Interest: Can see the event online for free
2- In-person: Can go to the event offline for $400

I also tried to make a privilege escalation from Interest to In-person for free, but I came up with nothing.

I was almost giveing up on this subdomain, but I looked at the URL and said, “What if I changed create26 to create25?”

It opened a 2025 event registration portal (which is an ended event). So I tried to register with the same account that I had registered with in the 2026 event, and it registered normally.

To explain it more, imagine that we have two sessions:

1- victim@gmail.com → registered with:
https://create.target.com/flow/target/create"26"/register-interest/createaccount

And the attacker, in another session, uses victim@gmail.com to register in:
https://create.target.com/flow/target/create"25"/register-interest/createaccount

Now, from the attacker session, I tried to navigate to create26 (which is a valid and working event), hoping that it would open the victim’s account. But I found that every time I tried to navigate to 26 from 25, it logged me out.

I kept digging and found that when I register the email, it takes an invalid session.

Because of that, it logs me out, but once I log in with OTP, it verifies the account and gives me access to navigate to 26 from the 25 account.

But here is the problem: as an attacker, I can’t log in using OTP because I don’t have access to the victim’s email account. So I tried to change the account email to one I control to be able to log in with OTP and verify the account, then navigate to the 2026 victim account.

To understand it more, the attacker will do the Next:

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

1- Create an account with the victim’s email address in the create25 portal (for example: victim@gmail.com)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —-
2- Change the victim account email to attacker@gmail.com to be able to verify the account using OTP login

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -
3- Navigate to Create26, and boom, the victim account is there.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

So the subdomain logic does the following:

The backend links attendee identities across events for the same email, but at the same time allows registering with the same email in the 2025 event without saying “Email already exists” or asking for authorization.

It also does not enforce ownership verification when the email address is modified in the CREATE25 profile,

Allowing an attacker to rebind the identity to a different email address, which allows them to navigate to the 2026 event and see the connected email there (the victim’s email).

But it was a third-party vendor and thanks god it’s has a private bug bounty program on bugcrow

I send the finding to thim and in 4 day i was awarded the bounty but as a P3 finding

in the end i can’t stop saying:

Thank god | الْحَمْدُ لِلَّهِ