🚨 CVE-2021-47951
WordPress Picture Gallery 1.4.2 contains a stored cross-site scripting vulnerability that allows authenticated attackers to inject malicious scripts through the Edit Content URL field in the Access Control settings. Attackers can enter JavaScript payloads in the plugin options that are stored in the database and executed when the functionality is triggered, enabling session hijacking or credential theft.

🎖@cveNotify

🚨 CVE-2021-47953
OpenCart 3.0.3.7 contains a cross-site request forgery vulnerability that allows attackers to change user passwords by sending crafted requests to the account/password endpoint. Attackers can trick authenticated users into submitting hidden forms with new password values in the 'password' and 'confirm' parameters to hijack accounts.

🎖@cveNotify

🚨 CVE-2022-50943
Moodle LMS 4.0 contains a cross-site scripting vulnerability that allows unauthenticated attackers to inject malicious scripts by submitting payloads through the search parameter. Attackers can inject JavaScript code via the search field in course/search.php to execute arbitrary scripts in users' browsers and steal session cookies.

🎖@cveNotify

🚨 CVE-2022-50944
Aero CMS 0.0.1 contains a PHP code injection vulnerability that allows authenticated attackers to execute arbitrary PHP code by uploading malicious files through the image parameter. Attackers can upload PHP files with embedded code to the admin posts.php endpoint with source=add_post parameter, and the uploaded files are executed by the server.

🎖@cveNotify

🚨 CVE-2022-50946
WordPress Plugin Netroics Blog Posts Grid 1.0 contains a stored cross-site scripting vulnerability that allows authenticated editors to inject malicious scripts by failing to sanitize the post_title parameter. Attackers with editor privileges can inject script payloads through the testimonial title field that execute in the browsers of other users viewing the draft post, enabling cookie theft and session hijacking.

🎖@cveNotify

🚨 CVE-2022-50947
WordPress Plugin Testimonial Slider and Showcase 2.2.6 contains a stored cross-site scripting vulnerability that allows authenticated editors to inject malicious scripts by failing to sanitize the post_title parameter. Attackers with editor privileges can inject JavaScript payloads through the testimonial title field that execute in the browsers of users viewing the draft post, enabling cookie theft and session hijacking.

🎖@cveNotify

🚨 CVE-2022-50948
Motopress Hotel Booking Lite 4.2.4 contains a stored cross-site scripting vulnerability that allows authenticated attackers to inject malicious scripts by submitting payloads in accommodation type fields. Attackers can inject script tags through the title and excerpt parameters when creating accommodation types, which execute in the browser when visitors access the accommodations page.

🎖@cveNotify

🚨 CVE-2022-50967
uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the tickets/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

🎖@cveNotify

🚨 CVE-2022-50968
uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the auctions/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

🎖@cveNotify

🚨 CVE-2022-50969
uBidAuction 2.0.1 contains a reflected cross-site scripting vulnerability in the backend/mailingLog/manage module. The date_created, date_from, date_to, and created_at parameters in the filter functionality are not properly sanitized, allowing remote attackers to inject malicious scripts via crafted GET requests that execute in victims' browsers.

🎖@cveNotify

🚨 CVE-2022-50970
WordPress Plugin AAWP 3.16 contains a reflected cross-site scripting vulnerability that allows authenticated attackers to inject malicious scripts by manipulating the tab parameter. Attackers can craft URLs with XSS payloads in the tab parameter of the aawp-settings admin page to execute arbitrary JavaScript in the context of authenticated users.

🎖@cveNotify

🚨 CVE-2026-47179
Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 1.19.4, ProjectService.GetProjectFileContent returns the contents of any Docker Compose include directive declared in a project's compose file before any path-traversal validation runs. Because ProjectService.CreateProject writes attacker-supplied compose content to disk without validating include paths, an authenticated user can create a project whose compose file declares include: ['../../../../etc/passwd'], then read the include via the project file API. The result is arbitrary read of any file readable by the Arcane backend process, including /app/data/arcane.db (the SQLite database containing every user's password hash and API key), enabling escalation to admin and, via Arcane's Docker control plane, RCE on the host. This vulnerability is fixed in 1.19.4.

🎖@cveNotify

🚨 CVE-2026-64256
In the Linux kernel, the following vulnerability has been resolved:

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that q_id is an unsigned 32-bit variable. If it happens
to be set to XFS_DQ_ID_MAX due to a filesystem that actually has a dquot
for ID_MAX, then this addition will truncate to zero and the iteration
starts over. Fix this by casting to u64.

🎖@cveNotify

🚨 CVE-2026-64257
In the Linux kernel, the following vulnerability has been resolved:

smb: client: reject overlapping data areas in SMB2 responses

