| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Denial of Service in Forescout SecureConnector 11.1.02.1019 on Windows allows Unprivileged user to corrupt the configuration file and cause Denial of Service in the application. |
| Vulnerability of uncontrolled system resource applications in the setting module
Impact: Successful exploitation of this vulnerability may affect availability. |
| Zipkin through 3.5.1 has a /heapdump endpoint (associated with the use of Spring Boot Actuator), a similar issue to CVE-2025-48927. |
| Windows Mobile Broadband Driver Remote Code Execution Vulnerability |
| Insecure Default Initialization of Resource vulnerability in Apache Solr.
New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the "trusted" metadata.
ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to "trusted" ConfigSets that may not have been created with an Authenticated request.
"trusted" ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized.
This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization.
Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise. |
| The Versa Director software exposes a number of services by default and allow attackers an easy foothold due to default credentials and multiple accounts (most with sudo access) that utilize the same default credentials. By default, Versa director exposes ssh and postgres to the internet, alongside a host of other services.
Versa Networks is not aware of any reported instance where this vulnerability was exploited. Proof of concept for this vulnerability has been disclosed by third party security researchers.
Workarounds or Mitigation:
Versa recommends the following security controls:
1) Change default passwords to complex passwords
2) Passwords must be complex with at least 8 characters that comprise of upper case, and lower case alphabets, as well as at at least one digit, and one special character
3) Passwords must be changed at least every 90 days
4) Password change history is checked to ensure that the at least the last 5 passwords must be used when changing password.
5) Review and audit logs for all authentication attempts to check for unauthorized/suspicious login attempts and enforce remediation steps. |
| CNCF K3s 1.32 before 1.32.4-rc1+k3s1 has a Kubernetes kubelet configuration change with the unintended consequence that, in some situations, ReadOnlyPort is set to 10255. For example, the default behavior of a K3s online installation might allow unauthenticated access to this port, exposing credentials. |
| Multiple arbitrary write vulnerabilities exist in the VCD sorted bsearch functionality of GTKWave 3.3.115. A specially crafted .vcd file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the arbitrary write when triggered via the vcd2lxt conversion utility. |
| Multiple arbitrary write vulnerabilities exist in the VCD sorted bsearch functionality of GTKWave 3.3.115. A specially crafted .vcd file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the arbitrary write when triggered via the vcd2vzt conversion utility. |
| fastify-swagger-ui is a Fastify plugin for serving Swagger UI. Prior to 2.1.0, the default configuration of `@fastify/swagger-ui` without `baseDir` set will lead to all files in the module's directory being exposed via http routes served by the module. The vulnerability is fixed in v2.1.0. Setting the `baseDir` option can also work around this vulnerability. |
| Donetick an open-source app for managing tasks and chores. Prior to version 0.1.44, the application uses JSON Web Tokens (JWT) for authentication, but the signing secret has a weak default value. While the responsibility is left to the system administrator to change it, this approach is inadequate. The vulnerability is proven by existence of the issue in the live version as well. This issue can result in full account takeover of any user. Version 0.1.44 contains a patch. |
| The CS5000 Fire Panel is vulnerable due to a default account that exists
on the panel. Even though it is possible to change this by SSHing into
the device, it has remained unchanged on every installed system
observed. This account is not root but holds high-level permissions that
could severely impact the device's operation if exploited. |
| A vulnerability has been identified in IEC 1Ph 7.4kW Child socket (8EM1310-2EH04-0GA0) (All versions < V2.135), IEC 1Ph 7.4kW Child socket/ shutter (8EM1310-2EN04-0GA0) (All versions < V2.135), IEC 1Ph 7.4kW Parent cable 7m (8EM1310-2EJ04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent cable 7m incl. SIM (8EM1310-2EJ04-3GA2) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket (8EM1310-2EH04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket incl. SIM (8EM1310-2EH04-3GA2) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket/ shutter (8EM1310-2EN04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket/ shutter SIM (8EM1310-2EN04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Child cable 7m (8EM1310-3EJ04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Child socket (8EM1310-3EH04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Child socket/ shutter (8EM1310-3EN04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Parent cable 7m (8EM1310-3EJ04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent cable 7m incl. SIM (8EM1310-3EJ04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Parent socket (8EM1310-3EH04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent socket incl. SIM (8EM1310-3EH04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Parent socket/ shutter (8EM1310-3EN04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent socket/ shutter SIM (8EM1310-3EN04-3GA2) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA0) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA1) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA2) (All versions < V2.135), IEC ERK 3Ph 22 kW Child socket (8EM1310-3FH04-0GA0) (All versions < V2.135), IEC ERK 3Ph 22 kW Parent socket (8EM1310-3FH04-3GA1) (All versions < V2.135), IEC ERK 3Ph 22 kW Parent socket incl. SI (8EM1310-3FH04-3GA2) (All versions < V2.135), UL Commercial Cellular 48A NTEP (8EM1310-5HF14-1GA2) (All versions < V2.135), UL Commercial Child 40A w/ 15118 HW (8EM1310-4CF14-0GA0) (All versions < V2.135), UL Commercial Child 48A BA Compliant (8EM1315-5CG14-0GA0) (All versions < V2.135), UL Commercial Child 48A w/ 15118 HW (8EM1310-5CF14-0GA0) (All versions < V2.135), UL Commercial Parent 40A with Simcard (8EM1310-4CF14-1GA2) (All versions < V2.135), UL Commercial Parent 48A (USPS) (8EM1317-5CG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A BA Compliant (8EM1315-5CG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A with Simcard BA (8EM1310-5CF14-1GA2) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1310-5CG14-1GA1) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1314-5CG14-2FA2) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1315-5HG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A,15118 25ft Sim (8EM1310-5CG14-1GA2) (All versions < V2.135), VersiCharge Blue™ 80A AC Cellular (8EM1315-7BG16-1FH2) (All versions < V2.135). Affected devices contain Modbus service enabled by default. This could allow an attacker connected to the same network to remotely control the EV charger. |
| In the Linux kernel, the following vulnerability has been resolved:
dm btree remove: assign new_root only when removal succeeds
remove_raw() in dm_btree_remove() may fail due to IO read error
(e.g. read the content of origin block fails during shadowing),
and the value of shadow_spine::root is uninitialized, but
the uninitialized value is still assign to new_root in the
end of dm_btree_remove().
For dm-thin, the value of pmd->details_root or pmd->root will become
an uninitialized value, so if trying to read details_info tree again
out-of-bound memory may occur as showed below:
general protection fault, probably for non-canonical address 0x3fdcb14c8d7520
CPU: 4 PID: 515 Comm: dmsetup Not tainted 5.13.0-rc6
Hardware name: QEMU Standard PC
RIP: 0010:metadata_ll_load_ie+0x14/0x30
Call Trace:
sm_metadata_count_is_more_than_one+0xb9/0xe0
dm_tm_shadow_block+0x52/0x1c0
shadow_step+0x59/0xf0
remove_raw+0xb2/0x170
dm_btree_remove+0xf4/0x1c0
dm_pool_delete_thin_device+0xc3/0x140
pool_message+0x218/0x2b0
target_message+0x251/0x290
ctl_ioctl+0x1c4/0x4d0
dm_ctl_ioctl+0xe/0x20
__x64_sys_ioctl+0x7b/0xb0
do_syscall_64+0x40/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixing it by only assign new_root when removal succeeds |
| Certain configuration available in the communication channel for encoders could expose sensitive data when reader configuration cards are programmed. This data could include credential and device administration keys. |
| Insecure default variable initialization of Intel(R) RealSense(TM) ID Solution F450 before version 2.6.0.74 may allow an unauthenticated user to potentially enable information disclosure via physical access. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: regenerate buddy after block freeing failed if under fc replay
This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant
mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on
code in mb_free_blocks(), fast commit replay can end up marking as free
blocks that are already marked as such. This causes corruption of the
buddy bitmap so we need to regenerate it in that case. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: sdio: Honor the host max_req_size in the RX path
Lukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes
with an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth
combo card. The error he observed is identical to what has been fixed
in commit e967229ead0e ("wifi: rtw88: sdio: Check the HISR RX_REQUEST
bit in rtw_sdio_rx_isr()") but that commit didn't fix Lukas' problem.
Lukas found that disabling or limiting RX aggregation works around the
problem for some time (but does not fully fix it). In the following
discussion a few key topics have been discussed which have an impact on
this problem:
- The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller
which prevents DMA transfers. Instead all transfers need to go through
the controller SRAM which limits transfers to 1536 bytes
- rtw88 chips don't split incoming (RX) packets, so if a big packet is
received this is forwarded to the host in it's original form
- rtw88 chips can do RX aggregation, meaning more multiple incoming
packets can be pulled by the host from the card with one MMC/SDIO
transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH
register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will
be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation
and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)
Use multiple consecutive reads in rtw_sdio_read_port() and limit the
number of bytes which are copied by the host from the card in one
MMC/SDIO transfer. This allows receiving a buffer that's larger than
the hosts max_req_size (number of bytes which can be transferred in
one MMC/SDIO transfer). As a result of this the skb_over_panic error
is gone as the rtw88 driver is now able to receive more than 1536 bytes
from the card (either because the incoming packet is larger than that
or because multiple packets have been aggregated).
In case of an receive errors (-EILSEQ has been observed by Lukas) we
need to drain the remaining data from the card's buffer, otherwise the
card will return corrupt data for the next rtw_sdio_read_port() call. |
| In the Linux kernel, the following vulnerability has been resolved:
kvm: avoid speculation-based attacks from out-of-range memslot accesses
KVM's mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot. The translation is
performed in __gfn_to_hva_memslot using the following formula:
hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE
It is expected that gfn falls within the boundaries of the guest's
physical memory. However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.
__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot. While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest's
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva. If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.
Right now it's not clear if there are any cases in which this is
exploitable. One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86. Right
now these are not vulnerable because the hva read goes through get_user(),
which contains an LFENCE speculation barrier. However, there are
patches in progress for x86 uaccess.h to mask kernel addresses instead of
using LFENCE; once these land, a guest could use speculation to read
from the VMM's ring 3 address space. Other architectures such as ARM
already use the address masking method, and would be susceptible to
this same kind of data-dependent access gadgets. Therefore, this patch
proactively protects from these attacks by masking out-of-bounds gfns
in __gfn_to_hva_memslot, which blocks speculation of invalid hvas.
Sean Christopherson noted that this patch does not cover
kvm_read_guest_offset_cached. This however is limited to a few bytes
past the end of the cache, and therefore it is unlikely to be useful in
the context of building a chain of data dependent accesses. |
| In the Linux kernel, the following vulnerability has been resolved:
ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled
The debugging code for kmap_local() doubles the number of per-CPU fixmap
slots allocated for kmap_local(), in order to use half of them as guard
regions. This causes the fixmap region to grow downwards beyond the start
of its reserved window if the supported number of CPUs is large, and collide
with the newly added virtual DT mapping right below it, which is obviously
not good.
One manifestation of this is EFI boot on a kernel built with NR_CPUS=32
and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting
in block entries below the fixmap region that the fixmap code misidentifies
as fixmap table entries, and subsequently tries to dereference using a
phys-to-virt translation that is only valid for lowmem. This results in a
cryptic splat such as the one below.
ftrace: allocating 45548 entries in 89 pages
8<--- cut here ---
Unable to handle kernel paging request at virtual address fc6006f0
pgd = (ptrval)
[fc6006f0] *pgd=80000040207003, *pmd=00000000
Internal error: Oops: a06 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0+ #382
Hardware name: Generic DT based system
PC is at cpu_ca15_set_pte_ext+0x24/0x30
LR is at __set_fixmap+0xe4/0x118
pc : [<c041ac9c>] lr : [<c04189d8>] psr: 400000d3
sp : c1601ed8 ip : 00400000 fp : 00800000
r10: 0000071f r9 : 00421000 r8 : 00c00000
r7 : 00c00000 r6 : 0000071f r5 : ffade000 r4 : 4040171f
r3 : 00c00000 r2 : 4040171f r1 : c041ac78 r0 : fc6006f0
Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
Control: 30c5387d Table: 40203000 DAC: 00000001
Process swapper (pid: 0, stack limit = 0x(ptrval))
So let's limit CONFIG_NR_CPUS to 16 when CONFIG_DEBUG_KMAP_LOCAL=y. Also,
fix the BUILD_BUG_ON() check that was supposed to catch this, by checking
whether the region grows below the start address rather than above the end
address. |
