| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The Responsive and Swipe slider plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's rsSlider shortcode in all versions up to, and including, 1.0.2 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| The F70 Lead Document Download plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'file_download' function in all versions up to, and including, 1.4.4. This makes it possible for unauthenticated attackers to download any file from the WordPress media library by guessing or enumerating WordPress attachment IDs. |
| The HTTPS service on Tapo C200 V3 exposes a connectAP interface without proper authentication. An unauthenticated attacker on the same local network segment can exploit this to modify the device’s Wi-Fi configuration, resulting in loss of connectivity and denial-of-service (DoS). |
| The FiboSearch – Ajax Search for WooCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's `thegem_te_search` shortcode in all versions up to, and including, 1.32.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This vulnerability requires TheGem theme (premium) to be installed with Header Builder mode enabled, and the FiboSearch "Replace search bars" option enabled for TheGem integration. |
| The Quran Gateway plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.5. This is due to missing nonce validation in the quran_gateway_options function. This makes it possible for unauthenticated attackers to modify the plugin's display settings via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. |
| The Flex Store Users plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.1.0. This is due to the 'fsUserHandle::signup' and the 'fsSellerRole::add_role_seller' functions not restricting what user roles a user can register with. This makes it possible for unauthenticated attackers to supply the 'administrator' role during registration and gain administrator access to the site. Note: The vulnerability can be exploited with the 'fs_type' parameter if the Flex Store Seller plugin is also activated. |
| The WP Hallo Welt plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 1.4. This is due to missing or incorrect nonce validation on the 'hallo_welt_seite' function. This makes it possible for unauthenticated attackers to update plugin settings and inject malicious web scripts via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. Due to the insufficient input sanitization and output escaping, this can lead to Stored Cross-Site Scripting. |
| The File Uploader for WooCommerce plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the callback function for the 'add-image-data' REST API endpoint in all versions up to, and including, 1.0.3. This makes it possible for unauthenticated attackers to upload arbitrary files to the Uploadcare service and subsequently download them on the affected site's server which may make remote code execution possible. |
| The Pretty Google Calendar plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the pgcal_ajax_handler() function in all versions up to, and including, 2.0.0. This makes it possible for unauthenticated attackers to retrieve the Google API key set in the plugin's settings. |
| The Pure WC Variation Swatches WordPress plugin through 1.1.7 does not have an authorization check when updating its settings, which could allow any authenticated users to update them. |
| The Ultimate Member – User Profile, Registration, Login, Member Directory, Content Restriction & Membership Plugin plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.11.0 via the ajax_get_members function. This is due to the use of a predictable low-entropy token (5 hex characters derived from md5 of post ID) to identify member directories and insufficient authorization checks on the unauthenticated AJAX endpoint. This makes it possible for unauthenticated attackers to extract sensitive data including usernames, display names, user roles (including administrator accounts), profile URLs, and user IDs by enumerating predictable directory_id values or brute-forcing the small 16^5 token space. |
| FastAPI Users allows users to quickly add a registration and authentication system to their FastAPI project. Prior to version 15.0.2, the OAuth login state tokens are completely stateless and carry no per-request entropy or any data that could link them to the session that initiated the OAuth flow. `generate_state_token()` is always called with an empty `state_data` dict, so the resulting JWT only contains the fixed audience claim plus an expiration timestamp. On callback, the library merely checks that the JWT verifies under `state_secret` and is unexpired; there is no attempt to match the state value to the browser that initiated the OAuth request, no correlation cookie, and no server-side cache. Any attacker can hit `/authorize`, capture the server-generated state, finish the upstream OAuth flow with their own provider account, and then trick a victim into loading `.../callback?code=<attacker_code>&state=<attacker_state>`. Because the state JWT is valid for any client for \~1 hour, the victim’s browser will complete the flow. This leads to login CSRF. Depending on the app’s logic, the login CSRF can lead to an account takeover of the victim account or to the victim user getting logged in to the attacker's account. Version 15.0.2 contains a patch for the issue. |
| LDAP Tool Box Self Service Password 1.5.2 contains a password reset vulnerability that allows attackers to manipulate HTTP Host headers during token generation. Attackers can craft malicious password reset requests that generate tokens sent to a controlled server, enabling potential account takeover by intercepting and using stolen reset tokens. |
| Kimai 1.30.10 contains a SameSite cookie vulnerability that allows attackers to steal user session cookies through malicious exploitation. Attackers can trick victims into executing a crafted PHP script that captures and writes session cookie information to a file, enabling potential session hijacking. |
| In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header
The driver expects to receive a struct gs_host_frame in
gs_usb_receive_bulk_callback().
Use struct_group to describe the header of the struct gs_host_frame and
check that we have at least received the header before accessing any
members of it.
To resubmit the URB, do not dereference the pointer chain
"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since
"urb->context" contains "parent", it is always defined, while "dev" is not
defined if the URB it too short. |
| In the Linux kernel, the following vulnerability has been resolved:
can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data
The URB received in gs_usb_receive_bulk_callback() contains a struct
gs_host_frame. The length of the data after the header depends on the
gs_host_frame hf::flags and the active device features (e.g. time
stamping).
Introduce a new function gs_usb_get_minimum_length() and check that we have
at least received the required amount of data before accessing it. Only
copy the data to that skb that has actually been received.
[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()] |
| In the Linux kernel, the following vulnerability has been resolved:
veth: reduce XDP no_direct return section to fix race
As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing
old or uninitialized descriptors") for veth there is a chance after
napi_complete_done() that another CPU can manage start another NAPI
instance running veth_pool(). For NAPI this is correctly handled as the
napi_schedule_prep() check will prevent multiple instances from getting
scheduled, but for the remaining code in veth_pool() this can run
concurrent with the newly started NAPI instance.
The problem/race is that xdp_clear_return_frame_no_direct() isn't
designed to be nested.
Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via
task_struct on PREEMPT_RT.") the temporary BPF net context
bpf_redirect_info was stored per CPU, where this wasn't an issue. Since
this commit the BPF context is stored in 'current' task_struct. When
running veth in threaded-NAPI mode, then the kthread becomes the storage
area. Now a race exists between two concurrent veth_pool() function calls
one exiting NAPI and one running new NAPI, both using the same BPF net
context.
Race is when another CPU gets within the xdp_set_return_frame_no_direct()
section before exiting veth_pool() calls the clear-function
xdp_clear_return_frame_no_direct(). |
| In the Linux kernel, the following vulnerability has been resolved:
team: Move team device type change at the end of team_port_add
Attempting to add a port device that is already up will expectedly fail,
but not before modifying the team device header_ops.
In the case of the syzbot reproducer the gre0 device is
already in state UP when it attempts to add it as a
port device of team0, this fails but before that
header_ops->create of team0 is changed from eth_header to ipgre_header
in the call to team_dev_type_check_change.
Later when we end up in ipgre_header() struct ip_tunnel* points to nonsense
as the private data of the device still holds a struct team.
Example sequence of iproute2 commands to reproduce the hang/BUG():
ip link add dev team0 type team
ip link add dev gre0 type gre
ip link set dev gre0 up
ip link set dev gre0 master team0
ip link set dev team0 up
ping -I team0 1.1.1.1
Move team_dev_type_check_change down where all other checks have passed
as it changes the dev type with no way to restore it in case
one of the checks that follow it fail.
Also make sure to preserve the origial mtu assignment:
- If port_dev is not the same type as dev, dev takes mtu from port_dev
- If port_dev is the same type as dev, port_dev takes mtu from dev
This is done by adding a conditional before the call to dev_set_mtu
to prevent it from assigning port_dev->mtu = dev->mtu and instead
letting team_dev_type_check_change assign dev->mtu = port_dev->mtu.
The conditional is needed because the patch moves the call to
team_dev_type_check_change past dev_set_mtu.
Testing:
- team device driver in-tree selftests
- Add/remove various devices as slaves of team device
- syzbot |
| In the Linux kernel, the following vulnerability has been resolved:
atm/fore200e: Fix possible data race in fore200e_open()
Protect access to fore200e->available_cell_rate with rate_mtx lock in the
error handling path of fore200e_open() to prevent a data race.
The field fore200e->available_cell_rate is a shared resource used to track
available bandwidth. It is concurrently accessed by fore200e_open(),
fore200e_close(), and fore200e_change_qos().
In fore200e_open(), the lock rate_mtx is correctly held when subtracting
vcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.
However, if the subsequent call to fore200e_activate_vcin() fails, the
function restores the reserved bandwidth by adding back to
available_cell_rate without holding the lock.
This introduces a race condition because available_cell_rate is a global
device resource shared across all VCCs. If the error path in
fore200e_open() executes concurrently with operations like
fore200e_close() or fore200e_change_qos() on other VCCs, a
read-modify-write race occurs.
Specifically, the error path reads the rate without the lock. If another
CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in
fore200e_close()) between this read and the subsequent write, the error
path will overwrite the concurrent update with a stale value. This results
in incorrect bandwidth accounting. |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Hotech Software Inc. Otello allows Stored XSS.This issue affects Otello: from 2.4.0 before 2.4.4. |
