Skip to main content

foreUP API EUVDEUVD-2026-51159

| CVE-2026-15658 HIGH
Authorization Bypass Through User-Controlled Key (CWE-639)
2026-07-30 certcc GHSA-jhcw-2w66-f34v
8.1
CVSS 3.1 · Vendor: certcc
Share

Severity by source

Vendor (certcc) PRIMARY
8.1 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
vuln.today AI
6.5 MEDIUM

Description documents unauthorized read of other users' records only; no write or modification capability described, so I:N; A:N confirmed by lack of availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (certcc).

CVSS VectorVendor: certcc

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

4
Analysis Generated
Jul 31, 2026 - 22:31 vuln.today
CVSS changed
Jul 31, 2026 - 20:22 NVD
8.1 (HIGH)
CVE Published
Jul 30, 2026 - 15:18 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 30, 2026 - 15:18 cve.org
HIGH 8.1

DescriptionCVE.org

A vulnerability in the foreUP customer REST API allows any authenticated, low-privilege customer to access an endpoint that returns the records of other users without checking that the caller owns the data associated with that record.

AnalysisAI

Insecure Direct Object Reference (IDOR) in the foreUP customer REST API exposes records belonging to arbitrary users to any authenticated, low-privilege customer account. The endpoint returns user records based on a caller-supplied identifier without verifying that the requesting customer owns or is authorized to access the requested record. No active exploitation has been confirmed (not listed in CISA KEV), and EPSS places real-world exploitation probability at 0.13% - well below the 3rd percentile - though the high CVSS score of 8.1 reflects the potential confidentiality and integrity impact if an adversary with a valid account begins enumerating records.

Technical ContextAI

CWE-639 (Authorization Through User-Controlled Key) describes the root cause: the API uses a user-supplied key - likely a record ID or account identifier - to look up and return data without enforcing server-side ownership validation. This is a classic IDOR pattern in REST APIs where the access control decision is effectively delegated to the client. The affected product is the foreUP SaaS platform (CPE: cpe:2.3:a:foreup:foreup:*:*:*:*:*:*:*:*), a golf course management system. The wildcard CPE indicates NVD has not scoped the flaw to a specific version range, suggesting the API endpoint behavior is architectural rather than a version-specific regression. The CVSS vector AV:N/AC:L/PR:L/UI:N confirms network-accessible exploitation with low complexity, requiring only a standard customer credential.

RemediationAI

No vendor-released patch or fixed version has been identified at the time of analysis; the CPE wildcard and absence of fix version data in any reference confirm this. The primary remediation is for foreUP (the vendor) to implement server-side ownership checks on the affected REST API endpoint - verifying that the authenticated customer's identity matches the owner of the requested record before returning data. As a compensating control, operators should enforce strict API rate limiting and anomaly detection on the endpoint to surface enumeration patterns (e.g., sequential ID traversal). Organizations should also evaluate whether the endpoint is exposed to the public internet versus restricted to internal or partner networks, and apply network-layer ACLs if possible. Restricting the endpoint to minimum necessary access scope (e.g., requiring session-bound tokens that carry owner context) reduces exposure until a vendor patch is issued. See the CERT/CC advisory at https://kb.cert.org/vuls/id/790363 for vendor guidance.

Share

EUVD-2026-51159 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy