Vikunja 2.2.0 before 2.7.0 Permissive CORS Policy Trusting Localhost Origins

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

RabbitMQ: CORS * reflects Origin with Allow-Credentials

RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6, match_origin/1 returned the bare reflected Origin and allowed credentials even when the wildcard "" was configured, so the response echoed the attacker's origin together with Access-Control-Allow-Credentials. The affected code is rabbit_mgmt_cors.erl. When the management plugin is configured with a wildcard CORS origin (cors_allow_origins = ""), the handler reflects the request Origin back in Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. A malicious web page that a signed-in administrator visits can then use that administrator's cached HTTP Basic credentials to issue authenticated, state-changing requests to the management API. Preconditions include The management plugin is configured with the wildcard cors_allow_origins = "*", which is an explicit operator misconfiguration A target administrator has a cached HTTP Basic-auth session in the browser. This issue is fixed in versions 3.13.17, 4.0.22, 4.1.13, and 4.2.6.

HCL BigFix Service Management is affected by multiple security vulnerabilities.

HCL BigFix Service Management is affected by a CORS Misconfiguration vulnerability due to improperly validated origin headers, which could allow an attacker to craft a malicious web page that interacts with the vulnerable application, enabling unauthorized access to protected resources and restricted APIs on behalf of a victim.

Electron: Custom protocol with supportFetchAPI but not corsEnabled allows cross-origin reads

Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 39.8.10, 40.9.3, 41.4.0, and 42.0.0, a custom scheme registered with supportFetchAPI: true but without corsEnabled: true was not subject to CORS enforcement. A page loaded from a remote origin could therefore fetch() or XMLHttpRequest that scheme cross-origin and read the full response body, rather than the read being blocked. Apps that serve sensitive data from such a scheme and load remote or untrusted content in a renderer are affected. This issue is fixed in versions 39.8.10, 40.9.3, 41.4.0, and 42.0.0.

Insecure Cross-Origin Resource Sharing Policy Enabling Credentialed Access

iControl is affected by an insecure Cross-Origin Resource Sharing (CORS) policy vulnerability, which could allow a malicious website to execute cross-origin requests with included credentials, enabling an attacker to access and exfiltrate sensitive data within the context of the victim's active session.

openssl_encrypt before 1.4.0 CORS Misconfiguration via Wildcard Origins

openssl_encrypt versions before 1.4.0 configure CORS with allow_origins set to wildcard and allow_credentials enabled to true. Attackers can create malicious websites that make authenticated cross-origin requests to the API on behalf of any user who visits them.

Reflected arbitrary origins with credentials, allowing cross-origin reads of authenticated user data

The open-vsx.org deployment returned Access-Control-Allow-Origin reflecting the requesting origin together with Access-Control-Allow-Credentials: true on the authenticated /user/ endpoints. A page on any origin could therefore issue credentialed requests to the service in a logged-in user's browser and read the responses. This exposed /user (login name, avatar, homepage, tokens URL), /user/tokens, /user/namespaces, /user/extensions, /user/search/{name} and /user/namespace/{name}/members, and — because /user/csrf was readable the same way — allowed the CSRF protection on write endpoints to be defeated. Chaining the two, an attacker page could call /user/token/create and exfiltrate a personal access token carrying publish and delete rights over the victim's namespaces. The headers were emitted by the CDN/edge layer, not by the application: the Open VSX software sets allowCredentials(true) in exactly one place, against a single exact origin derived from ovsx.webui.url, and defines no CORS mapping on /user/ beyond it. No configuration of the software produces origin reflection with credentials.

NTLM Hash Theft via Untrusted Cross‑domain Policy in Armoury Crate

A Permissive Cross-domain Security Policy with Untrusted Domains in Armoury Crate allows a remote user to obtain a local user's NTLM hash by convincing the user to visit a crafted web page that sends a request containing a UNC path to the application's local service endpoint.Refer to the ' Security Update for Armoury Crate App ' section on the ASUS Security Advisory for more information.

Permissive Cross-domain Security Policy with Untrusted Domains in ASUS GameSDK allows a remote user to obtain a local user’s NTLM hash by convincing the user to visit a crafted web page that sends a request containing a UNC path to the application’s local service endpoint. This can result in information disclosure or data tampering, may cause GameSDK to become unavailable, and may also enable access to the victim’s information on other services. Refer to the ' Security Update for ASUS GameSDK  ' section on the ASUS Security Advisory for more information.

ag-ui-protocol ag-ui CORSMiddleware utils.py create_strands_app cross-domain policy

A security flaw has been discovered in ag-ui-protocol ag-ui 0.3.0. The affected element is the function create_strands_app of the file integrations/aws-strands/python/src/ag_ui_strands/utils.py of the component CORSMiddleware. The manipulation results in permissive cross-domain policy with untrusted domains. The attack may be launched remotely. The attack requires a high level of complexity. The exploitability is described as difficult. Upgrading to version AGUI.Abstractions@0.0.6 is sufficient to fix this issue. The patch is identified as 9b143b9668fa52c2054ede9d34a45ac4b4401089. It is suggested to upgrade the affected component.

