Vulnerabilities

A Stored cross-site scripting vulnerability in the Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q3.0, 2025.Q2.0 through 2025.Q2.12, 2025.Q1.0 through 2025.Q1.17, 2024.Q4.0 through 2024.Q4.7, 2024.Q3.0 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13 and 2024.Q1.1 through 2024.Q1.20 allows an remote authenticated attacker to inject JavaScript through the organization site names. The malicious payload is stored and executed without proper sanitization or escaping.

An issue was discovered in AXIS BANK LIMITED Axis Mobile App 9.9 that allows attackers to obtain sensitive information without a UPI PIN, such as account information, balances, transaction history, and unspecified other information. NOTE: the Supplier's perspective is that this is an intended feature and "does not reveal much sensitive information."

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.

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.

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.

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.

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

An issue in H3C Magic M Device M2V100R006 allows a remote attacker to execute arbitrary code via the default password

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

File Upload vulnerability in SueamCMS v.0.1.2 allows a remote attacker to execute arbitrary code via the lack of filtering.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Duplicate SPI Handling<br /> <br /> The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI<br /> Netlink message, which triggers the kernel function xfrm_alloc_spi().<br /> This function is expected to ensure uniqueness of the Security Parameter<br /> Index (SPI) for inbound Security Associations (SAs). However, it can<br /> return success even when the requested SPI is already in use, leading<br /> to duplicate SPIs assigned to multiple inbound SAs, differentiated<br /> only by their destination addresses.<br /> <br /> This behavior causes inconsistencies during SPI lookups for inbound packets.<br /> Since the lookup may return an arbitrary SA among those with the same SPI,<br /> packet processing can fail, resulting in packet drops.<br /> <br /> According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA<br /> is uniquely identified by the SPI and optionally protocol.<br /> <br /> Reproducing the Issue Reliably:<br /> To consistently reproduce the problem, restrict the available SPI range in<br /> charon.conf : spi_min = 0x10000000 spi_max = 0x10000002<br /> This limits the system to only 2 usable SPI values.<br /> Next, create more than 2 Child SA. each using unique pair of src/dst address.<br /> As soon as the 3rd Child SA is initiated, it will be assigned a duplicate<br /> SPI, since the SPI pool is already exhausted.<br /> With a narrow SPI range, the issue is consistently reproducible.<br /> With a broader/default range, it becomes rare and unpredictable.<br /> <br /> Current implementation:<br /> xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.<br /> So if two SAs have the same SPI but different destination addresses, then<br /> they will:<br /> a. Hash into different buckets<br /> b. Be stored in different linked lists (byspi + h)<br /> c. Not be seen in the same hlist_for_each_entry_rcu() iteration.<br /> As a result, the lookup will result in NULL and kernel allows that Duplicate SPI<br /> <br /> Proposed Change:<br /> xfrm_state_lookup_spi_proto() does a truly global search - across all states,<br /> regardless of hash bucket and matches SPI and proto.

An issue in H3C Device R365V300R004 allows a remote attacker to execute arbitrary code via the default password. NOTE: the Supplier&amp;#39;s position is that their "product lines enforce or clearly prompt users to change any initial credentials upon first use. At most, this would be a case of misconfiguration if an administrator deliberately ignored the prompts, which is outside the scope of CVE definitions."