| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink
A tunnel changelink() operates on at most two netns, dev_net(dev) and
the tunnel link netns t->net. They differ once the device is created in
or moved to a netns other than the one the request runs in. The rtnl
changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a
caller privileged there but not in t->net can rewrite a tunnel that
lives in t->net.
Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in
net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is
skipped when the link netns is dev_net(dev), where the rtnl path already
checked it. The other patches in this series use the same helper.
Gate ipgre_changelink() and erspan_changelink() with it, at the top of
the op before any attribute is parsed, because the parsers update live
tunnel fields first. ipgre_netlink_parms() sets t->collect_md before
ip_tunnel_changelink() runs.
Commit 8b484efd5cb4 ("ip6: vti: Use ip6_tnl.net in
vti6_siocdevprivate().") added the same check on the ioctl path. This
adds it on RTM_NEWLINK. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/CPU/AMD: Prevent improper isolation of shared resources in Zen2's op cache
Make sure resources are not improperly shared in the op cache and
cause instruction corruption this way. |
| In the Linux kernel, the following vulnerability has been resolved:
selinux: fix overlayfs mmap() and mprotect() access checks
The existing SELinux security model for overlayfs is to allow access if
the current task is able to access the top level file (the "user" file)
and the mounter's credentials are sufficient to access the lower
level file (the "backing" file). Unfortunately, the current code does
not properly enforce these access controls for both mmap() and mprotect()
operations on overlayfs filesystems.
This patch makes use of the newly created security_mmap_backing_file()
LSM hook to provide the missing backing file enforcement for mmap()
operations, and leverages the backing file API and new LSM blob to
provide the necessary information to properly enforce the mprotect()
access controls. |
| In the Linux kernel, the following vulnerability has been resolved:
xen/privcmd: restrict usage in unprivileged domU
The Xen privcmd driver allows to issue arbitrary hypercalls from
user space processes. This is normally no problem, as access is
usually limited to root and the hypervisor will deny any hypercalls
affecting other domains.
In case the guest is booted using secure boot, however, the privcmd
driver would be enabling a root user process to modify e.g. kernel
memory contents, thus breaking the secure boot feature.
The only known case where an unprivileged domU is really needing to
use the privcmd driver is the case when it is acting as the device
model for another guest. In this case all hypercalls issued via the
privcmd driver will target that other guest.
Fortunately the privcmd driver can already be locked down to allow
only hypercalls targeting a specific domain, but this mode can be
activated from user land only today.
The target domain can be obtained from Xenstore, so when not running
in dom0 restrict the privcmd driver to that target domain from the
beginning, resolving the potential problem of breaking secure boot.
This is XSA-482
---
V2:
- defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich)
- wait in open() if target domain isn't known yet
- issue message in case no target domain found (Jan Beulich) |
| Missing Authorization vulnerability in WPExperts Advanced File Manager file-manager-advanced allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Advanced File Manager: from n/a through 5.4.14. |
| RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, The shovel management resource's is_authorized/2 delegates to rabbit_mgmt_util:is_authorized_monitor/2, which accepts the monitoring tag. But allowed_methods includes DELETE, and delete_resource/2 deletes / restarts shovel runtime parameters with no additional role check. A monitoring user , intended to have read-only visibility , can therefore delete or restart any shovel in any vhost they can see. A read-only monitoring user can delete or restart any dynamic shovel , a state-changing operation that the equivalent /api/parameters endpoint correctly restricts to policymaker. Preconditions include rabbitmq_shovel + rabbitmq_shovel_management plugins enabled Attacker has credentials with the monitoring tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1. |
| Seven Gitea API routes under `/api/v1/users/{username}` (followers, following, following/{target}, starred, subscriptions, keys and gpg_keys) were registered without the `individualPermsChecker` middleware that enforces the visibility of the target user. An authenticated user could therefore read the followers, following list, starred and watched repositories and public SSH and GPG keys of a user with limited or private visibility, whom they could not otherwise see. The issue was fixed in 1.27.3 and 28.0.0 and disclosed with 28.2.0. |
| Missing Authorization vulnerability in Kit Kit (formerly ConvertKit) convertkit allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Kit (formerly ConvertKit): from n/a through 3.4.6. |
| Missing Authorization vulnerability in ThimPress LearnPress learnpress allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects LearnPress: from n/a through 4.4.10. |
| In the Linux kernel, the following vulnerability has been resolved:
NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags
When a filesystem is being automounted, it needs to preserve the
user-set superblock mount options, such as the "ro" flag. |
| Camunda 7.24.0 before 7.24.14 and 7.23.0 before 7.23.17 contains a missing authorization check vulnerability in engine-rest task sub-resources that allows authenticated attackers with no permission grants to access task comments and attachments by calling singular read and delete endpoints that lack the authorization-filtered checks enforced on their corresponding list endpoints. Attackers can exploit TaskAttachmentResourceImpl and TaskCommentResourceImpl methods such as getAttachment, getAttachmentData, deleteAttachment, and getComment using only a known object ID to read, download, or permanently delete task attachments and comments. |
| Missing authorization in the Sieve notify action (6.2.22 through 6.3.6) and in the mail-rule Reply action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to send mail through the server as any address. A Sieve notify sends a notification message, and its :from tag names the sender; the server set the notification's From header to that :from as the script wrote it, without checking that the address belongs to the account - the check that the Sieve vacation action applies to its own :from, and that the server applies to the sender of mail queued over COM or sent from the webmail. An account that can store a Sieve script (over ManageSieve, the REST API's self-service filter, or the administration interface) could therefore have the server send a notification from any address, on this server or anywhere; and where the claimed address is at a domain the server hosts with DKIM signing enabled, the server signed the notification with that domain's DKIM key, because it signs by the From header's domain, producing forged mail aligned to pass the domain's DMARC policy. The notify action and this behaviour were introduced in 6.2.22. In the mail-rule engine, a rule's Reply was likewise sent from whatever address the action named, whoever the rule belonged to, so that an account acting on its own rules over COM, a domain administrator, or an API key confined to a domain (over the REST API from 6.3.4) could have a domain's or an account's rule reply from any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key. |
| Missing authorization in the Sieve editheader action (6.2.22 through 6.3.6) and in the mail-rule Set header value action (6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to make the server send mail as any address, DKIM-signed where the address is at a domain the server signs for. A Sieve script's editheader (addheader/deleteheader) could add or delete any header field except Received and Return-Path, and the server applies a script's header edits before it queues a redirect, so the redirected copy is sent as the script left it. The server signs a message's first delivery pass as the domain named in its From header wherever it signs DKIM for that domain and the message carries no signature of it. A script could therefore delete and re-add From - another account's address, or anyone's at a hosted domain - and redirect, so the server sent the message in that name and, for a hosted domain, signed it with that domain's DKIM key, a forgery aligned to pass the domain's DMARC; or, where another sender's domain is one the server signs for, delete the DKIM-Signature that sender's message arrived with, alter a field, and redirect, so the server re-signed the altered message as that sender's domain. editheader placed no restriction on From, Sender, Resent-From, Resent-Sender or DKIM-Signature. The editheader action was introduced in 6.2.22. In the mail-rule engine, a domain's or an account's rule's Set header value action could likewise set From, Sender, Resent-From, Resent-Sender or DKIM-Signature ahead of a forward or a copy, whoever the rule belonged to, so that an account acting on its own rules over COM, a domain administrator, or an API key confined to a domain (over the REST API from 6.3.4) could have the server forward or copy a message in the name of any address, signed, where that address is at a domain the server hosts with DKIM signing enabled, with that domain's key. |
| MISP contains a vulnerability in the handling of module plugin settings. When the server rebuilds module-supplied settings for API consumption, it drops the redacted and cli_only flags that a module declares in its own configuration metadata.
As a result:
- A module that marks a setting (such as an API key) as redacted still has its value returned in full by the servers/getSetting and servers/serverSettingsEdit endpoints, exposing sensitive credentials to any authenticated user who can read server settings.
- A module that marks a setting as cli_only (intended to be editable only via the command-line interface) can still be modified through the web API, bypassing the intended access restriction.
An authenticated user with access to server settings can therefore read sensitive module credentials and modify settings that the module author intended to restrict to CLI-only access.
Affected: <2.5.48 |
| MISP contains an access control flaw in the proposal (shadow attribute) visibility logic. The authorization check accepted any attribute or object carrying one of the user's sharing groups without verifying the distribution level, and denied the owning organisation access to proposals on its own organisation-only attributes.
- A user belonging to a sharing group could view proposals on attributes or objects with that sharing group, regardless of the attribute's distribution level (levels 1-3 should restrict visibility)
- The owning organisation could not view proposals on its own org-only attributes
Security impact: Unauthorized disclosure of proposed attribute changes to users who should not have access based on distribution level restrictions.
Affected: <2.5.48 |
| A security flaw has been discovered in aircheng-org iWebShop-5 up to 5.16. The affected element is the function admin_repwd/admin_repwd_act of the file controllers/system.php of the component Password Change. The manipulation of the argument password/repassword results in cross-site request forgery. It is possible to launch the attack remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. |
| Missing Authorization vulnerability in Apache Answer.
This issue affects Apache Answer: through 2.0.2.
An unauthenticated or unauthorized user can retrieve the invited-user list associated with a non-public question due to missing visibility authorization checks.
Users are recommended to upgrade to version 2.0.3, which fixes the issue. |
| Frappe HR is an open-source human resources management solution (HRMS). Prior to 15.58.3 and 16.4.3, HRMS PWA API endpoints for employee data do not consistently authorize employee-specific PWA API requests. An authenticated user requests records associated with another employee. The user can request records associated with another employee through PWA API endpoints. Successful exploitation can access sensitive HR data belonging to other employees. This issue is fixed in versions 15.58.3 and 16.4.3. |
| A security flaw has been discovered in dyad-sh dyad up to 1.16.0. Affected by this issue is some unknown functionality of the component OAuth Callback Handler. Performing a manipulation results in cross-site request forgery. The attack may be initiated remotely. Upgrading to version 1.17.0-beta.1 can resolve this issue. The patch is named 39fbae87b38573616a1a3b152cdb292787bb1109. It is advisable to upgrade the affected component. |
| A vulnerability has been found in David-Crty Databasement up to 1.8.1. Affected by this vulnerability is an unknown functionality of the file app/Http/Requests/Api/V1/SaveScheduledRestoreRequest.php of the component Scheduled Restore. Such manipulation of the argument schema_name leads to missing authorization. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 1.8.2 addresses this issue. It is suggested to upgrade the affected component. |
