Vulnerabilities

A Regular Expression Denial of Service (ReDoS) vulnerability exists in Apache Superset versions 1.5.0 through 5.0.0. The vulnerability is located in the sql_parse.py component, specifically within the SQL_REGEX used for parsing SQL statements in the sqlparse library integration.<br /> The affected regular expression contains overlapping disjunctions that share a common outer quantifier. An authenticated attacker can exploit this by sending a maliciously crafted input string (specifically a long sequence of backslashes or similar characters) to endpoints that process SQL queries<br /> <br /> This issue affects Apache Superset: before 6.0.0.<br /> <br /> Users are recommended to upgrade to version 6.0.0, which fixes the issue. <br /> <br /> Workarounds:<br /> ● WAF Rules: Implement Web Application Firewall (WAF) rules to detect and block<br /> requests containing excessively long sequences of backslashes or suspicious repeated<br /> patterns in the queries.extras.where parameter.<br /> ● Rate Limiting: Ensure strict rate limiting is applied to the /api/v1/chart/data endpoint to<br /> reduce the impact of potential attacks.

A vulnerability in the foreUP customer REST API allows any authenticated user to read cleartext payment-processor merchant credentials in the response body.

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

IBM WebSphere Application Server 8.5, and 9.0 and IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.7 Traditional and Liberty could allow a remote attacker to bypass security constraints.

Calico&amp;#39;s Application Layer Policy (disabled by default), which enforces HTTP rules through Dikastes, fails to perform URL path normalization. As a result, HTTP requests using path-traversal segments, encoded slashes, or repeated slashes are not correctly evaluated by Prefix path rules. Dikastes authorizes the request under the permitted prefix while the downstream workload or a fronting proxy normalizes the path and serves the restricted endpoint. An attacker with network access and no special RBAC can potentially reach HTTP endpoints the policy was intended to restrict.

OpenCost before 1.121.0 fails to authenticate the GET /helmValues endpoint, exposing base64-decoded HELM_VALUES environment variable containing cloud provider credentials. Additionally, adminAuthMiddleware fails open when ADMIN_TOKEN is unset, allowing unauthenticated attackers to modify GCP service account keys via POST /serviceKey to redirect billing calls.

Vendure through 3.7.1, fixed in commit f67ef5f, contains a cross-channel authorization bypass vulnerability in stock-location.service.ts and asset.service.ts update methods that allows channel-scoped administrators to modify other tenants&amp;#39; data. Attackers can supply global IDs of StockLocation or Asset entities from different channels to overwrite inventory locations or catalog assets belonging to other tenants without proper channel isolation validation.

Julep contains an insecure direct object reference vulnerability in the get_execution_details endpoint that allows authenticated tenants to read another tenant&amp;#39;s execution data. Attackers can supply arbitrary execution_id values to retrieve sensitive execution records including task inputs, outputs, metadata, and temporal task tokens from other tenants.

Improper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval.<br /> <br /> This vulnerability is associated with program files lib/boruta/openid.ex and program routines &amp;#39;Elixir.Boruta.Openid&amp;#39;:register_client/3, &amp;#39;Elixir.Boruta.Openid&amp;#39;:parse_registration_params/2.<br /> <br /> This issue affects boruta from 2.3.0 before 2.3.7.

MaxKey through 4.1.12, fixed in commit ddbb72f, contains an insufficient redirect URI validation vulnerability in DefaultRedirectResolver.hostMatches() that allows remote attackers to hijack OAuth 2.0 authorization codes by supplying a crafted redirect_uri whose hostname suffix matches a registered URI without proper dot-boundary anchoring. Attackers who control a domain ending with the registered redirect URI hostname can social-engineer victims into clicking a crafted authorization URL, causing the authorization code to be issued to the attacker-controlled URI and exchanged for an access token granting access to the victim&amp;#39;s identity.

Swarms through 6.8.1, fixed in commit 8b0fc9e, contains a server-side request forgery vulnerability in the _is_safe_url function that fails to validate hostnames through DNS resolution, allowing attackers to bypass the blocklist. Attackers can supply user-controlled image or audio URLs that resolve to private, loopback, or metadata addresses to reach internal services and exfiltrate credentials.

Server-Side Request Forgery vulnerability in malach-it Boruta allows an unauthenticated remote attacker to cause the OAuth/OpenID authorization server to issue outbound HTTP requests to attacker-chosen URIs, including internal services and cloud metadata endpoints.<br /> <br /> Three code paths fetch remote URIs supplied by the requester without sufficient validation of the target. Boruta.Oauth.Request.Base.fetch_unsigned_request/1 in lib/boruta/oauth/request/base.ex dereferences the OAuth request_uri parameter from the authorization request via Finch.build(:get, request_uri) |&gt; Finch.request(OpenIDHttpClient). Boruta.Openid.parse_registration_params/2 in lib/boruta/openid.ex dereferences the jwks_uri supplied in an OpenID Connect dynamic client registration request. Boruta.Ecto.Clients.refresh_jwk_from_jwks_uri/1 in lib/boruta/adapters/ecto/clients.ex later refreshes the stored jwks_uri for an existing client. In all three paths the only validation is that the URI parses with a scheme (and one of the two request_uri clauses does not even restrict the scheme to http or https). The implementations do not require HTTPS, do not enforce a host or IP allowlist, do not reject loopback, private, link-local, or other non-public ranges after DNS resolution, do not cap response size, and do not constrain redirects. An attacker can therefore steer the server&amp;#39;s HTTP client at arbitrary network targets reachable from the Boruta host.<br /> <br /> This issue affects boruta: from 2.3.2 before 2.3.7.