Skip to content

Race Condition in Outray cli's webapp

Moderate
akinloluwami published GHSA-45hj-9x76-wp9g Jan 13, 2026

Package

npm Outray (npm)

Affected versions

0.1.3

Patched versions

None

Description

Summary

This vulnerability allows a user i.e a free plan user to get more than the desired subdomains due to lack of db transaction lock mechanisms in https://github.com/akinloluwami/outray/blob/main/apps/web/src/routes/api/%24orgSlug/subdomains/index.ts

Details

  • The affected code-:
//Race condition
        const [subscription] = await db
          .select()
          .from(subscriptions)
          .where(eq(subscriptions.organizationId, organization.id));

        const currentPlan = subscription?.plan || "free";
        const planLimits = getPlanLimits(currentPlan as any);
        const subdomainLimit = planLimits.maxSubdomains;

        const existingSubdomains = await db
          .select()
          .from(subdomains)
          .where(eq(subdomains.organizationId, organization.id));

        if (existingSubdomains.length >= subdomainLimit) {
          return json(
            {
              error: `Subdomain limit reached. The ${currentPlan} plan allows ${subdomainLimit} subdomain${subdomainLimit > 1 ? "s" : ""}.`,
            },
            { status: 403 },
          );
        }

        const existing = await db
          .select()
          .from(subdomains)
          .where(eq(subdomains.subdomain, subdomain))
          .limit(1);

        if (existing.length > 0) {
          return json({ error: "Subdomain already taken" }, { status: 409 });
        }

        const [newSubdomain] = await db
          .insert(subdomains)
          .values({
            id: crypto.randomUUID(),
            subdomain,
            organizationId: organization.id,
            userId: session.user.id,
          })
          .returning();
  • The first part of the code checks the user plan and determine his/her existing_domains without locking the transaction and allowing it to run.
const existingSubdomains = await db
          .select()
          .from(subdomains)
          .where(eq(subdomains.organizationId, organization.id));
  • The other part of the code checks if the desired domain is more than the limit.
if (existingSubdomains.length >= subdomainLimit) {
          return json(
            {
              error: `Subdomain limit reached. The ${currentPlan} plan allows ${subdomainLimit} subdomain${subdomainLimit > 1 ? "s" : ""}.`,
            },
            { status: 403 },
          );
        }
  • Finally, it inserts the subdomain also after the whole check without locking transactions.
const [newSubdomain] = await db
          .insert(subdomains)
          .values({
            id: crypto.randomUUID(),
            subdomain,
            organizationId: organization.id,
            userId: session.user.id,
          })
          .returning();
  • An attacker can exploit this by making parallel requests to the same endpoint and if the second request reads row subdomains before the INSERT statement of request one is made.It allows the attacker to act on a not yet updated row which bypasses the checks and allow the attacker to get more subdomains.For example-:
  Parallel request 1                               Parallel  Request  2    
     |                                                                     |
checks for                                                     Checks the not yet updated
available subdomain                                     row and bypasses the logic checks
and determines if it is more than limit
    |                                                                        |
Inserts subdomain and calls it a day           Also inserts the  subdomain
  • The attack focuses on exploiting the race window between reading and writing the db rows.

PoC

  • Intercept with Burp proxy,pass to Repeater and create multiple requests in a single batch with different subdomain names as seen below. Lastly, send the requests in parallel.
image
  • Result-:
image

Impact

The vulnerability provides an infiinite supply of domains to users bypassing the need for subscription

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H

CVE ID

CVE-2026-22819

Weaknesses

Race Condition within a Thread

If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined. Learn more on MITRE.

Credits