| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| This issue may allow an authenticated IPMI Administrator to read arbitrary files from the BMC filesystem, disclosing material well beyond the intended IPMI management role. |
| HCL BigFix AEX is affected by an Unrestricted File Upload and Improper Access Control vulnerability. This could allow an attacker to upload malicious or unauthorized files and directly access or download sensitive uploaded content, potentially leading to information disclosure, unauthorized access, or system compromise. |
| Vulnerability in the PeopleSoft Enterprise PeopleTools product of Oracle PeopleSoft (component: Updates Environment Mgmt). Supported versions that are affected are 8.61-8.63. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where PeopleSoft Enterprise PeopleTools executes to compromise PeopleSoft Enterprise PeopleTools. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of PeopleSoft Enterprise PeopleTools accessible data as well as unauthorized read access to a subset of PeopleSoft Enterprise PeopleTools accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of PeopleSoft Enterprise PeopleTools. CVSS 3.1 Base Score 4.2 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L). |
| Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 allows the disabled_actions configuration setting to be bypassed. The check compared only the action name as requested, so a remote authenticated attacker could reach an action listed in disabled_actions by requesting it through its deprecated alias instead. Upstream fixed this in the commit “Fix bug where deprecated action aliases bypassed `disabled_actions` setting”, which moves the check into rcmail::action_handler() and resolves aliases before comparing. |
| In the Linux kernel, the following vulnerability has been resolved:
namespace: keep covered mounts covered in OPEN_TREE_NAMESPACE
open_tree(OPEN_TREE_NAMESPACE) creates a new mount namespace from a
copy of the tree at the given path. The caller needs to be privileged
over its current user namespace because the new mount namespace will be
owned by it. It doesn't need to be privileged over the mount namespace
the tree is copied from. An unprivileged user just needs to create a
user namespace first.
The copy follows the rules of a detached bind mount. Without
AT_RECURSIVE only the mount itself is cloned and its children are left
out. With AT_RECURSIVE unbindable mounts are skipped. Both is fine when
the caller has privileges over the source mount namespace because it
could unmount those mounts anyway. Not so for an unprivileged user in
that mount namespace. For them a mount namespace copy is what unshare()
does. copy_mnt_ns() copies everything including unbindable mounts and
lock_mnt_tree() makes sure nothing can be unmounted in the copy. Nothing
that was covered gets revealed.
create_new_namespace() only does the locking and so the covered content
is right there in the new mount namespace:
# mount -t tmpfs none /tmp/otn; mkdir /tmp/otn/covered
# echo hidden > /tmp/otn/covered/under.txt
# mount -t tmpfs none /tmp/otn/covered
uid 1000, after unshare(CLONE_NEWUSER):
fd = open_tree(AT_FDCWD, "/tmp/otn", OPEN_TREE_NAMESPACE);
setns(fd, CLONE_NEWNS);
open("/covered/under.txt", O_RDONLY) -> "hidden"
Covering paths with mounts is how container runtimes mask parts of
/proc and /sys and how admins hide things.
When the caller's user namespace doesn't own the source mount namespace
copy the way unshare() does and refuse a non-recursive copy of a mount
that has anything mounted below the requested directory and copy
unbindable mounts in a recursive copy. A caller that is privileged over
the source mount namespace sees no change. |
| In the Linux kernel, the following vulnerability has been resolved:
namespace: never expire a locked mount
Locked mounts are special. They protect the underlying files and
directories from being revealed. do_umount() refuses to unmount locked
mounts but shrink_submounts() doesn't.
A shrinkable mount can become locked once the owner of a user namespace
puts it beneath a locked mount with MOVE_MOUNT_BENEATH. The locked
property now moves to the mount at the bottom making it possible to
unmount the top mount.
So umount() of an unlocked ancestor now expires the bottom mount first
and the covered directory is revealed:
move_mount(c -> x/hidden, MOVE_MOUNT_BENEATH) = 0
the cover after the lock moved: umount2(x/hidden) = 0
the holder of the lock: umount2(x/hidden) = EINVAL
the root of the copy, busy: umount2(x) = EBUSY
reads x/hidden/secret: "covered-by-root"
So leave a locked mount alone as it dies together with its parent. A
plain umount() of an unlocked mount with a locked one below it is EBUSY
from now on. It's the same for any other locked child. A lazy umount
still takes the whole tree.
mark_mounts_for_expiry() never sees a locked mount. lock_mnt_tree()
leaves a mount on an expiry list alone and nothing else puts a locked
one on such a list. Add an assert for this. |
| The Goobi viewer is a web application that allows digitised material to be displayed in a web browser. From version 24.03 to before version 26.05, the DownloadTaskEndpoint WebSocket endpoint (/tasks/download/monitor.socket) in goobi-viewer-core accepts download requests from unauthenticated users. This issue has been patched in version 26.05. |
| Trudesk through 1.2.11 contains a missing authentication vulnerability that allows unauthenticated attackers to download private ticket attachments under /uploads. Because express.static serves the public/ directory before the hasAuth-guarded /uploads mount, attackers who know or guess a ticket ObjectId and filename can retrieve confidential attachments. |
| In the Linux kernel, the following vulnerability has been resolved:
namespace: don't copy an unmounted mount tree
may_copy_tree() accepts a mount whose root is an nsfs or pidfs file
before it checks whether that mount is mounted. This exception exists
for nsfs and pidfs mounts. They are part of no mount namespace so
neither check_mnt() nor is_mounted() would let them through and
bind-mounting a nsfsfd or a pidfd wouldn't work.
Problem is that exception also admits a bind mount of such a file when
it was lazily unmounted and is only kept alive by a file descriptor:
mount --bind /proc/self/ns/net /tmp/x
exec 3< /tmp/x
umount -l /tmp/x
mount --rbind /proc/self/fd/3 /tmp/y
With MS_REC or AT_RECURSIVE copy_tree() doesn't stop at the unmounted
mount. It copies every mount that stayed attached to it as well. So if
you have a bunch of overmounts over the nsfsfd or the pidfd the whole
unmounted stack is copied. That's a bug.
So refuse to walk an unmounted tree. Copying its root alone stays
possible. So a bind mount of a namespace that is gone can still be
recreated from a file descriptor on the old one. The file descriptor
pins that mount and its root and __has_locked_children() only reads the
direct children which don't leave the parent's list without
namespace_sem. The internal mounts carry MNT_NS_INTERNAL instead of NULL
and are still walked. Copying an unmounted tree recursively fails with
EINVAL. |
| Files or directories accessible to external parties in Windows Event Viewer allows an authorized attacker to disclose information over a network. |
| As part of Cisco's ongoing commitment to proactive security and product quality, Cisco has conducted a comprehensive internal security review. This review resulted in a software hardening release that addresses multiple internally discovered vulnerabilities. The vulnerabilities tracked by CVE-2026-76531 are related to files or directories accessible to external parties and are grouped under the Common Weakness Enumeration (CWE) CWE-552. |
| Vitest is a testing framework powered by Vite. From 5.0.0-beta.6 until 5.0.5, Vitest dev servers can misapply server.fs.deny because project servers replace Vite's defaults and the root server adds .vitest-secret-token after Vite compiles its matcher. An attacker who can reach an affected UI, Browser Mode, or API server can read denied project files or the fallback API token at node_modules/.vitest/.vitest-secret-token, and Browser Mode with test.projects can expose JavaScript-compatible .env values through a malicious website. This issue is fixed in version 5.0.5. |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-31 and 6.9.13-56, a crafted image can bypass an ImageMagick security policy that uses coder as its domain, potentially allowing data prohibited by the policy to be read. This issue is fixed in versions 7.1.2-31 and 6.9.13-56. |
| Vite is a frontend tooling framework for JavaScript. Prior to 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3, import analysis can record a root-relative browser URL in safeModulePaths instead of the cleaned resolved module identifier. On a network-accessible, non-Windows development server, an imported project file whose URL matches an absolute host path can authorize a later raw-filesystem request for that host file, provided server.fs.deny does not block it. The request can disclose the matching file outside the project root, but it does not allow arbitrary path traversal because the host path must correspond to a project-relative URL authorized by the application graph. This issue is fixed in versions 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3. |
| Hono is a Web application framework that provides support for any JavaScript runtime. From 4.12.4 until 4.13.11, serveStatic can interpret a malformed percent-encoded path differently from upstream routing middleware and bypass protection for a static prefix. The root cause is serveStatic decodes a routed request path a second time before filesystem lookup. The attack mechanism is malformed percent encoding survives the first routing interpretation and becomes a protected path only during the later static-file decode. The affected component is serveStatic. The trigger conditions are an application protects a static prefix with upstream middleware and serveStatic receives an attacker-controlled malformed percent-encoded path. The impact is unauthorized disclosure of a static file that upstream middleware was intended to protect. The issue does not permit traversal outside the configured static root. This issue is fixed in version 4.13.11. |
| MariaDB server is a community developed fork of MySQL server. From 10.6.1 until 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2, the CONNECT engine plugin file-access UDFs json_file(), bson_file(), jfile_make(), bfile_make(), and jbin_file() are affected because each does not enforce FILE privilege or the secure_file_priv setting. A low-privileged attacker can trigger the issue by calling a CONNECT file-access UDF with a filesystem path, then invoke a CONNECT file-access UDF to access a filesystem path and read or write files that the database account is not authorized to access, subject to operating-system permissions. This issue is fixed in versions 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. |
| OmniFaces is a utility library for Faces. In OmniFaces versions before 1.14.3, 2.7.33, 3.14.23, 4.7.12, and 5.4.2, CombinedResourceHandler accepts a structurally valid deflated and base64 encoded combined resource ID without verifying that the server issued it. A forged ID can cause unbounded decoded output, add unique reconstructed IDs to a process-lifetime cache, or combine resources other than stylesheets and scripts. Because jakarta.faces.RESOURCE_EXCLUDES is not applied by this custom resolution path, a forged ID can disclose Facelets source from the webapp resource tree or META-INF/resources. In a deployment configured with the wildcard CDN mapping, a forged ID that selects omnifaces.graphic can also cause a blind, deployment-dependent server-side fetch whose destination derives partly from the request Host header. The flaw does not provide arbitrary file read or establish arbitrary-scheme or arbitrary-destination SSRF. The shared authenticity failure permits memory exhaustion and limited resource disclosure. This issue is fixed in versions 1.14.3, 2.7.33, 3.14.23, 4.7.12, and 5.4.2. |
| Files or directories accessible to external parties in Windows Projected File System allows an authorized attacker to disclose information locally. |
| This is a vulnerability in Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center. Crowd Data Center, Crucible and Fisheye. This Arbitrary File Access vulnerability allows an unauthenticated attacker to access specific files within the web application root directory in affected versions. Exploitation requires prior knowledge of the target file's exact name and path; this vulnerability does not allow attackers to enumerate or list directory contents. In some configurations, there may be some sensitive files that make this highly severe. This vulnerability allows an unauthenticated remote attacker to access specific files within the web application root directory in affected versions. The vulnerability must be addressed for affected versions of: -- Bitbucket Data Center, introduced in version >= 4.6.0, fix versions: 9.4.26, 10.2.8, 10.5.1 -- Confluence Data Center, introduced in version >= 5.10.0, fix versions 9.2.26, 10.2.19 -- Crowd Data Center, introduced in version >= 2.11.0, fix versions 6.3.7, 7.0.3, 7.1.7, 7.2.4 -- Jira Software Data Center, introduced in version >= 7.1.0, fix versions 9.12.40, 10.3.26, 11.3.12 -- Jira Service Management Data Center, introduced in version >= 3.1.0, fix versions 5.12.40, 10.3.26, 11.3.12 -- Bamboo Data Center >= 7.0.1, fix versions 10.2.24, 12.1.12 -- Crucible, fix versions 4.9.15 -- Fisheye, fix version 4.9.15 -- Exploitation requires prior knowledge of the target file's exact name and path. The vulnerability does not include the capability to enumerate or list directory contents. |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_policy: fix strict mode inbound policy matching
match_policy_in() walks sec_path entries from the last transform to the
first one, but strict policy matching needs to consume info->pol[] in
the same forward order as the rule layout.
Derive the strict-match policy position from the number of transforms
already consumed so that multi-element inbound rules are matched
consistently. |
