Search

Search Results (378544 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-70455 2 Rsync Project, Samba 2 Rsync, Rsync 2026-08-14 7.5 High
rsync 3.4.2 before 3.5.0 contains a denial of service vulnerability that allows a remote sender to exhaust system resources by specifying the --zt short alias for --compress-threads, which bypasses the refuse options directive's string matching on long option names. Attackers can specify --zt=N with a large value to spawn an unbounded number of Zstandard worker threads on the receiver, exhausting available thread and memory resources.
CVE-2026-69113 1 Capsoftware 1 Cap 2026-08-14 5.4 Medium
Cap v0.3.1 contains a broken access control vulnerability in the POST /api/video/comment endpoint that allows authenticated users to post comments on any private video without permission by supplying an arbitrary videoId in the request body. Attackers can inject comments into private video recordings belonging to other users, trigger comment notification emails to the video owner, and enumerate valid video IDs through response differences.
CVE-2026-63361 1 Limesurvey 1 Limesurvey 2026-08-14 N/A
LimeSurvey Community Edition 7.0.5 contains an authenticated reflected cross-site scripting vulnerability in the HTML editor popup endpoint. The text and name query parameters are passed through a blacklist sanitizer and then rendered without context-appropriate output encoding.
CVE-2026-58443 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 9.1 Critical
Public-only repository tokens can update private PR head branches
CVE-2026-58442 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 6.5 Medium
Repository migration SSRF via multi-answer DNS allow-list bypass
CVE-2026-58441 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 6.3 Medium
SSRF in restore-repo via unsanitized pull_request.yml Head.CloneURL
CVE-2026-58440 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 6.8 Medium
Webhooks created by a collaborator keep firing after their repo access is revoked → ongoing real-time exfiltration of private repo content (incomplete revocation cleanup in `DeleteCollaboration`)
CVE-2026-58439 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 8.1 High
Branch Protection Bypass via PR Retargeting Preserves Stale `official` Approval Flag
CVE-2026-58438 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 7.5 High
Cross-repository IDOR in issue-dependency removal lets an attacker tamper with and comment on private repos they cannot access
CVE-2026-58433 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 9.1 Critical
Team-repository linking endpoint bypasses the RepoAdminChangeTeamAccess organization setting
CVE-2026-58432 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 5.9 Medium
Missing Authorization and Authorization Bypass Through User-Controlled Key and Incorrect Permission Assignment for Critical Resource and Exposure of Sensitive Information to an Unauthorized Actor in code.gitea.io/gitea
CVE-2026-56750 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 9.1 Critical
Gitea Remember-Me Token Theft Not Invalidating Attacker Session
CVE-2026-56654 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 9.8 Critical
Privilege Escalation via Access Token Scope Escalation in API
CVE-2026-56443 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 9.6 Critical
Token public-only scope bypassed on Limited-visibility owners (Repository + Package categories) — residual after CVE-2026-25714 / PR #37118
CVE-2026-55987 1 Gitea 1 Gitea Open Source Git Server 2026-08-14 8.1 High
OAuth2 sign-in reactivates an administrator-deactivated account on auth sources without refresh tokens (incomplete fix of #38009)
CVE-2026-27871 1 Johnson Controls 1 Tl280 2026-08-14 N/A
Cwe-327 Use of a Broken or Risky Cryptographic Algorithm vulnerability in Johnson Controls TL280 allows Cryptanalytic Attack. This issue affects TL280: before 5.63.
CVE-2026-18403 1 Limesurvey 1 Limesurvey 2026-08-14 N/A
LimeSurvey Community Edition 7.0.5 contains an authenticated SQL injection vulnerability in the Central Participant Database (CPDB) workflow that copies survey participant tokens to the central participant list.
CVE-2026-12366 1 Zephyrproject 1 Zephyr 2026-08-14 8.8 High
Zephyr's dynamic kernel-object disposal path unref_check() in kernel/userspace/userspace.c frees an object's storage (k_free(dyn->data)) once its reference count reaches zero, after running a per-object-type cleanup. The cleanup switch handled only K_OBJ_MSGQ and K_OBJ_STACK; there was no K_OBJ_TIMER case. A dynamically-allocated, initialized, and armed k_timer keeps its embedded struct _timeout dnode linked in the global timeout queue (_timeout_q), so freeing the timer storage without cancelling the timeout leaves a dangling node in that queue. When the timer next expires, the timeout machinery walks _timeout_q and invokes z_timer_expiration_handler() on the freed node, dereferencing and writing freed (and reusable) kernel heap in kernel/ISR context. This is a deterministic use-after-free that does not depend on SMP: the queued node is simply never unlinked at free time. The disposal is reachable from an unprivileged user thread under CONFIG_USERSPACE + CONFIG_DYNAMIC_OBJECTS: a thread that holds the last permission on such a timer drops it via the k_object_release() syscall (or by exiting, through k_thread_perms_all_clear()), and can arm the timer itself via the k_timer_start() syscall. The free and the expiration handler run at kernel privilege while the actor is a user thread, so the bug is a sandbox-escape memory-corruption primitive usable for privilege escalation. The fix adds k_timer_cleanup() (cancel the timeout and wait for any in-flight handler) and calls it for K_OBJ_TIMER before freeing.
CVE-2026-12365 1 Zephyrproject 1 Zephyr 2026-08-14 5.8 Medium
A use-after-free exists in the Zephyr second-generation work queue (kernel/work.c) in the handling of delayable work timeouts. When a delayable work item's timeout has been dequeued and its handler work_timeout() is in flight (blocked acquiring the work-queue spinlock), a concurrent cancellation does not wait for that handler to finish. In unschedule_locked() the pre-fix code called z_abort_timeout(), which for an already-announcing record returns -EINVAL without removing it; cancel_async_locked() then observes the work as idle, so even k_work_cancel_delayable_sync() and k_work_flush_delayable() return without blocking on the in-flight handler. Because those are the APIs the kernel header documents as the safe way to cancel before freeing a k_work_delayable, a caller that frees the object immediately after a successful sync cancel can race the still-pending handler. work_timeout() subsequently dereferences the freed record: it reads to->dticks via z_is_timeout_handler_canceled() and, if the freed slot has been reused so the bail check fails, performs a read-modify-write of wp->flags (K_WORK_DELAYED_BIT) and submits work against a stale dw->queue pointer — a use-after-free read and write. The k_work API is kernel-mode only (no __syscall entry point), so this is a kernel-internal concurrency defect rather than a userspace privilege escalation. Triggering it requires an SMP build and a subsystem that schedules and then frees (or reschedules) a delayable work item in the narrow window while its timeout is announcing; an attacker able to influence the timing of such teardown (for example via connection churn driving subsystem timers) has a plausible but probabilistic path. The impact is kernel memory corruption or crash (denial of service). The fix makes unschedule_locked() wait, by spinning on z_try_abort_timeout() returning -EAGAIN while releasing and re-acquiring the work spinlock, until any in-flight handler completes before returning, and switches work_timeout() to atomic K_WORK_DELAYED_BIT ownership. This closes both the free-then-handler use-after-free and the related reschedule early-fire race.
CVE-2026-12364 1 Zephyrproject 1 Zephyr 2026-08-14 8.4 High
The user-space system-call verifier z_vrfy_z_log_msg_static_create() in subsys/logging/log_msg.c was a pure pass-through: it forwarded the caller-supplied source, desc, package, and data arguments directly to the kernel-mode implementation z_impl_z_log_msg_static_create() without performing any of the mandatory K_SYSCALL_* checks. Because z_log_msg_static_create() is declared __syscall, under CONFIG_USERSPACE any unprivileged user-mode thread can invoke it directly with fully attacker-controlled arguments. The kernel-mode handler dereferences each of these untrusted values: frontend_runtime_filtering() reads through the source pointer as a struct log_source_dynamic_data, cbprintf_package_copy() reads desc.package_len bytes from the package pointer, and z_log_msg_finalize() performs a memcpy() of desc.data_len bytes from the data pointer. With no verification, a user thread can supply arbitrary kernel addresses and arbitrary lengths, and the kernel will read from them. The impact is a kernel-mode denial of service (the kernel faults dereferencing an attacker-chosen pointer) and, where a log backend output is observable to the attacker, disclosure of arbitrary kernel memory copied into the emitted log message — a confidentiality breach across the user/kernel boundary that the userspace sandbox is meant to enforce. The reads do not corrupt kernel memory, so there is no out-of-bounds write primitive. The fix adds the required validation to the verifier: it bounds desc.package_len against Z_LOG_MSG_MAX_PACKAGE, rejects non-NULL/length mismatches, and applies K_SYSCALL_MEMORY_READ() to package, data, and (when runtime filtering with a frontend is enabled) source, so any out-of-bounds or kernel pointer now raises K_OOPS instead of being honored.