Intelligence
Explorer.

Unauthenticated Cross Site Scripting (XSS) in Charitable <= 1.8.12.3 versions.

Unauthenticated Broken Access Control in PowerPress Podcasting <= 11.17.9 versions.

Unauthenticated Sensitive Data Exposure in Groundhogg <= 4.8.3 versions.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Tomlister Payflex Payment Gateway payflex-payment-gateway allows Reflected XSS.This issue affects Payflex Payment Gateway: from n/a through 2.7.1.

Subscriber Broken Access Control in WPO365 <= 44.1 versions.

Unauthenticated Sensitive Data Exposure in Xserver Migrator <= 1.6.6 versions.

Unauthenticated Broken Authentication in Advanced Google reCAPTCHA <= 5.40 versions.

This vulnerability exists in the Schmooze app due to the use of hardcoded credentials and cryptographic keys in the client application. An unauthenticated remote attacker could exploit this vulnerability by decompiling the distributed application package and extracting the embedded credentials and cryptographic keys. Successful exploitation of this vulnerability could allow the attacker to gain unauthorized access to backend and cloud resources and forge client requests on the targeted system.

A vulnerability was found in SourceCodester Simple Student Information System 1.0. This affects an unknown part of the file searchquery.php. Performing a manipulation results in sql injection. The attack can be initiated remotely.

A flaw was found in the OIDC implementation of Keycloak, specifically within the Device Authorization Grant flow. This component allows devices with limited input capabilities to obtain security tokens. The issue occurs because the flow fails to check the minimum authentication level required by a client configuration. This allows an attacker who has stolen a user's password to bypass mandatory multi-factor authentication and gain unauthorized access to the Keycloak Admin REST API.

The elegro Crypto Payment WordPress plugin through 1.0.1 does not require a shared secret to be configured before trusting incoming payment notification requests, allowing unauthenticated attackers to forge payment confirmations and change the status of arbitrary orders on any installation where that secret has been left at its default empty value.

An unauthenticated remote attacker can modify Asset Administration Shell submodel data via PATCH requests and can read all data exposed by the GET endpoints.

The File Media Renamer WordPress plugin through 1.3 does not verify that the requesting user is authorised to modify a given media attachment, allowing any user with file-upload privileges to rename attachments belonging to other users, including administrators, and to corrupt unrelated stored site data that referenced the old file path.

The Deema Payment Gateway WordPress plugin through 1.1.2 does not verify the payment with the payment provider when handling the return from the hosted checkout, and does not check the payment status or amount, allowing unauthenticated users to have orders marked as paid without any payment being taken.

The Deema Payment Gateway WordPress plugin through 1.1.2 does not verify the authenticity of incoming payment provider notifications, and ships with that verification disabled by default, allowing unauthenticated attackers to mark an unpaid order as paid, or to cancel or refund an existing order.

The Fast Courier WordPress plugin through 5.2.3 does not restrict an unauthenticated REST route that writes order fulfillment data, allowing unauthenticated attackers to overwrite the courier status and customer-facing tracking details of any WooCommerce order by supplying its id.

The Slider Pro WordPress plugin through 1.0.0 does not perform any capability or authorisation check on one of its AJAX actions, allowing unauthenticated users to retrieve the title, excerpt and permalink of non-public posts, including drafts, pending, scheduled, private and trashed posts, as well as post revisions and media metadata.

Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client’s configured secret. UAA’s client_credentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=none — satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a client_credentials request for the same client, UAA issues a new client-only token carrying the client’s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client’s actual secret. Exploitation requires a valid user access token (the attacker’s own) for a client that is configured to support both a public, user-facing authorization flow and the client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client.

Insufficient verification of data authenticity (CWE-345) in the external OIDC login callback in Cloud Foundry UAA v4.5.0 to v79.6.0 (inclusive) allows an authenticated UAA user to bypass the OAuth authorization-code exchange and establish an authenticated external-OIDC browser session, via submitting a UAA access token or a cross-client ID token as the callback’s id_token parameter. The issue only manifests when a UAA zone is configured with an OIDC identity provider whose issuer exactly matches that zone’s own /oauth/token endpoint (a “self-UAA” OIDC configuration). In this configuration, the callback takes a supplied id_token directly instead of requiring the authorization code exchange, and does not verify that the token was actually issued as an ID token for the specific self-OIDC relying-party client. An attacker holding any valid UAA JWT for themselves — including a plain access token with only uaa.user scope, or a valid ID token issued to an unrelated client such as cf — can present it as the callback’s id_token and be authenticated into a mapped local (“shadow”) account. Because the resulting session is not verified against the originating token’s true audience or user_id, its effective privilege depends entirely on the shadow account’s group memberships, which can include administrative scopes such as clients.write. Exploitation requires a valid UAA user JWT, a valid browser login state for the target zone, and the presence of a self-referential OIDC provider configuration — this is not a pre-authentication vulnerability, and does not by itself grant privileges beyond those already held by the mapped shadow account.

Memory corruption while processing service requests.

Memory Corruption when executing system service routines due to improper handling of user input buffers.

Memory Corruption when asynchronous threads access shared performance counter data simultaneously during FastRPC invocations.

Transient DOS when processing a continuous receive command with a zero-sized global configuration override.

Memory corruption when processing draw objects of incorrect type during graphics command list execution.