| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| In PCRE2 before 10.48, pcre2_jit_match mishandles a previously copied subject being passed in as a context. An incorrect free operation can occur. |
| Doco-CD is a GitOps continuous delivery tool that automatically deploys and updates Docker Compose projects/services and Swarm stacks. Prior to version 0.90.1, a trust-boundary flaw in OCI artifact verification allowed artifact-provided deployment config to influence the policy used to verify that same artifact. When global OCI signature verification was enabled via `OCI_TRUST_POLICY` (`enabled: true`), an attacker with write access to the configured OCI tag could publish an unsigned or improperly signed artifact containing `.doco-cd.yml` with `oci.verify: false`. This could cause signature verification to be bypassed and untrusted deployment content to be applied. This primarily impacts users deploying from OCI artifacts where deployment config is read from artifact contents (for example, poll/webhook flows without trusted inline deployment overrides). The issue is fixed by enforcing a strict trust boundary and no-downgrade behavior. First, artifact-contained `.doco-cd.yml` is treated as untrusted for OCI trust-policy override decisions. Second, if global `OCI_TRUST_POLICY.enabled` is `true`, per-deployment `oci.verify: false` cannot disable verification. Some workarounds are available. Do not source deployment config from untrusted OCI artifact contents. Use trusted inline `POLL_CONFIG.deployments` and avoid relying on artifact-contained trust-policy overrides. Restrict write/push permissions for OCI repositories/tags used by doco-cd. Prefer immutable digest pinning and protected release/tag workflows. Monitor for unexpected artifact digest changes and failed/suspicious verification events. |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insertion of Sensitive Information into Log File vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to information exposure. |
| A cross-namespace authorization flaw in multicluster-observability-addon allows a user with permission to modify a managed cluster’s ManagedClusterAddOn configuration to reference ClusterLogForwarder or OpenTelemetryCollector resources outside the permitted namespace. If those resources reference Secrets, the add-on may copy the referenced Secrets to the attacker-controlled managed cluster. |
| Unauthenticated PHP Object Injection in Masteriyo - LMS <= 3.4.0 versions. |
| Unauthenticated PHP Object Injection in Everest Forms <= 3.6.0 versions. |
| Unauthenticated PHP Object Injection in ThemeREX Addons < 2.45.0 versions. |
| In Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, transient fields cannot be excluded from deserialization, allowing attackers able to submit configuration updates to specify the values of transient fields that will be deserialized, the impact depending on how those fields are used. |
| In Jenkins 2.579 and earlier, LTS 2.568.2 and earlier, user objects can appear as nested field values in other deserialized XML objects, allowing attackers with Overall/Read permission to create user objects by submitting crafted XML. |
| CWE-522: Insufficiently Protected Credentials vulnerability that could result in exposure of authentication information and unauthorized access to RTU functionality. |
| In the Linux kernel, the following vulnerability has been resolved:
mfd: qnap-mcu: keep the reply buffer alive past a command timeout
qnap_mcu_exec() publishes an on-stack buffer to the receive path:
unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE];
...
reply->data = rx;
reply->length = length;
and qnap_mcu_receive_buf() writes into it from the serdev receive path,
which runs out of flush_to_ldisc() and is not serialized against
qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec()
holds that mutex across wait_for_completion_timeout().
On a timeout qnap_mcu_exec() returns with reply->data still pointing at
its own frame. A reply that arrives late, or an unsolicited message from
the MCU, is then written into a stack frame that has been left, corrupting
whatever runs next on that stack. The same applies when qnap_mcu_write()
fails, since that path returns without touching the reply state either.
Move the receive buffer into struct qnap_mcu. It is 37 bytes and the
structure is devm_kzalloc()ed, so it lives as long as the driver, and a
late write lands in memory that is still valid and is reinitialized by the
next command. bus_lock keeps commands from sharing it.
This deliberately does not clear reply->data or reply->length on the
timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both
after its
if (!reply->length)
return size;
check: clearing reply->data gives a NULL dereference, and clearing
reply->length alone removes the reply->received == reply->length exit
condition, so the copy loop runs until the uart chunk is consumed and
overruns the buffer. Leaving both set keeps the write bounded by
reply->length, which qnap_mcu_exec() has already checked against
sizeof(mcu->rx). |
| In the Linux kernel, the following vulnerability has been resolved:
fuse: copy request headers via a stack buffer for io-uring
The fuse-io-uring transport copies req->in.h out to the ring in
fuse_uring_copy_to_ring() and req->out.h back in fuse_uring_commit().
Both headers live inside the fuse_request slab object, whose cache
(fuse_req_cachep) is created without a usercopy whitelist, so copying
them directly to/from userspace trips CONFIG_HARDENED_USERCOPY and
panics:
usercopy: Kernel memory exposure attempt detected from SLUB object
'fuse_request' (offset 56, size 40)!
kernel BUG at mm/usercopy.c:102!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:usercopy_abort (mm/usercopy.c:90)
Call Trace:
__check_heap_object (mm/slub.c:8268)
__check_object_size (mm/usercopy.c:197 mm/usercopy.c:258 mm/usercopy.c:223)
copy_header_to_ring (fs/fuse/dev_uring.c:618)
fuse_uring_prepare_send (fs/fuse/dev_uring.c:776 fs/fuse/dev_uring.c:785)
fuse_uring_send_in_task (fs/fuse/dev_uring.c:1306)
tctx_task_work_run (io_uring/tw.c:96)
task_work_run (kernel/task_work.c:233)
io_run_task_work (io_uring/tw.h:84)
io_cqring_wait (io_uring/wait.c:278)
__do_sys_io_uring_enter (io_uring/io_uring.c:2685)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Bounce both headers through an on-stack copy so the usercopy touches
stack memory, not the slab object. |
| Concrete CMS below 9.5.3 is vulnerable to PHP Object Injection via unserialize()
calls in the Workflow, Form block, and File/Set components that lack the
allowed_classes restriction. The Form block and File/Set sinks were addressed in
9.5.2; the Workflow component sinks were addressed in 9.5.3. An unauthenticated
attacker may trigger arbitrary PHP object instantiation if a malicious serialized
payload has been placed in the database. Thanks XananasX7 and Sanjorn Keeratirungsan
(dizconnect) for independently reporting the original components, and sh4d0byss for
reporting the Workflow component wasn't fixed in 9.5.2. The Concrete CMS security team gave this
vulnerability a CVSS v.4.0 score of 8.4 with vector CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/
VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. |
| Incorrect authorization in Isolated in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium) |
| Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 20.3.28, 21.2.20, and 22.1.1, Angular's @angular/common HttpTransferCache can cache an authenticated response when Server-Side Rendering (SSR) and hydration use a hierarchical HttpClient configured with withRequestsMadeViaParent. The child TransferCache evaluates an initially anonymous request before delegation, then a parent withInterceptors chain adds an Authorization header, cookie, or API token; although the parent cache skips the authenticated request, the child still stores the private response in TransferState serialized as JSON in the ng-state script. Exploitation requires provideClientHydration, child provideHttpClient delegation through withRequestsMadeViaParent, parent-level credential injection, and an SSR HTML response shared across users by a CDN, reverse proxy, or application cache. A later unauthenticated or unauthorized visitor can receive the cached HTML containing the earlier authenticated user's sensitive response data. Applications can mitigate by attaching credentials at the child, filtering sensitive endpoints with withHttpTransferCacheOptions, disabling transfer caching for sensitive routes, or marking personalized HTML private or no-store. This issue is fixed in versions 20.3.28, 21.2.20, and 22.1.1. |
| A link following vulnerability in LXD allows an attacker to achieve root command execution on the host system. During the import or unpacking of crafted image or backup archives, LXD fails to properly validate and confine the backup.yaml file when it exists as a symbolic link. An attacker can exploit this flaw by providing a malicious archive with a symlinked backup.yaml file, causing LXD to process unconfined configuration metadata and execute arbitrary commands with root privileges. |
| Content Extractor contained a deserialization of untrusted data issue affecting privilege management. Software customers upgrade to resolved maintenance release. Update Content Extractor. |
| Improper link resolution before file access ('link following') in Windows Resilient File System (ReFS) Deduplication Service allows an authorized attacker to elevate privileges locally. |
| A inclusion of sensitive information in source code vulnerability in Fortinet FortiMonitorOnSight 7.2.4 through 7.2.7, FortiMonitorOnSight 7.2.0 through 7.2.2 may allow attacker to improper access control via <insert attack vector here> |
