A Server-Side Request Forgery (SSRF) vulnerability exists in the generic HTTP source and tool components of Google mcp-toolbox versions 0.3.0 through 1.4.0. While the toolbox implements baseline input sanitization for user-controlled parameters, the underlying HTTP client (internal/sources/http/http.go) fails to safely regulate request redirection boundaries. Specifically, the client is initialized without a restrictive CheckRedirect policy hook and lacks target IP validation. An attacker or a malicious data-driven prompt can supply a crafted path parameter that triggers an open redirect or a direct destination swap on the target backend, coercing the mcp-toolbox into blindly following the redirection and making unauthorized requests to internal or arbitrary external endpoints.

In smp_process_secure_connection_oob_data of smp_act.cc, there is a possible way to bypass SMP authentication due to Incorrect implementation of a protocol. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Inappropriate implementation in the ChromeOS Readiness Tool installer on Windows prior to 1.0.2.0 loosens DCOM access rights on two objects allowing an attacker to potentially bypass discretionary access controls.

there is a possible permission bypass due to Debug certs being allowlisted. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

An authentication bypass vulnerability exists in the generic opaque token validation path (validateOpaqueToken) of googleapis/mcp-toolbox. When verifying an unparsed opaque token via an OAuth 2.0 introspection endpoint (RFC 7662), the toolbox decodes the response into an introspectResp struct where the Active field is declared as a pointer to a boolean (*bool). The code only explicitly rejects a token if the response contains a populated active field set to false (if introspectResp.Active != nil && !*introspectResp.Active). If an introspection endpoint responds with a payload that completely omits the mandatory active key, the internal variable remains nil, causing the conditional check to short-circuit. As a result, Toolbox accepts authorization tokens missing the "active" field, granting access to protected tools and underlying data sources.

An authentication bypass vulnerability exists in the generic opaque token validation path (validateOpaqueToken) of googleapis/mcp-toolbox. When the toolbox validates an opaque token via an OAuth 2.0 introspection endpoint (RFC 7662), it decodes the response into an introspectResp struct. However, the subsequent claim-checking logic (validateClaims) evaluates the issuer condition as if a.issuer != "" && iss != "". If the external OAuth provider's introspection response omits the optional iss (issuer) field completely, the variable iss defaults to an empty string. This causes the conditional block to evaluate to false and be skipped silently. Consequently, the application accepts tokens issued by unauthorized or unintended third-party identity providers.

An Improper Access Control vulnerability in the Stylus Tools component of Google ChromeOS version 16238.64.0 on the garaged stylus devices allows a physical attacker to bypass the lock screen and access user files by removing the stylus while the device is closed and using the screen capture feature.

There exists an authentication bypass vulnerability in OpenThread border router devices and implementations. This issue allows unauthenticated nodes to craft radio frames using “Key ID Mode 2”: a special mode using a static encryption key to bypass security checks, resulting in arbitrary IP packets being allowed on the Thread network. This provides a pathway for an attacker to send/receive arbitrary IPv6 packets to devices on the LAN, potentially exploiting them if they lack additional authentication or contain any network vulnerabilities that would normally be mitigated by the home router’s NAT firewall. Effected devices have been mitigated through an automatic update beyond the affected range.

In Bluetooth, there is a possible way for a paired Bluetooth device to access a long term identifier for an Android device due to a permissions bypass. This could lead to local information disclosure with no additional execution privileges needed. User interaction is needed for exploitation.

In SEPolicy, there is a possible way to access the factory MAC address due to a permissions bypass. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.

In multiple functions of ConnectionServiceWrapper.java, there is a possible way to retain a permission forever in the background due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

Frappe is a full-stack web application framework. Prior to versions 14.89.0 and 15.51.0, making crafted requests could lead to information disclosure that could further lead to account takeover. Versions 14.89.0 and 15.51.0 fix the issue. There's no workaround to fix this without upgrading.

Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to versions 7.10.8, 7.11.5, 7.12.5, 7.13.4, 8.0.2, 8.1.1, and 8.2.0, authentication vulnerabilities exist in Rocket.Chat's enterprise DDP Streamer service. The Account.login method exposed through the DDP Streamer does not enforce Two-Factor Authentication (2FA) or validate user account status (deactivated users can still login), despite these checks being mandatory in the standard Meteor login flow. This issue has been patched in versions 7.10.8, 7.11.5, 7.12.5, 7.13.4, 8.0.2, 8.1.1, and 8.2.0.