Post cover image

September 13, 2026

An Email Address Was Enough to Act as Another User —Vulnerability or Acceptable Risk?

How an unauthenticated marketplace API trusted an email address as account authority — and why the resulting authorization flaw was…

By PaulHaykeens

16 min read

How an unauthenticated marketplace API trusted an email address as account authority — and why the resulting authorization flaw was ultimately left unfixed.

I promise, this is one of the more interesting findings I've investigated.

Grab a drink, get some popcorn, and settle in. 🍿

What looked like a simple information-disclosure issue took me somewhere I genuinely wasn't expecting.

It's going to be an interesting journey.

Disclosure Note:

This article describes security research performed during an authorized bug bounty assessment.

The affected organization, application hostname, report identifiers, real account details, customer information, object identifiers, and unnecessary infrastructure details have been intentionally omitted or generalized.

All cross-account testing described in this article was performed using accounts under my control and benign test content. Test marketplace objects were closed after sufficient evidence had been collected.

**Introduction (**It Started With a Few Public APIs)

Some vulnerabilities look insignificant when viewed one endpoint at a time. It Started as an Information-Disclosure Investigation, some vulnerabilities look insignificant when viewed one endpoint at a time.

An unauthenticated API returning marketplace listings might be information disclosure.

An endpoint revealing whether an email belongs to a particular account type might be account enumeration.

An endpoint allowing anonymous marketplace submissions might simply be an abuse or spam problem.

But security research becomes more interesting when you stop asking:

What does this endpoint do?

and start asking:

What happens when these behaviors interact?

That shift in perspective changed this investigation completely.

What began as research into several publicly accessible API endpoints eventually led to a much more interesting observation:

An unauthenticated requester could create an active marketplace job and have it attributed to an existing publisher account without authenticating as that publisher or demonstrating control of the associated email address.

No publisher password.

No publisher session.

No authorization token.

The requester only needed to supply an email address.

And the backend did the rest.

1. Understanding the Marketplace

Before discussing the API, it's important to understand what the application actually sells.

The affected platform operates as a two-sided service marketplace.

Customers publish jobs for renovation, repair, construction, and related services.

Professionals operating within relevant regions discover those opportunities and can pursue potential customers.

At a simplified level:

Publisher / Customer
        │
        │ creates job
        ▼
     Marketplace
        │
        │ regional distribution
        ▼
Professional / Contractor
        │
        │ pays for access to
        │ relevant opportunities
        ▼
Potential Customer

Contractors are not simply browsing an unrestricted collection of public posts.

Access to relevant regional jobs forms part of the marketplace's commercial service.

Contractors pay to access those opportunities.

That means the marketplace isn't selling only software functionality.

It is also selling access to something much more valuable:

Potentially genuine customer demand

Conceptually:

Real publisher
      │
      ▼
Genuine job request
      │
      ▼
Marketplace
      │
      ▼
Regional opportunity
      │
      ▼
Contractor pays for access

If unauthorized or fabricated jobs can enter that same pipeline, content integrity becomes directly connected to the platform's business model.

That distinction became central to the investigation.

2. Mapping the Public Attack Surface

I started by examining the application's API rather than assuming that the visible web interface represented the complete security boundary.

Several operations existed beneath a public namespace similar to:


