ghsa

### Summary sigstore-java has insufficient verification for a situation where a validly-signed but "mismatched" bundle is presented as proof of inclusion into a transparency log ### Impact This bug impacts clients using any variation of KeylessVerifier.verify() The verifier may accept a bundle with an unrelated log entry, cryptographically verifying everything but fails to ensure the log entry applies to the artifact in question, thereby "verifying" a bundle without any proof the signing event was logged. This allows the creation of a bundle without fulcio certificate and private key combined with an unrelated but time-correct log entry to fake logging of a signing event. A malicious actor using a compromised identity may want to do this to prevent discovery via rekor's log monitors. The signer's identity will still be available to the verifier. The signature on the bundle must still be on the correct artifact for the verifier to pass. sigstore-gradle-plugin and sigstore-maven-pl...

### Summary The user invite acceptance API endpoint lacks server-side password policy enforcement, allowing users to set arbitrarily weak passwords by bypassing client-side validation. While the UI enforces password complexity requirements, direct API calls can circumvent these checks, enabling the creation of accounts with passwords as short as a single character. ### Details When an email messaging provider is enabled and a new user account is created in the system, an invite email containing a special link is sent to the new user's email address. This link directs the new user to a page where they can set their initial password. While the user interface implements password complexity checks, these validations are only performed client-side. The underlying `/api/v1/user/accept-invite` API endpoint does not implement the same password policy validations. ### Impact This vulnerability allows an invited user to set an extremely weak password for their own account during the initial...

### Summary lobe-chat before 1.19.13 has an unauthorized ssrf vulnerability. An attacker can construct malicious requests to cause SSRF without logging in, attack intranet services, and leak sensitive information. ### Details * visit https://chat-preview.lobehub.com/ * click settings -> llm -> openai * fill the OpenAI API Key you like * fill the proxy address that you want to attack (e.g. a domain that resolved to a local ip addr like 127.0.0.1.xip.io) (the address will concat the path "/chat/completions" which can be bypassed with sharp like "http://172.23.0.1:8000/#") * then lobe will echo the ssrf result The jwt token header X-Lobe-Chat-Auth strored proxy address and OpenAI API Key, you can modify it to scan internal network in your target lobe-web.   ![image](https://github.com/lobe...

aiocpa is a user-facing library for generating color gradients of text. Version 0.1.13 introduced obfuscated, malicious code targeting Crypto Pay users, forwarding client credentials to a remote Telegram bot. All versions have been removed from PyPI.

A vulnerability was found in Keycloak. Deployments of Keycloak with a reverse proxy not using pass-through termination of TLS, with mTLS enabled, are affected. This issue may allow an attacker on the local network to authenticate as any user or client that leverages mTLS as the authentication mechanism.

Keycloak versions 26 and earlier are vulnerable to a denial-of-service (DoS) attack through improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service. The attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers. For Keycloak version 26, for successful exploitation includes: the realm must have SslRequired=EXTERNAL (the default), HTTP must be enabled, the instance must not be using a full hostname URL, access must come from behind a proxy (assuming the proxy overwrites the X-Forwarded-For header), and trusted proxies must not be set or must incor...

### Impact For users with the following configuration: * An allow policy that selects a [Layer 3 destination](https://docs.cilium.io/en/v1.14/security/policy/language/#layer-3-examples) and a [port range](https://docs.cilium.io/en/stable/security/policy/language/#example-port-ranges) **AND** * A [Layer 7 allow policy](https://docs.cilium.io/en/latest/security/policy/language/#layer-7-examples) that selects a specific port within the first policy's range then Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy. This issue only affects users who use Cilium's port range functionality, which was introduced in Cilium v1.16. For reference, an example of a pair of policies that would trigger this issue is: ``` apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "l3-port-range-rule" spec: endpointSelector: matchLabels: app: service ingress: - fromCIDR: - 192.168.60.0/24 toPorts: - ports: - port...

### Summary Several cross-site scripting vulnerabilities existed in the `deno_doc` crate which lead to Self-XSS with `deno doc --html`. ### Details & PoC 1.) XSS in generated `search_index.js` `deno_doc` outputed a JavaScript file for searching. However, the generated file used `innerHTML` on unsanitzed HTML input. https://github.com/denoland/deno_doc/blob/dc556c848831d7ae48f3eff2ababc6e75eb6b73e/src/html/templates/pages/search.js#L120-L144 2.) XSS via property, method and enum names `deno_doc` did not sanitize property names, method names and enum names. ### Impact The first XSS most likely didn't have an impact since `deno doc --html` is expected to be used locally with own packages.

A flaw was found in Keycloak. This issue occurs because sensitive runtime values, such as passwords, may be captured during the Keycloak build process and embedded as default values in bytecode, leading to unintended information disclosure. In Keycloak 26, sensitive data specified directly in environment variables during the build process is also stored as a default values, making it accessible during runtime. Indirect usage of environment variables for SPI options and Quarkus properties is also vulnerable due to unconditional expansion by PropertyMapper logic, capturing sensitive data as default values in all Keycloak versions up to 26.0.2.

A vulnerability was found in Keycloak. A user with high privileges could read sensitive information from a Vault file that is not within the expected context. This attacker must have previous high access to the Keycloak server in order to perform resource creation, for example, an LDAP provider configuration and set up a Vault read file, which will only inform whether that file exists or not.