gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.

A vulnerability classified as critical has been found in ageerle ruoyi-ai up to 2.0.0. Affected is an unknown function of the file ruoyi-modules/ruoyi-system/src/main/java/org/ruoyi/system/controller/system/SysNoticeController.java. The manipulation leads to improper authorization. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 2.0.1 is able to address this issue. The name of the patch is 6382e177bf90cc56ff70521842409e35c50df32d. It is recommended to upgrade the affected component.

Next.js is a React framework for building full-stack web applications. Starting in version 1.11.4 and prior to versions 12.3.5, 13.5.9, 14.2.25, and 15.2.3, it is possible to bypass authorization checks within a Next.js application, if the authorization check occurs in middleware. If patching to a safe version is infeasible, it is recommend that you prevent external user requests which contain the x-middleware-subrequest header from reaching your Next.js application. This vulnerability is fixed in 12.3.5, 13.5.9, 14.2.25, and 15.2.3.

Improper Authorization in GitHub repository modoboa/modoboa prior to 2.1.0.

An issue was discovered in the fp_newsletter (aka Newsletter subscriber management) extension before 1.1.1, 1.2.0, 2.x before 2.1.2, 2.2.1 through 2.4.0, and 3.x before 3.2.6 for TYPO3. Attackers can unsubscribe everyone via a series of modified subscription UIDs in deleteAction operations.

@keystone-6/core is a core package for Keystone 6, a content management system for Node.js. Starting with version 2.2.0 and prior to version 2.3.1, users who expected their `multiselect` fields to use the field-level access control - if configured - are vulnerable to their field-level access control not being used. List-level access control is not affected. Field-level access control for fields other than `multiselect` are not affected. Version 2.3.1 contains a fix for this issue. As a workaround, stop using the `multiselect` field.

A vulnerability exists in a SDM600 endpoint. An attacker could exploit this vulnerability by running multiple parallel requests, the SDM600 web services become busy rendering the application unresponsive. This issue affects: All SDM600 versions prior to version 1.2 FP3 HF4 (Build Nr. 1.2.23000.291) List of CPEs: * cpe:2.3:a:hitachienergy:sdm600:1.0:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.1:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.9002.257:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.10002.257:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.11002.149:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.12002.222:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.13002.72:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.44:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.92:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.108:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.182:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.257:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.342:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.447:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.481:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.506:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.14002.566:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.20000.3174:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.21000.291:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.21000.931:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.21000.105:*:*:*:*:*:*:* * cpe:2.3:a:hitachienergy:sdm600:1.2.23000.291:*:*:*:*:*:*:*

Whale browser before 4.35.351.12 allows an attacker to escape the iframe sandbox in a sidebar environment.

Improper Authorization in GitHub repository cobbler/cobbler prior to 3.3.2.

Improper authorization in Microsoft PC Manager allows an unauthorized attacker to elevate privileges over a network.

Azure Portal Elevation of Privilege Vulnerability

In OpenDaylight Model-Driven Service Abstraction Layer (MD-SAL) through 13.0.1, a controller with a follower role can configure flow entries in an OpenDaylight clustering deployment.

OAuthenticator provides plugins for JupyterHub to use common OAuth providers, as well as base classes for writing one's own Authenticators with any OAuth 2.0 provider. `GoogleOAuthenticator.hosted_domain` is used to restrict what Google accounts can be authorized access to a JupyterHub. The restriction is intented to be to Google accounts part of one or more Google organization verified to control specified domain(s). Prior to version 16.3.0, the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023). OAuthenticator 16.3.0 contains a patch for this issue. As a workaround, restrict who can login another way, such as `allowed_users` or `allowed_google_groups`.