Pre-Auth POS Token Disclosure + Partner IDOR Exposes PII

The Vulnerability

1. Bearer token leaked without authentication

The platform's point-of-sale self-ordering system exposed a configuration endpoint that returned POS setup data including product catalogs, table layouts, and session details. When called with an empty access_token parameter, the endpoint still returned a full response containing a valid bearer token embedded in a URL field:

POST /pos-self/data/1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"call","params":{"access_token":""}}

The response included a self_ordering_url field with the bearer token in the query string. This token was a 16-character hex string generated from the POS configuration and was active and usable for authenticated API calls. The endpoint should have rejected the request with a 401 or 403 status when no valid token was provided.

2. Partner record lookup with no authorization check

A second endpoint designed to validate partner (customer) records accepted an arbitrary partner_id parameter and returned the corresponding record from the database. The lookup was performed using elevated privileges (sudo()) with no object-level authorization. Any valid POS token could be used to retrieve any partner record in the system, regardless of whether that partner belonged to the requesting POS session or tenant.

POST /pos-self-order/validate-partner
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"call","params":{
  "access_token":"[leaked_token]",
  "partner_id":3,
  "name":"","email":"","phone":"","street":"",
  "zip":"","city":"","country_id":false
}}

The response returned the full partner record including name, email address, phone number, physical address, and VAT/tax identification number.

3. Sequential IDs enable enumeration

Partner records used sequential integer IDs, making it trivial to enumerate all records by incrementing the partner_id parameter. The proof of concept intentionally stopped after three matches to minimize data exposure, but there was no rate limiting or detection mechanism to prevent bulk extraction.

The Attack

1. The attacker identifies a target instance using the platform's self-ordering feature. The POS configuration ID is a small sequential integer (typically 1 through 10)
2. The attacker sends a POST request to the configuration endpoint with an empty access token. The response contains a valid bearer token leaked in the self-ordering URL
3. The attacker confirms the token is valid by calling a ping endpoint, which returns a successful response
4. Using the leaked token, the attacker sends requests to the partner validation endpoint with incrementing partner_id values
5. Each request returns the full partner record including email, phone, street address, and tax identification number

Additional attack surface

The leaked token also granted access to several other sensitive operations through the self-ordering API surface:

• Product cost price disclosure, revealing purchase prices and profit margins for all POS products
• Unlimited partner record creation via the same validation endpoint, enabling database pollution
• Payment API abuse through kiosk endpoints, allowing creation and cancellation of payment intents on configured payment processors
• Order creation with mass-assignable fields including arbitrary partner association and invoice generation flags
• Full configuration data dump returning records from 48 different data models including table identifiers used as security tokens

The Impact

Scale of exposure

This vulnerability affected any instance of the platform using the POS self-ordering feature, which is commonly deployed by restaurants, retail stores, and other businesses. The chained attack started entirely pre-auth (no login, no session cookie, no credentials) and could be automated to extract partner records at scale. VAT/tax identification numbers are regulated personal data in many jurisdictions and their exposure creates risk for identity fraud and tax fraud.

Remediation

• Enforce strict authentication on the POS configuration endpoint so that empty or invalid tokens receive a 401 or 403 response instead of a full data dump containing usable credentials
• Remove bearer tokens from URL query strings in API responses to prevent token leakage via logs, referrer headers, and browser history
• Implement object-level authorization on the partner validation endpoint so that partner lookups are restricted to records associated with the current POS session or tenant context
• Replace sequential partner IDs with non-guessable identifiers or enforce server-side derivation of partner identity rather than accepting client-supplied IDs
• Minimize the fields returned by the partner validation endpoint, avoiding email, phone, and tax ID unless strictly necessary and authorized
• Add rate limiting and anomaly detection for repeated partner validation attempts as a defense-in-depth measure