| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Armatura One's message broker logs client connection credentials and the associated password in plain text during normal operation. Any party with read access to this log, or to a backup or support bundle that includes it, can obtain the logged credential. |
| Armatura One's backup and restore routine records the full database connection command, including the superuser password, in plain text in a log file on the host. Credentials disclosed by this finding can be used to access the database when access to the server operating system is available. |
| A flaw was found in advisor-backend. Multiple code paths within the application deserialize YAML (YAML Ain't Markup Language) with an unsafe full Loader, which can instantiate arbitrary Python objects via YAML tags. An unauthenticated remote attacker can exploit this by submitting specially crafted YAML input, leading to remote code execution (RCE) within the `advisor-backend` pod. This compromise could allow access to shared database credentials and impact all tenants. |
| In the Linux kernel, the following vulnerability has been resolved:
dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds
DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the
caller's fd table via dma_buf_fd() -> fd_install() before
dma_heap_ioctl() copies the result back to userspace. If the trailing
copy_to_user() fails, userspace never learns the fd number, but the
fd (and the underlying dma-buf reference) are already visible to
other threads in the same process and are leaked for the lifetime of
the process.
The obvious "close it on the failure path" fix is unsafe: once
fd_install() has run, another thread can already dup() the fd, send
it via SCM_RIGHTS, or close() it and let its number be reused, so a
subsequent close_fd() from the ioctl path can operate on an unrelated
file. This was pointed out by Christian König on v1 [1].
Restructure the allocation path so that fd_install() is the last,
unfailable step of a successful ioctl:
1. heap->ops->allocate() creates the dma_buf.
2. get_unused_fd_flags() reserves an fd number in the caller's
fd table without publishing it, so
no other thread can observe it.
3. copy_to_user() delivers the fd number to userspace;
on failure the fd is returned with
put_unused_fd() and the dma_buf
reference is dropped with
dma_buf_put(), leaving no user-
visible state behind.
4. dma_buf_fd_install() publishes the fd and emits the
trace_dma_buf_fd tracepoint -- from
here on the ioctl cannot fail.
A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap
fd_install() together with the DMA_BUF_TRACE() call, preserving the
export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate()
is refactored to return the struct dma_buf * directly (returning
ERR_PTR on failure) so the caller holds the dmabuf reference across
steps 3 and 4.
The failure at step 3 is easily reachable from userspace: pass a
struct dma_heap_allocation_data that lives in a page whose protection
is flipped to PROT_READ between copy_from_user() and copy_to_user()
(e.g. via mprotect()). Before this change each such ioctl leaks one
dmabuf fd; after it, the fd table is unchanged on failure and only
/dev/dma_heap/<name> remains open.
No UAPI or heap-driver interface change.
[1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/ |
| The cleanup of tempfile.TemporaryDirectory is vulnerable to a race condition. An attacker who can modify the tree during cleanup can replace a directory with a symbolic link, causing files outside of the temporary directory to be deleted or have their permissions and file flags reset, with the privileges of the process performing the cleanup. Note that platforms where shutil.rmtree.avoids_symlink_attacks is false, remain affected, and file flags may still be reset outside of the tree on all platforms. |
| An API key is
hardcoded and retrievable from the application package. Since Android
applications can be reverse engineered, embedding sensitive API credentials
directly in the client application may allow unauthorized users to extract and
misuse the key. |
| API
key is hardcoded and retrievable from the application package. Since Android
applications can be reverse engineered, embedding sensitive API credentials
directly in the client application may allow unauthorized users to extract and
misuse the key. |
| In JetBrains YouTrack before 2026.2.18991 stored SMTP server credentials could be disclosed by changing the server host |
| Classroom 50 is a free and open-source tool for managing and grading programming assignments via GitHub. Prior to version 1.11.0, `gh teacher download` clones each student's assignment repository and then writes autograde artifacts (`result.json` and `results.json`) into the just-cloned working tree. The write followed symlinks, so a student who committed `result.json` or `results.json` as a **symlink** (materialized verbatim by `git clone`) could redirect the teacher's write to an arbitrary path — e.g. `~/.zshrc`, `~/.ssh/authorized_keys`, a cron file, or an in-clone `.git/hooks/*` file that git subsequently executes. The written bytes are attacker-controlled (the student's uploaded release asset for `result.json`; student-chosen submit-tag names for `results.json`). This is an arbitrary file write leading to code execution as the teacher, whose `gh` token carries `admin:org`, `repo`, and `workflow` across the entire classroom organization. Version 1.11.0 contains a patch. Some workarounds are available. Avoid running `gh teacher download` against untrusted student repositories, or run it inside a disposable sandbox / container with no access to sensitive host files or credentials. Inspect cloned trees for symlinked, hardlinked, or special (`result.json`/`results.json`) entries before allowing the artifact-refresh step to run. |
| OpenPanel through 2.3.0 writes Model Context Protocol authentication tokens from URL query parameters to plaintext application logs without redaction. Attackers with access to application stdout or centralized logging systems can capture base64-encoded credentials to replay MCP requests and access project analytics. |
| A flaw was found in crun. After pivot_root, reopening /dev/null for stdio can follow a symlink and attach a host file to container stdio, then change that file's ownership. Affected versions are crun 1.29.1 and earlier. Default configurations that mount a fresh /dev are not exposed. No fixed release is available yet. |
| When tarfile extracts a link on a system that doesn't support links, it falls back to extracting a member from the archive. In this case, the filter function is run twice: once for the extracted member, and once with name set to the location of the link. For one of the calls, the return value was ignored. Instead, the member should be skipped if either call returns None. |
| Editor PHP Object Injection in Hide Shipping Method For WooCommerce <= 1.5.4 versions. |
| Tornado before 6.5.9 contains a path traversal vulnerability in StaticFileHandler that follows symbolic links inside the static root without confirming the resolved target stays within it. When a symlink pointing outside the static directory exists inside it, unauthenticated attackers can request it to read files such as configuration files, private keys, and application secrets accessible to the process user. |
| RARLAB UnRAR before 6.12 on Linux and UNIX allows directory traversal to write to files during an extract (aka unpack) operation, as demonstrated by creating a ~/.ssh/authorized_keys file. NOTE: WinRAR and Android RAR are unaffected. |
| Editor PHP Object Injection in Page Builder by SiteOrigin <= 2.36.0 versions. |
| Contributor PHP Object Injection in Schema & Structured Data for WP & AMP <= 1.66 versions. |
| Contributor PHP Object Injection in Nested Pages <= 3.3.2 versions. |
| Contributor PHP Object Injection in Photo Gallery by 10Web <= 1.8.46 versions. |
| Shop manager PHP Object Injection in Extra Product Options For WooCommerce | Custom Product Addons and Fields <= 3.3.8 versions. |
