Export limit exceeded: 424405 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (424405 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-82441 | 1 Apache | 1 Storm Nimbus | 2026-11-10 | 9.1 Critical |
| Description A submitted topology carries two lists of blobstore keys, `dependency_jars` and `dependency_artifacts`, which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their contents on the submission path, yet acts on them in two places. During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who listed a key belonging to another topology, such as its `-stormjar.jar`, could therefore cause that blob to be deleted when their own topology was cleaned up. Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions. Mitigation Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key and exists in the blobstore. Note that this validates new submissions only; a topology stored by an affected version with an invalid list is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them. Users who cannot upgrade immediately should restrict topology submission to trusted principals. Credit This issue was discovered by rzo1 while investigating an unrelated blobstore defect. | ||||
| CVE-2026-82426 | 1 Apache | 1 Storm Nimbus | 2026-11-10 | 6.5 Medium |
| Description Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checking that it referred to a file the caller had actually uploaded. The intended flow is that a client first calls `beginFileUpload`, which returns a path inside the Nimbus inbox, and uploads the jar in chunks to that location; nothing bound submission to that flow, and the `uploaders` map populated by `beginFileUpload` was never consulted at submit time. An authenticated user with topology submission rights could therefore submit any path readable by the Nimbus daemon user as their topology jar. Nimbus copied the file into the topology's jar blob, and the blob ACL grants the submitting subject read access, so the contents could then be retrieved with the ordinary blob download RPCs. Candidate targets include the Nimbus Kerberos keytab, Thrift and UI TLS private keys, and `storm.yaml` with the ZooKeeper authentication payload. Possession of the Nimbus keytab turns an ordinary tenant into a cluster administrator. In a deployment configured as the documentation recommends, submission is available to every authenticated principal when `nimbus.users` is unset, so no elevated privilege is required. Mitigation Upgrade to 3.1.0, where the submitted location is canonicalised and must resolve inside the Nimbus inbox. Users who cannot upgrade immediately should restrict topology submission to trusted principals via `nimbus.users` or `nimbus.groups`, and should treat any file readable by the Nimbus daemon user as potentially exposed to submitters: rotate the Nimbus keytab and any TLS private keys or ZooKeeper credentials reachable from that account. Local mode is unaffected. Credit Independently reported to the Apache Storm PMC by n0mi1k, with a proof of concept. Also found by the ASF using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | ||||
| CVE-2026-82432 | 1 Apache | 1 Storm Nimbus | 2026-11-10 | 8.1 High |
| Description Nimbus validated `topology.blobstore.map` against the calling subject at submission time only. The rebalance operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the blob's contents into the topology's working directory. The same advisory covers `listBlobs`, which performed no authorization check and passed no subject, unlike the neighbouring `getBlobMeta` and `beginBlobDownload` operations. It therefore returned every key in the blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the above practical. On its own the disclosure is metadata only. Mitigation Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time configuration is, against the rebalancing caller, and where `listBlobs` applies the configured authorization. Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind that membership of a topology's `topology.users` or `topology.groups` confers them. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | ||||
| CVE-2026-82431 | 1 Apache | 1 Storm Client | 2026-11-10 | 9.8 Critical |
| Description `SimpleACLAuthorizer` evaluated the user-level command set by returning early when `nimbus.users` was empty, before `nimbus.groups` was considered. An operator who restricted cluster access by group alone, leaving `nimbus.users` unset, therefore received no restriction at all: every authenticated principal was permitted every user-level operation, including `submitTopology`, `beginFileUpload` and `getNimbusConf`. `docs/SECURITY.md` presents `nimbus.groups` as a supported way to lock down a cluster, so a deployment following the documentation could believe it was restricted while it was not. The failure is silent; nothing in the logs or the configuration indicates that the group list is being ignored. Both lists left empty continues to mean that no restriction is configured, which is the shipped default and is unchanged. Mitigation Upgrade to 3.1.0, where `nimbus.groups` is evaluated whether or not `nimbus.users` is set. Users who cannot upgrade immediately should additionally populate `nimbus.users` with the intended principals, since a non-empty user list causes the group list to be evaluated on affected versions. Operators should review Nimbus access logs for operations by principals outside the intended groups. Note that after upgrading, a cluster configured with `nimbus.groups` alone becomes restrictive for the first time. This includes `NimbusClient`, which calls `getLeader` on every connection, so clients outside the configured groups will begin to be refused. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | ||||
| CVE-2026-82427 | 1 Apache | 1 Storm Nimbus | 2026-11-10 | 7.8 High |
| Description A topology's `topology.blobstore.map` lets the submitter choose a local name for each blob that the supervisor localises. That name was used to build a path under the topology's working directory without normalisation, in both `AsyncLocalizer` and `Container.createBlobstoreLinks`, and the symlink helper force-deletes whatever already exists at the target before creating the link. A submitter could therefore use `../` segments to direct that delete-and-symlink operation at an arbitrary path, as the supervisor user, on every node the topology is scheduled onto. The consequences include recursive deletion of supervisor-owned content and planting a symlink that causes a subsequent worker launch to execute attacker-chosen code as another tenant's operating-system user, which defeats the isolation that `supervisor.run.worker.as.user` is intended to provide. Mitigation Upgrade to 3.1.0, where the resolved target must lie inside the expected root at both call sites. Users who cannot upgrade immediately should restrict topology submission to trusted principals, and may reject submissions whose `topology.blobstore.map` entries contain path separators or `..` segments before they reach Nimbus. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. | ||||
| CVE-2026-55236 | 1 Langchain-ai | 1 Langgraph-api | 2026-11-10 | 5.9 Medium |
| langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, the langgraph-api run-creation path authorizes the assistant attached to a run by dispatching assistants.search with an incomplete value instead of the assistants.read event used by direct reads and cron creation. In deployments with custom resource handlers that register only assistants.read, omit an assistants.search handler, and have no global fallback handler, no applicable handler supplies an owner filter, allowing a low-privileged user to reference another user's private assistant through POST /runs or POST /threads/{thread_id}/runs. The run-creation response can disclose the private assistant's metadata, config, and context, and the run can execute using that assistant's configuration. Deployments without custom authorization handlers, or with an equivalent owner filter applied through a global handler or across all assistant events, are not affected. This issue is fixed in version 0.10.0. | ||||
| CVE-2026-55235 | 1 Langchain-ai | 1 Langgraph-api | 2026-11-10 | 5.9 Medium |
| langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, langgraph-api permits a run or cron to specify a relative webhook target that is delivered through an in-process loopback transport, and the authentication middleware treats that transport as internal without applying the authentication context used for external requests. In deployments that rely on per-user authorization to separate threads and runs, an authenticated user can direct a webhook to the server's own thread and run routes, allowing creation of a run on or modification of another user's thread and limited incorporation of the targeted thread's metadata into the created run record. The affected path requires webhook targets and per-user authorization boundaries; deployments that deliberately re-enable loopback delivery should restrict it to controlled same-process routes because those webhooks remain unauthenticated. This issue is fixed in version 0.10.0. | ||||
| CVE-2026-90994 | 3 Red Hat, Redhat, Sssd | 6 Enterprise Linux, Enterprise Linux, Openshift and 3 more | 2026-11-10 | 4 Medium |
| A flaw was found in sssd, specifically within the PAM (Pluggable Authentication Modules) responder's protocol v1 parser, pam_parse_in_data(). A local client with access to the PAM responder's UNIX socket can exploit this by negotiating protocol v1 and sending an empty or truncated PAM request body. This can trigger an out-of-bounds read, potentially causing the PAM responder to terminate or restart, leading to a local denial of service. | ||||
| CVE-2026-90995 | 4 Fedoraproject, Red Hat, Redhat and 1 more | 7 Sssd, Enterprise Linux, Enterprise Linux and 4 more | 2026-11-10 | 5.5 Medium |
| A flaw was found in SSSD (System Security Services Daemon). A local attacker with privileges to connect to the PAM (Pluggable Authentication Modules) responder socket can send a specially crafted protocol request. If the `pam_app_services` configuration is enabled and the service item is omitted from the request, a NULL pointer dereference can occur. This vulnerability leads to a denial of service, causing the PAM responder to crash and disrupt authentication services. | ||||
| CVE-2026-90996 | 4 Fedoraproject, Red Hat, Redhat and 1 more | 7 Sssd, Enterprise Linux, Enterprise Linux and 4 more | 2026-11-10 | 4 Medium |
| A flaw was found in sssd. A local unprivileged user could send a specially crafted request with a zero-length body to the Network Security Services (NSS) responder. This could lead to a denial-of-service condition, causing the NSS responder to become unstable or terminate. This vulnerability affects the availability of the system responder. | ||||
| CVE-2026-73449 | 1 Arista | 1 Eos | 2026-11-10 | 5.9 Medium |
| On affected platforms running Arista EOS with both 802.1X port authentication and the RADIUS proxy feature configured with dynamic authorization, a low-privileged attacker on an adjacent network segment who induces a RADIUS packet through a configured RADIUS proxy client can prevent RADIUS dynamic authorization messages, including Change-of-Authorization (CoA) and Disconnect-Requests as defined in RFC 5176, from being applied to locally authenticated 802.1X sessions. This allows an endpoint session that a RADIUS server or network access control system has ordered disconnected to remain authorized on the network. Both 802.1X port authentication with dynamic authorization and RADIUS proxy with dynamic authorization must be explicitly configured for a deployment to be exposed to this issue. This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks. | ||||
| CVE-2026-77191 | 1 Arista | 1 Eos | 2026-11-10 | 2.6 Low |
| An authenticated supplicant on an adjacent network may bypass intended network authorization policy and send unrestricted traffic during a brief window (milliseconds to seconds) between the completion of the authentication phase and the full enforcement of its assigned ACL. | ||||
| CVE-2026-91199 | 1 Refly-ai | 1 Refly | 2026-11-10 | 5 Medium |
| Refly through 1.1.0 contains a server-side request forgery vulnerability in the POST /v1/misc/scrape endpoint that fetches caller-supplied URLs without validating the scheme, host, or resolved address. Authenticated attackers can make the backend issue requests to loopback, private, and link-local addresses including cloud metadata services to read page titles and descriptions of internal resources. | ||||
| CVE-2026-75943 | 1 Arista | 1 Eos | 2026-11-10 | 2.6 Low |
| A brief (milliseconds to seconds) traffic leak may occur when an authenticated supplicant is removed, either via the clear dot1x host all CLI command or due to a supplicant timeout. During this window, the supplicant's traffic may pass without ACL enforcement. | ||||
| CVE-2026-75944 | 1 Arista | 1 Eos | 2026-11-10 | 2.6 Low |
| A race condition during supplicant re-authentication may leave a stale ACL entry that persists in the system. If the AclAgent subsequently restarts, this stale entry may be applied to new supplicants, resulting in incorrect access control enforcement. User interaction (an AclAgent restart by an administrator) is required for the unintended behavior to take effect. | ||||
| CVE-2026-75945 | 1 Arista | 1 Eos | 2026-11-10 | 2.6 Low |
| A race condition may cause a supplicant to remain in an authorized state after a clear dot1x host all command is issued. | ||||
| CVE-2026-88617 | 1 1024-lab | 1 Smart-admin | 2026-11-10 | 9.8 Critical |
| SmartAdmin v3.30.0 contains an authorization flaw in the configuration query endpoint. This allows a remote attacker to escalate privileges. | ||||
| CVE-2026-91772 | 1 Halo | 1 Halo | 2026-11-10 | 6.1 Medium |
| Halo through 2.26.1 contains an open redirect vulnerability in the anonymous thumbnail endpoint that fails to validate the uri query parameter. Attackers can craft malicious links on the trusted Halo domain that redirect visitors to arbitrary external sites, enabling phishing attacks and abuse of redirect-based trust relationships. | ||||
| CVE-2026-91778 | 1 Octopus | 1 Octopus Server | 2026-11-10 | N/A |
| In affected versions of Octopus Server, users with certain scoped permission sets could execute arbitrary scripts on a worker (including the Octopus Server built-in worker). Incorrect permission validation during script execution would allow the script to execute without the user possessing the required authorisation. | ||||
| CVE-2026-91786 | 2 Red Hat, Redhat | 3 Enterprise Linux, Enterprise Linux, Rhel Els | 2026-11-10 | 6.1 Medium |
| A flaw was found in GNOME Shell. When processing icons from a remote search provider via D-Bus, the system fails to validate the icon's declared dimensions against the actual data buffer size. A malicious or compromised remote search provider could exploit this by providing oversized icon dimensions, leading to an out-of-bounds read. This can cause the GNOME Shell process to crash, disrupting the user's session, and potentially disclose sensitive information from adjacent memory. | ||||