ghsa

Hugging Face Smolagents version 1.20.0 contains an XPath injection vulnerability in the search_item_ctrl_f function located in src/smolagents/vision_web_browser.py. The function constructs an XPath query by directly concatenating user-supplied input into the XPath expression without proper sanitization or escaping. This allows an attacker to inject malicious XPath syntax that can alter the intended query logic. The vulnerability enables attackers to bypass search filters, access unintended DOM elements, and disrupt web automation workflows. This can lead to information disclosure, manipulation of AI agent interactions, and compromise the reliability of automated web tasks. The issue is fixed in version 1.22.0.

### Improper Authorization in Hono (JWT Audience Validation) Hono’s JWT authentication middleware did not validate the `aud` (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up). The issue is addressed by adding a new `verification.aud` configuration option to allow RFC 7519–compliant audience validation. This change is classified as a **security hardening improvement**, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification. ### Recommended secure configuration You can enable RFC 7519–compliant audience validation using the new `verification.aud` option: ```ts import { Hono } from 'hono' import { jwt } from 'hono/jwt' const app = new Hono() app.use( '/api/*', jwt({ secret: 'my-secret', verification: { // Require this API to only accep...

The safe function `create_ring_buffer` allocates a buffer using `Vec::with_capacity` followed by `set_len`, creating a `Box<[T]>` containing uninitialized memory. This leads to undefined behavior when functions like `write_slices` create typed slices (e.g., `&mut [bool]`) over the uninitialized memory, violating Rust's validity invariants. The issue has been confirmed using Miri. Fixed in version 0.2.2 by using `resize_with` to properly initialize the buffer with `T::default()`, adding a `T: Default` bound to ensure sound initialization.

The safe function `index_of_ptr` causes undefined behavior when called with an empty slice. The issue occurs in the line `ptr.add(slice.len() - 1)` which underflows when `slice.len()` is 0, creating a pointer with a massive offset. According to Rust's safety rules, creating such a pointer causes immediate undefined behavior.

The servicenow config URL is using a generic django View with no authentication. URL: `/plugins/ssot/servicenow/config/` ### Impact _What kind of vulnerability is it? Who is impacted?_ An Unauthenticated attacker could access this page to view the Service Now public instance name e.g. `companyname.service-now.com`. This is considered **low-value information**. This does not expose the Secret, the Secret Name, or the Secret Value for the Username/Password for Service-Now.com. An unauthenticated member would not be able to change the instance name, nor set a Secret. There is not a way to gain access to other pages Nautobot through the unauthenticated Configuration page. ### Patches _Has the problem been patched? What versions should users upgrade to?_ We highly recommend upgrading to SSoT v3.10.0 which includes this patch. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Disable the servicenow SSoT integration

code16 Sharp v9.6.6 is vulnerable to Cross Site Scripting (XSS) src/Form/Fields/SharpFormUploadField.php.

A reflected cross-site scripting (XSS) vulnerability in the Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q3.0 through 2025.Q3.2, 2025.Q2.0 through 2025.Q2.12, 2025.Q1.0 through 2025.Q1.17, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.20, and 2023.Q4.0 through 2023.Q4.10 allows an remote non-authenticated attacker to inject JavaScript into the google_gadget.

### Impact NeuVector used a hard-coded cryptographic key embedded in the source code. At compilation time, the key value was replaced with the secret key value and used to encrypt sensitive configurations when NeuVector stores the data. In the patched version, NeuVector leverages the Kubernetes secret `neuvector-store-secret` in `neuvector` namespace to dynamically generate cryptographically secure random keys. This approach removes the reliance on static key values and ensures that encryption keys are managed securely within Kubernetes. During rolling upgrade or restoring from persistent storage, the NeuVector controller checks each encrypted configured field. If a sensitive field in the configuration is found to be encrypted by the default encryption key, it’s decrypted with the default encryption key and then re-encrypted with the new dynamic encryption key. If the NeuVector controller does not have the correct RBAC for accessing the new secret, it writes this error log : `Requ...

### Impact This vulnerability affects NeuVector deployments only when the `Report anonymous cluster data option` is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server at `https://upgrades.neuvector-upgrade-responder.livestock.rancher.io`. In affected versions, NeuVector does not enforce TLS certificate verification when transmitting anonymous cluster data to the telemetry server. As a result, the communication channel is susceptible to man-in-the-middle (MITM) attacks, where an attacker could intercept or modify the transmitted data. Additionally, NeuVector loads the response of the telemetry server is loaded into memory without size limitation, which makes it vulnerable to a Denial of Service(DoS) attack. The patched version includes the following security improvements: - NeuVector now verifies the telemetry server’s `TLS certificate chain` and `hostname` during the handshake process. This ensures that all telemetry communication...

### Impact A vulnerability was identified in NeuVector, where the enforcer used environment variables `CLUSTER_RPC_PORT` and `CLUSTER_LAN_PORT` to generate a command to be executed via `popen`, without first sanitising their values. The entry process of the enforcer container is the monitor process. When the enforcer container stops, the monitor process checks whether the consul subprocess has exited. To perform this check, the monitor process uses the `popen` function to execute a shell command that determines whether the ports used by the consul subprocess are still active. The values of environment variables `CLUSTER_RPC_PORT` and `CLUSTER_LAN_PORT` are used directly to compose shell commands via popen without validation or sanitization. This behavior could allow a malicious user to inject malicious commands through these variables within the enforcer container. In the patched version, the monitor process validates the values of `CLUSTER_RPC_PORT` and `CLUSTER_LAN_PORT` to ensur...