#vulnerability

### Impact Under certain threat models, OpenBao operators with privileged API access may not be system administrators and thus normally lack the ability to update binaries or execute code on the system. Additionally, privileged API operators should be unable to perform TCP connections to arbitrary hosts in the environment OpenBao is executing within. The API-driven audit subsystem granted privileged API operators the ability to do both with an attacker-controlled log prefix. Access to these endpoints should be restricted. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Users may deny all access to the `sys/audit/*` interface (with `create` and `update`) permission via policies with explicit deny grants. This would not restrict `root` level operators, however, for whom there are no workarounds. This interface allowed arbitrary filesystem and network (write) access as the user the OpenBao server was running as; in conjunction with allowing custom plugins or other...

### Impact Accounts with access to the highly-privileged identity entity system in the root namespace may increase their scope directly to the `root` policy. While the identity system always allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the `root` policy is restricted to manual generation using unseal or recovery key shares. The global `root` policy is not accessible from child namespaces. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Use of `denied_parameters` in any policy which has access to the affected identity endpoints (on [identity entities](https://openbao.org/api-docs/secret/identity/entity/)) may be sufficient to prohibit this type of attack. ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-13-vault-root-namespace-operator-may-elevate-token-privileges/76032 - https://nvd.nist.gov/vuln/deta...

### Summary An authentication bypass vulnerability allows any unauthenticated attacker to impersonate any ActivityPub actor by sending forged activities signed with their own keys. Activities are processed before verifying the signing key belongs to the claimed actor, enabling complete actor impersonation across all Fedify instances ### Details The vulnerability exists in handleInboxInternal function in fedify/federation/handler.ts. The critical flaw is in the order of operations: 1. Line 1712: routeActivity() is called first, which processes the activity (either immediately or by adding to queue) 2. Line 1730: Authentication check (doesActorOwnKey) happens AFTER processing ```ts // fedify/federation/handler.ts:1712-1750 const routeResult = await routeActivity({ // ← Activity processed here context: ctx, json, activity, recipient, inboxListeners, inboxContextFactory, inboxErrorHandler, kv, kvPrefixes, queue, span, tracerProvi...

A pair of hackers found that a vape detector often found in high school bathrooms contained microphones—and security weaknesses that could allow someone to turn it into a secret listening device.

If untrusted users are allowed to configure JMS for Apache CXF, previously they could use RMI or LDAP URLs, potentially leading to code execution capabilities. This interface is now restricted to reject those protocols, removing this possibility. Users are recommended to upgrade to versions 3.6.8, 4.0.9 or 4.1.3, which fix this issue.

Deserialization of Untrusted Data vulnerability in Apache Seata (incubating). This issue affects Apache Seata (incubating): 2.4.0. Users are recommended to upgrade to version 2.5.0, which fixes the issue.

An integer overflow vulnerability in the loading of ExecuTorch models can cause smaller-than-expected memory regions to be allocated, potentially resulting in code execution or other undesirable effects. This issue affects ExecuTorch prior to commit 8f062d3f661e20bb19b24b767b9a9a46e8359f2b.

### Overview The authentication tag of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs. ### Impact - JWEs can be modified to decrypt to an arbitrary value - JWEs can be decrypted by observing parsing differences - The GCM internal [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=\)%20is%20the-,hash%20key,-%2C%20a%20string%20of) can be recovered ### Am I Affected? You are affected by this vulnerability even if you do not use an `AES-GCM` encryption algorithm for your JWEs. ### Patches The version 1.1.1 fixes the issue by adding the tag length check for the `AES-GCM` algorithm. **Important:** As the [GHASH key](https://en.wikipedia.org/wiki/Galois/Counter_Mode#:~:text=\)%20is%20the-,hash%20key,-%2C%20a%20string%20of) could have leaked, you must rotate the encryption keys after upgrading to version 1.1.1. ### References [Félix Charette talk at NorthSec 2025 about the issue](h...

## Impact Cloudflare quiche was discovered to be vulnerable to an infinite loop when sending packets containing RETIRE_CONNECTION_ID frames. QUIC connections possess a set of connection identifiers (IDs); see [Section 5.1 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Once the QUIC handshake completes, a local endpoint is responsible for issuing and retiring Connection IDs that are used by the remote peer to populate the Destination Connection ID field in packets sent from remote to local. Each Connection ID has a sequence number to ensure synchronization between peers An unauthenticated remote attacker can exploit this vulnerability by first completing a handshake and then sending a specially-crafted set of frames that trigger a connection ID retirement in the victim. When the victim attempts to send a packet containing RETIRE_CONNECTION_ID frames, [Section 19.16 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-19.16) requires that the se...

## Impact In versions 0.8.5 and earlier of uv, remote ZIP archives were handled in a streamwise fashion, and file entries were not reconciled against the archive's central directory. This enabled two parser differentials against other Python package installers: 1. An attacker could contrive a ZIP archive that would extract with legitimate contents on some package installers, and malicious contents on others due to multiple local file entries. The attacker could choose which installer to target. 2. An attacker could contrive a "stacked" ZIP input with multiple internal ZIPs, which would be handled differently by different package installers. The attacker could choose which installer to target. In both cases, the outcome is that an attacker can produce a ZIP with a consistent digest that expands differently with different installers. The [ZIP standard](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) is ambiguous with respect to these behavior differentials. Consequently,...