| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Padding Oracle vulnerability in Apache Tomcat's EncryptInterceptor with default configuration.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.0.0-M1 through 10.1.52, from 9.0.13 through 9..115, from 8.5.38 through 8.5.100, from 7.0.100 through 7.0.109.
Users are recommended to upgrade to version 11.0.19, 10.1.53 and 9.0.116, which fixes the issue. |
| An issue was discovered in musl libc 0.7.10 through 1.2.6. Stack-based memory corruption can occur during qsort of very large arrays, due to incorrectly implemented double-word primitives. The number of elements must exceed about seven million, i.e., the 32nd Leonardo number on 32-bit platforms (or the 64th Leonardo number on 64-bit platforms, which is not practical). |
| Improper restriction of names for files and other resources in Active Directory Domain Services allows an authorized attacker to elevate privileges over a network. |
| In the Linux kernel, the following vulnerability has been resolved:
bridge: mrp: reject zero test interval to avoid OOM panic
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes. |
| OpenClaw before 2026.3.2 contains a filesystem boundary bypass vulnerability in the image tool that fails to honor tools.fs.workspaceOnly restrictions. Attackers can traverse sandbox bridge mounts outside the workspace to read files that other filesystem tools would reject. |
| OpenClaw before 2026.3.22 contains an authorization bypass vulnerability in interactive callback dispatch that allows non-allowlisted senders to execute action handlers. Attackers can bypass sender authorization checks by dispatching callbacks before normal security validation completes, enabling unauthorized actions. |
| OpenClaw before 2026.3.25 contains a privilege escalation vulnerability allowing non-admin operators to self-request broader scopes during backend reconnect. Attackers can bypass pairing requirements to reconnect as operator.admin, gaining unauthorized administrative privileges. |
| OpenClaw before 2026.3.25 contains a privilege escalation vulnerability in gateway-authenticated plugin HTTP routes that incorrectly mint operator.admin runtime scope regardless of caller-granted scopes. Attackers can exploit this scope boundary bypass to gain elevated privileges and perform unauthorized administrative actions. |
| OpenClaw before 2026.3.31 (patched in 2026.4.8) contains a request body replay vulnerability in fetchWithSsrFGuard that allows unsafe request bodies to be resent across cross-origin redirects. Attackers can exploit this by triggering redirects to exfiltrate sensitive request data or headers to unintended origins. |
| Any guest issuing a Xenstore command accessing a node using the
(illegal) node path "/local/domain/", will crash xenstored due to a
clobbered error indicator in xenstored when verifying the node path.
Note that the crash is forced via a failing assert() statement in
xenstored. In case xenstored is being built with NDEBUG #defined,
an unprivileged guest trying to access the node path "/local/domain/"
will result in it no longer being serviced by xenstored, other guests
(including dom0) will still be serviced, but xenstored will use up
all cpu time it can get. |
| Incorrect access control in Kaleris YMS v7.2.2.1 allows authenticated attackers with only the shipping/receiving role to view the truck's dashboard resources. |
| An open redirect in Ascertia SigningHub User v10.0 allows attackers to redirect users to a malicious site via a crafted URL. |
| fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.1.0 and earlier, fast-jwt does not validate the crit (Critical) Header Parameter defined in RFC 7515 ยง4.1.11. When a JWS token contains a crit array listing extensions that fast-jwt does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC. |
| Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Prior to 2.6.4, the PUT /api/recipe/batch_update/ endpoint in Tandoor Recipes allows any authenticated user within a Space to modify any recipe in that Space, including recipes marked as private by other users. This bypasses all object-level authorization checks enforced on standard single-recipe endpoints (PUT /api/recipe/{id}/), enabling forced exposure of private recipes, unauthorized self-grant of access via the shared list, and metadata tampering. This vulnerability is fixed in 2.6.4. |
| WeGIA is a Web manager for charitable institutions. Prior to 3.6.9, an Open Redirect vulnerability was identified in the /WeGIA/controle/control.php endpoint of the WeGIA application, specifically through the nextPage parameter when combined with metodo=listarId and nomeClasse=IentradaControle. The application fails to validate or restrict the nextPage parameter, allowing attackers to redirect users to arbitrary external websites. This can be abused for phishing attacks, credential theft, malware distribution, and social engineering using the trusted WeGIA domain. This vulnerability is fixed in 3.6.9. |
| WeGIA is a Web manager for charitable institutions. Prior to 3.6.9, open redirect has been found in WeGIA webapp. The redirect parameter is taken directly from $_GET with no URL validation or whitelist check, then used verbatim in a header("Location: ...") call. This vulnerability is fixed in 3.6.9. |
| WeGIA is a Web manager for charitable institutions. Prior to 3.6.9, the redirect parameter is taken directly from $_GET with no URL validation or whitelist check, then used verbatim in a header("Location: ...") call. This vulnerability is fixed in 3.6.9. |
| ChurchCRM is an open-source church management system. Prior to 7.1.0, an authenticated API user can modify any family record's state without proper authorization by simply changing the {familyId} parameter in requests, regardless of whether they possess the required EditRecords privilege. /family/{familyId}/verify, /family/{familyId}/verify/url, /family/{familyId}/verify/now, /family/{familyId}/activate/{status}, and /family/{familyId}/geocode lack role-based access control, allowing users to deactivate/reactivate arbitrary families, spam verification emails, and mark families as verified and trigger geocoding. This vulnerability is fixed in 7.1.0. |
| Scoold is a Q&A and a knowledge sharing platform for teams. Prior to 1.66.2, an authenticated authorization flaw in Scoold allows any logged-in, low-privilege user to overwrite another user's existing question by supplying that question's public ID as the postId parameter to POST /questions/ask. Because question IDs are exposed in normal question URLs, a low-privilege attacker can take a victim question ID from a public page and cause attacker-controlled content to be stored under that existing question object. This causes direct integrity loss of user-generated content and corrupts the integrity of the existing discussion thread. This vulnerability is fixed in 1.66.2. |
| LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.25.3, for {% include %}, {% render %}, and {% layout %}, LiquidJS checks whether the candidate path is inside the configured partials or layouts roots before reading it. That check is path-based, not realpath-based. Because of that, a file like partials/link.liquid passes the directory containment check as long as its pathname is under the allowed root. If link.liquid is actually a symlink to a file outside the allowed root, the filesystem follows the symlink when the file is opened and LiquidJS renders the external target. So the restriction is applied to the path string that was requested, not to the file that is actually read. This matters in environments where an attacker can place templates or otherwise influence files under a trusted template root, including uploaded themes, extracted archives, mounted content, or repository-controlled template trees. This vulnerability is fixed in 10.25.3. |
