| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A security vulnerability has been detected in y_project RuoYi up to 4.8.3. This impacts the function changeStatus of the file /system/config/add of the component Disable API. The manipulation leads to session expiration. It is possible to initiate the attack remotely. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was determined in jackq XCMS up to 3fab5342cc509945a7ce1b8ec39d19f701b89261. Impacted is the function PublicController::sendFindPwdMail of the file Admin/Home/Controller/PublicController.class.php of the component Password Recovery Mail Endpoint. This manipulation of the argument email causes sql injection. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. |
| A vulnerability was detected in ZKTeco BioTime 9.5.6 Build 20260130.3206. Affected by this issue is some unknown functionality of the file /base/api/systemSettings of the component System Settings API. Performing a manipulation results in improper access controls. The attack can be initiated remotely. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was identified in deepseek-ai deepseek-harness up to 0.1.1-rc.2. This affects the function agent of the component dsh-workflow-worker-thread. The manipulation leads to enforcement of behavioral workflow. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| A flaw has been found in macrozheng mall up to 1.0.3. This issue affects the function JwtTokenUtil.refreshHeadToken of the file /admin/refreshToken of the component JwtAuthenticationTokenFilter. This manipulation of the argument token causes session expiration. The attack may be initiated remotely. The exploit has been published and may be used. Patch name: 9bfc2fd2c4aaa4ac519e9152e65d673a5380de1a. To fix this issue, it is recommended to deploy a patch. |
| A flaw has been found in **permission filters** in the **foreman** package. The API loads a filter by its identifier and does not apply the search limit on the caller's permission. A low-privileged network attacker or user must already be allowed to delete filters for one role only. They can delete filters that belong to other unlocked roles. Those other roles then lose the access the deleted filters had granted. |
| Backstage is an open framework for building developer portals. Prior to 0.17.8, the @backstage/backend-defaults package is affected by improper access control in backend action invocation. An authenticated user could invoke actions that an operator had excluded through action configuration. Existing action permissions and downstream authorization remain enforced. This issue is fixed in version 0.17.8. |
| QGIS is a free, open source, cross-platform geographic information system. Prior to 3.44.12 and 4.0.0 through 4.2.3, QGIS Server renders feature data in WFS3 (OGC API Features) HTML responses without HTML escaping. Attacker-controlled feature.properties values from a published writable vector layer reach resources/server/api/ogc/templates/wfs3/getFeatures.html through QgsServerOgcApiHandler::htmlDump and the if_nullptr_null_str callback. A user who opens an items HTML page can execute stored markup or script in the QGIS Server origin, which can expose the viewer's session data or issue authenticated requests with the viewer's privileges. This issue is fixed in version 3.44.12. |
| IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.10 and IBM WebSphere Application Server 8.5, and 9.0 Liberty could allow a remote unauthenticated attacker to cause a denial of service due to uncontrolled resource consumption. |
| IBM TRIRIGA Application Platform 5.0.0 through 5.0.8 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of file paths during archive extraction. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg
This improves the fix for CVE-2026-43500.
Fix the pagecache corruption from in-place decryption of a DATA packet
transmitted locally by splice() by getting rid of the packet sharing in the
I/O thread and unconditionally extracting the packet content into a bounce
buffer in which the buffer is decrypted. recvmsg() (or the kernel
equivalent) then copies the data from the bounce buffer to the destination
buffer. The sk_buff then remains unmodified.
This has an additional advantage in that the packet is then arranged in the
buffer with the correct alignment required for the crypto algorithms to
process directly. The performance of the crypto does seem to be a little
faster and, surprisingly, the unencrypted performance doesn't seem to
change much - possibly due to removing complexity from the I/O thread.
Yet another advantage is that the I/O thread doesn't have to copy packets
which would slow down packet distribution, ACK generation, etc..
The buffer belongs to the call and is allocated initially at 2K,
sufficiently large to hold a whole jumbo subpacket, but the buffer will be
increased in size if needed. However, to take this work, MSG_PEEK may
cause a later packet to be decrypted into the buffer, in which case the
earlier one will need re-decrypting for a subsequent recvmsg().
Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so
switch to using USHRT_MAX to indicate an invalid offset.
Note also that I would generally prefer to replace the buffers of the
current sk_buff with a new kmalloc'd buffer of the right size, ditching the
old data and frags as this makes the handling of MSG_PEEK easier and
removes the re-decryption issue, but this looks like quite a complicated
thing to achieve. skb_morph() looks half way to what I want, but I don't
want to have to allocate a new sk_buff. |
| Hono from 4.12.4 before 4.13.11 contains a middleware bypass vulnerability in serveStatic that allows unauthenticated attackers to skip prefix middleware by exploiting double path decoding. Attackers can send malformed percent-encoded paths that the router matches in encoded form, reaching static files without authentication checks running. |
| A flaw was found in tftp-hpa. When the `in.tftpd` remap engine processes an inverse remap rule that also aborts with a non-empty custom error message, it can pass invalid match offsets to the `genmatchstring()` function. This leads to out-of-bounds read/write operations. A remote, unauthenticated attacker can exploit this vulnerability by sending a specially crafted request, causing the daemon to crash and resulting in a denial of service. |
| Improper input validation in Extensions in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy into a privileged page via a crafted Chrome extension. (Chromium security severity: Low) |
| Race condition in Chromoting in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to potentially bypass system access restrictions via crafted network traffic. (Chromium security severity: Low) |
| Incorrect authorization in Passwords in Google Chrome on on iOS prior to 155.0.8059.39 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) |
| Incorrect authorization in Scheduling in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Missing authorization in Network in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy via crafted network traffic. (Chromium security severity: Low) |
| ProPhoenix Law RMS v2022.2403.3.101 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the PageTitle/Alert/MsgType parameter in the errorHandler.aspx endpoint. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: fix verdict sk_data_ready racing with ktls rx
sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and
defers to psock->saved_data_ready when a TLS RX context is present,
avoiding a conflict with the TLS strparser's ownership of the receive
queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types
with ktls").
sk_psock_verdict_data_ready() has no equivalent guard. When a socket
is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is
configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready
as rx_ctx->saved_data_ready. On data arrival:
tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready
-> saved_data_ready() = sk_psock_verdict_data_ready()
-> tcp_read_skb() drains sk_receive_queue via __skb_unlink()
without calling tcp_eat_skb(), so copied_seq is not advanced.
tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls
tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and
returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned
(potentially freed) skb. tls_decrypt_sg() subsequently walks that
frag_list: use-after-free.
Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context
is present, call psock->saved_data_ready (sock_def_readable) to wake
recv() waiters and return immediately, leaving the receive queue
untouched. TLS retains sole ownership of the queue and decrypts the
record normally through tls_sw_recvmsg(). |
