| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insufficient policy enforcement in Sandbox in Google Chrome on Mac prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Low) |
| A flaw was found in foreman. Authenticated users with 'view_keypairs' permission can bypass taxonomy scoping, allowing them to download private SSH (Secure Shell) keys from other organizations by directly querying key pair IDs. This vulnerability leads to cross-tenant data exposure in multi-tenant deployments, potentially compromising sensitive information. |
| A flaw was found in Foreman. An authenticated user with host-edit permissions could exploit a cross-tenant information disclosure vulnerability. This flaw occurs because the taxonomy_scope controller method does not properly validate organization and location IDs from nested request parameters, bypassing existing authorization checks. This allows the user to leak sensitive infrastructure metadata, including subnet topology, IP ranges, gateways, DNS servers, and VLAN IDs, from organizations and locations they are not authorized to access. |
| A flaw was found in Foreman. This broken access control vulnerability allows an authenticated user with host-edit permissions to retarget an existing lookup value override to a different host. This is achieved by modifying the match field through nested host attributes, effectively bypassing authorisation checks. The consequence is the potential for unauthorised modification of managed host configurations across different organisational and location boundaries. |
| Use after free in Updater in Google Chrome on Windows prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Low) |
| Insufficient validation of untrusted input in DevTools in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who convinced a user to engage in specific UI gestures to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in Printing in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in CSS in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to inject arbitrary scripts or HTML (UXSS) via a crafted HTML page. (Chromium security severity: Low) |
| SQL Injection vulnerability in GoAdminGroup GoAdmin (last release v1.2.26) allows a remote attacker to execute arbitrary code and obtain sensitive information via the the __sort_type URL parameter on all /admin/info/{table} endpoints |
| Improper certificate validation and a time-of-check time-of-use (TOCTOU) race condition in the PrivilegedHelperTool XPC service in Cato Client before v.5.13.1 on macOS allows a local authenticated attacker to escalate privileges to root via a self-signed certificate that bypasses the XPC caller verification and a symlink swap during package installation. |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Wikimedia Foundation CheckUser.
This vulnerability is associated with program files modules/ext.CheckUser.TempAccounts/components/blockConnectedTempAccountsField.Vue.
This issue affects CheckUser: from 1.46.0-rc.0 before 1.46.0. |
| Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Wikimedia Foundation MediaWiki.
This vulnerability is associated with program files resources/src/mediawiki.Special.Apisandbox/ApiSandboxLayout.Js.
This issue affects MediaWiki: from 1.46.0-rc.0 before 1.46.0. |
| Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation MediaWiki.
This vulnerability is associated with program files includes/Api/ApiQueryAllUsers.Php, includes/Api/ApiQueryUsers.Php, includes/Permissions/PermissionManager.Php, includes/User/UserGroupManager.Php. |
| Craft CMS is a content management system (CMS). In versions 5.0.0-RC1 and above prior to 5.9.21, the EntriesController::actionMoveToSection() endpoint gates the destination section only by viewEntries:$section->uid rather than requiring saveEntries permission (the source entry is separately checked via Entry::canMove()). As a result, a low-privileged authenticated control-panel user who can move an entry out of its current section can call moveEntryToSection() to rewrite the entry's sectionId and save it into a section where they have read access but no write access. This breaks the section-level authorization model, letting a user with limited permissions inject content into a protected section and interfere with editorial boundaries, approval workflows, and section-specific business logic. This issue has been fixed in version 5.9.21. |
| A flaw was found in Foreman. The Usergroup model in Foreman does not properly validate role assignments against the calling user's permissions. This allows an authenticated user with usergroup management permissions to attach arbitrary roles, including administrative roles, to a user group and then add themselves as a member. Successful exploitation of this vulnerability leads to full privilege escalation, granting the attacker administrator-level access. |
| Craft CMS is a content management system (CMS). IN versions 5.0.0-RC1 and above prior to 5.9.21, theEntriesController::actionSaveEntry() performs entry-edit permission checks before request-controlled author changes are applied to the model, allowing for authorship spoofing. The subsequent author mutation path accepts attacker-supplied authors / author parameters and allows the change when the current user is one of the old authors. Because the controller does not re-run authorization after mutating the author list, a low-privileged user can reassign an entry’s authorship to another user without holding the dedicated peer-author-change permission. This issue has been fixed in version 5.9.21. |
| In the Linux kernel, the following vulnerability has been resolved:
debugobjects: Do not fill_pool() if pi_blocked_on
On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which
asserts if current::pi_blocked_on is set, because a task can obviously only
block on one lock as otherwise the priority inheritenace chain gets
corrupted.
Prevent this by expanding the conditional to take current::pi_blocked_on
into account. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Use krealloc_array() in dal_vector_reserve()
[Why & How]
dal_vector_reserve() computes the allocation size as
"capacity * vector->struct_size" using uint32_t arithmetic, which can
silently wrap to a small value on overflow. This would cause krealloc to
return a smaller buffer than expected, leading to heap overflows on
subsequent vector appends.
Replace krealloc() with krealloc_array() which performs an internal
overflow check and returns NULL on wrap, preventing the issue.
(cherry picked from commit 37668568641ccc4cc1dbca4923d0a16609dd5707) |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying
When marking a page dirty, complain about not having a running/loaded vCPU
if and only if the VM is still alive, i.e. its refcount is non-zero. This
will allow fixing a memory leak for x86 SEV-ES guests without hitting what
is effectively a false positive on the WARN.
For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page
across an exit to userspace, and typically unmaps the page on the next
KVM_RUN. But if userspace never calls KVM_RUN after such an exit, then KVM
needs to unmap the page when the vCPU is destroyed, which in turn triggers
the WARN about not having a running vCPU.
Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN,
as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons;
suppressing WARN from nested_put_vmcs12_pages() is pure happenstance). But
loading a vCPU during destruction is gross (ideally nVMX code would be
cleaned up), risks complicating the SEV-ES code (KVM would need to ensure
the temporarily load()+put() only runs when the vCPU isn't already loaded),
and is ultimately pointless.
The motivation for the WARN is to guard against KVM dirtying guest memory
without pushing the corresponding GFN to the active vCPU's dirty ring, e.g.
to ensure userspace doesn't miss a dirty page. But for the VM's refcount
to reach zero, there can't be _any_ userspace mappings to the dirty ring,
as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if
userspace had a valid mapping for the dirty ring, then the vCPU file and
thus the owning VM would still be alive. And so since userspace can't
possibly reach the dirty ring, whether or not KVM technically "misses" a
push to the dirty ring is irrelevant. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
NAT helpers such as nf_nat_h323 store a raw pointer to module text in
exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()
only unlinks the callback descriptor and never walks the expectation table,
so an expectation pending at module removal survives with a dangling
exp->expectfn into freed module text.
When the expected connection arrives, init_conntrack() invokes
exp->expectfn(), now a stale pointer into the unloaded module. Reproduced
on a KASAN build by loading the H.323 helpers, creating a Q.931
expectation, unloading nf_nat_h323, then connecting to the expected port:
Oops: int3: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:0xffffffffa06102d1
init_conntrack.isra.0 (net/netfilter/nf_conntrack_core.c:1862)
nf_conntrack_in (net/netfilter/nf_conntrack_core.c:2049)
ipv4_conntrack_local (net/netfilter/nf_conntrack_proto.c:223)
nf_hook_slow (net/netfilter/core.c:619)
__ip_local_out (net/ipv4/ip_output.c:120)
__tcp_transmit_skb (net/ipv4/tcp_output.c:1715)
tcp_connect (net/ipv4/tcp_output.c:4374)
tcp_v4_connect (net/ipv4/tcp_ipv4.c:345)
__sys_connect (net/socket.c:2167)
Modules linked in: nf_conntrack_h323 [last unloaded: nf_nat_h323]
Reaching the dangling state requires CAP_SYS_MODULE in the initial user
namespace to remove a NAT helper that still has live expectations, so this
is a robustness fix; leaving an expectation pointing at freed text is wrong
regardless.
Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and
drops every expectation whose ->expectfn matches the descriptor being torn
down. Call it from each NAT helper's exit path after the existing RCU grace
period, so no expectation outlives the code it points at and no extra
synchronize_rcu() is introduced. With the fix, the same reproducer runs to
completion without the Oops. |
