CVE WatchAug 1, 2026

CVE-2025-14073

The WooCommerce PayPal Payments plugin for WordPress is vulnerable to Sensitive Information Disclosure due to an Insecure Direct Object Refe

CVSS

5.3

Medium

EPSS

—

KEV

—

Exploit Today

0-100

Published: Aug 1, 2026 · Last modified: Aug 1, 2026 · CWE-639

EPSS · 30d

Not enough EPSS history yet.

Technical description

The WooCommerce PayPal Payments plugin for WordPress is vulnerable to Sensitive Information Disclosure due to an Insecure Direct Object Reference in all versions up to, and including, 3.3.2 via the `enqueue_paypal_insights_script_on_order_received()` function due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to obtain sensitive order information including order keys, which can then be leveraged to access full customer billing details (name, email, phone, address) via the WooCommerce Store API within a 10-minute grace period after order creation.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-673429.8 CRI

—

———ArcadeDB versions before 26.7.2 contain an authorization bypass vulnerability in HTTP handlers for time series, batch, Prometheus, and Grafana endpoints that fail to validate database access permissions. Attackers can access and modify databases they are not authorized to use by directly calling affected endpoints with arbitrary database parameters.9h CVE-2026-673318.3 HIG

—

———better-auth SCIM versions from 1.5.0 before 1.7.0-beta.4 fail to bind non-organization SCIM providers to their creator by default, allowing authenticated users to manage other users' providers. Attackers can regenerate SCIM bearer tokens, invalidate legitimate tokens, and authenticate to SCIM API routes with the attacker-controlled token.9h CVE-2026-673297.1 HIG

—

———@better-auth/stripe versions >= 1.4.11 and < 1.6.21, and >= 1.7.0-beta.0 and < 1.7.0-beta.10, contain an authorization bypass in organization subscription actions. The middleware validates the organization ID taken from the request query string against the authorizeReference callback, but the handler reads the organization ID only from the request body and falls back to the caller's active organization from their session. When these differ, an authenticated member of multiple organizations can perform subscription actions (cancel, change plan, restore, billing portal access) against an organization they belong to but should not manage, and can access another organization's billing details including payment methods, invoices, and subscription state.9h CVE-2026-453304.9 MED

—

——0Decidim is a participatory democracy framework. Prior to 0.30.9, from 0.31.0 before 0.31.5, and in 0.32.0.rc1 before 0.32.0.rc2, the identity-document verification admin controllers load pending Authorization records by raw identifier without confirming current_organization ownership, allowing an administrator from one tenant to view, approve, or reject another tenant’s ID-document request. This issue is fixed in versions 0.30.9, 0.31.5, and 0.32.0.rc2.23h CVE-2026-659817.1 HIG

—

——0Coturn is a free open source implementation of TURN and STUN Server. Prior to 4.15.0, a server using --mobility authenticates a resumed REFRESH request with the resuming user's credentials but does not verify that identity against the original allocation owner, allowing an authenticated attacker who obtains a victim MOBILITY-TICKET to receive and inject relayed traffic and consume the victim's quota. In the handle_turn_refresh resume branch, the victim allocation (orig_ss) is located solely by the attacker-controlled mobile id, and credentials are only adopted (via copy_auth_parameters) when the resuming session is unauthenticated. Because the attacker's session already has hmackey_set set to 1 from its own prior authentication (which is never reset for long-term-credential sessions), the credential copy is skipped and check_stun_auth validates the REFRESH against the attacker's own identity rather than the allocation owner's. This issue is fixed in version 4.15.0.1d CVE-2026-173499.6 CRI

—

——0/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own. Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials. This issue affects pgAdmin 4: from 9.0 before 9.17.17h