| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The WordPress Online Booking and Scheduling Plugin – Bookly plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Color Profile parameter in all versions up to, and including, 23.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with the staff member role and Subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| Cross-Site Request Forgery (CSRF) vulnerability in Chaser324 Featured Posts Scroll featured-posts-scroll allows Stored XSS.This issue affects Featured Posts Scroll: from n/a through <= 1.25. |
| Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries. Prior to version 3.3.0, Open Source Harness git LFS server (Gitness) exposes api to retrieve and upload files via git LFS. Implementation of upload git LFS file api is vulnerable to arbitrary file write. Due to improper sanitization for upload path, a malicious authenticated user who has access to Harness Gitness server api can use a crafted upload request to write arbitrary file to any location on file system, may even compromise the server. Users using git LFS are vulnerable. This issue has been patched in version 3.3.0. |
| Cross-site scripting vulnerability exists in My WP Customize Admin/Frontend versions prior to ver 1.24.1. If a malicious administrative user customizes the administrative page with some malicious contents, an arbitrary script may be executed on the web browser of the other users who are accessing the page. |
| A vulnerability was found in Casdoor up to 1.335.0. It has been classified as problematic. Affected is an unknown function of the file /conf/app.conf of the component Configuration File Handler. The manipulation leads to files or directories accessible. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-266838 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way. |
| In the Linux kernel, the following vulnerability has been resolved:
net: fix skb leak in __skb_tstamp_tx()
Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with
TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with
zerocopy skbs. But it ended up adding a leak of its own. When
skb_orphan_frags_rx() fails, the function just returns, leaking the skb
it just cloned. Free it before returning.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc. |
| SimpleXLSX is software for parsing and retrieving data from Excel XLSx files. Starting in version 1.0.12 and prior to version 1.1.12, when calling the extended toHTMLEx method, it is possible to execute arbitrary JavaScript code. Version 1.1.12 fixes the issue. As a workaround, don't use direct publication via toHTMLEx. |
| Exposure of Sensitive System Information Due to Uncleared Debug Information vulnerability in 1clickmigration 1 Click WordPress Migration 1-click-migration allows Retrieve Embedded Sensitive Data.This issue affects 1 Click WordPress Migration: from n/a through <= 2.5.7. |
| In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Release the label when replacing existing ct entry
Cited commit doesn't release the label mapping when replacing existing ct
entry which leads to following memleak report:
unreferenced object 0xffff8881854cf280 (size 96):
comm "kworker/u48:74", pid 23093, jiffies 4296664564 (age 175.944s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000002722d368>] __kmalloc+0x4b/0x1c0
[<00000000cc44e18f>] mapping_add+0x6e8/0xc90 [mlx5_core]
[<000000003ad942a7>] mlx5_get_label_mapping+0x66/0xe0 [mlx5_core]
[<00000000266308ac>] mlx5_tc_ct_entry_create_mod_hdr+0x1c4/0xf50 [mlx5_core]
[<000000009a768b4f>] mlx5_tc_ct_entry_add_rule+0x16f/0xaf0 [mlx5_core]
[<00000000a178f3e5>] mlx5_tc_ct_block_flow_offload_add+0x10cb/0x1f90 [mlx5_core]
[<000000007b46c496>] mlx5_tc_ct_block_flow_offload+0x14a/0x630 [mlx5_core]
[<00000000a9a18ac5>] nf_flow_offload_tuple+0x1a3/0x390 [nf_flow_table]
[<00000000d0881951>] flow_offload_work_handler+0x257/0xd30 [nf_flow_table]
[<000000009e4935a4>] process_one_work+0x7c2/0x13e0
[<00000000f5cd36a7>] worker_thread+0x59d/0xec0
[<00000000baed1daf>] kthread+0x28f/0x330
[<0000000063d282a4>] ret_from_fork+0x1f/0x30
Fix the issue by correctly releasing the label mapping. |
| Cross-Site Request Forgery (CSRF) vulnerability in Hossni Mubarak JobWP jobwp allows Cross Site Request Forgery.This issue affects JobWP: from n/a through <= 2.3.9. |
| Directory Traversal vulnerability in Punkbuster pbsv.d64 2.351, allows remote attackers to execute arbitrary code. |
| In the Linux kernel, the following vulnerability has been resolved:
PCI/DOE: Fix destroy_work_on_stack() race
The following debug object splat was observed in testing:
ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510
WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0
...
Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work
RIP: 0010:debug_print_object+0x7d/0xb0
...
Call Trace:
? debug_print_object+0x7d/0xb0
? __pfx_doe_statemachine_work+0x10/0x10
debug_object_free.part.0+0x11b/0x150
doe_statemachine_work+0x45e/0x510
process_one_work+0x1d4/0x3c0
This occurs because destroy_work_on_stack() was called after signaling
the completion in the calling thread. This creates a race between
destroy_work_on_stack() and the task->work struct going out of scope in
pci_doe().
Signal the work complete after destroying the work struct. This is safe
because signal_task_complete() is the final thing the work item does and
the workqueue code is careful not to access the work struct after. |
| In the Linux kernel, the following vulnerability has been resolved:
refscale: Fix uninitalized use of wait_queue_head_t
Running the refscale test occasionally crashes the kernel with the
following error:
[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8
[ 8569.952900] #PF: supervisor read access in kernel mode
[ 8569.952902] #PF: error_code(0x0000) - not-present page
[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0
[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI
[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021
[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190
:
[ 8569.952940] Call Trace:
[ 8569.952941] <TASK>
[ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale]
[ 8569.952959] kthread+0x10e/0x130
[ 8569.952966] ret_from_fork+0x1f/0x30
[ 8569.952973] </TASK>
The likely cause is that init_waitqueue_head() is called after the call to
the torture_create_kthread() function that creates the ref_scale_reader
kthread. Although this init_waitqueue_head() call will very likely
complete before this kthread is created and starts running, it is
possible that the calling kthread will be delayed between the calls to
torture_create_kthread() and init_waitqueue_head(). In this case, the
new kthread will use the waitqueue head before it is properly initialized,
which is not good for the kernel's health and well-being.
The above crash happened here:
static inline void __add_wait_queue(...)
{
:
if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here
The offset of flags from list_head entry in wait_queue_entry is
-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task
structure is zero initialized, the instruction will try to access address
0xffffffffffffffe8, which is exactly the fault address listed above.
This commit therefore invokes init_waitqueue_head() before creating
the kthread. |
| An issue was discovered in the Graphics::ColorNames package before 3.2.0 for Perl. There is an ambiguity between modules and filenames that can lead to HTML injection by an attacker who can create a file in the current working directory. |
| In the Linux kernel, the following vulnerability has been resolved:
clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe
Smatch reports:
drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()
warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.
timer_baseaddr may have the problem of not being released after use,
I replaced it with the devm_of_iomap() function and added the clk_put()
function to cleanup the "clk_ce" and "clk_cs". |
| Cross-Site Request Forgery (CSRF) vulnerability in Broadstreet Broadstreet Ads broadstreet allows Cross Site Request Forgery.This issue affects Broadstreet Ads: from n/a through <= 1.52.1. |
| Missing Authorization vulnerability in Shahjada Live Forms liveforms.This issue affects Live Forms: from n/a through <= 4.8.5. |
| ChatBar.tsx in Lumos before 1.0.17 parses raw HTML in Markdown because the markdown-to-jsx package is used without disableParsingRawHTML set to true. |
| In the Linux kernel, the following vulnerability has been resolved:
posix-timers: Ensure timer ID search-loop limit is valid
posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.
This is done in a loop searching the ID space for a free slot one by
one. The loop has to terminate when the search wrapped around to the
starting point.
But that's racy vs. establishing the starting point. That is read out
lockless, which leads to the following problem:
CPU0 CPU1
posix_timer_add()
start = sig->posix_timer_id;
lock(hash_lock);
... posix_timer_add()
if (++sig->posix_timer_id < 0)
start = sig->posix_timer_id;
sig->posix_timer_id = 0;
So CPU1 can observe a negative start value, i.e. -1, and the loop break
never happens because the condition can never be true:
if (sig->posix_timer_id == start)
break;
While this is unlikely to ever turn into an endless loop as the ID space is
huge (INT_MAX), the racy read of the start value caught the attention of
KCSAN and Dmitry unearthed that incorrectness.
Rewrite it so that all id operations are under the hash lock. |
| Metabase is an open-source data analytics platform. For new sandboxing configurations created in 1.52.0 till 1.52.2.4, sandboxed users are able to see field filter values from other sandboxed users. This is fixed in 1.52.2.5. Users on 1.52.0 or 1.52.1 or 1.5.2 should upgrade to 1.52.2.5. There are no workarounds for this issue aside from upgrading. |
