| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Nuxt is an open-source web development framework for Vue.js. From 3.11.0 until 3.21.4 and 4.4.4, Nuxt compares route-rule keys with the raw request path while route resolution decodes dynamic and catch-all parameters, allowing a percent-encoded segment to resolve to a protected page without matching the routeRules entry intended for that path. As a result, appMiddleware can be skipped during server rendering and an unauthenticated requester can receive the gated page and its SSR data. The same mismatch affects app-manifest rules including redirect, appLayout, ssr, prerender, and payload flags derived from cache, isr, and swr. This vulnerability is fixed in 4.4.4 and 3.21.4. |
| Nuxt is an open-source web development framework for Vue.js. Prior to 4.6.2, Nuxt resolves pages case-insensitively by default while Nitro matches server-side route-rule keys case-sensitively, allowing a request whose path differs only by letter case to render without the server rule intended for that page. The mismatch can skip redirect, headers, proxy, ssr: false, and noScripts, and can cause getRouteRules(event) and matchRouteRules to return no rule for the case variant. Applications that set router.options.sensitive: true in nuxt.config are not affected; setting sensitive only in app/router.options.ts does not establish this exclusion because the server follows the nuxt.config value. Access checks implemented in server middleware, page route middleware, or page data fetching remain independent of this matcher. This issue is fixed in version 4.6.2. |
| ArcadeDB before 26.10.1 contains a remote code execution vulnerability that allows authenticated users, including read-only reader role holders, to execute Groovy code because GremlinQueryEngine.command() lacks scripting authorization checks. Attackers can submit Gremlin commands to the POST /api/v1/command/{database} endpoint when the Groovy engine is enabled to run OS commands as the server process user. |
| Trigger.dev 4.5.0 before 4.6.2 contains an improper authorization vulnerability in the PUT snapshot-url session endpoint that allows public session token holders to obtain presigned S3 write URLs. End users can overwrite their own session's durable chat snapshot to forge the agent's conversation history, since the route lacks a secret-key-only check. |
| The Apache Pulsar WebSocket service allows a WebSocket consumer to configure a dead letter policy through query parameters of the consumer endpoint, including the deadLetterTopic parameter that names the topic to which messages are written after the maximum number of redeliveries is exceeded. When authorization is enabled, the WebSocket service checks only that the connecting user holds the CONSUME permission on the subscribed topic. It does not check whether the user holds the PRODUCE permission on the topic named in deadLetterTopic. The dead letter messages are then written by the WebSocket service using its own broker client identity rather than the identity of the connecting user.
As a result, an authenticated user who holds the CONSUME permission on at least one topic can cause messages to be written to a topic of their choosing in any existing namespace, including namespaces belonging to other tenants, provided the role used by the WebSocket service to connect to the brokers is authorized to produce to that topic and the topic accepts a producer that registers no schema. The dead letter producer created by the WebSocket service registers no schema, so it is rejected when the target topic has a schema and schema validation is enforced for that topic or its namespace; this setting is not enabled by default. The same user is refused when attempting to produce to that topic directly. Where automatic topic creation is enabled, which is the default, the named topic is created if it does not already exist. The issue can only be triggered when the WebSocket service is enabled, either in the broker (webSocketServiceEnabled, which is disabled by default) or as a standalone WebSocket proxy.
The impact is unauthorized injection of messages into topics the user is not permitted to produce to. The user can determine the content of the injected messages when they also control the messages on the subscribed topic. The issue does not allow reading, modifying or deleting existing messages in the target topic. Injected messages carry the dead letter message properties and a dead letter producer name, so they can be distinguished from messages produced normally; however, the values of these properties are not authenticated and should not be relied upon to establish the origin of a message. Whether an injected message has further consequences depends on how the applications consuming the target topic process it. Repeated injection also consumes storage and backlog capacity in the target namespace.
This issue affects Apache Pulsar versions from 2.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.
Users who cannot upgrade immediately and do not require the WebSocket service should disable it. Where the WebSocket service is required, restricting network access to it and limiting the permissions granted to the role the WebSocket service uses to connect to the brokers to the namespaces WebSocket clients are intended to access reduces the exposure. |
| When package management is enabled, Pulsar Functions, Sources and Sinks can be registered or updated from a package stored in the Pulsar Packages Management Service by supplying a package URL. The Pulsar Functions worker authorized these requests only against the namespace in which the component was being registered or updated. It did not check whether the requesting user was permitted to access packages in the namespace that the package URL refers to, and it retrieved the package from the broker using the worker's own credentials. The permission check of the Packages Management Service was therefore applied to the worker's identity instead of the requesting user's. Package URLs of transform functions supplied when registering or updating a sink were handled in the same way.
An authenticated user who is permitted to register or update functions, sources or sinks in any namespace of their own tenant could use this to obtain the contents of a package stored in a namespace of another tenant, without having the packages permission on that namespace. The impact is limited to disclosure of package contents, which may include application code, business logic or embedded credentials. The issue does not allow packages to be modified or deleted and does not affect availability.
This issue only affects deployments that have authentication and authorization enabled and in which package management has been enabled: the broker setting enablePackagesManagement and, in current releases, the functions worker setting functionsWorkerEnablePackageManagement. Both settings are disabled by default.
This issue affects Apache Pulsar versions from 2.8.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/. |
| Apache Traffic Server's origin_server_auth plugin lets a client force signing of attacker-chosen AWS request headers under the proxy's own credentials.
This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0.
Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. |
| Vulnerability in Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit vulnerability allows unauthenticated attacker with logon to the infrastructure where Oracle Java SE executes to compromise Oracle Java SE. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N). |
| ZenTao PMS before 22.3 contains an authorization bypass vulnerability in commonModel::isOpenMethod() that lets logged-in users skip group-based ACL checks for any method containing 'ajax'. Minimal-privilege users can call methods like task.ajaxGetByID, system.ajaxDBAuthUrl and admin.ajaxChangeTableEngine to read data, obtain database credentials, trigger CI jobs and alter tables. |
| Incorrect Authorization vulnerability in Drupal Jsonapi Role Access allows Forceful Browsing. This issue affects Jsonapi Role Access versions: from 0.0.0 to 2.0.2. |
| Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 allows the disabled_actions configuration setting to be bypassed. The check compared only the action name as requested, so a remote authenticated attacker could reach an action listed in disabled_actions by requesting it through its deprecated alias instead. Upstream fixed this in the commit “Fix bug where deprecated action aliases bypassed `disabled_actions` setting”, which moves the check into rcmail::action_handler() and resolves aliases before comparing. |
| Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 is affected by an incorrect authorization vulnerability in the Modoboa driver of the password plugin. The driver took the first entry of the account search result returned by the Modoboa API instead of matching the authenticated user, so a password change could be applied to a different account. Upstream fixed this in the commit “Fix bug where Password Modoboa driver could change password for another account”, which selects the account whose username matches and fails if none does. |
| Incorrect Authorization vulnerability in Drupal Unpublished Node Permissions allows Forceful Browsing. This issue affects Unpublished Node Permissions versions: from 0.0.0 to 1.8.0. |
| A flaw was found in sudo. When sudoers rules use NOTBEFORE or NOTAFTER time-based access restrictions with timestamps that omit the trailing 'Z' timezone indicator, the time evaluation relies on the TZ environment variable inherited from the calling user. Because sudo is a setuid-root program, an unprivileged local user can set TZ to an extreme timezone offset to shift the authorization window by up to approximately 25 hours, causing expired rules to be treated as valid. This allows the user to execute commands outside the intended time window. Authentication is not bypassed; only the time-based authorization check is affected. |
| Incorrect authorization in the Sender Rewriting Scheme (SRS) of Progressive Robot hMailServer 6.2.1 through 6.3.6 allows a remote attacker to relay mail through the server to outside addresses. With SRS enabled, the server rewrites the envelope sender of mail it forwards to a signed SRS address at the forwarding domain, and passes a bounce to that address back to the original sender; but it took every message to a valid SRS address, whatever its sender, as delivery to a local recipient, so the relay rules and the SMTP authentication they require were not applied, and the message was delivered to the outside address the SRS address encodes. Anyone holding a valid SRS address of the server, such as the recipient of a forwarded message, could have the server relay mail to the address it encodes for 21 days, and an account holder whose account forwards to an outside mailbox could obtain one for any address. SRS is off by default. |
| Incorrect authorization in the REST administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential holds the manage_roles permission in named domains - a full-scope API key issued for those domains, or an account assigned the serveradmin role with a list of domains - to obtain the server administrator's authority. An account's admin level gives it authority, and a role assigned to it replaces that authority, which is how an administrator narrows an account whose admin level is the server administrator's. The route that takes a role away (DELETE /api/v1/role-assignments/{address}) checked only that the credential takes in what the account held at the time, not what it would hold afterwards, so such a credential could take a narrowing role away from an account in its domains whose admin level is the server administrator's, returning it to the server administrator's authority, and, having set that account's password while it held the narrower role, sign in as the server administrator. |
| Incorrect authorization in the COM administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows an account assigned the serveradmin role with a list of domains - a credential an administrator may create meaning to confine it to those domains - to act as the whole-server administrator over COM. Administrator roles are meant to confine such a credential to the domains its list names, and the REST API did not take it for the server administrator, but the COM API's server-administrator check read the administer_server permission as the whole server whatever list the grant carried. So the credential signed in through the Control Panel, or through a script run on the server, as the server administrator of every domain: it could read and change every domain's accounts and mail, rename any domain, map a domain alias onto any, write the server's settings and secrets, and create further server-administrator accounts. The COM API's domain-administrator check, asked with no domain, likewise let an account assigned the domainadmin role with a list of domains that leaves out the account's own domain administer that domain's ordinary accounts over COM. An account holding serveradmin with no list is the server administrator by design and is unaffected, as are the help desk, auditor and custom roles. |
| WWBN AVideo before 29.4.0 contains an incorrect authorization vulnerability that allows delegated Users Admin accounts to delete or modify administrator accounts. Attackers can submit requests to confirmDeleteUser.json.php or userAddNew.json.php targeting administrators to delete their videos and accounts, or change and demote them. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an authenticated user with a read_api-scoped token to retrieve a project's incoming email address and create work items, bypassing the token's restrictions, due to insufficient scope enforcement on a GraphQL field. |
| GitLab has remediated an issue in GitLab EE affecting all versions from 12.0 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, when the instance-wide SAML or LDAP membership lock was enabled, an authenticated user could have granted or accepted project and group membership outside the identity provider's control, due to incomplete enforcement of the membership lock on requests created before the lock was enabled. |
