Export limit exceeded: 400992 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (400992 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-90446 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 4.3 Medium |
| An application programming interface endpoint accepts a user-supplied value and interpolates it directly into the path of a backend request to the underlying search and analytics data store, without restricting its contents. This allows an authenticated attacker to substitute an arbitrary backend path, causing the application's own elevated service credentials to be used against unintended internal endpoints. This could allow an attacker to enumerate or read internal configuration and administrative data from the backend data store that would otherwise be restricted. | ||||
| CVE-2026-90447 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 6.5 Medium |
| A routing rule selects between two different authentication mechanisms for the same downstream service based on the value of a client-supplied request header, rather than on any property the client cannot control. An authenticated user in possession of a shared service credential can set this header to route around the primary role-based authorization check and reach the alternate path's fixed, elevated role instead. This allows a low-privileged authenticated attacker who knows the shared credential to perform actions reserved for a higher-privileged role. | ||||
| CVE-2026-104887 | 2026-10-02 | N/A | ||
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-78409. Reason: This candidate is a duplicate of CVE-2026-78409. Notes: All CVE users should reference CVE-2026-78409 instead of this candidate | ||||
| CVE-2026-104886 | 2026-10-02 | N/A | ||
| ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2026-78410. Reason: This candidate is a duplicate of CVE-2026-78410. Notes: All CVE users should reference CVE-2026-78410 instead of this candidate | ||||
| CVE-2026-90448 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 6.5 Medium |
| A deployment mode intended to expose only read access to stored data proxies a set of application programming interface routes without restricting which request methods are allowed. One such route accepts a request that creates or overwrites a stored record, including an attacker-chosen identifier, using the application's own elevated backend credentials. This allows an authenticated user on a deployment intended to be read-only to forge or overwrite stored records that should not be modifiable in that deployment mode. | ||||
| CVE-2026-98164 | 1 Linux | 1 Linux Kernel | 2026-10-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Check write tracking in all address spaces kvm_gfn_is_write_tracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other. Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmu_try_to_unsync_pages() from marking an upper-level shadow page unsync and eventually triggering the BUG in pte_list_remove(). [invert direction of the conditional. - Paolo] | ||||
| CVE-2026-90449 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 6.5 Medium |
| When a particular authentication mode is configured, the reverse proxy forwards requests for a bundled third-party administrative interface directly to that interface without applying the gateway's own authentication requirement first. All access control for this administrative interface, which manages the credential store used to gate every other service in the deployment, is delegated entirely to that third-party interface's own login mechanism. Any authentication weakness in that bundled interface would compromise the credential store protecting the rest of the deployment. | ||||
| CVE-2026-42356 | 2 Apache, Redhat | 2 Http Server, Hummingbird | 2026-10-02 | 3.7 Low |
| Deployment of wrong handler vulnerability in Apache HTTP Server allows the target of some internal redirects from CGI programs to also be treated as CGI and executed. The target must already be in a directory enabled for CGI and have no other extension understood by mod_mime. This issue affects Apache HTTP Server: from 2.4.60 through 2.4.68. | ||||
| CVE-2026-90450 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 4.3 Medium |
| The application's role-authorization lookup defaults to granting access when a request handler's name is not present in its table of role requirements, rather than defaulting to deny. Any request handler that is not explicitly registered in this table is reachable by any authenticated user regardless of their assigned role, and any newly added handler is fail-open by default until explicitly added to the table. | ||||
| CVE-2026-42528 | 2 Apache, Redhat | 2 Http Server, Hummingbird | 2026-10-02 | 4.3 Medium |
| A memory calculation bug in mod_dav in Apache httpd 2.4.67 and earlier allows an attacker with permission to create WebDAV locks to crash server child processes. Users are recommended to upgrade to version 2.4.69, which fixes this issue | ||||
| CVE-2026-90451 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 5.9 Medium |
| An example environment-configuration file ships with a fixed, publicly-known secret value used to sign authentication cookies for a bundled packet-analysis component. A deployment that copies this example file into active configuration without running the setup routine that regenerates the value will use the known default, allowing an attacker aware of the default to forge valid authentication cookies for that component. | ||||
| CVE-2026-46729 | 3 Apache, Apache Software Foundation, Redhat | 3 Http Server, Apache Http Server, Hummingbird | 2026-10-02 | 7.5 High |
| NULL Pointer Dereference vulnerability in Apache HTTP Servers mod_heartmonitor over unicast listener. This issue affects Apache HTTP Server: from 2.4.0 through 2.4.68. | ||||
| CVE-2020-8664 | 2 Envoyproxy, Redhat | 2 Envoy, Service Mesh | 2026-10-02 | 5.3 Medium |
| CNCF Envoy through 1.13.0 has incorrect Access Control when using SDS with Combined Validation Context. Using the same secret (e.g. trusted CA) across many resources together with the combined validation context could lead to the “static” part of the validation context to be not applied, even though it was visible in the active config dump. | ||||
| CVE-2020-8661 | 2 Envoyproxy, Redhat | 3 Envoy, Openshift Service Mesh, Service Mesh | 2026-10-02 | 7.5 High |
| CNCF Envoy through 1.13.0 may consume excessive amounts of memory when responding internally to pipelined requests. | ||||
| CVE-2020-8659 | 3 Debian, Envoyproxy, Redhat | 4 Debian Linux, Envoy, Openshift Service Mesh and 1 more | 2026-10-02 | 7.5 High |
| CNCF Envoy through 1.13.0 may consume excessive amounts of memory when proxying HTTP/1.1 requests or responses with many small (i.e. 1 byte) chunks. | ||||
| CVE-2026-51895 | 1 Infiniflow | 1 Ragflow | 2026-10-02 | 6.5 Medium |
| Ragflow 0.24.0 and prior contains improper access control in update_metadata_setting (api/apps/kb_app.py). Depending on the exposed entry, an attacker can perform unauthorized cross-session or privilege-crossing operations. | ||||
| CVE-2026-90452 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 5.3 Medium |
| Requests from the reverse proxy to the identity-provider service for token discovery, introspection, and credential exchange do not verify the identity provider's server certificate. An attacker positioned on the network path between the proxy and the identity provider could impersonate the identity provider and issue forged authentication tokens accepted by the deployment. | ||||
| CVE-2026-47360 | 2 Apache, Redhat | 2 Http Server, Hummingbird | 2026-10-02 | 7.5 High |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache HTTP Server's mod_session_cookie module. When SessionCookieRemove changes across internal redirects, the session cookie may still be passed to a backend server. This issue affects Apache HTTP Server: from 2.4.0 through 2.4.68. | ||||
| CVE-2026-90453 | 1 Cisagov | 1 Malcolm | 2026-10-02 | 3.5 Low |
| A file-upload handler redirects the authenticated client's browser to a URL taken directly from that same request's Referer header, without validating it against the application's own origin. This allows an authenticated attacker to craft a request that causes another user's browser to be redirected to an arbitrary external destination after completing an upload. | ||||
| CVE-2026-98163 | 1 Linux | 1 Linux Kernel | 2026-10-02 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: cgroup: Avoid iteration of dying tasks with zero refcount The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L) | ||||