Security Vulnerabilities
A vulnerability has been found in Wavlink WL-WN578W2 221110. The affected element is an unknown function of the file /sysinit.html. The manipulation of the argument newpass/confpass leads to weak password recovery. The attack is possible to be carried out remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score
5.3
EPSS Score
0.002
Published
2025-09-12
PHPGURUKUL Online Shopping Portal 2.1 is vulnerable to Cross Site Scripting (XSS) due to lack of input sanitization in the quantity parameter when adding a product to the cart.
CVSS Score
6.1
EPSS Score
0.001
Published
2025-09-12
OpenSynergy BlueSDK (aka Blue SDK) through 6.x mishandles a function call. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from an incorrect variable used as a function argument. An attacker can leverage this to cause unexpected behavior or obtain sensitive information.
CVSS Score
7.5
EPSS Score
0.001
Published
2025-09-12
OpenSynergy BlueSDK (aka Blue SDK) through 6.x has Incorrect Control Flow Scoping. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of proper return control flow after detecting an unusual condition. An attacker can leverage this to bypass a security validation and make the incoming data be processed.
CVSS Score
6.5
EPSS Score
0.001
Published
2025-09-12
OpenSynergy BlueSDK (aka Blue SDK) through 6.x has a Use-After-Free. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of validating the existence of an object before performing operations on the object (aka use after free). An attacker can leverage this to achieve remote code execution in the context of a user account under which the Bluetooth process runs.
CVSS Score
9.8
EPSS Score
0.009
Published
2025-09-12
OpenSynergy BlueSDK (aka Blue SDK) through 6.x has Improper Input Validation. The specific flaw exists within the BlueSDK Bluetooth stack. The issue results from the lack of proper validation of remote L2CAP channel ID (CID). An attacker can leverage this to create an L2CAP channel with the null identifier assigned as a remote CID.
CVSS Score
5.3
EPSS Score
0.001
Published
2025-09-12
An issue in TOTOLINK Wi-Fi 6 Router Series Device X2000R-Gh-V2.0.0 allows a remote attacker to execute arbitrary code via the default password
CVSS Score
8.0
EPSS Score
0.004
Published
2025-09-12
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Duplicate SPI Handling
The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI
Netlink message, which triggers the kernel function xfrm_alloc_spi().
This function is expected to ensure uniqueness of the Security Parameter
Index (SPI) for inbound Security Associations (SAs). However, it can
return success even when the requested SPI is already in use, leading
to duplicate SPIs assigned to multiple inbound SAs, differentiated
only by their destination addresses.
This behavior causes inconsistencies during SPI lookups for inbound packets.
Since the lookup may return an arbitrary SA among those with the same SPI,
packet processing can fail, resulting in packet drops.
According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA
is uniquely identified by the SPI and optionally protocol.
Reproducing the Issue Reliably:
To consistently reproduce the problem, restrict the available SPI range in
charon.conf : spi_min = 0x10000000 spi_max = 0x10000002
This limits the system to only 2 usable SPI values.
Next, create more than 2 Child SA. each using unique pair of src/dst address.
As soon as the 3rd Child SA is initiated, it will be assigned a duplicate
SPI, since the SPI pool is already exhausted.
With a narrow SPI range, the issue is consistently reproducible.
With a broader/default range, it becomes rare and unpredictable.
Current implementation:
xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.
So if two SAs have the same SPI but different destination addresses, then
they will:
a. Hash into different buckets
b. Be stored in different linked lists (byspi + h)
c. Not be seen in the same hlist_for_each_entry_rcu() iteration.
As a result, the lookup will result in NULL and kernel allows that Duplicate SPI
Proposed Change:
xfrm_state_lookup_spi_proto() does a truly global search - across all states,
regardless of hash bucket and matches SPI and proto.
CVSS Score
7.8
EPSS Score
0.0
Published
2025-09-12
File Upload vulnerability in SueamCMS v.0.1.2 allows a remote attacker to execute arbitrary code via the lack of filtering.
CVSS Score
9.8
EPSS Score
0.005
Published
2025-09-12
In the Linux kernel, the following vulnerability has been resolved:
dm: Always split write BIOs to zoned device limits
Any zoned DM target that requires zone append emulation will use the
block layer zone write plugging. In such case, DM target drivers must
not split BIOs using dm_accept_partial_bio() as doing so can potentially
lead to deadlocks with queue freeze operations. Regular write operations
used to emulate zone append operations also cannot be split by the
target driver as that would result in an invalid writen sector value
return using the BIO sector.
In order for zoned DM target drivers to avoid such incorrect BIO
splitting, we must ensure that large BIOs are split before being passed
to the map() function of the target, thus guaranteeing that the
limits for the mapped device are not exceeded.
dm-crypt and dm-flakey are the only target drivers supporting zoned
devices and using dm_accept_partial_bio().
In the case of dm-crypt, this function is used to split BIOs to the
internal max_write_size limit (which will be suppressed in a different
patch). However, since crypt_alloc_buffer() uses a bioset allowing only
up to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt device
max_segments limit, which is not set and so default to BLK_MAX_SEGMENTS
(128), must thus be respected and write BIOs split accordingly.
In the case of dm-flakey, since zone append emulation is not required,
the block layer zone write plugging is not used and no splitting of BIOs
required.
Modify the function dm_zone_bio_needs_split() to use the block layer
helper function bio_needs_zone_write_plugging() to force a call to
bio_split_to_limits() in dm_split_and_process_bio(). This allows DM
target drivers to avoid using dm_accept_partial_bio() for write
operations on zoned DM devices.
CVSS Score
5.5
EPSS Score
0.0
Published
2025-09-12