Updated 8 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,764exploited flaws on CISA’s list

35added in the last 30 days

456new WordPress flaws this week

390,714entries in the database

781 results · page 3 of 16

Sep 11, 2026A race condition in the document value layer of MongoDB Server can allow concurrent server threads to operate on the same internal memory without synchronizatioCVE-2026-89099 · Other software · MongoDB · reported by cna@mongodb.comHigh 7.7
A race condition in the document value layer of MongoDB Server can allow concurrent server threads to operate on the same internal memory without synchronization, leading to memory corruption. An authenticated user holding ordinary read-write privileges on a database may be able to trigger this condition over the normal client protocol, resulting in server termination and potential corruption of process memory with user-influenced content. Successful use of this issue may impact the confidentiality, integrity, and availability of the affected server process.
Product
MongoDB Server
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record jira.mongodb.org
Sep 8, 2026A client may issue HTTP/2 requests to a Jetty server that result in blocking writes that are never unblocked, eventually causing all threads to be blocked and tCVE-2026-12611 · Other software · Eclipse Foundation · reported by emo@eclipse.orgHigh 8.7
A client may issue HTTP/2 requests to a Jetty server that result in blocking writes that are never unblocked, eventually causing all threads to be blocked and the whole server to become unresponsive. This is caused by a race condition in the server when handling RST_STREAM frames and GOAWAY frames sent by the client. The race condition "resets" the HTTP2Flusher.terminated, previously set to a non-null value, to the null value, allowing entries to be enqueued in the flusher that however will never be processed. These unprocessed entries are the ones that would unblock the write-blocked threads.
Product
Eclipse Jetty
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com
Sep 4, 2026Slink before 1.12.3 fails to properly authorize access to image comment endpoints, allowing unauthenticated attackers to read comment threads via GET /api/imageCVE-2026-85605 · Other software · andrii-kryvoviaz · reported by VulnCheckMedium 6.9
Slink before 1.12.3 fails to properly authorize access to image comment endpoints, allowing unauthenticated attackers to read comment threads via GET /api/image/{imageId}/comments and server-sent-events subscriptions. Attackers who obtain image IDs out of band can retrieve full comment threads on public images and subscribe to live comment updates without authentication or authorization checks.
Product
slink
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Sep 3, 2026MOOS core-moos through 10.4.0 contains a denial of service vulnerability in the MOOSDB HTTP server that creates unbounded connections and threads without limitsCVE-2026-85450 · Other software · themoos · reported by VulnCheckHigh 8.7
MOOS core-moos through 10.4.0 contains a denial of service vulnerability in the MOOSDB HTTP server that creates unbounded connections and threads without limits. Attackers can open many connections and send endless header data to exhaust server threads and memory, causing service unavailability.
Product
core-moos
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Sep 3, 2026MOOS core-moos through 10.4.0 contains a denial of service vulnerability in MOOSCommServer::ListenLoop() where the accept thread performs a blocking receive witCVE-2026-85443 · Other software · themoos · reported by VulnCheckHigh 8.7
MOOS core-moos through 10.4.0 contains a denial of service vulnerability in MOOSCommServer::ListenLoop() where the accept thread performs a blocking receive without timeout during the wire-protocol handshake. An attacker can open a TCP connection to the MOOSDB port and send no data, causing the accept thread to block indefinitely while holding the socket-list lock, preventing all subsequent client connections.
Product
core-moos
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Sep 3, 2026In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix crash passing ERR_PTR to kthread_stop() In test_ringbuffer()'s out_free cCVE-2026-80730 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix crash passing ERR_PTR to kthread_stop() In test_ringbuffer()'s out_free cleanup loop, the check `!rb_threads[cpu]` only catches NULL entries and misses entries that hold an ERR_PTR. rb_threads[] is static, so unassigned slots are NULL. But when kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or -EINTR) in rb_threads[cpu] before the creation loop jumps to out_free. That entry is non-NULL, so the old `!ptr` check does not break, and the cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop() then dereferences the bogus pointer, crashing the kernel during the late_initcall self-test. crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Sep 1, 2026Uncontrolled Resource Consumption vulnerability in ash-project ash lets a slow asynchronous read spin a scheduler thread at full CPU while the framework waits fCVE-2026-82743 · Other software · ash-project · reported by 6b3ad84c-e1a6-4bf7-a703-f496b71e49dbLow 2.1
Uncontrolled Resource Consumption vulnerability in ash-project ash lets a slow asynchronous read spin a scheduler thread at full CPU while the framework waits for it. Ash.Actions.Read.AsyncLimiter.await_at_least_one/1 (lib/ash/actions/read/async_limiter.ex) waited for concurrent async read tasks by polling each with Task.yield(task, 0) in a tight loop rather than blocking. While every outstanding task is still running (a slow related-data load or calculation), the loop returns immediately and repeats, busy-spinning and holding a BEAM scheduler at full CPU for the whole duration of the slow read; concurrent slow reads tie up further schedulers. The fix waits with Task.yield_many (a non-blocking sweep followed by a blocking wait with timeout: :infinity), so the process sleeps until a task completes instead of spinning. This issue affects ash: from 2.19.0 before 3.32.2.
Product
ash
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record cna.erlef.org github.com
Aug 28, 2026Mastra through 1.63.0 contains an authentication bypass vulnerability in the memory API thread ownership validation when mapUserToResourceId callback is omittedCVE-2026-82273 · Other software · mastra-ai · reported by VulnCheckHigh 7.1
Mastra through 1.63.0 contains an authentication bypass vulnerability in the memory API thread ownership validation when mapUserToResourceId callback is omitted from configuration. Authenticated attackers can enumerate all threads via GET /api/memory/threads and read conversation history and metadata of other resource owners.
Product
mastra
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 28, 2026An attacker that can send mail to a user can craft a message header whose values are chosen to collide in an internal hash table, which makes the IMAP THREAD coCVE-2026-40017 · Other software · Open-Xchange GmbH · reported by security@open-xchange.comMedium 6.5
An attacker that can send mail to a user can craft a message header whose values are chosen to collide in an internal hash table, which makes the IMAP THREAD command consume CPU disproportionate to the size of the message. This is a separate issue from CVE-2026-40014 and is not addressed by that fix. Whenever a mail client issues a THREAD command on the affected mailbox, this can cause degradation or denial of service for IMAP. Monitor system for abnormal CPU usage, kill the offending process and remove the offending message from the affected mailbox. Update to non-vulnerable version. No publicly available exploits are known.
Product
OX Dovecot Pro
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record documentation.open-xchange.com
Aug 28, 2026An attacker that can send mail to a user can craft a message header that makes the IMAP THREAD command consume CPU disproportionate to the size of the message.CVE-2026-40014 · Other software · Open-Xchange GmbH · reported by security@open-xchange.comMedium 6.5
An attacker that can send mail to a user can craft a message header that makes the IMAP THREAD command consume CPU disproportionate to the size of the message. When a mail client issues a THREAD command on the affected mailbox, this can cause degradation or denial of service for IMAP. Monitor system for abnormal CPU usage, kill the offending process and remove the offending message from the affected mailbox. Update to non-vulnerable version. No publicly available exploits are known.
Product
OX Dovecot Pro
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record documentation.open-xchange.com
Aug 28, 2026In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_muCVE-2026-80659 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: defer reset until cmd_mutex is unlocked vub300_cmndwork_thread() holds cmd_mutex while it sends a command and waits for the command response. If the response wait times out, __vub300_command_response() kills the command URBs and then synchronously resets the USB device through usb_reset_device(). That reset path re-enters the driver through vub300_pre_reset(), which also takes cmd_mutex. The worker therefore tries to acquire the same mutex recursively while it is still holding it from the command path. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the real worker and timeout/reset carrier: vub300_cmndwork_thread() __vub300_command_response() usb_lock_device_for_reset() usb_reset_device() vub300_pre_reset() Lockdep reported the same-task recursive acquisition on cmd_mutex: WARNING: possible recursive locking detected ... (&test_vub300.cmd_mutex) ... at: usb_reset_device... [vuln_msv] ... (&test_vub300.cmd_mutex) ... at: vub300_cmndwork_thread+0x12/0x20 [vuln_msv] Workqueue: vub300_cmd_wq vub300_cmnd
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 27, 2026A single hostile AMQP message can terminate the entire consumer JVM (System.exit(99)), not just the listener thread — full availability loss for every workload CVE-2026-59275 · Other software · Spring · reported by security@vmware.comMedium 6.6
A single hostile AMQP message can terminate the entire consumer JVM (System.exit(99)), not just the listener thread — full availability loss for every workload co-located in that process. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier
Product
Spring AMQP
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record spring.io
Aug 26, 2026Analyzing a PDF with a deeply nested or cyclic table of contents can cause a StackOverflowError in the ingestion thread.CVE-2026-47851 · Other software · Spring · reported by security@vmware.comHigh 7.5
Analyzing a PDF with a deeply nested or cyclic table of contents can cause a StackOverflowError in the ingestion thread. Spring AI 2.0.0 Spring AI 1.1.0 - 1.1.8 Spring AI 1.0.0 - 1.0.9
Product
Spring AI
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record spring.io
Aug 24, 2026Multiple vulnerabilities exist in OpenThread's handling of MLE packets.CVE-2025-36939 · Computers, phones & browsers · Google · reported by dsap-vuln-management@google.comCritical 10
Multiple vulnerabilities exist in OpenThread's handling of MLE packets. An authenticated attacker on the same Thread network could send specially crafted packets to cause a denial of service. These issues include triggerable assertion failures and a stack-based buffer overflow.
Product
Nest
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record support.google.com
Aug 22, 2026In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroedCVE-2026-74670 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: ipvs: stop estimator after disabled calc phase IPVS estimator kthread 0 starts with zeroed chain and tick limits until its initial calculation phase completes. If network namespace teardown clears ipvs->enable during that phase, ip_vs_est_calc_phase() can return without installing positive limits. The kthread can then continue into its main loop and drain est_temp_list with zero chain_max, tick_max and est_max_count values. Each enqueue consumes one available tick row, but est_count never reaches the zero est_max_count value. After all rows are consumed, the row lookup returns IPVS_EST_NTICKS and ip_vs_enqueue_estimator() writes past the ticks and tick_len arrays. Exit kthread 0 after the calculation phase if the kthread is stopping or IPVS has been disabled. That keeps temporary estimators from being drained after the limits failed to initialize. Estimator kthreads can now self-exit before teardown or reload stops kd->task. Keep an extra task reference after creation and release it with kthread_stop_put(), so kd->task remains valid until the stop paths consume that reference.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 18, 2026The Zephyr kernel validates the k_thread_join() and k_thread_abort() system calls (declared __syscall in include/zephyr/kernel.h) through thread_obj_validate() CVE-2026-12631 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The Zephyr kernel validates the k_thread_join() and k_thread_abort() system calls (declared __syscall in include/zephyr/kernel.h) through thread_obj_validate() in kernel/thread.c. Its default switch branch is the access-denied path, taken when k_object_validate() returns -EPERM (the calling user thread was never granted access to the target thread object) or -EBADF (the supplied pointer is not a registered kernel object of the right type). That branch invoked K_OOPS(K_SYSCALL_VERIFY_MSG(ret, "access denied")), but K_SYSCALL_VERIFY_MSG treats a true expression as success; the non-zero error code ret therefore read as "verified OK", the kernel oops was never raised, and control fell through to CODE_UNREACHABLE. Because k_thread_join() and k_thread_abort() are system calls, an unprivileged user-mode thread (under CONFIG_USERSPACE) can reach this denial path directly by calling either syscall on a thread object it does not own. Instead of the offending thread being cleanly terminated, execution reaches __builtin_unreachable() while running in supervisor mode inside the syscall handler. On Clang builds CODE_UNREACHABLE emits an illegal-instruction trap, so a user thread can determinis
Product
zephyr
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Aug 18, 2026ArcadeDB before 26.8.1 fails to bind the authenticated principal on the gRPC transaction executor thread in beginTransaction, allowing authenticated readers to CVE-2026-75843 · Other software · ArcadeData · reported by VulnCheckCritical 9.4
ArcadeDB before 26.8.1 fails to bind the authenticated principal on the gRPC transaction executor thread in beginTransaction, allowing authenticated readers to execute JavaScript commands without scripting authorization checks. Attackers can execute executeCommand with a transaction ID to run unrestricted JavaScript that creates server-wide administrator accounts.
Product
arcadedb
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com vulncheck.com
Aug 17, 2026Mattermost versions 10.11.x <= 10.11.20, 11.7.x <= 11.7.5 Mattermost fails to remove thread membership records when a user is removed from or leaves a team, whiCVE-2026-9693 · Other software · Mattermost · reported by responsibledisclosure@mattermost.comLow 3.5
Mattermost versions 10.11.x <= 10.11.20, 11.7.x <= 11.7.5 Mattermost fails to remove thread membership records when a user is removed from or leaves a team, which allows a previously removed user who is later re-invited to the team to view private channel thread root post content and metadata via the team threads API.. Mattermost Advisory ID: MMSA-2026-00682
Product
Mattermost
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record mattermost.com
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configuresCVE-2026-74547 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: hwmon: (adt7470) Fix busy-loop and I2C flooding in update thread When userspace configures 'auto_update_interval' to 0 via sysfs, the background kthread executes schedule_timeout_interruptible(0), which returns immediately. If 'num_temp_sensors' is concurrently or previously set to 0, the msleep_interruptible() delay inside adt7470_read_temperatures() also becomes 0. This combination forces the background thread into a tight, unbounded busy-loop, hogging the CPU and flooding the I2C bus with a continuous stream of transactions. Fix this vulnerability by raising the lower limit of the clamp_val in auto_update_interval_store() from 0 to 500 milliseconds. This guarantees a reasonable minimum sleep window between sensor updates, protecting the system from intentional or accidental I2C bus denial of service.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: netdev-genl: report NAPI thread PID in the caller's pid namespace netdev_nl_napi_fill_one(CVE-2026-72127 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: netdev-genl: report NAPI thread PID in the caller's pid namespace netdev_nl_napi_fill_one() reports the NAPI kthread PID in NETDEV_A_NAPI_PID using task_pid_nr(), which returns the PID in the initial pid namespace. NETDEV_CMD_NAPI_GET does not have GENL_ADMIN_PERM and the netdev genl family is netnsok, so a caller in a child pid namespace can issue it. That caller then sees the kthread's global PID, even though the kthread is not visible in its pid namespace, where the value should be 0. Translate the PID through the caller's pid namespace, the same way commit 3799c2570982 ("io_uring/fdinfo: translate SqThread PID through caller's pid_ns") did for the io_uring SQPOLL thread. The doit and dumpit paths both run synchronously in the caller's context, so task_active_pid_ns(current) is the caller's pid namespace.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: dm: avoid leaking the caller's thread keyring via the table device file The refactoring inCVE-2026-72103 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.3
In the Linux kernel, the following vulnerability has been resolved: dm: avoid leaking the caller's thread keyring via the table device file The refactoring in commit a28d893eb327 ("md: port block device access to file") accidentally causes the caller's thread keyring to be kept alive long beyond the caller's lifetime. As a result, "cryptsetup luksSuspend" silently fails to wipe the LUKS volume key from memory. In detail: "cryptsetup luksOpen" uses its supposedly ephemeral thread keyring to pass the volume key to the kernel. dm-crypt's crypt_set_keyring_key() copies the key material into its own crypt_config structure and then drops its own reference to the key in the keyring with key_put(). With this fix, restoring pre-v6.9 behavior, the copy in the thread keyring is then promptly garbage collected, such that exactly one copy of the volume key remains. This single copy is correctly wiped from memory on "cryptsetup luksSuspend". Without this fix, the thread keyring and the volume key in it remains. This second copy is only freed on "luksClose". "luksSuspend" neither knows about this copy nor has any way to remove it, so the key remains recoverable from RAM after a suspend that
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 13, 2026IBM i 7.6, 7.5, 7.4, and 7.3 could allow an authenticated attacker to force a NetServer server thread exception, caused by an integer overflow during bounds cheCVE-2026-18671 · Other software · IBM · reported by psirt@us.ibm.comMedium 6.5
IBM i 7.6, 7.5, 7.4, and 7.3 could allow an authenticated attacker to force a NetServer server thread exception, caused by an integer overflow during bounds checking in request processing. The attacker could exploit this vulnerability to cause a temporary denial of service.
Product
i
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record ibm.com
Aug 13, 2026IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local attacker to gain elevated privileges due to improper management of thread authority swaps.CVE-2026-18101 · Other software · IBM · reported by psirt@us.ibm.comHigh 8.8
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a local attacker to gain elevated privileges due to improper management of thread authority swaps.
Product
i
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record ibm.com
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks loCVE-2026-68334 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires devicCVE-2026-68319 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Aug 3, 2026A stored cross-site scripting (XSS) vulnerability exists in osTicket 1.18.3 due to improper sanitization of the thread entry title field.CVE-2026-38446 · Other software · reported by MITREMedium 6.1
A stored cross-site scripting (XSS) vulnerability exists in osTicket 1.18.3 due to improper sanitization of the thread entry title field. User-controlled input in the title is stored without adequate HTML escaping and later rendered in multiple staff-facing templates without proper output encoding. An attacker can inject arbitrary JavaScript by submitting a crafted ticket reply or email with a malicious subject line.
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 31, 2026LightFTP 2.3.1 contains a residual race condition vulnerability (an incomplete fix for CVE-2024-11144) in the worker_thread_cleanup() function of ftpserv.c thatCVE-2026-67607 · Other software · hfiref0x · reported by VulnCheckHigh 8.2
LightFTP 2.3.1 contains a residual race condition vulnerability (an incomplete fix for CVE-2024-11144) in the worker_thread_cleanup() function of ftpserv.c that allows remote unauthenticated attackers to destabilize or crash the daemon by triggering unsynchronized access to shared per-connection state without holding the required mutex lock. Attackers can send a data-transfer command such as LIST followed immediately by ABOR to exploit the missing synchronization on shared context and detached thread id reuse, resulting in daemon destabilization or crash which can lead to a denial of service. The 2.3.1 patch only narrowed the timing window (an extra re-check and reordered cleanup), it never added the missing lock, so the underlying race remains.
Product
LightFTP
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com vulncheck.com
Jul 30, 2026Tutor LMS: Does not properly verify that a user has access to the course a Q&A thread belongs to before returning or writing to that threadCVE-2026-14310 · WordPress plugins & themes · reported by WPScanMedium 5.4
The Tutor LMS WordPress plugin before 4.0.0 does not properly verify that a user has access to the course a Q&A thread belongs to before returning or writing to that thread, allowing authenticated users with subscriber-level access and above who can access any single course to read the Q&A threads of other courses and to inject replies into them.
Product
Tutor LMS
Fixed in
4.0.0
What to do
Update Tutor LMS to 4.0.0 or newer.
Full record and what to do →NVD record wpscan.com
Jul 25, 2026In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thrCVE-2026-10681 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
In Zephyr's userspace dynamic-objects subsystem, thread_idx_alloc() in kernel/userspace/userspace.c allocated a new thread permission index from the global _thread_idx_map[] bitmap without holding lists_lock. On SMP systems, two user-mode threads invoking the k_object_alloc(K_OBJ_THREAD) syscall concurrently can both observe the same low free bit, perform the same non-atomic RMW to clear it, and return the identical tidx. The two newly created K_OBJ_THREAD objects are then assigned the same thread_id, so the two user threads alias a single bit position in every kernel object's perms[] bitfield: any subsequent grant of access on a kernel object to one thread is implicitly a grant to the other, defeating userspace ACL isolation. A secondary lost-update window between the unlocked &=~BIT() in alloc and the locked |= BIT() in thread_idx_free() can also leak entries from the thread-index pool. The defect is reachable from any user-mode thread via the unrestricted __syscall k_object_alloc and is gated on CONFIG_USERSPACE, CONFIG_DYNAMIC_OBJECTS, and CONFIG_SMP. The flaw was introduced when the per-thread permission index was added in 2018 and is present in every release up to and incl
Product
zephyr
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() waCVE-2026-64469 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF in binder_thread_release() When a thread exits, binder_thread_release() walks its transaction stack to clear the t->from and t->to_proc that correspond with the exiting thread. However, a process dying in parallel might attempt to kfree some of these transactions. And if one of them has no associated t->to_proc, the t->to_proc->inner_lock will not be acquired. This means that transaction accesses in binder_thread_release() after t->to_proc has been cleared might race with binder_free_transaction() and cause a use-after-free error as reported by KASAN: ================================================================== BUG: KASAN: slab-use-after-free in binder_thread_release+0x5d0/0x798 Write of size 8 at addr ffff000016627500 by task X/715 CPU: 17 UID: 0 PID: 715 Comm: X Not tainted 7.1.0-rc5-00149-g8fde5d1d47f6 #30 PREEMPT Hardware name: linux,dummy-virt (DT) Call trace: binder_thread_release+0x5d0/0x798 binder_ioctl+0x12c0/0x299c [...] Allocated by task 717 on cpu 18 at 67.267803s: __kasan_kmalloc+0xa0/0xbc __kmalloc_cache_noprof+0x174/0x444 binder_transaction+
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_iCVE-2026-64329 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove The threaded IRQ handler ccg_irq_handler() calls ucsi_notify_common(), which on a connector-change event calls ucsi_connector_change() and schedules connector work. In ucsi_ccg_remove(), ucsi_destroy() frees uc->ucsi (kfree) before free_irq() is called, so a handler invocation already in flight may access the freed object after ucsi_destroy(). CPU 0 (remove) | CPU 1 (threaded IRQ) ucsi_destroy(uc->ucsi) | ccg_irq_handler() kfree(ucsi) // FREE | ucsi_notify_common(uc->ucsi) // USE Move free_irq() before ucsi_destroy() in the remove path. It is kept after ucsi_unregister(): ucsi_unregister() cancels connector work whose handler issues GET_CONNECTOR_STATUS through ucsi_send_command_common(), which waits for a completion that is signalled from the IRQ handler, so the IRQ must stay active until that work has been cancelled. The probe error path already orders free_irq() before ucsi_destroy(). This bug was found by static analysis.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Jul 25, 2026In the Linux kernel, the following vulnerability has been resolved: svcrdma: wake sq waiters when the transport closes Threads parked in svc_rdma_sq_wait() onCVE-2026-64281 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: svcrdma: wake sq waiters when the transport closes Threads parked in svc_rdma_sq_wait() on sc_sq_ticket_wait or sc_send_wait can hang indefinitely in TASK_UNINTERRUPTIBLE state across transport teardown, pinning svc_xprt references and blocking svc_rdma_free(). The close path sets XPT_CLOSE before invoking xpo_detach and both wait_event predicates include an XPT_CLOSE term, but the predicates are re-evaluated only on wakeup. sc_sq_ticket_wait has no completion-driven wake path; it is advanced solely by the chained ticket handoff inside svc_rdma_sq_wait() itself. Without an explicit wake at close, parked threads never observe XPT_CLOSE, hold their svc_xprt_get reference forever, and svc_rdma_free() blocks on xpt_ref dropping to zero. Two close entry points reach this transport. Local teardown runs svc_rdma_detach() from svc_handle_xprt() -> svc_delete_xprt() -> xpo_detach() on a worker thread. A remote disconnect arrives at svc_rdma_cma_handler(), which calls svc_xprt_deferred_close(): that sets XPT_CLOSE and enqueues the transport but does not access either RDMA waitqueue, so a worker already parked in svc_rdma
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Jul 24, 2026ProfileGrid: Does not perform any authorization or ownership check on some of its private-message thread actionsCVE-2026-12689 · WordPress plugins & themes · reported by WPScanMedium 5.4
The ProfileGrid WordPress plugin before 5.9.9.7 does not perform any authorization or ownership check on some of its private-message thread actions, allowing authenticated users with Subscriber-level access and above to soft-delete, tamper with the metadata of, and mark as read other users' private message threads.
Product
ProfileGrid
Fixed in
5.9.9.7
What to do
Update ProfileGrid to 5.9.9.7 or newer.
Full record and what to do →NVD record wpscan.com
Jul 21, 2026The CONFIG_USERSPACE syscall verifier z_vrfy_k_poll() in kernel/poll.c allocates a kernel-side copy of the user-supplied k_poll_event[] via z_thread_malloc() anCVE-2026-10677 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The CONFIG_USERSPACE syscall verifier z_vrfy_k_poll() in kernel/poll.c allocates a kernel-side copy of the user-supplied k_poll_event[] via z_thread_malloc() and then validates each event's object handle. Before this fix, validation used K_OOPS(K_SYSCALL_OBJ(...)) inline inside the loop, which kills the calling thread without freeing events_copy. A user thread can pass num_events >= 1 with a forged object handle to leak the allocation; because newly spawned user threads inherit the parent's resource_pool (kernel/thread.c), an attacker spawns sacrificial threads to repeat the leak until the shared kernel heap is exhausted. Once depleted, legitimate kernel allocations from that pool (k_queue alloc nodes, k_msgq buffers, future k_poll calls, etc.) fail, causing a system-level denial of service. The fix replaces each inline K_OOPS with a conditional goto oops_free so the buffer is freed before the thread is killed. Affects Zephyr releases from v1.12.0 (when k_poll was first exposed to user mode) through v4.4.1.
Product
zephyr
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 14, 2026NVIDIA TensorRT-LLM contains a vulnerability in the OpenAI-compatible inference API where an attacker could trigger a reachable assertion in the sampler thread.CVE-2026-47475 · Other software · NVIDIA · reported by psirt@nvidia.comMedium 6.2
NVIDIA TensorRT-LLM contains a vulnerability in the OpenAI-compatible inference API where an attacker could trigger a reachable assertion in the sampler thread. A successful exploit of this vulnerability might lead to denial of service.
Product
TensorRT-LLM
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record nvd.nist.gov cve.org
Jul 14, 2026The CONFIG_USERSPACE verification handler for the k_thread_name_copy() system call (z_vrfy_k_thread_name_copy() in kernel/thread.c) calls k_object_find() on theCVE-2026-10670 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 5.5
The CONFIG_USERSPACE verification handler for the k_thread_name_copy() system call (z_vrfy_k_thread_name_copy() in kernel/thread.c) calls k_object_find() on the caller-supplied thread pointer and then dereferences the returned struct k_object without checking it for NULL. k_object_find() returns NULL whenever the supplied pointer is not a registered (static or dynamic) kernel object. The pre-fix guard tested thread == NULL instead of ko == NULL, so an unprivileged user-mode thread that invokes k_thread_name_copy() with any non-NULL but unregistered pointer (e.g. an arbitrary address) passes the NULL test, after which the verifier reads ko->type through a NULL pointer. Because the syscall verifier runs in supervisor mode, this NULL dereference is a kernel-mode fault that halts or reboots the system, allowing untrusted user code to crash the kernel across the userspace security boundary (denial of service). The marshaller passes the thread argument to the verifier without any prior K_SYSCALL_OBJ validation, so the bad pointer reaches the defect directly. The flaw affects builds with CONFIG_USERSPACE and CONFIG_THREAD_NAME enabled and has been present since the special-case lookup
Product
zephyr
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 4, 2026A flaw has been found in RT-Thread up to 5.2.2.CVE-2026-14629 · Other software · reported by VulDBLow 2.1
A flaw has been found in RT-Thread up to 5.2.2. Affected is the function read/write/sys_ioctl of the file components/lwp/lwp_syscall.c of the component Parameter Handler. Executing a manipulation can lead to divide by zero. The attack may be launched remotely. The exploit has been published and may be used. The pull request to fix this issue awaits acceptance.
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 3, 2026A weakness has been identified in RT-Thread up to 5.0.2.CVE-2026-14607 · Other software · reported by VulDBMedium 5.4
A weakness has been identified in RT-Thread up to 5.0.2. This affects the function sys_getaddrinfo of the file components/lwp/lwp_syscall.c. Executing a manipulation of the argument ai_addr can lead to memory corruption. The attack can only be executed locally. The exploit has been made available to the public and could be used for attacks. The pull request to fix this issue awaits acceptance.
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 3, 2026A security flaw has been discovered in RT-Thread up to 5.0.2.CVE-2026-14606 · Other software · reported by VulDBHigh 7.1
A security flaw has been discovered in RT-Thread up to 5.0.2. Affected by this issue is the function CAN_Receive in the library bsp/synwit/libraries/SWM341_CSL/CMSIS/DeviceSupport/SWM341.h of the component SWM341 CAN Handler. Performing a manipulation results in stack-based buffer overflow. The attack needs to be approached locally. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 3, 2026A vulnerability was identified in RT-Thread up to 5.0.2.CVE-2026-14605 · Other software · reported by VulDBHigh 7.1
A vulnerability was identified in RT-Thread up to 5.0.2. Affected by this vulnerability is the function recvmsg in the library bsp/loongson/ls1cdev/libraries/ls1c_can.h of the component ls1c CAN Handler. Such manipulation leads to stack-based buffer overflow. Local access is required to approach this attack. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jul 1, 2026In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded CVE-2026-53352 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Medium 4.7
In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: <TASK> do_signal_stop+0x3be/0x5c0 k
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Jun 30, 2026The asynchronous SNTP client in Zephyr (subsys/net/lib/sntp/sntp.c, sntp_close_async) closed the UDP socket file descriptor directly from the calling thread immCVE-2026-10655 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.5
The asynchronous SNTP client in Zephyr (subsys/net/lib/sntp/sntp.c, sntp_close_async) closed the UDP socket file descriptor directly from the calling thread immediately after detaching it from the network socket service, without synchronizing with the socket-service poll thread. The socket service thread polls each socket via zvfs_poll, which (in zsock_poll_prepare_ctx) registers a k_poll_event pointing into the socket's net_context (&ctx->recv_q) and then blocks in k_poll without holding a reference or lock. net_context objects are allocated from a fixed pool (contexts[CONFIG_NET_MAX_CONTEXTS]) and reused after close. When sntp_close_async is invoked from a different thread than the poll thread (in the in-tree consumer subsys/net/lib/config/init_clock_sntp.c, the SNTP timeout handler runs on the system workqueue while the socket service thread is blocked in poll on the same fd), the close frees and may reuse the net_context while the poll thread still has a poller node linked into the freed object, resulting in a use-after-free / object confusion of kernel poll structures. The SNTP timeout path is the normal no-response failure mode, so a network peer or off-path attacker who d
Product
zephyr
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com github.com
Jun 26, 2026When used to deliver a signal to a specific thread, thr_kill2(2) called p_cansignal() to determine whether the operation was permitted but did not check the resCVE-2026-45256 · Other software · FreeBSD · reported by secteam@freebsd.orgMedium 5.5
When used to deliver a signal to a specific thread, thr_kill2(2) called p_cansignal() to determine whether the operation was permitted but did not check the result before delivering the signal. The signal was sent even when the permission check failed. The system call returned the resulting error to the caller, but by then the signal had already been delivered. The missing check allows an unprivileged local user who knows or can guess a target's process and thread IDs to send any signal to a process they would not normally be permitted to signal, including processes owned by other users or by root. The same check enforces jail boundaries, so a jailed process can signal processes on the host or in other jails. Thread IDs are allocated globally and sequentially, and so can be discovered by brute force with no visibility into the target. An attacker can stop or terminate arbitrary processes, including critical system daemons, resulting in a Denial of Service (DoS).
Product
FreeBSD
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record security.freebsd.org
Jun 25, 2026An issue in the pthread_rwlockattr_setpshared() function of relibc commit 61f42d allows attackers to cause a Denial of Service (DoS) via a crafted input.CVE-2026-38637 · Other software · reported by MITREHigh 7.5
An issue in the pthread_rwlockattr_setpshared() function of relibc commit 61f42d allows attackers to cause a Denial of Service (DoS) via a crafted input.
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record github.com gitlab.redox-os.org
Jun 24, 2026In the Linux kernel, the following vulnerability has been resolved: futex: Drop CLONE_THREAD requirement for private default hash alloc Currently need_futex_hCVE-2026-52973 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: futex: Drop CLONE_THREAD requirement for private default hash alloc Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Jun 24, 2026In the Linux kernel, the following vulnerability has been resolved: Revert "wireguard: device: enable threaded NAPI" This reverts commit 933466fc50a8e4eb167acCVE-2026-52945 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: Revert "wireguard: device: enable threaded NAPI" This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream. We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows: - Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wg_prev_queue_enqueue fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's rx_queue is reached. - Also, bpftrace shows that wg_packet_rx_poll for
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Jun 19, 2026The security fix for CVE-2025-0728 in eclipse-threadx NetX Duo refactors error handling in the HTTP server PUT process to use a shared cleanup label, but this uCVE-2026-11576 · Other software · Eclipse Foundation · reported by emo@eclipse.orgHigh 7.5
The security fix for CVE-2025-0728 in eclipse-threadx NetX Duo refactors error handling in the HTTP server PUT process to use a shared cleanup label, but this unified cleanup path unconditionally calls fx_file_close() even when the file was never successfully opened. Multiple error branches jump to the shared cleanup label before any file open operation has occurred, causing fx_file_close() to operate on an uninitialized file handle, leading to undefined behavior, double-close issues, or memory corruption.
Product
Eclipse ThreadX - NetX Duo
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record gitlab.eclipse.org
Jun 18, 2026UBB.threads is vulnerable to Denial of Service (DoS).CVE-2026-54224 · Other software · UBB Systems · reported by cvd@cert.plHigh 7.1
UBB.threads is vulnerable to Denial of Service (DoS). By sending multiple concurrent requests to view any user profile on instances with many registered users, an authenticated attacker can easily exhaust database resources and completely deny access to the application for other users. Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 7.7.5 but may also affect other versions.
Product
UBB.threads
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record cert.pl ubbcentral.com
Jun 18, 2026UBB.threads is vulnerable to Path traversal, allowing attackers with privilege to edit templates to read and write any file on the application’s server that appCVE-2026-54223 · Other software · UBB Systems · reported by cvd@cert.plHigh 8.6
UBB.threads is vulnerable to Path traversal, allowing attackers with privilege to edit templates to read and write any file on the application’s server that application has privileges to, what results in Remote Code Execution. Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 7.7.5 but may also affect other versions.
Product
UBB.threads
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record cert.pl ubbcentral.com
Jun 18, 2026UBB.threads is vulnerable to Blind SQL Injection, allowing attackers with access to the Members in Control Panel to interact with the underlying database.CVE-2026-54222 · Other software · UBB Systems · reported by cvd@cert.plHigh 8.6
UBB.threads is vulnerable to Blind SQL Injection, allowing attackers with access to the Members in Control Panel to interact with the underlying database. Due to insufficient input sanitization, an attacker can extract sensitive information, such as user credentials, by manipulating SQL queries through time-based or boolean-based techniques. Because vendor contact attempts were unsuccessful, the vulnerability has only been confirmed in version 7.7.5 but may also affect other versions.
Product
UBB.threads
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record cert.pl ubbcentral.com

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Vulnerability database

The flaws that hit local websites, every Friday.

Tell us what you're building.