| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| CCleaner v5.33.6162 and CCleaner Cloud v1.07.3191 (32-bit builds) contained a malicious pre-entry-point loader that diverts execution from __scrt_common_main_seh into a custom loader. That loader decodes an embedded blob into shellcode, allocates executable heap memory, resolves Windows API functions at runtime, and transfers execution to an in-memory payload. The payload performs anti-analysis checks, gathers host telemetry, encodes the data with a two-stage obfuscation, and attempts HTTPS exfiltration to hard-coded C2 servers or month-based DGA domains. Potential impacts include remote data collection and exfiltration, stealthy in-memory execution and persistence, and potential lateral movement. CCleaner was developed by Piriform, which was acquired by Avast in July 2017; Avast later merged with NortonLifeLock to form the parent company now known as Gen Digital. According to vendor advisories, the compromised CCleaner build was released on August 15, 2017 and remediated on September 12, 2017 with v5.34; the compromised CCleaner Cloud build was released on August 24, 2017 and remediated on September 15, 2017 with v1.07.3214. |
| Web Developer for Chrome v0.4.9 contained malicious code that generated a domain via a DGA and fetched a remote script. The fetched script conditionally loaded follow-on modules that performed extensive ad substitution and malvertising, displayed fake “repair” alerts that redirected users to affiliate programs, and attempted to harvest credentials when users logged in. Injected components enumerate common banner sizes for substitution, replace third-party ad calls, and redirect victim traffic to affiliate landing pages. Potential impacts include user-level code execution in the browser context, large-scale ad fraud and traffic hijacking, credential theft, and exposure to additional payloads delivered by the actor. The compromise was reported on by the maintainer of Web Developer for Chrome on August 2, 2017 and remediated in v0.5.0. |
| The Cookie Notice & Consent plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the uuid parameter in all versions up to, and including, 1.6.5 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. |
| A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch. |
| A vulnerability was determined in PHPGurukul Beauty Parlour Management System 1.1. This issue affects some unknown processing of the file /admin/manage-services.php. Executing manipulation of the argument delid can lead to sql injection. The attack may be performed from remote. The exploit has been publicly disclosed and may be utilized. |
| A vulnerability was detected in code-projects E-Commerce Website 1.0. This impacts an unknown function of the file /pages/product_add.php. Performing manipulation of the argument prod_name results in sql injection. The attack may be initiated remotely. The exploit is now public and may be used. |
| A vulnerability was identified in code-projects Online Complaint Site 1.0. This vulnerability affects unknown code of the file /cms/users/index.php. Such manipulation of the argument Username leads to sql injection. The attack may be performed from remote. The exploit is publicly available and might be used. |
| A security flaw has been discovered in code-projects Online Complaint Site 1.0. This issue affects some unknown processing of the file /cms/users/register-complaint.php. Performing manipulation of the argument cid results in sql injection. It is possible to initiate the attack remotely. The exploit has been released to the public and may be exploited. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/s390: Make attach succeed when the device was surprise removed
When a PCI device is removed with surprise hotplug, there may still be
attempts to attach the device to the default domain as part of tear down
via (__iommu_release_dma_ownership()), or because the removal happens
during probe (__iommu_probe_device()). In both cases zpci_register_ioat()
fails with a cc value indicating that the device handle is invalid. This
is because the device is no longer part of the instance as far as the
hypervisor is concerned.
Currently this leads to an error return and s390_iommu_attach_device()
fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()
because attaching to the default domain must never fail.
With the device fenced by the hypervisor no DMAs to or from memory are
possible and the IOMMU translations have no effect. Proceed as if the
registration was successful and let the hotplug event handling clean up
the device.
This is similar to how devices in the error state are handled since
commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device
is in error state") except that for removal the domain will not be
registered later. This approach was also previously discussed at the
link.
Handle both cases, error state and removal, in a helper which checks if
the error needs to be propagated or ignored. Avoid magic number
condition codes by using the pre-existing, but never used, defines for
PCI load/store condition codes and rename them to reflect that they
apply to all PCI instructions. |
| In the Linux kernel, the following vulnerability has been resolved:
gpiolib: acpi: initialize acpi_gpio_info struct
Since commit 7c010d463372 ("gpiolib: acpi: Make sure we fill struct
acpi_gpio_info"), uninitialized acpi_gpio_info struct are passed to
__acpi_find_gpio() and later in the call stack info->quirks is used in
acpi_populate_gpio_lookup. This breaks the i2c_hid_cpi driver:
[ 58.122916] i2c_hid_acpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ
[ 58.123097] i2c_hid_acpi i2c-UNIW0001:00: probe with driver i2c_hid_acpi failed with error -22
Fix this by initializing the acpi_gpio_info pass to __acpi_find_gpio() |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix incorrect io_kiocb reference in io_link_skb
In io_link_skb function, there is a bug where prev_notif is incorrectly
assigned using 'nd' instead of 'prev_nd'. This causes the context
validation check to compare the current notification with itself instead
of comparing it with the previous notification.
Fix by using the correct prev_nd parameter when obtaining prev_notif. |
| ProjectWorlds Gym Management System1.0 is vulnerable to SQL Injection via the "id" parameter in the profile/edit.php page |
| The Lisfinity Core - Lisfinity Core plugin used for pebas® Lisfinity WordPress theme plugin for WordPress is vulnerable to privilege escalation via password update in all versions up to, and including, 1.4.0. This is due to the plugin not properly validating a user's identity prior to updating their password. This makes it possible for authenticated attackers, with Subscriber-level access and above, to change arbitrary user's passwords, including those of administrators. |
| Apache Flink CDC version 3.4.0 was vulnerable to a SQL injection via maliciously crafted identifiers eg. crafted database name or crafted table name. Even through only the logged-in database user can trigger the attack, we recommend users update Flink CDC version to 3.5.0 which address this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: mp: Fix dual-divider clock rate readback
When dual-divider clock support was introduced, the P divider offset was
left out of the .recalc_rate readback function. This causes the clock
rate to become bogus or even zero (possibly due to the P divider being
1, leading to a divide-by-zero).
Fix this by incorporating the P divider offset into the calculation. |
| In the Linux kernel, the following vulnerability has been resolved:
igc: don't fail igc_probe() on LED setup error
When igc_led_setup() fails, igc_probe() fails and triggers kernel panic
in free_netdev() since unregister_netdev() is not called. [1]
This behavior can be tested using fault-injection framework, especially
the failslab feature. [2]
Since LED support is not mandatory, treat LED setup failures as
non-fatal and continue probe with a warning message, consequently
avoiding the kernel panic.
[1]
kernel BUG at net/core/dev.c:12047!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:free_netdev+0x278/0x2b0
[...]
Call Trace:
<TASK>
igc_probe+0x370/0x910
local_pci_probe+0x3a/0x80
pci_device_probe+0xd1/0x200
[...]
[2]
#!/bin/bash -ex
FAILSLAB_PATH=/sys/kernel/debug/failslab/
DEVICE=0000:00:05.0
START_ADDR=$(grep " igc_led_setup" /proc/kallsyms \
| awk '{printf("0x%s", $1)}')
END_ADDR=$(printf "0x%x" $((START_ADDR + 0x100)))
echo $START_ADDR > $FAILSLAB_PATH/require-start
echo $END_ADDR > $FAILSLAB_PATH/require-end
echo 1 > $FAILSLAB_PATH/times
echo 100 > $FAILSLAB_PATH/probability
echo N > $FAILSLAB_PATH/ignore-gfp-wait
echo $DEVICE > /sys/bus/pci/drivers/igc/bind |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: amd: acp: Fix incorrect retrival of acp_chip_info
Use dev_get_drvdata(dev->parent) instead of dev_get_platdata(dev)
to correctly obtain acp_chip_info members in the acp I2S driver.
Previously, some members were not updated properly due to incorrect
data access, which could potentially lead to null pointer
dereferences.
This issue was missed in the earlier commit
("ASoC: amd: acp: Fix NULL pointer deref in acp_i2s_set_tdm_slot"),
which only addressed set_tdm_slot(). This change ensures that all
relevant functions correctly retrieve acp_chip_info, preventing
further null pointer dereference issues. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/amd/pgtbl: Fix possible race while increase page table level
The AMD IOMMU host page table implementation supports dynamic page table levels
(up to 6 levels), starting with a 3-level configuration that expands based on
IOVA address. The kernel maintains a root pointer and current page table level
to enable proper page table walks in alloc_pte()/fetch_pte() operations.
The IOMMU IOVA allocator initially starts with 32-bit address and onces its
exhuasted it switches to 64-bit address (max address is determined based
on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU
driver increases page table level.
But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads
pgtable->[root/mode] without lock. So its possible that in exteme corner case,
when increase_address_space() is updating pgtable->[root/mode], fetch_pte()
reads wrong page table level (pgtable->mode). It does compare the value with
level encoded in page table and returns NULL. This will result is
iommu_unmap ops to fail and upper layer may retry/log WARN_ON.
CPU 0 CPU 1
------ ------
map pages unmap pages
alloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte()
pgtable->root = pte (new root value)
READ pgtable->[mode/root]
Reads new root, old mode
Updates mode (pgtable->mode += 1)
Since Page table level updates are infrequent and already synchronized with a
spinlock, implement seqcount to enable lock-free read operations on the read path. |
| In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix untrusted unsigned subtract
Fix the following Smatch static checker warning:
net/rxrpc/rxgk_app.c:65 rxgk_yfs_decode_ticket()
warn: untrusted unsigned subtract. 'ticket_len - 10 * 4'
by prechecking the length of what we're trying to extract in two places in
the token and decoding for a response packet.
Also use sizeof() on the struct we're extracting rather specifying the size
numerically to be consistent with the other related statements. |
| GitLab has remediated an issue in GitLab EE affecting all versions from 18.3 to 18.3.4, 18.4 to 18.4.2 that, under certain conditions, could have allowed authenticated users with read-only API tokens to perform unauthorized write operations on vulnerability records by exploiting incorrectly scoped GraphQL mutations. |
