foreUP golf software exposes payment credentials
Two API flaws in Golf Compete foreUP let any customer steal merchant payment credentials and other golfers' full profiles and payment tokens.
Golf Compete foreUP, a cloud-based golf course management platform used by over 2,000 facilities, contained two REST API vulnerabilities disclosed via CERT/CC. CVE-2026-15657 exposed cleartext Finix merchant API credentials (username, password, merchant ID) in every customer record response, with credentials shared across all customers at a facility. CVE-2026-15658 is a Broken Object Level Authorization (BOLA/IDOR) flaw allowing an authenticated user to substitute another customer's golfer_id in the request path to retrieve that customer's full profile, including PII, payment tokens, Dwolla bank funding-source tokens, and transaction history.
Chained together, these vulnerabilities allowed any low-privilege authenticated customer to enumerate other customers' data and extract facility-wide merchant payment processor credentials. Because the API is shared across tenants, a customer at one facility could access merchant credentials belonging to a completely different facility, expanding the blast radius across the entire platform's customer base. No authentication bypass or exploit development was required beyond a valid JWT and predictable identifier manipulation.
foreUP confirmed remediation of both issues on July 26, 2026. No evidence of active exploitation was reported; this is a responsibly disclosed vulnerability finding rather than an observed attack campaign. Affected users are advised to watch for phishing and identity theft attempts stemming from potential prior exposure of payment tokens and PII.
Mentioned in this report
Detection guidance
Possible IDOR Enumeration Against Golfer/Customer Profile API Endpoint
Detects a pattern of authenticated REST API requests that substitute numeric/path-based golfer or customer identifiers on a profile-style endpoint, consistent with BOLA/IDOR probing where an attacker walks through identifiers to retrieve other customers' records. Sigma cannot express the 'many distinct IDs from one session in a short window' threshold directly - SOC correlation logic should flag when a single client/session hits this endpoint with a high number of DISTINCT identifier values in a short timeframe; this rule surfaces the qualifying raw events for that correlation. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Possible IDOR Enumeration Against Golfer/Customer Profile API Endpoint
description: Detects GET requests to a golfer/customer profile-style REST endpoint
that takes a numeric or opaque identifier in the path, which is the exploitation
pattern for BOLA/IDOR vulnerabilities where an authenticated low-privilege user
substitutes another user's ID to retrieve their profile, payment tokens, or transaction
history. This rule flags qualifying requests; pair with a SIEM correlation rule
that alerts when a single session/JWT/source IP accesses many distinct identifier
values on this endpoint in a short window, since that count cannot be expressed
in Sigma condition syntax.
tags:
- attack.initial-access
- attack.t1190
logsource:
category: webserver
detection:
selection:
cs-method: GET
cs-uri-stem|re: .*/(golfer|customer)s?/[0-9a-fA-F-]+(/profile)?/?$
sc-status: 200
filter_static_assets:
cs-uri-stem|contains:
- .css
- .js
- .png
- .jpg
condition: selection and not filter_static_assets
falsepositives:
- Front-desk or facility staff accounts legitimately looking up multiple customers
in sequence
- Automated data sync or reporting integrations that iterate over customer records
for the facility they own
- Load testing or QA scripts exercising the profile endpoint
level: medium
id: 0517ee1a-11d1-5c31-ace5-b66ec55aad90
status: experimental
author: Vorant
Authenticated API Access to Merchant Payment Credential Fields in Customer Record Response
Detects requests to the facility/customer record API endpoint known to embed cleartext merchant payment-processor credentials (username, password, merchant ID) in every response, which combined with IDOR-style ID substitution allows cross-tenant credential harvesting. Flags repeated calls to this endpoint by a given session across facility-record boundaries; exact response content cannot be inspected in Sigma so this targets the request pattern to the vulnerable endpoint class. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Authenticated API Access to Merchant Payment Credential Fields in Customer
Record Response
description: Detects GET requests to facility or customer record endpoints that return
embedded merchant payment processor credentials in cleartext, the CVE-2026-15657-style
exposure pattern. Useful to baseline which accounts/roles call this endpoint and
to flag calls originating from sessions associated with a different facility_id
than the one being queried, indicating potential cross-tenant credential harvesting
when chained with BOLA.
tags:
- attack.initial-access
- attack.t1190
logsource:
category: webserver
detection:
selection:
cs-method: GET
cs-uri-stem|re: .*/(facilit(y|ies)|customer)s?/[0-9a-fA-F-]+/?(record|details)?/?$
sc-status: 200
filter_internal_admin_tools:
c-useragent|contains:
- InternalAdminConsole
- MonitoringBot
condition: selection and not filter_internal_admin_tools
falsepositives:
- Legitimate facility administrators retrieving their own facility's customer/merchant
records
- Internal support tooling that queries the same endpoint for troubleshooting
level: low
id: 7e74429a-6f1a-508d-8401-b43fbe5bbd06
status: experimental
author: Vorant
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://kb.cert.org/vuls/id/790363
This is the public brief
Subscribers see the full picture: extracted IOCs, ready-to-deploy detections (Sigma, Splunk, KQL, Elastic, YARA, Suricata), the entity graph, TAXII 2.1 feed and real-time alerts matched to your sectors.
Start free