🚨 CVE-2024-49706
Internet Starter, one of SoftCOM iKSORIS system modules, is vulnerable to Open Redirect attacks by including base64 encoded URLs in the target parameter sent in a POST request to one of the endpoints.
This vulnerability has been patched in version 79.0

🎖@cveNotify

🚨 CVE-2024-49707
Internet Starter, one of SoftCOM iKSORIS system modules, is vulnerable to Reflected XSS (Cross-site Scripting) attacks. An attacker might trick a user into filling a form designed for resetting user's password with a malicious script, what causes the script to run in user's context. 
This vulnerability has been patched in version 79.0

🎖@cveNotify

🚨 CVE-2024-49708
Internet Starter, one of SoftCOM iKSORIS system modules, is vulnerable to Stored XSS (Cross-site Scripting) attacks. An attacker might trick a user into filling a form designed for setting delivery address with a malicious script, what causes the script to run in user's context. 
This vulnerability has been patched in version 79.0

🎖@cveNotify

🚨 CVE-2024-49709
Internet Starter, one of SoftCOM iKSORIS system modules, allows for setting an arbitrary session cookie value. An attacker with an access to user's browser might set such a cookie, wait until the user logs in and then use the same cookie to take over the account.
Moreover, the system does not destroy the old sessions when creating new ones, what expands the time frame in which an attack might be performed. 
This vulnerability has been patched in version 79.0

🎖@cveNotify

🚨 CVE-2025-54539
A Deserialization of Untrusted Data vulnerability exists in the Apache ActiveMQ NMS AMQP Client.

This issue affects all versions of Apache ActiveMQ NMS AMQP up to and including 2.3.0, when establishing connections to untrusted AMQP servers. Malicious servers could exploit unbounded deserialization logic present in the client to craft responses that may lead to arbitrary code execution on the client side.

Although version 2.1.0 introduced a mechanism to restrict deserialization via allow/deny lists, the protection was found to be bypassable under certain conditions.

In line with Microsoft’s deprecation of binary serialization in .NET 9, the project is evaluating the removal of .NET binary serialization support from the NMS API entirely in future releases.

Mitigation and Recommendations:
Users are strongly encouraged to upgrade to version 2.4.0 or later, which resolves the issue. Additionally, projects depending on NMS-AMQP should migrate away from .NET binary serialization as part of a long-term hardening strategy.

🎖@cveNotify

🚨 CVE-2025-61102
FRRouting/frr from v4.0 through v10.4.1 was discovered to contain a NULL pointer dereference via the show_vty_ext_link_adj_sid function at ospf_ext.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted OSPF packet.

🎖@cveNotify

🚨 CVE-2025-54604
Bitcoin Core through 29.0 allows Uncontrolled Resource Consumption (issue 1 of 2).

🎖@cveNotify

🚨 CVE-2024-0640
A stored cross-site scripting (XSS) vulnerability exists in chatwoot/chatwoot versions 3.0.0 to 3.5.1. This vulnerability allows an admin user to inject malicious JavaScript code via the dashboard app settings, which can then be executed by another admin user when they access the affected dashboard app. The issue is fixed in version 3.5.2.

🎖@cveNotify

🚨 CVE-2024-33891
Delinea Secret Server before 11.7.000001 allows attackers to bypass authentication via the SOAP API in SecretServer/webservices/SSWebService.asmx. This is related to a hardcoded key, the use of the integer 2 for the Admin user, and removal of the oauthExpirationId attribute.

🎖@cveNotify

🚨 CVE-2024-30112
HCL Connections is vulnerable to a cross-site scripting attack where an attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user which leads to executing malicious script code. This may let the attacker steal cookie-based authentication credentials and comprise user's account then launch other attacks.

🎖@cveNotify

🚨 CVE-2024-39595
SAP Business Warehouse - Business Planning and
Simulation application does not sufficiently encode user-controlled inputs,
resulting in Stored Cross-Site Scripting (XSS) vulnerability. This
vulnerability allows users to modify website content and on successful
exploitation, an attacker can cause low impact to the confidentiality and
integrity of the application.

🎖@cveNotify