Commit 53b7c271f06b ("smb: client: restrict implied bcc[0] exemption to
responses without data area") restricted the implied bcc[0] length
exception to responses without a data area. However, the overlap
handling in __smb2_calc_size() clears data_length, which can make an
invalid response appear to have no data area and so qualify for the
exception.

Track data area overlap separately and reject such responses before
applying the length compatibility exceptions.

🎖@cveNotify

🚨 CVE-2026-64258
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: remove request-less entries from ent_w_req_queue to fix NULL deref

If a copy into the userspace ring buffer fails, a request will be
terminated and fuse_uring_req_end() will set ent->fuse_req to NULL but
it will leave the entry on ent_w_req_queue in FRRS_FUSE_REQ state. This
can lead to a NULL deref if the request expiration logic scans
ent_w_req_queue in the window before the entry is moved off it.

Fix this by taking the entry off ent_w_req_queue and changing its state
from FRRS_FUSE_REQ to FRRS_INVALID before terminating the request.

🎖@cveNotify

🚨 CVE-2026-64259
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: make a fuse_req on SQE commit only findable after memcpy

Bad userspace might try to trick us and send commit SQEs request
unique / commit-id of requests that are not even send to
fuse-server (io_uring_cmd_done() not called) yet.

fuse_uring_commit_fetch() ends the fuse request when the ring entry
has a wrong state, but that could have caused a use-after-free
with the memcpy operations in fuse_uring_send_in_task().
In order to avoid such races the call of fuse_uring_add_to_pq()
is moved after the copy operations and just before completing
the io-uring request - malicious userspace cannot find the request
anymore until all prepration work in fuse-client/kernel is completed.

This also moves fuse_uring_add_to_pq() a bit up in the code to
avoid a forward declaration. Also not with a preparation commit,
to make it easier to back port to older kernels.

🎖@cveNotify

🚨 CVE-2026-64260
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: Avoid queue->stopped races and set/read that value under lock

There are several readers of queue->stopped that check the value
under lock, but fuse_uring_commit_fetch() did not and actually
the value was not set under the lock in fuse_uring_abort_end_requests()
either. Especially in fuse_uring_commit_fetch it is important
to check under a lock, because due to races 'struct fuse_req'
might be freed with fuse_request_end, but another thread/cpu
might already do teardown work.

🎖@cveNotify

🚨 CVE-2026-64261
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: Avoid use-after-free in fuse_uring_async_stop_queues

fuse_uring_async_stop_queues() might run when the last reference
on ring->queue_refs was already dropped.

In order to avoid an early destruction a reference on struct fuse_conn
is now taken before starting fuse_uring_async_stop_queues() and that
reference is only released when that delayed work queue terminates.

🎖@cveNotify

🚨 CVE-2026-64262
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: end fuse_req on io-uring cancel task work

When io_uring delivers task work with tw.cancel set (PF_EXITING,
PF_KTHREAD fallback, or percpu_ref_is_dying on the ring context),
fuse_uring_send_in_task() takes the cancel branch, assigns
-ECANCELED, and falls through to fuse_uring_send(). That path only
flips the entry to FRRS_USERSPACE and completes the io_uring cmd;
it never discharges the ring entry's owning reference to the
fuse_req that fuse_uring_add_req_to_ring_ent() handed it at
dispatch time.

fuse_uring_send_in_task()
tw.cancel == true
err = -ECANCELED
fuse_uring_send(ent, cmd, err, issue_flags)
ent->state = FRRS_USERSPACE
list_move(&ent->list, &queue->ent_in_userspace)
ent->cmd = NULL
io_uring_cmd_done(-ECANCELED)
/* ent->fuse_req still set, req still hashed */

The fuse_req stays linked on fpq->processing[hash] and
fuse_request_end() is never invoked. The originating syscall
thread blocks in D-state in request_wait_answer() until
fuse_abort_conn() runs, which can be the entire connection
lifetime. For FR_BACKGROUND requests fc->num_background is never
decremented either, so repeated cancels inflate the counter until
max_background is hit and all later background ops stall. tw.cancel does
not imply a connection abort (e.g. a single io_uring worker thread exits
while the fuse connection stays up), so this cannot be left for
fuse_abort_conn() to clean up.

Ending the req but still routing the entry through fuse_uring_send()
is not enough: that leaves a req-less entry on ent_in_userspace, and
ent_list_request_expired() dereferences ent->fuse_req unconditionally
on the head of that list, which would then NULL-deref.

Fix the cancel branch to release the entry directly. Remove it from the
queue, complete the io_uring cmd, end the fuse_req, free the entry, and
drop its queue_refs (waking the teardown waiter if it was the last).

🎖@cveNotify

🚨 CVE-2026-64263
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: fix moving cancelled entry to ent_in_userspace list

fuse_uring_cancel() moves entries that are available (these have no reqs
attached) to the ent_in_userspace list. ent_list_request_expired()
checks the first entry on ent_in_userspace and dereferences
ent->fuse_req unconditionally, which will crash on a cancelled entry
that was moved to this list.

Fix this by freeing the entry and dropping queue_refs directly in
fuse_uring_cancel(). This is safe because cancel is the cancel handler
itself - after io_uring_cmd_done(), no more cancels will be dispatched
for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queue_refs, fuse_uring_abort() must no
longer gate fuse_uring_abort_end_requests() on queue_refs > 0, as
cancelled entries may have already dropped queue_refs while requests are
still queued. Remove the gate so abort always flushes requests and stops
queues.

🎖@cveNotify

🚨 CVE-2026-64264
In the Linux kernel, the following vulnerability has been resolved:

fuse-uring: fix EFAULT clobber in fuse_uring_commit

copy_from_user() returns the number of bytes not copied as an unsigned
residual on failure (1..sizeof(struct fuse_out_header)). fuse_uring_commit
stores that residual in ssize_t err, sets req->out.h.error to -EFAULT,
then jumps to out: with err still holding the positive residual.

err = copy_from_user(&req->out.h, &ent->headers->in_out,
sizeof(req->out.h));
if (err) {
req->out.h.error = -EFAULT;
goto out; /* err is the positive residual */
}
...
out:
fuse_uring_req_end(ent, req, err);

fuse_uring_req_end() then runs

if (error)
req->out.h.error = error;

which overwrites the just-assigned -EFAULT with the positive residual.
FUSE callers such as fuse_simple_request() test err < 0 to detect
failure, so the positive value is interpreted as success and the
caller proceeds with an uninitialised or partial req->out.args.

Fix by assigning err = -EFAULT in the failure branch before jumping
to out, so fuse_uring_req_end() receives a negative errno and sets
req->out.h.error to -EFAULT.

🎖@cveNotify