/public/*

One endpoint returned marketplace task information without requiring authentication:

GET /public/tasks
None

No authorization header.

No authenticated session.

No account was required.

Individual marketplace records could also be queried.

A generalized response looked something like:

```json
{
  "taskUid": "[REDACTED]",
  "title": "Example marketplace request",
  "place": {
    "postalCode": "[REDACTED]",
    "placeName": "[REDACTED]"
  },
  "state": "CLOSED",
  "createdAt": "[REDACTED]",
  "expires": "[REDACTED]",
  "maxNumberOfOffers": 10
}

The API exposed a substantial collection of marketplace records.

Initially, this looked like information disclosure (CWE-200).

But there was an important limitation.

A meaningful portion of the returned information was already intended to be visible through the public marketplace.

Calling all of it sensitive would therefore have overstated the confidentiality impact.

So I kept looking.

### 3. Contractor Information Was Public Too

Another operation exposed structured contractor information:

```go
```http
GET /public/contractors

Again, authentication wasn't required.

<picture>
  <source media="(max-width: 768px)" srcset="/img/medium/700/1*njujdEIFONe63IZOAFnyvw.png 1x">
  <source media="(min-width: 769px)" srcset="/img/medium/2000/1*njujdEIFONe63IZOAFnyvw.png 1x">
  <img src="/img/medium/700/1*njujdEIFONe63IZOAFnyvw.png" alt="None" width="1918" height="865" loading="lazy" data-zoom-src="/img/medium/4000/1*njujdEIFONe63IZOAFnyvw.png" class="prose-image"/>
</picture>

Depending on the record, responses contained attributes relating to contractor profiles, categories, geographic coverage, account metadata, and business/contact information.

Some of this information overlapped with publicly available contractor profiles.

That limited the standalone confidentiality impact.

But it raised a more interesting question:

> How does the application use account identity elsewhere in the public API?

That led to another endpoint.

### 4. An Account-Role Oracle(Enumeration-endpoint)

An account-related public endpoint accepted an email address.

Conceptually:

```bash
```http
POST /public/account
Content-Type: application/json
{
 "email": "researcher-controlled@example.com",
 "password": ""
}

The application's behavior changed depending on whether the supplied email already belonged to an account.

For certain existing accounts, the response explicitly indicated that the account existed and revealed its role.

Conceptually:

```go
```text
Unexpected existing account [REDACTED]
with role=CONTRACTOR

That meant an unauthenticated requester could potentially distinguish certain account types.

<picture>
  <source media="(max-width: 768px)" srcset="/img/medium/700/1*pHsajrgOAtYwpJOAf0UmTg.png 1x">
  <source media="(min-width: 769px)" srcset="/img/medium/2000/1*pHsajrgOAtYwpJOAf0UmTg.png 1x">
  <img src="/img/medium/700/1*pHsajrgOAtYwpJOAf0UmTg.png" alt="None" width="936" height="722" loading="lazy" data-zoom-src="/img/medium/4000/1*pHsajrgOAtYwpJOAf0UmTg.png" class="prose-image" data-caption="Account Enumeration Endpoint"/>
</picture>

At this point I had several observations:

```vbnet
```text
/public/tasks
 │
 └── marketplace information
/public/contractors
 │
 └── contractor information
/public/account
 │
 └── account / role enumeration

None of those became the main finding.

Instead, they led me to ask another question:

> Which public operations can actually change marketplace state?

### 5. Can an Anonymous User Create a Job?

The API exposed task-creation functionality:

```go
```http
POST /public/tasks

That immediately raised an obvious question.

> **_If tasks can be read anonymously, can they also be created anonymously?_**

My initial requests didn't immediately result in active marketplace jobs.

Some objects remained in what appeared to be an incomplete or review-like state.

That was useful information.

It suggested the backend implemented some kind of completeness gate before a job entered the marketplace.

It also meant that simply receiving:

```go
```http
HTTP 201 Created

wasn't sufficient evidence of meaningful impact.

So I compared my request with the legitimate task-creation workflow.

Several fields were relevant to constructing a complete marketplace submission, including task description information, category selection, execution details, attachments, offer configuration, and publisher information.

Then one structure caught my attention:

```bash
```json
"publisherAccountCreate": {
 "firstName": "…",
 "lastName": "…",
 "phone": "…",
 "email": "…"
}

That produced the question that changed the investigation:

> **_What happens if the email already belongs to an existing publisher?_**

### 6. Testing the Authorization Boundary

For this test, I used a publisher account under my control.

I submitted a task-creation request without authenticating as that publisher.

There was no:

```go
```http
Authorization: Bearer [token]

There were no publisher session cookies.

There was no authenticated principal connecting the request to the publisher account.

Instead, the request contained:

```bash
```json
"publisherAccountCreate": {
 "email": "controlled-publisher@example.com"
}

The server accepted it:

```http
HTTP/2 201 Created

and returned a response similar to:

```json
{
 "taskUid": "[REDACTED]",
 "accountAlreadyExists": true,
 "conversionValue": null
}

That was interesting.

But it wasn't proof.

**_`accountAlreadyExists: true`_** demonstrated that the backend recognized the email address.

It didn't establish that the resulting job had actually been attributed to that account.

So I authenticated normally to my controlled publisher account and checked.

The new task was there(whoaaaaah!!!).

<picture>
  <source media="(max-width: 768px)" srcset="/img/medium/700/1*g1IppDlO2JhdsDExLCgLgw.png 1x">
  <source media="(min-width: 769px)" srcset="/img/medium/2000/1*g1IppDlO2JhdsDExLCgLgw.png 1x">
  <img src="/img/medium/700/1*g1IppDlO2JhdsDExLCgLgw.png" alt="None" width="937" height="898" loading="lazy" data-zoom-src="/img/medium/4000/1*g1IppDlO2JhdsDExLCgLgw.png" class="prose-image"/>
</picture>

The publisher associated with the task corresponded to the account whose email had been supplied in the unauthenticated request.

That established the authorization failure.

### 7. The Backend Knew the Account — But Not the Requester

Conceptually, the backend appeared to be doing something similar to:

```go
```text
Client supplies email
 │
 ▼
Backend searches accounts
 │
 ▼
Existing publisher found
 │
 ▼
Create marketplace task
 │
 ▼
Associate task with publisher

The missing security decision was:

```vbnet
```text
Existing publisher found
 │
 ▼
WHO IS MAKING THIS REQUEST?
 │
 ▼
ARE THEY AUTHORIZED
TO ACT AS THIS PUBLISHER?

An email address answers:

> Which account?

It does not answer:

> Who is authorized to act as that account?

That distinction is the heart of the vulnerability.

### 8. Account Creation and Account Attribution Are Not the Same Thing

This distinction matters because anonymous marketplace submission may itself be intentional.

Consider two scenarios.

#### Scenario A — New visitor

An unauthenticated visitor provides an email that doesn't belong to an existing publisher.

The platform creates some form of new account or pending publisher state as part of its onboarding workflow.

Depending on the application's design, that may be completely intentional.

Now consider:

#### Scenario B — Existing publisher

An unauthenticated visitor supplies an email belonging to an **existing publisher**.

The backend recognizes the account and associates the resulting marketplace activity with it.

The requester provided:

```yaml
```text
No password
No authentication token
No publisher session
No demonstrated email ownership

Yet the task became activity belonging to that existing publisher.

That is fundamentally different from anonymous onboarding.

The requester isn't merely creating content.

They are causing the application to perform an action **_through another existing marketplace identity_**.

9. I Reproduced It With Another Controlled Account

One account isn't always enough to establish a pattern.

So I repeated the process using another publisher account under my control.

The behavior remained consistent:

```css
```text
Controlled publisher A
 │
 ▼
Email A supplied anonymously
 │
 ▼
Task attributed to A
Controlled publisher B
 │
 ▼
Email B supplied anonymously
 │
 ▼
Task attributed to B

Neither creation request contained an authenticated publisher session.

This reduced the likelihood that the first result was caused by some unusual account state.

### 9. Then the Job Became ACTIVE

Cross-account attribution established the authorization issue.

But there was another important question:

> What happens to the resulting job?

If it remained an inert database object requiring manual verification, the practical impact would be different.

So I observed the resulting task.

It transitioned into:

```go
```text
ACTIVE

It appeared in the controlled publisher's dashboard.

And more importantly, it entered the contractor discovery workflow.

The observed chain was therefore:

```go
```text
Unauthenticated requester
          │
          ▼
Supply existing publisher email
          │
          ▼
Backend selects publisher
          │
          ▼
Task created under publisher
          │
          ▼
        ACTIVE
          │
          ▼
Regional marketplace
          │
          ▼
Contractor discovery

The unauthenticated request had crossed two important boundaries:

```go
```text
Anonymous user
      ↓
Existing account identity
      ↓
Live marketplace activity

### 10. And Contractors Pay to Access Those Jobs

This is where understanding the business model becomes important.

Contractors pay for access to marketplace jobs available within their region.

So the normal commercial flow resembles:

```go
```text
Publisher creates genuine job
 │
 ▼
Job enters marketplace
 │
 ▼
Regional contractor discovers it
 │
 ▼
Contractor pays for access
 │
 ▼
Potential business opportunity

But the vulnerability introduced another possible source of marketplace activity:

```go
```text
Unauthenticated requester
 │
 ▼
Creates attacker-controlled job
 │
 ▼
Attributes job to existing publisher
 │
 ▼
Job becomes ACTIVE
 │
 ▼
Regional marketplace
 │
 ▼
Paid contractor ecosystem

That is why I don't think describing this solely as **_spam_** captures the complete risk.

The integrity of the marketplace content is connected directly to something customers on the contractor side are paying to access.

### 11. Attacker-Controlled Content Could Travel With It

The public API also exposed file-upload functionality:

```go
```http
POST /public/files

A benign image could be uploaded without authentication.

The resulting file identifier could then be associated with the newly created task.

I deliberately used harmless content.

This wasn't a stored-XSS test or an attempt to upload executable content.

I wanted to establish whether content supplied by the unauthenticated requester could travel through the same marketplace workflow.

It could.

Conceptually:

```go
```text
Anonymous requester
 │
 ▼
Anonymous benign upload
 │
 ▼
 file UID
 │
 ▼
Anonymous task creation
 │
 ▼
Existing publisher
 │
 ▼
 ACTIVE task
 │
 ▼
Paid marketplace pipeline

### 12. Then I Looked at Scale

At this point I had established that the workflow could be performed manually.

The next question was:

> Does exploitation require meaningful human interaction, or can the workflow be automated?

I wrote a small proof-of-concept that reproduced the minimum relevant sequence:

```go
```text
1. Upload benign test content
2. Submit marketplace task

No publisher credentials were required.

No authenticated publisher session was required.

A controlled publisher email was supplied as the target identity.

The API-side operation completed within seconds.

That meant the vulnerability wasn't constrained by a complicated browser workflow or repeated manual interaction.

It was scriptable.

### 13. What About Rate Limiting?

Automation changes the threat model considerably when the affected operation also lacks effective abuse controls.

During my limited authorized testing, I did not observe an effective rate-limiting mechanism preventing repeated task submissions through the vulnerable workflow.

I intentionally did **_not_** attempt to flood the production marketplace or benchmark its maximum throughput.

Doing so would have created unnecessary operational risk.

So I am not claiming:

> I generated thousands of jobs per minute.

I didn't.

What I demonstrated was the prerequisite for that class of abuse:

```go
```text
Unauthenticated operation
 +
Scriptable request
 +
Attacker-controlled publisher identifier
 +
No effective throttling observed
 +
Automatic marketplace activation

Together, those properties create a credible scaling concern.

An attacker wouldn't necessarily need to sit in front of a browser manually creating fake jobs one by one.

The operation could be automated.

And because the account identity was supplied as data, the automation could theoretically vary that identifier across requests.

That changes the threat model from:

> Someone can manually submit a fake marketplace job.

to:

> An unauthenticated actor has a scriptable primitive capable of injecting unauthorized marketplace activity at scale.

The exact maximum throughput wasn't necessary or responsible to determine.

### 14. Why Scale Matters Here

Now combine the technical behavior with the business model.

The marketplace's commercial pipeline looks roughly like:

```go
```text
Marketplace job
 │
 ▼
Regional contractor
 │
 ▼
Paid access
 │
 ▼
Potential customer opportunity

The vulnerable path looked like:

```go
```text
Automation
 │
 ▼
Attacker-selected publisher
 │
 ▼
Attacker-controlled task
 │
 ▼
ACTIVE
 │
 ▼
Regional marketplace
 │
 ▼
Paid contractor ecosystem

A single fraudulent job might be dismissed as nuisance content.

A **_scriptable mechanism for generating unauthorized jobs_** is a different risk category.

Potential consequences could include:

- dilution of legitimate marketplace opportunities;
- fraudulent activity attributed to real publishers;
- wasted contractor time;
- contractors encountering fabricated opportunities in a paid service;
- abuse of marketplace categories or regions;
- increased moderation and support burden;
- reduced trust in marketplace leads;
- systematic marketplace manipulation.

Those are potential consequences, not claims that I demonstrated each one.

But they follow from the security primitive that was demonstrated.

### 15. The Difference Between Exploitability and Destructive Testing

There's an important security-testing lesson here.

Once you have established:

```diff
```text
Unauthenticated
+
Cross-account
++
ACTIVE marketplace placement
+++
Scriptable workflow
++++
No effective throttling observed

you don't need to create thousands of production objects to prove that automation exists.

Doing so would likely create more operational harm without materially improving the vulnerability evidence.

The responsible stopping point is:

> Demonstrate the primitive, establish reproducibility, document the absence of the expected control, and stop before validation becomes abuse.

That's what I did.

#### Is This Still Just Spam?

With the full context, consider the difference.

Ordinary anonymous spam might look like:

```go
```text
Anonymous user
 │
 ▼
Anonymous content
 │
 ▼
Spam

The demonstrated behavior looked more like:

```go
```text
Unauthenticated user
 │
 ▼
Select existing publisher
 │
 ▼
Create attacker-controlled job
 │
 ▼
Job attributed to publisher
 │
 ▼
Job becomes ACTIVE
 │
 ▼
Regional marketplace
 │
 ▼
Contractors pay for access

And the creation mechanism was scriptable.

That introduces at least three different integrity concerns.

#### i. Identity integrity

Marketplace activity can be attributed to an existing publisher without authorization from that publisher.

#### ii. Marketplace integrity

Attacker-generated jobs can enter the same marketplace pipeline used for genuine customer demand.

#### iii. Commercial integrity

Contractors pay for access to regional opportunities.

If unauthorized jobs can be programmatically injected into that pipeline, the integrity of the content is connected to the integrity of the product being sold.

I did **_not_** make an unrelated contractor pay for access to a test job.

I did not attempt to demonstrate direct financial loss.

That wasn't necessary to establish the underlying security condition.

### 16. The Attack Chain

Putting the research together produced something like this:

```go

```text
            UNAUTHENTICATED REQUESTER
                      │
                      ▼
              Public API surface
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
 Marketplace      Account       Contractor
 information      role oracle   information
                      │
                      ▼
          Identify account context
                      │
                      ▼
             Anonymous file upload
                      │
                      ▼
                 file UID
                      │
                      ▼
          Anonymous task creation
                      │
                      ▼
       Supply existing publisher email
                      │
                      ▼
          Existing publisher selected
                      │
                      ▼
              Task attributed
                      │
                      ▼
                   ACTIVE
                      │
                      ▼
            Regional marketplace
                      │
                      ▼
          Paid contractor ecosystem
                      ▲
                      │
               Scriptable workflow
                      │
             No effective throttling
              observed during testing

The public information endpoints weren't necessarily severe individually.

The significance came from the trust relationship surrounding the state-changing operation.

#### What I Did Not Demonstrate

Good vulnerability research requires documenting the boundaries that held.

I did **_not_** demonstrate:

- authentication-session takeover;
- password compromise;
- arbitrary access to publisher credentials;
- modification of every existing task;
- persistent publisher-profile takeover;
- stored XSS through the upload workflow;
- compromise of the entire account system;
- access to unrelated private customer data;
- direct financial loss to contractors;
- contractors actually purchasing access to my test content;
- production flooding;
- thousands of task creations;
- maximum request throughput.

Those distinctions matter.

The demonstrated behavior was narrower and defensible:

> An unauthenticated requester could programmatically create attacker-controlled marketplace activity attributed to an existing controlled publisher account, have that activity become active within a marketplace where contractors pay for access to regional opportunities, and I observed no effective throttling preventing repeated submissions during my limited testing.

That's what I could prove.

So that's what I claim.

### 17. Then Came the Triage Outcome

I reported the findings through the authorized vulnerability-disclosure programme.

The public marketplace and contractor-data observations were assessed as falling below the programme's validity threshold because much of the returned information was considered non-sensitive business information already available through the public marketplace.

<picture>
  <source media="(max-width: 768px)" srcset="/img/medium/700/1*_qnG39P7dFyGDT5jbDAXtw.png 1x">
  <source media="(min-width: 769px)" srcset="/img/medium/2000/1*_qnG39P7dFyGDT5jbDAXtw.png 1x">
  <img src="/img/medium/700/1*_qnG39P7dFyGDT5jbDAXtw.png" alt="None" width="1577" height="585" loading="lazy" data-zoom-src="/img/medium/4000/1*_qnG39P7dFyGDT5jbDAXtw.png" class="prose-image" data-caption="TRIAGE RESPONSE-1"/>
</picture>

Fair enough.

But the cross-account authorization behavior had a different history.

I was informed that another researcher had discovered the underlying issue before me(OVER A YEAR AGO).

<picture>
  <source media="(max-width: 768px)" srcset="/img/medium/700/1*iMOd0kyjL9BGSlEfN1r8jQ.png 1x">
  <source media="(min-width: 769px)" srcset="/img/medium/2000/1*iMOd0kyjL9BGSlEfN1r8jQ.png 1x">
  <img src="/img/medium/700/1*iMOd0kyjL9BGSlEfN1r8jQ.png" alt="None" width="1580" height="320" loading="lazy" data-zoom-src="/img/medium/4000/1*iMOd0kyjL9BGSlEfN1r8jQ.png" class="prose-image" data-caption="TRIAGE RESPONSE AFTER PUSHBACK"/>
</picture>

According to the programme response, the earlier report had been:

```go
```text
Reported
 │
 ▼
Reproduced
 │
 ▼
Acknowledged
 │
 ▼
Rewarded
 │
 ▼
Closed as "Won't Fix"

The asset owner had reportedly confirmed the behavior but deferred remediation.

My submission was therefore treated as a duplicate.

I don't dispute the duplicate decision.

Someone else got there first.

That's straightforward.

What interested me much more was the **_security state that remained afterward_**.

At the time of my independent testing, I could still reproduce the underlying behavior(not fixed yet).

So the interesting question isn't:

> **_Should a duplicate receive another bounty?_**

It shouldn't be.

The interesting question is:

> **_What level of risk are we comfortable accepting once an authorization flaw like this is understood?_**

### 18. Vulnerability or Acceptable Risk?

Organizations make risk-acceptance decisions every day.

An external researcher doesn't necessarily know the entire internal picture.

There may be:

- fraud detection;
- abuse monitoring;
- operational controls;
- architectural constraints;
- remediation costs;
- product requirements;
- historical abuse data;
- compensating controls.

So a **_Won't Fix_** decision doesn't automatically prove that an organization misunderstood a vulnerability.

Sometimes it means the risk was consciously accepted.

But that still leaves us with a useful security-engineering question.

Consider the properties together:

```go
```text
Unauthenticated
 │
 ▼
Existing account selected
using client-controlled email
 │
 ▼
Marketplace activity created
under that identity
 │
 ▼
Attacker-controlled content
 │
 ▼
ACTIVE marketplace placement
 │
 ▼
Contractors pay for regional access
 │
 ▼
Workflow is scriptable
 │
 ▼
No effective rate limit
observed during testing

Would you accept that trust boundary????????

#### How I Would Fix It

The central remediation principle is simple:

> An account identifier must never substitute for authorization.

If an existing publisher is creating marketplace activity, the server should derive the publisher identity from an authenticated principal.

For example:

```go
```text
Authenticated session
 │
 ▼
Authenticated account
 │
 ▼
Authorization check
 │
 ▼
Create marketplace task

Not:

```go
```text
Client-supplied email
 │
 ▼
Account lookup
 │
 ▼
Existing account
 │
 ▼
Create marketplace task

If anonymous task creation is an intentional product feature, it should be logically separated from actions attributed to existing accounts.

A safer anonymous workflow could resemble:

```go
```text
Anonymous submission
 │
 ▼
Verify email ownership
 │
 ▼
Pending task
 │
 ▼
Ownership established
 │
 ▼
Marketplace activation

I would also implement:

- server-side authorization checks for existing accounts;
- email ownership verification;
- separation of anonymous onboarding from existing-account actions;
- effective rate limiting on task and file creation;
- per-identity and behavioral abuse controls;
- marketplace activation safeguards;
- anomaly detection for high-volume submissions;
- monitoring for unusual publisher/region activity;
- review of other public APIs accepting account identifiers.

Rate limiting alone would **_not fix the authorization vulnerability_**_._

It would only make automated exploitation more expensive.

The authorization boundary itself still needs to be corrected.

### 20. The Lesson I Took Away

This investigation started with:

> What information is publicly accessible?

It ended with:

> What authority does the application give to information supplied by an unauthenticated requester?

One ordinary field captured the problem:

```go
```json
{
 "email": "publisher@example.com"
}

An email address can identify an account.

It cannot authenticate the requester.

And it cannot authorize an action.

In simple terms:

```go
```text
IDENTIFIER ≠ AUTHENTICATION
AUTHENTICATION ≠ AUTHORIZATION

But there was another lesson.

Severity isn't always visible from one HTTP request.

Sometimes you need to understand:

```go
```text
Technical primitive
 +
Business workflow
 ++
Commercial model
 +++
Exploit scalability

A single anonymous task might look like spam.

A cross-account task might look like broken authorization.

An active cross-account task entering a marketplace where contractors pay for opportunities adds a business-integrity dimension.

And a scriptable workflow without effective throttling changes the potential scale.

The vulnerability becomes clearer when you understand the **_SYSTEM_** , not just the endpoint.

### What Would You Do?

This is the part I'm deliberately leaving open.

I was informed that the underlying authorization behavior had previously been reported, reproduced, acknowledged, rewarded, and ultimately closed as **_Won't Fix_** after remediation was deferred.

At the time of my independent testing, the behavior remained reproducible.

So forget the bounty.

Forget who reported it first.

Consider only the security model:

> An unauthenticated requester can supply the email address of an existing publisher, create attacker-controlled marketplace activity attributed to that account, and have it become active in a marketplace where contractors pay for access to regional job opportunities. The workflow is scriptable, and I observed no effective throttling preventing repeated submissions during my limited testing.

I deliberately did not flood the service to determine its maximum throughput.

I deliberately did not make an unrelated contractor pay for access to a test job.

Those actions weren't necessary to establish the underlying risk.

So I'm curious how other practitioners would classify what remains.

Is this primarily:

— _Broken authorization?_

— _Marketplace abuse?_

— _Commercial-integrity risk?_

— _A fraud-enablement primitive?_

— Insufficient anti-automation? —

— _Or an acceptable business risk?_

And if you were responsible for securing this marketplace:

> **_Would you fix it, mitigate it, monitor it or accept it?_**

I'd be interested to hear where AppSec engineers, penetration testers, bug bounty researchers, developers, and security leaders draw that line.

### Disclosure

This research was conducted through an authorized vulnerability-disclosure programme.

The affected organization, hostname, report URLs, report identifiers, bounty information, real emails, account identifiers, task identifiers, credentials, customer information, and unnecessary infrastructure details have been intentionally omitted or generalized.

All cross-account validation used researcher-controlled accounts and benign content. No unrelated user's account was accessed or modified to establish the finding.

High-volume production testing was deliberately not performed. The scalability discussion is based on the demonstrated scriptability of the workflow and the absence of effective throttling observed during limited authorized validation, rather than destructive load testing.

### About the Researcher

I'm **Godwin Akinyomi**, publicly known as **Paul Haykeens**, an Offensive Security Researcher focused on **Web, API, and Mobile and software Security** and vulnerability research.

I'm open to **security research collaborations, penetration-testing opportunities, and connecting with fellow security practitioners**.

**Curiosity is the only crime. 🧑‍💻**
**I Offend to Defend. ⚔️**