🚨 CVE-2024-39599
Due to a Protection Mechanism Failure in SAP
NetWeaver Application Server for ABAP and ABAP Platform, a developer can bypass
the configured malware scanner API because of a programming error. This leads
to a low impact on the application's confidentiality, integrity, and
availability.

🎖@cveNotify

🚨 CVE-2024-45281
SAP BusinessObjects Business Intelligence Platform allows a high privilege user to run client desktop applications even if some of the DLLs are not digitally signed or if the signature is broken. The attacker needs to have local access to the vulnerable system to perform DLL related tasks. This could result in a high impact on confidentiality and integrity of the application.

🎖@cveNotify

🚨 CVE-2024-42188
HCL Connections is vulnerable to a broken access control vulnerability that may allow an unauthorized user to update data in certain scenarios.

🎖@cveNotify

🚨 CVE-2024-11481
A vulnerability in ESM 11.6.10 allows unauthenticated access to the internal Snowservice API. This leads to improper handling of path traversal, insecure forwarding to an AJP backend without adequate validation, and lack of authentication for accessing internal API endpoints.

🎖@cveNotify

🚨 CVE-2024-11482
A vulnerability in ESM 11.6.10 allows unauthenticated access to the internal Snowservice API and enables remote code execution through command injection, executed as the root user.

🎖@cveNotify

🚨 CVE-2024-32732
Under certain conditions SAP BusinessObjects Business Intelligence platform allows an attacker to access information which would otherwise be restricted.This has low impact on Confidentiality with no impact on Integrity and Availability of the application.

🎖@cveNotify

🚨 CVE-2023-52929
In the Linux kernel, the following vulnerability has been resolved:

nvmem: core: fix cleanup after dev_set_name()

If dev_set_name() fails, we leak nvmem->wp_gpio as the cleanup does not
put this. While a minimal fix for this would be to add the gpiod_put()
call, we can do better if we split device_register(), and use the
tested nvmem_release() cleanup code by initialising the device early,
and putting the device.

This results in a slightly larger fix, but results in clear code.

Note: this patch depends on "nvmem: core: initialise nvmem->id early"
and "nvmem: core: remove nvmem_config wp_gpio".

[Srini: Fixed subject line and error code handing with wp_gpio while applying.]

🎖@cveNotify

🚨 CVE-2023-52933
In the Linux kernel, the following vulnerability has been resolved:

Squashfs: fix handling and sanity checking of xattr_ids count

A Sysbot [1] corrupted filesystem exposes two flaws in the handling and
sanity checking of the xattr_ids count in the filesystem. Both of these
flaws cause computation overflow due to incorrect typing.

In the corrupted filesystem the xattr_ids value is 4294967071, which
stored in a signed variable becomes the negative number -225.

Flaw 1 (64-bit systems only):

The signed integer xattr_ids variable causes sign extension.

This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The
variable is first multiplied by sizeof(struct squashfs_xattr_id) where the
type of the sizeof operator is "unsigned long".

On a 64-bit system this is 64-bits in size, and causes the negative number
to be sign extended and widened to 64-bits and then become unsigned. This
produces the very large number 18446744073709548016 or 2^64 - 3600. This
number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and
divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0
(stored in len).

Flaw 2 (32-bit systems only):

On a 32-bit system the integer variable is not widened by the unsigned
long type of the sizeof operator (32-bits), and the signedness of the
variable has no effect due it always being treated as unsigned.

The above corrupted xattr_ids value of 4294967071, when multiplied
overflows and produces the number 4294963696 or 2^32 - 3400. This number
when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by
SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.

The effect of the 0 length computation:

In conjunction with the corrupted xattr_ids field, the filesystem also has
a corrupted xattr_table_start value, where it matches the end of
filesystem value of 850.

This causes the following sanity check code to fail because the
incorrectly computed len of 0 matches the incorrect size of the table
reported by the superblock (0 bytes).

len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);
indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);

/*
* The computed size of the index table (len bytes) should exactly
* match the table start and end points
*/
start = table_start + sizeof(*id_table);
end = msblk->bytes_used;

if (len != (end - start))
return ERR_PTR(-EINVAL);

Changing the xattr_ids variable to be "usigned int" fixes the flaw on a
64-bit system. This relies on the fact the computation is widened by the
unsigned long type of the sizeof operator.

Casting the variable to u64 in the above macro fixes this flaw on a 32-bit
system.

It also means 64-bit systems do not implicitly rely on the type of the
sizeof operator to widen the computation.

[1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/

🎖@cveNotify

🚨 CVE-2023-52934
In the Linux kernel, the following vulnerability has been resolved:

mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups

In commit 34488399fa08 ("mm/madvise: add file and shmem support to
MADV_COLLAPSE") we make the following change to find_pmd_or_thp_or_none():

- if (!pmd_present(pmde))
- return SCAN_PMD_NULL;
+ if (pmd_none(pmde))
+ return SCAN_PMD_NONE;

This was for-use by MADV_COLLAPSE file/shmem codepaths, where
MADV_COLLAPSE might identify a pte-mapped hugepage, only to have
khugepaged race-in, free the pte table, and clear the pmd. Such codepaths
include:

A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER
already in the pagecache.
B) In retract_page_tables(), if we fail to grab mmap_lock for the target
mm/address.

In these cases, collapse_pte_mapped_thp() really does expect a none (not
just !present) pmd, and we want to suitably identify that case separate
from the case where no pmd is found, or it's a bad-pmd (of course, many
things could happen once we drop mmap_lock, and the pmd could plausibly
undergo multiple transitions due to intervening fault, split, etc).
Regardless, the code is prepared install a huge-pmd only when the existing
pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.

However, the commit introduces a logical hole; namely, that we've allowed
!none- && !huge- && !bad-pmds to be classified as genuine
pte-table-mapping-pmds. One such example that could leak through are swap
entries. The pmd values aren't checked again before use in
pte_offset_map_lock(), which is expecting nothing less than a genuine
pte-table-mapping-pmd.

We want to put back the !pmd_present() check (below the pmd_none() check),
but need to be careful to deal with subtleties in pmd transitions and
treatments by various arch.

The issue is that __split_huge_pmd_locked() temporarily clears the present
bit (or otherwise marks the entry as invalid), but pmd_present() and
pmd_trans_huge() still need to return true while the pmd is in this
transitory state. For example, x86's pmd_present() also checks the
_PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also
checks a PMD_PRESENT_INVALID bit.

Covering all 4 cases for x86 (all checks done on the same pmd value):

1) pmd_present() && pmd_trans_huge()
All we actually know here is that the PSE bit is set. Either:
a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE
is set.
=> huge-pmd
b) We are currently racing with __split_huge_page(). The danger here
is that we proceed as-if we have a huge-pmd, but really we are
looking at a pte-mapping-pmd. So, what is the risk of this
danger?

The only relevant path is:

madvise_collapse() -> collapse_pte_mapped_thp()

Where we might just incorrectly report back "success", when really
the memory isn't pmd-backed. This is fine, since split could
happen immediately after (actually) successful madvise_collapse().
So, it should be safe to just assume huge-pmd here.

2) pmd_present() && !pmd_trans_huge()
Either:
a) PSE not set and either PRESENT or PROTNONE is.
=> pte-table-mapping pmd (or PROT_NONE)
b) devmap. This routine can be called immediately after
unlocking/locking mmap_lock -- or called with no locks held (see
khugepaged_scan_mm_slot()), so previous VMA checks have since been
invalidated.

3) !pmd_present() && pmd_trans_huge()
Not possible.

4) !pmd_present() && !pmd_trans_huge()
Neither PRESENT nor PROTNONE set
=> not present

I've checked all archs that implement pmd_trans_huge() (arm64, riscv,
powerpc, longarch, x86, mips, s390) and this logic roughly translates
(though devmap treatment is unique to x86 and powerpc, and (3) doesn't
necessarily hold in general -- but that doesn't matter since
!pmd_present() always takes failure path).

Also, add a comment above find_pmd_or_thp_or_none()
---truncated---

🎖@cveNotify

🚨 CVE-2025-30712
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is 7.1.6. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle VM VirtualBox accessible data as well as unauthorized access to critical data or complete access to all Oracle VM VirtualBox accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:L).

🎖@cveNotify