| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An attacker who gains the ability to execute arbitrary code on a system with TrueConf Server (Linux) versions from 4.7.2 up to, but not including, 5.5.6 installed, running as the user trueconf (by exploiting some other vulnerability), can elevate their privileges to root. |
| Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.3.7 allow a local authenticated user to run code as the administrator who installs the product, when it is installed into a new program folder in a location whose permissions let every user write, such as the root of a drive. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but its setup lets Inno Setup make a new program folder first, with the permissions the folder above hands down, and replaces them only afterwards, tens of milliseconds later (33 to 139 milliseconds in the project's test runs). In that time any local account may make files and folders in the new folder, which keep that account as their owner, among them the Bin folder that setup then copies the programs into. Setup runs programs from Bin with the administrator's elevated rights, registering the service among them, before its hardening at the end of setup takes such a folder back, and those programs load a library placed in Bin in place of the system's. The default installation under Program Files, whose folders give ordinary users read and execute only, is not affected. |
| Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.3.7 allow a local authenticated user to run code as the administrator who runs setup, when the server is installed into a program folder that is already there and that accounts other than the administrators could write, such as a folder made beforehand at the root of a drive, or when such an installation is upgraded or repaired. 6.3.7 fixed CVE-2026-107571 by giving the program folder, Bin and ControlPanel permissions that only administrators may change, but for a folder that is already there it does so only at the end of setup: setup first copies the programs into Bin, which every user may still write, and runs programs from Bin with the administrator's elevated rights, registering the service among them, before that hardening, so that a library another account places in Bin meanwhile is loaded in place of the system's. A handle an account opened on such a folder while it could write it keeps that access after the hardening. The default installation under Program Files, whose folders give ordinary users read and execute only, is not affected. |
| Improper access control in Windows Kernel allows an authorized attacker to elevate privileges locally. |
| Incorrect default file permissions in Kiro CLI (formerly Amazon Q Developer CLI) before version 2.27.0 on macOS and Linux might allow other local users on the same host to read a user's session transcripts and prompt history, including any credentials or source code they contain. The CLI created its local session storage files with permissions that made them readable by all local users.
To remediate this issue, users should upgrade to Kiro CLI version 2.27.0 or later and launch it once. Users who ran Amazon Q Developer CLI 1.16.0 through 1.19.x should also delete the ~/.aws/amazonq/.cli_bash_history file or restrict it to the owner. |
| In the Linux kernel, the following vulnerability has been resolved:
tun: Require CAP_NET_ADMIN to attach to an ownerless device
Twenty years ago I made creating a tuntap device require CAP_NET_ADMIN
in commit ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap
devices.")
The idea was to allow the permissions on /dev/net/tun to be relaxed to
0666 and thus allow owners of tun devices assigned with TUNSETOWNER to
actually open it and get at their devices.
What we missed at the time was that persistent devices with *no* owner
were already essentially world-consumable, and anyone who could open
the device node could also attach to those.
Even then, using persistent devices with no explicitly set owner — on
the (false) presumption that CAP_NET_ADMIN would be required to open
them — wasn't an egregious userspace bug. There are cases where it does
make sense to separate the creation/configuration of the netdevice, from
the process which shovels packets into it.
Since then, TUNSETGROUP was added a year later in commit 8c644623fe7e
("[NET]: Allow group ownership of TUN/TAP devices."). Its commit message
noted that if both uid and gid are set, both have to match (in itself a
bizarre choice) — but still not that with *neither* set, no permission
at all was required.
Then in 2012 commit c8d68e6be1c3 ("tuntap: multiqueue support") allowed
new queues to be attached to a device from the moment of its creation,
with no way for userspace to close the race between creation and a
subsequent TUNSET{OWNER,GROUP}.
In 2024, commit 3ca459eaba1bf ("tun: fix group permission check") tried
to fix things to be saner: only require the user *or* the group to
match, in line with standard POSIX permissions, and require
CAP_NET_ADMIN if neither the user nor group authorised the access
(although it put the CAP_NET_ADMIN check first, and would wrongly have
reported the capability as having been used even when it was not).
That fix was reverted in commit a70c7b3cbc06 ("tun: revert fix group
permission check") due to allegedly causing a regression in an selinux
test suite which *expected* the attachment to succeed when authorised
by none of user, group, nor CAP_NET_ADMIN:
https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/
We should not break UAPI. But we don't have to consider an selinux test
case which deliberately exercises a security flaw to be UAPI worth
preserving either. To which end, I have fixed it in selinux-testsuite
commit b2f894f0016b ("tests/tun_tap: set an owner on the device for the
relabel tests").
So: fix the lack of CAP_NET_ADMIN check on devices which *haven't* been
assigned an owner or group, while leaving the weird tun ownership model
as it was (user *and* group have to match, if both are set). If someone
still wants to fix the latter (which wasn't actually the reason the
previous attempt was reverted), they can do it under separate cover.
Permit attaching to an existing device only if an owner and/or group was
set and the caller matches all that were set, or if the caller has
CAP_NET_ADMIN. The only behavioural change is that a device with no
owner or group now requires CAP_NET_ADMIN to attach — precisely the
loophole we want to close.
And put the CAP_NET_ADMIN check in the right place this time. |
| Incorrect default permissions for the Intel(R) VTune(TM) Profiler software within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an unauthenticated user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via network access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Incorrect default permissions for some Intel(R) Graphics Driver software installers within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires active user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Incorrect default permissions for some Intel(R) Graphics Driver software installers within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an authenticated user combined with a high complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are present without special internal knowledge and requires active user interaction. The potential vulnerability may impact the confidentiality (high), integrity (high) and availability (high) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| Incorrect default permissions vulnerability in TÜBİTAK BİLGEM Software Technologies Research Institute eta-remote allows Accessing Functionality Not Properly Constrained by ACLs.
This issue affects eta-remote: from 0.0.2 before 0.0.3. |
| IRISPowerscan contain an insecure default
configuration where the built-in installation account is assigned elevated
privileges with a predictable password, which could allow an unauthenticated
attacker to gain unauthorised access to privileged application functionality. |
| Improper Access Control in the program installation folder in NEC Corporation WebSAM Winshare Ver 7.5.0 and earlier (excluding Ver 7.3.3), Ver 7.6.0 and Ver 7.7.0 through 7.7.1 on Windows allows a locally authenticated low-privileged attacker to execute arbitrary code with SYSTEM privileges via a crafted DLL file that is loaded by a SYSTEM-level process. |
| Gitleaks through 8.30.1 contains an incorrect permission assignment vulnerability that allows local users to read scan reports because cmd/root.go creates the --report-path file with os.Create and default permissions. Unless --redact is passed, other local users on shared hosts or CI runners can read plaintext secrets and matching lines to obtain discovered credentials. |
| Vikunja before 2.7.1 contains an insecure file permissions vulnerability that allows local users to read stored data because localStorage.Write creates blobs world-readable. Local attackers on a shared host can read attachments, project backgrounds and exports, and copy the SQLite database to crack password hashes offline. |
| Vikunja before 2.7.1 contains an insecure file permissions vulnerability that allows local users to read dump archives created with umask permissions by the vikunja dump command. Local attackers on a shared host can read the world-readable zip in the rootpath to obtain config, password hashes, TOTP secrets, tokens, and stored files. |
| A vulnerability was discovered in Samba, where the flaw allows SMB clients to truncate files, even with read-only permissions when the Samba VFS module "acl_xattr" is configured with "acl_xattr:ignore system acls = yes". The SMB protocol allows opening files when the client requests read-only access but then implicitly truncates the opened file to 0 bytes if the client specifies a separate OVERWRITE create disposition request. The issue arises in configurations that bypass kernel file system permissions checks, relying solely on Samba's permissions. |
| Vulnerability in the Oracle Product Lifecycle Analytics product of Oracle Supply Chain (component: Installation Issues). The supported version that is affected is 3.6.1. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Product Lifecycle Analytics executes to compromise Oracle Product Lifecycle Analytics. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Product Lifecycle Analytics accessible data. CVSS 3.1 Base Score 5.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). |
| Local privilege escalation in `SmartUpdate.exe` and `SmartExecute.exe` in INFINITT Healthcare Co., Ltd. INFINITT PACS allows a local low-privileged attacker to execute arbitrary commands with administrator privileges via modification of a world-writable `execlist.txt` command manifest that is processed during application updates. |
| In HPE Cray Programming Environment versions 25.03 and 25.09, prior to 26.03, the method that CPE is deployed on HPCM potentially allows elevated access by a local unprivileged user. |
| GFI KerioConnect (Kerio Connect) Outlook Connector (Offline Edition), 'KOFF', before 10.0.9 Patch 2 contains a local privilege escalation vulnerability caused by weak installer permissions that leave the product directory writable by the built-in Users group. A local non-administrative attacker can replace the searchd.exe service binary used by the bundled KOFFIndexingService, which runs as LocalSystem, to execute arbitrary code with NT AUTHORITY\SYSTEM privileges upon the next service start or reboot. |
