| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect Privilege Assignment vulnerability in Ultimate Member Ultimate Member ultimate-member allows Privilege Escalation.This issue affects Ultimate Member: from n/a through 2.13.1. |
| A vulnerability was detected in HarnessRouter up to 0.31.10. This affects an unknown function of the file gateway/app.py of the component Identity Mode. Performing a manipulation of the argument X-Harness-Org/X-Harness-Member results in improper authorization. The attack is possible to be carried out remotely. The attack is considered to have high complexity. The exploitability is reported as difficult. Upgrading to version 0.31.11 mitigates this issue. The patch is named 48a26cdf9c4544d2c88d1a07f0777f063f1d753f. The affected component should be upgraded. |
| Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 2.6.0, UpdateUser in backend/api/handlers/users.go sets PasswordHash for any target without comparing caller and target privilege. A holder of delegated users:update permission can submit a password change for the global administrator, replace the administrator password, and authenticate as that account, resulting in complete global administrator account takeover. This issue is fixed in version 2.6.0. |
| A vulnerability was found in aaPanel up to 8.25.0. The impacted element is the function GetClientIp of the file class/public/common.py. The manipulation of the argument X-Real-Ip results in improper access controls. The attack may be performed from remote. The exploit has been made public and could be used. The vendor confirms: "The reported X-Real-Ip IP-bypass vulnerability has already been fixed". |
| A flaw was found in Keycloak. A highly privileged user with `manage-clients` permission can exploit this vulnerability by injecting a hardcoded role mapper into any client. This action allows the user to bypass existing scope restrictions and inject the `realm-admin` role into generated tokens, resulting in privilege escalation and full administrative access to the realm. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Correctly cap ZCR_EL2 provided by a guest hypervisor
ZCR_EL2 can be updated by a VHE guest hypervisor either using ZCR_EL2
(which traps) or ZCR_EL1 (which does not trap). KVM handles both in
different way:
- on ZCR_EL2 trap, ZCR_EL2.LEN is immediately capped at the VM's own
VL limit. This has the potential to break existing SW that relies
on the full LEN field to be stateful.
- on ZCR_EL1 access, we do absolutely nothing.
On restoring the SVE context for an L2 guest, we directly restore the
guest hypervisor's view of ZCR_EL2 into the physical ZCR_EL2. If the
guest's view of the register was updated using the ZCR_EL2 accessor,
the value has already been sanitised (with the caveat mentioned above).
But if the guest used ZCR_EL1, the raw value is written into the HW,
and the L2 guest can now access VLs that it shouldn't.
Fix all the above by moving the VL capping to the restore points,
ensuring that:
- the HW is always programmed with a capped value, irrespective of
the accessor being used,
- the ZCR_EL2.LEN field is always completely stateful, irrespective
of the accessor being used.
Additionally, move ZCR_EL2 to be a sanitised register, ensuring that
only the LEN field is actually stateful. This requires some creative
construction of the RES0 mask, as the sysreg generation script does
not yet generate RAZ/WI fields.
[maz: rewrote commit message, tidy up access_zcr_el2()] |
| Incorrect Privilege Assignment vulnerability in Cozmoslabs Profile Builder profile-builder allows Privilege Escalation.This issue affects Profile Builder: from n/a through 4.0.4. |
| Incorrect Privilege Assignment vulnerability in Hamid Alinia Login with phone number login-with-phone-number allows Privilege Escalation.This issue affects Login with phone number: from n/a through 1.8.77. |
| A weakness has been identified in dhikshitha29 Insurance-Management-System 91de5edda5baa109ad8e9baf03ce6a3ceda84183/125362cc21dca20d74091a4913a5096bb58dd837. Affected by this issue is some unknown functionality of the file /Admin/includes/Admin-Register-inc.php of the component Add New Admin Form. Executing a manipulation of the argument submit/Admin_id/password can lead to improper authorization. The attack may be performed from remote. The exploit has been made available to the public and could be used for attacks. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was found in Open5GS up to 2.7.6. This impacts the function ran_ue_find_by_amf_ue_ngap_id of the file src/amf/context.c of the component AMF/MME. Performing a manipulation results in improper authorization. It is possible to initiate the attack remotely. The exploit has been made public and could be used. The patch is named 5746b8576cfceec18ed87eb7d8cf11b1fb4cd8b1. It is suggested to install a patch to address this issue. |
| A vulnerability was determined in Eleveo Call Recording Software 9.7.0. This affects an unknown part of the file /callrec/searchAction.do of the component Query Builder. This manipulation causes improper access controls. Remote exploitation of the attack is possible. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. |
| A security vulnerability has been detected in Portabilis i-Educar up to 2.9.10. Affected by this issue is some unknown functionality of the file app/Http/Controllers/AccessLevelController.php of the component User Type Handler. The manipulation leads to insecure inherited permissions. The attack may be initiated remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 2.12 can resolve this issue. The identifier of the patch is d53365e5656f6499a4deddf89d522814655f769d. It is advisable to upgrade the affected component. |
| A vulnerability has been found in Portabilis i-Educar up to 2.10. This vulnerability affects unknown code of the file /cancelar-enturmacao-em-lote/. Such manipulation leads to improper access controls. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. Upgrading to version 2.12 is able to resolve this issue. The name of the patch is d53365e5656f6499a4deddf89d522814655f769d. The affected component should be upgraded. |
| A flaw has been found in Portabilis i-Educar up to 2.10. This affects an unknown part of the file /enturmacao-em-lote/. This manipulation causes improper access controls. The attack is possible to be carried out remotely. The exploit has been published and may be used. Upgrading to version 2.12 is able to mitigate this issue. Patch name: d53365e5656f6499a4deddf89d522814655f769d. You should upgrade the affected component. |
| A vulnerability was detected in Portabilis i-Educar up to 2.10. This affects an unknown function of the file /exportacao-para-o-seb. Performing a manipulation results in improper access controls. The attack is possible to be carried out remotely. The exploit is now public and may be used. Upgrading to version 2.12 mitigates this issue. The patch is named d53365e5656f6499a4deddf89d522814655f769d. You should upgrade the affected component. |
| Incorrect privilege assignment in Temporary Elevated Access Management (TEAM) for AWS IAM Identity Center solution before version 1.5.1 might allow an authenticated remote user with application-level access to read, approve, modify, or revoke arbitrary access requests, thereby obtaining unintended temporary elevated access to the AWS accounts accessed using the TEAM deployment.
This issue has been addressed in TEAM version 1.5.1 or later. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. |
| In the Linux kernel, the following vulnerability has been resolved:
net: sit: require CAP_NET_ADMIN in the device netns for changelink
ipip6_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.
Gate ipip6_changelink() on rtnl_dev_link_net_capable() at its top,
before any attribute is parsed. sit was the one tunnel type not covered
by the recent series that added this check to the other changelink()
handlers. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink
ip6gre_changelink() and ip6erspan_changelink() operate 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.
Gate both ops on rtnl_dev_link_net_capable() at their top, before any
attribute is parsed. |
| In the Linux kernel, the following vulnerability has been resolved:
vxlan: require CAP_NET_ADMIN in the device netns for changelink
A tunnel changelink() operates on at most two netns, dev_net(dev) and
the sticky underlay netns vxlan->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 vxlan->net can rewrite a vxlan
device whose underlay lives in vxlan->net.
vxlan_changelink() validates and applies the new configuration against
vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the
underlay socket in that netns, so the same reasoning as the tunnel
changelink series applies here.
Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of
the op before any attribute is parsed, matching ipgre_changelink() and
the rest of the "require CAP_NET_ADMIN in the device netns for
changelink" series.
Found by 0sec automated security-research tooling (https://0sec.ai). |
| In the Linux kernel, the following vulnerability has been resolved:
geneve: require CAP_NET_ADMIN in the device netns for changelink
A tunnel changelink() operates on at most two netns, dev_net(dev) and
the sticky underlay netns geneve->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 geneve->net can rewrite a geneve
device whose underlay lives in geneve->net.
geneve_changelink() applies the new configuration against geneve->net:
geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
reopen the underlay sockets in that netns (geneve_sock_add() uses
geneve->net), so the same reasoning as the tunnel changelink series
applies here.
Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
the op before any attribute is parsed, matching ipgre_changelink() and
the rest of the "require CAP_NET_ADMIN in the device netns for
changelink" series.
Found by 0sec automated security-research tooling (https://0sec.ai). |