Azure Arc SQL Server Extension Elevation of Privilege Vulnerability

Permissive cross-domain policy with untrusted domains in Azure Arc allows an unauthorized attacker to elevate privileges over a network.

Joro: Unauthenticated Cross-Origin Plugin Upload Leads to RCE

Joro is a web exploitation framework. Prior to version 1.1.1, Joro's default proxy mode exposes a local API on 127.0.0.1:9090 that performs no authentication and applies a wildcard CORS policy. Because plugin uploads use the CORS-safelisted multipart/form-data content type, cross-origin JavaScript on any page the operator visits can reach privileged endpoints - including uploading a native plugin and triggering a restart - directly through the operator's browser, with no preflight or credentials. Since plugins execute on load, this yields unauthenticated remote code execution as the operator's user from a single page visit. This issue has been patched in version 1.1.1.

Windows ML CLI: CORS misconfig enables localhost RCE

Windows ML CLI is a command line tool for building portable, performant, and high-quality AI models for Windows ML. Prior to 0.4.0, the src/winml/modelkit/serve/cli_api.py component exposes WinML CLI commands through a localhost HTTP API without authentication and configures the allow_origins setting as a wildcard in both src/winml/modelkit/serve/cli_api.py and src/winml/modelkit/serve/app.py. A malicious website loaded by a user can send cross-origin requests to /v1/cli/build or /v1/cli/config and set the trust_remote_code parameter to true, which is converted to the --trust-remote-code command-line flag without validation. This reaches AutoConfig.from_pretrained with trust_remote_code=True in src/winml/modelkit/loader/_autoconfig.py and imports Python code from an attacker-controlled model repository, resulting in arbitrary code execution as the server user. This issue is fixed in version 0.4.0.

HeyForm Reflects Any Origin in CORS Responses While Allowing Credentials

HeyForm before 3.0.0-rc.8 reflects the request Origin header in CORS responses while allowing credentials, enabling cross-origin requests with authentication. Attackers can execute authenticated GraphQL queries from malicious pages visited by logged-in users to access workspaces, projects, forms, submissions, and respondent data, or modify account settings.

Rybbit Reflects Any Origin in CORS Responses While Allowing Credentials

Rybbit before 2.7.0 contains a CORS misconfiguration vulnerability that allows attackers to bypass origin restrictions by reflecting any request origin in Access-Control-Allow-Origin responses while credentials are enabled. Attackers can issue credentialed cross-origin requests from any website to read analytics data, account information, and perform authenticated state-changing operations as the victim user.

Cohere North AI: Cohere North AI: Information disclosure via improper Origin header validation

Cohere North AI v1.1.5 was discovered to contain excessively permissive cross-domain policy with untrusted domains. This occurs via the server failing to validate the Origin header of incoming connection requests.

Grav API Plugin: CORS 'Access-Control-Allow-Origin: *' on Authenticated API Responses

Grav API Plugin is a RESTful API for Grav CMS that provides full headless access to your site's content. Prior to 1.0.0-rc.16, the Grav API plugin CorsMiddleware returns Access-Control-Allow-Origin: * and permissive OPTIONS responses for authenticated /api/v1 endpoints. JavaScript from any origin can submit an attacker-obtained JWT through the Authorization or X-API-Token header, read the authenticated response, and perform write operations with the token owner's privileges, enabling data exfiltration and account modification. This issue is fixed in version 1.0.0-rc.16.

FiftyOne App server uses wildcard CORS (Access-Control-Allow-Origin: *), enabling cross-origin reads of local server data

FiftyOne is an open-source platform for refining high-quality datasets and visual AI models. Prior to 1.17.0, the FiftyOne App/API server in fiftyone/server/app.py and the /media route in fiftyone/server/routes/media.py unconditionally return Access-Control-Allow-Origin: *. Because the embedded server is local and unauthenticated, a malicious website visited by the user can read cross-origin responses. The /media endpoint accepts a filesystem path, allowing a drive-by page to read files accessible to the server process and exfiltrate them without additional clicks. The allowed_origins configuration and FIFTYONE_ALLOWED_ORIGINS environment variable now make cross-origin access explicit, while the default policy is same-origin. This issue is fixed in version 1.17.0.

Glances: REST API CORS Credentials Guard Uses Exact-Match Instead of Membership Test — Bypassed by Any Multi-Origin Allowlist Containing the Wildcard

Glances is an open-source system cross-platform monitoring tool. Prior to 4.5.6, the cors_origins guard in glances/outputs/glances_restful_api.py uses exact list equality instead of wildcard membership, allowing a multi-origin list containing the wildcard to retain cors_credentials and expose authenticated REST API data to an untrusted website visited by a previously authenticated user. This issue is fixed in 4.5.6.

Kong Mesh: default control plane config leaks the admin token cross-origin via a CORS wildcard and localhost admin

The default kuma-cp configuration in Kong Mesh reveals the admin bootstrap token and signing keys to any webpage the operator visits while the control plane is reachable from their browser. Due to a CORS misconfiguration a cross-origin fetch() from a malicious page returns the admin JWT and signing material.