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.
Sourcekb.cert.org — open the original
What to check
- Applies to
- The 2 CVEs named below. Whether you run an affected version is not assessed: check the versions the source lists.
- Exploitation
- No exploitation in the wild and no public exploit is recorded for the CVEs named.
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
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
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
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://kb.cert.org/vuls/id/790363
Free public brief. The detections with Splunk SPL already written (plus Elastic and KQL where they apply) are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply) and live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,433 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs