π¨ CVE-2025-27904
IBM DB2 Recovery Expert for LUW 5.5 Interim Fix 002 IBM Db2 Recovery Expert for Linux, UNIX and Windows is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.
π@cveNotify
IBM DB2 Recovery Expert for LUW 5.5 Interim Fix 002 IBM Db2 Recovery Expert for Linux, UNIX and Windows is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts.
π@cveNotify
Ibm
Security Bulletin: Multiple vulnerabilities in IBM Java SDK affecting Db2 Recovery Expert for Linux, Unix and Windows
There are multiple vulnerabilities in IBM Java SDK affecting Db2 Recovery Expert for Linux, Unix and Windows. All platforms are affected, and all previous versions may also be affected.
π¨ CVE-2026-26721
An issue in Key Systems Inc Global Facilities Management Software v.20230721a allows a remote attacker to obtain sensitive information via the sid query parameter.
π@cveNotify
An issue in Key Systems Inc Global Facilities Management Software v.20230721a allows a remote attacker to obtain sensitive information via the sid query parameter.
π@cveNotify
GitHub
vulnerability-disclosures/CVE-2026-26721 at main Β· chndlrx/vulnerability-disclosures
Public disclosures of software vulnerabilities discovered and responsibly reported by Chandler Johnson. Includes CVEs, technical writeups, and proof-of-concepts. - chndlrx/vulnerability-disclosures
π¨ CVE-2026-2459
A vulnerability exists in REB500 for an authenticated user with Installer role to access and alter the contents of directories that the role is not authorized to do so.
π@cveNotify
A vulnerability exists in REB500 for an authenticated user with Installer role to access and alter the contents of directories that the role is not authorized to do so.
π@cveNotify
π¨ CVE-2026-2460
A vulnerability exists in REB500 for an authenticated user with low-level privileges to access and alter the content of directories by using the DAC protocol that the user is not authorized to do so.
π@cveNotify
A vulnerability exists in REB500 for an authenticated user with low-level privileges to access and alter the content of directories by using the DAC protocol that the user is not authorized to do so.
π@cveNotify
π¨ CVE-2026-25603
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Linksys MR9600, Linksys MX4200 allows that contents of a USB drive partition can be mounted in an arbitrary location of the file system. This may result in the execution of shell scripts in the context of a root user.This issue affects MR9600: 1.0.4.205530; MX4200: 1.0.13.210200.
π@cveNotify
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Linksys MR9600, Linksys MX4200 allows that contents of a USB drive partition can be mounted in an arbitrary location of the file system. This may result in the execution of shell scripts in the context of a root user.This issue affects MR9600: 1.0.4.205530; MX4200: 1.0.13.210200.
π@cveNotify
π¨ CVE-2025-68358
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix racy bitfield write in btrfs_clear_space_info_full()
From the memory-barriers.txt document regarding memory barrier ordering
guarantees:
(*) These guarantees do not apply to bitfields, because compilers often
generate code to modify these using non-atomic read-modify-write
sequences. Do not attempt to use bitfields to synchronize parallel
algorithms.
(*) Even in cases where bitfields are protected by locks, all fields
in a given bitfield must be protected by one lock. If two fields
in a given bitfield are protected by different locks, the compiler's
non-atomic read-modify-write sequences can cause an update to one
field to corrupt the value of an adjacent field.
btrfs_space_info has a bitfield sharing an underlying word consisting of
the fields full, chunk_alloc, and flush:
struct btrfs_space_info {
struct btrfs_fs_info * fs_info; /* 0 8 */
struct btrfs_space_info * parent; /* 8 8 */
...
int clamp; /* 172 4 */
unsigned int full:1; /* 176: 0 4 */
unsigned int chunk_alloc:1; /* 176: 1 4 */
unsigned int flush:1; /* 176: 2 4 */
...
Therefore, to be safe from parallel read-modify-writes losing a write to
one of the bitfield members protected by a lock, all writes to all the
bitfields must use the lock. They almost universally do, except for
btrfs_clear_space_info_full() which iterates over the space_infos and
writes out found->full = 0 without a lock.
Imagine that we have one thread completing a transaction in which we
finished deleting a block_group and are thus calling
btrfs_clear_space_info_full() while simultaneously the data reclaim
ticket infrastructure is running do_async_reclaim_data_space():
T1 T2
btrfs_commit_transaction
btrfs_clear_space_info_full
data_sinfo->full = 0
READ: full:0, chunk_alloc:0, flush:1
do_async_reclaim_data_space(data_sinfo)
spin_lock(&space_info->lock);
if(list_empty(tickets))
space_info->flush = 0;
READ: full: 0, chunk_alloc:0, flush:1
MOD/WRITE: full: 0, chunk_alloc:0, flush:0
spin_unlock(&space_info->lock);
return;
MOD/WRITE: full:0, chunk_alloc:0, flush:1
and now data_sinfo->flush is 1 but the reclaim worker has exited. This
breaks the invariant that flush is 0 iff there is no work queued or
running. Once this invariant is violated, future allocations that go
into __reserve_bytes() will add tickets to space_info->tickets but will
see space_info->flush is set to 1 and not queue the work. After this,
they will block forever on the resulting ticket, as it is now impossible
to kick the worker again.
I also confirmed by looking at the assembly of the affected kernel that
it is doing RMW operations. For example, to set the flush (3rd) bit to 0,
the assembly is:
andb $0xfb,0x60(%rbx)
and similarly for setting the full (1st) bit to 0:
andb $0xfe,-0x20(%rax)
So I think this is really a bug on practical systems. I have observed
a number of systems in this exact state, but am currently unable to
reproduce it.
Rather than leaving this footgun lying around for the future, take
advantage of the fact that there is room in the struct anyway, and that
it is already quite large and simply change the three bitfield members to
bools. This avoids writes to space_info->full having any effect on
---truncated---
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix racy bitfield write in btrfs_clear_space_info_full()
From the memory-barriers.txt document regarding memory barrier ordering
guarantees:
(*) These guarantees do not apply to bitfields, because compilers often
generate code to modify these using non-atomic read-modify-write
sequences. Do not attempt to use bitfields to synchronize parallel
algorithms.
(*) Even in cases where bitfields are protected by locks, all fields
in a given bitfield must be protected by one lock. If two fields
in a given bitfield are protected by different locks, the compiler's
non-atomic read-modify-write sequences can cause an update to one
field to corrupt the value of an adjacent field.
btrfs_space_info has a bitfield sharing an underlying word consisting of
the fields full, chunk_alloc, and flush:
struct btrfs_space_info {
struct btrfs_fs_info * fs_info; /* 0 8 */
struct btrfs_space_info * parent; /* 8 8 */
...
int clamp; /* 172 4 */
unsigned int full:1; /* 176: 0 4 */
unsigned int chunk_alloc:1; /* 176: 1 4 */
unsigned int flush:1; /* 176: 2 4 */
...
Therefore, to be safe from parallel read-modify-writes losing a write to
one of the bitfield members protected by a lock, all writes to all the
bitfields must use the lock. They almost universally do, except for
btrfs_clear_space_info_full() which iterates over the space_infos and
writes out found->full = 0 without a lock.
Imagine that we have one thread completing a transaction in which we
finished deleting a block_group and are thus calling
btrfs_clear_space_info_full() while simultaneously the data reclaim
ticket infrastructure is running do_async_reclaim_data_space():
T1 T2
btrfs_commit_transaction
btrfs_clear_space_info_full
data_sinfo->full = 0
READ: full:0, chunk_alloc:0, flush:1
do_async_reclaim_data_space(data_sinfo)
spin_lock(&space_info->lock);
if(list_empty(tickets))
space_info->flush = 0;
READ: full: 0, chunk_alloc:0, flush:1
MOD/WRITE: full: 0, chunk_alloc:0, flush:0
spin_unlock(&space_info->lock);
return;
MOD/WRITE: full:0, chunk_alloc:0, flush:1
and now data_sinfo->flush is 1 but the reclaim worker has exited. This
breaks the invariant that flush is 0 iff there is no work queued or
running. Once this invariant is violated, future allocations that go
into __reserve_bytes() will add tickets to space_info->tickets but will
see space_info->flush is set to 1 and not queue the work. After this,
they will block forever on the resulting ticket, as it is now impossible
to kick the worker again.
I also confirmed by looking at the assembly of the affected kernel that
it is doing RMW operations. For example, to set the flush (3rd) bit to 0,
the assembly is:
andb $0xfb,0x60(%rbx)
and similarly for setting the full (1st) bit to 0:
andb $0xfe,-0x20(%rax)
So I think this is really a bug on practical systems. I have observed
a number of systems in this exact state, but am currently unable to
reproduce it.
Rather than leaving this footgun lying around for the future, take
advantage of the fact that there is room in the struct anyway, and that
it is already quite large and simply change the three bitfield members to
bools. This avoids writes to space_info->full having any effect on
---truncated---
π@cveNotify
π¨ CVE-2025-68365
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Initialize allocated memory before use
KMSAN reports: Multiple uninitialized values detected:
- KMSAN: uninit-value in ntfs_read_hdr (3)
- KMSAN: uninit-value in bcmp (3)
Memory is allocated by __getname(), which is a wrapper for
kmem_cache_alloc(). This memory is used before being properly
cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to
properly allocate and clear memory before use.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Initialize allocated memory before use
KMSAN reports: Multiple uninitialized values detected:
- KMSAN: uninit-value in ntfs_read_hdr (3)
- KMSAN: uninit-value in bcmp (3)
Memory is allocated by __getname(), which is a wrapper for
kmem_cache_alloc(). This memory is used before being properly
cleared. Change kmem_cache_alloc() to kmem_cache_zalloc() to
properly allocate and clear memory before use.
π@cveNotify
π¨ CVE-2025-68725
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not let BPF test infra emit invalid GSO types to stack
Yinhao et al. reported that their fuzzer tool was able to trigger a
skb_warn_bad_offload() from netif_skb_features() -> gso_features_check().
When a BPF program - triggered via BPF test infra - pushes the packet
to the loopback device via bpf_clone_redirect() then mentioned offload
warning can be seen. GSO-related features are then rightfully disabled.
We get into this situation due to convert___skb_to_skb() setting
gso_segs and gso_size but not gso_type. Technically, it makes sense
that this warning triggers since the GSO properties are malformed due
to the gso_type. Potentially, the gso_type could be marked non-trustworthy
through setting it at least to SKB_GSO_DODGY without any other specific
assumptions, but that also feels wrong given we should not go further
into the GSO engine in the first place.
The checks were added in 121d57af308d ("gso: validate gso_type in GSO
handlers") because there were malicious (syzbot) senders that combine
a protocol with a non-matching gso_type. If we would want to drop such
packets, gso_features_check() currently only returns feature flags via
netif_skb_features(), so one location for potentially dropping such skbs
could be validate_xmit_unreadable_skb(), but then otoh it would be
an additional check in the fast-path for a very corner case. Given
bpf_clone_redirect() is the only place where BPF test infra could emit
such packets, lets reject them right there.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
bpf: Do not let BPF test infra emit invalid GSO types to stack
Yinhao et al. reported that their fuzzer tool was able to trigger a
skb_warn_bad_offload() from netif_skb_features() -> gso_features_check().
When a BPF program - triggered via BPF test infra - pushes the packet
to the loopback device via bpf_clone_redirect() then mentioned offload
warning can be seen. GSO-related features are then rightfully disabled.
We get into this situation due to convert___skb_to_skb() setting
gso_segs and gso_size but not gso_type. Technically, it makes sense
that this warning triggers since the GSO properties are malformed due
to the gso_type. Potentially, the gso_type could be marked non-trustworthy
through setting it at least to SKB_GSO_DODGY without any other specific
assumptions, but that also feels wrong given we should not go further
into the GSO engine in the first place.
The checks were added in 121d57af308d ("gso: validate gso_type in GSO
handlers") because there were malicious (syzbot) senders that combine
a protocol with a non-matching gso_type. If we would want to drop such
packets, gso_features_check() currently only returns feature flags via
netif_skb_features(), so one location for potentially dropping such skbs
could be validate_xmit_unreadable_skb(), but then otoh it would be
an additional check in the fast-path for a very corner case. Given
bpf_clone_redirect() is the only place where BPF test infra could emit
such packets, lets reject them right there.
π@cveNotify
π¨ CVE-2025-68749
In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix race condition when unbinding BOs
Fix 'Memory manager not clean during takedown' warning that occurs
when ivpu_gem_bo_free() removes the BO from the BOs list before it
gets unmapped. Then file_priv_unbind() triggers a warning in
drm_mm_takedown() during context teardown.
Protect the unmapping sequence with bo_list_lock to ensure the BO is
always fully unmapped when removed from the list. This ensures the BO
is either fully unmapped at context teardown time or present on the
list and unmapped by file_priv_unbind().
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
accel/ivpu: Fix race condition when unbinding BOs
Fix 'Memory manager not clean during takedown' warning that occurs
when ivpu_gem_bo_free() removes the BO from the BOs list before it
gets unmapped. Then file_priv_unbind() triggers a warning in
drm_mm_takedown() during context teardown.
Protect the unmapping sequence with bo_list_lock to ensure the BO is
always fully unmapped when removed from the list. This ensures the BO
is either fully unmapped at context teardown time or present on the
list and unmapped by file_priv_unbind().
π@cveNotify
π¨ CVE-2023-54207
In the Linux kernel, the following vulnerability has been resolved:
HID: uclogic: Correct devm device reference for hidinput input_dev name
Reference the HID device rather than the input device for the devm
allocation of the input_dev name. Referencing the input_dev would lead to a
use-after-free when the input_dev was unregistered and subsequently fires a
uevent that depends on the name. At the point of firing the uevent, the
name would be freed by devres management.
Use devm_kasprintf to simplify the logic for allocating memory and
formatting the input_dev name string.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
HID: uclogic: Correct devm device reference for hidinput input_dev name
Reference the HID device rather than the input device for the devm
allocation of the input_dev name. Referencing the input_dev would lead to a
use-after-free when the input_dev was unregistered and subsequently fires a
uevent that depends on the name. At the point of firing the uevent, the
name would be freed by devres management.
Use devm_kasprintf to simplify the logic for allocating memory and
formatting the input_dev name string.
π@cveNotify
π¨ CVE-2023-54285
In the Linux kernel, the following vulnerability has been resolved:
iomap: Fix possible overflow condition in iomap_write_delalloc_scan
folio_next_index() returns an unsigned long value which left shifted
by PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead
use folio_pos(folio) + folio_size(folio), which does this correctly.
π@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
iomap: Fix possible overflow condition in iomap_write_delalloc_scan
folio_next_index() returns an unsigned long value which left shifted
by PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead
use folio_pos(folio) + folio_size(folio), which does this correctly.
π@cveNotify
π¨ CVE-2025-53627
Meshtastic is an open source mesh networking solution. The Meshtastic firmware (starting from version 2.5) introduces asymmetric encryption (PKI) for direct messages, but when the `pki_encrypted` flag is missing, the firmware silently falls back to legacy AES-256-CTR channel encryption. This was an intentional decision to maintain backwards compatibility. However, the end-user applications, like Web app, iOS/Android app, and applications built on top of Meshtastic using the SDK, did not have a way to differentiate between end-to-end encrypted DMs and the legacy DMs. This creates a downgrade attack path where adversaries who know a shared channel key can craft and inject spoofed direct messages that are displayed as if they were PKC encrypted. Users are not given any feedback of whether a direct message was decrypted with PKI or with legacy symmetric encryption, undermining the expected security guarantees of the PKI rollout. Version 2.7.15 fixes this issue.
π@cveNotify
Meshtastic is an open source mesh networking solution. The Meshtastic firmware (starting from version 2.5) introduces asymmetric encryption (PKI) for direct messages, but when the `pki_encrypted` flag is missing, the firmware silently falls back to legacy AES-256-CTR channel encryption. This was an intentional decision to maintain backwards compatibility. However, the end-user applications, like Web app, iOS/Android app, and applications built on top of Meshtastic using the SDK, did not have a way to differentiate between end-to-end encrypted DMs and the legacy DMs. This creates a downgrade attack path where adversaries who know a shared channel key can craft and inject spoofed direct messages that are displayed as if they were PKC encrypted. Users are not given any feedback of whether a direct message was decrypted with PKI or with legacy symmetric encryption, undermining the expected security guarantees of the PKI rollout. Version 2.7.15 fixes this issue.
π@cveNotify
GitHub
Forged DMs with no PKC show up as encrypted
### Summary
The Meshtastic firmware (starting from version 2.5) introduces asymmetric encryption (PKI) for direct messages, but when the `pki_encrypted` flag is missing, the firmware silently fa...
The Meshtastic firmware (starting from version 2.5) introduces asymmetric encryption (PKI) for direct messages, but when the `pki_encrypted` flag is missing, the firmware silently fa...
π¨ CVE-2026-27466
BigBlueButton is an open-source virtual classroom. In versions 3.0.21 and below, the official documentation for "Server Customization" on Support for ClamAV as presentation file scanner contains instructions that leave a BBB server vulnerable for Denial of Service. The flawed command exposes both ports (3310 and 7357) to the internet. A remote attacker can use this to send complex or large documents to clamd and waste server resources, or shutdown the clamd process. The clamd documentation explicitly warns about exposing this port. Enabling ufw (ubuntu firewall) during install does not help, because Docker routes container traffic through the nat table, which is not managed or restricted by ufw. Rules installed by ufw in the filter table have no effect on docker traffic. In addition, the provided example also mounts /var/bigbluebutton with write permissions into the container, which should not be required. Future vulnerabilities in clamd may allow attackers to manipulate files in that folder. Users are unaffected unless they have opted in to follow the extra instructions from BigBlueButton's documentation. This issue has been fixed in version 3.0.22.
π@cveNotify
BigBlueButton is an open-source virtual classroom. In versions 3.0.21 and below, the official documentation for "Server Customization" on Support for ClamAV as presentation file scanner contains instructions that leave a BBB server vulnerable for Denial of Service. The flawed command exposes both ports (3310 and 7357) to the internet. A remote attacker can use this to send complex or large documents to clamd and waste server resources, or shutdown the clamd process. The clamd documentation explicitly warns about exposing this port. Enabling ufw (ubuntu firewall) during install does not help, because Docker routes container traffic through the nat table, which is not managed or restricted by ufw. Rules installed by ufw in the filter table have no effect on docker traffic. In addition, the provided example also mounts /var/bigbluebutton with write permissions into the container, which should not be required. Future vulnerabilities in clamd may allow attackers to manipulate files in that folder. Users are unaffected unless they have opted in to follow the extra instructions from BigBlueButton's documentation. This issue has been fixed in version 3.0.22.
π@cveNotify
GitHub
Merge commit from fork Β· bigbluebutton/bigbluebutton@f3d33d9
[3.0]chore: clamav tighten command
π¨ CVE-2026-27571
NATS-Server is a High-Performance server for NATS.io, a cloud and edge native messaging system. The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. Prior to versions 2.11.2 and 2.12.3, the implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons. An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process. The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit. The fix, present in versions 2.11.2 and 2.12.3, was to bounds the decompression to fail once the message was too large, instead of continuing on. The vulnerability only affects deployments which use WebSockets and which expose the network port to untrusted end-points.
π@cveNotify
NATS-Server is a High-Performance server for NATS.io, a cloud and edge native messaging system. The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. Prior to versions 2.11.2 and 2.12.3, the implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons. An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process. The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit. The fix, present in versions 2.11.2 and 2.12.3, was to bounds the decompression to fail once the message was too large, instead of continuing on. The vulnerability only affects deployments which use WebSockets and which expose the network port to untrusted end-points.
π@cveNotify
GitHub
[FIXED] Websocket: limit buffer size during decompression of a frame Β· nats-io/nats-server@f77fb7c
When the server would decompress a compressed websocket frame, it would
not limit the resulting size of the uncompressed buffer. Once uncompressed
the maximum payload size would still be used to re...
not limit the resulting size of the uncompressed buffer. Once uncompressed
the maximum payload size would still be used to re...
π¨ CVE-2024-8411
A vulnerability was determined in ABCD ABCD2 up to 2.2.0-beta-1. Impacted is an unknown function of the file /buscar_integrada.php. Executing a manipulation of the argument Sub_Expresion can lead to cross site scripting. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The developer explains, that "this script has been completely redesigned after this version".
π@cveNotify
A vulnerability was determined in ABCD ABCD2 up to 2.2.0-beta-1. Impacted is an unknown function of the file /buscar_integrada.php. Executing a manipulation of the argument Sub_Expresion can lead to cross site scripting. It is possible to launch the attack remotely. The exploit has been publicly disclosed and may be utilized. The developer explains, that "this script has been completely redesigned after this version".
π@cveNotify
GitHub
GitHub - peritocibernetico/ABCD_Vulnerabilities
Contribute to peritocibernetico/ABCD_Vulnerabilities development by creating an account on GitHub.
π¨ CVE-2025-54236
Adobe Commerce versions 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier are affected by an Improper Input Validation vulnerability. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality, and integrity impact to high. Exploitation of this issue does not require user interaction.
π@cveNotify
Adobe Commerce versions 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier are affected by an Improper Input Validation vulnerability. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality, and integrity impact to high. Exploitation of this issue does not require user interaction.
π@cveNotify
Adobe
Adobe Security Bulletin
Security Updates Available for Adobe Commerce | APSB25-88
π¨ CVE-2024-47265
Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability in encrypted share umount functionality in Synology Active Backup for Business before 2.7.1-13234, 2.7.1-23234 and 2.7.1-3234 allows remote authenticated users to write specific files via unspecified vectors.
π@cveNotify
Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability in encrypted share umount functionality in Synology Active Backup for Business before 2.7.1-13234, 2.7.1-23234 and 2.7.1-3234 allows remote authenticated users to write specific files via unspecified vectors.
π@cveNotify
Synology
Synology_SA_25_02 | Synology Inc.
Synology Product Security Advisory
π¨ CVE-2024-47266
Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability in share file list functionality in Synology Active Backup for Business before 2.7.1-13234, 2.7.1-23234 and 2.7.1-3234 allows remote authenticated users with administrator privileges to read specific files containing non-sensitive information via unspecified vectors.
π@cveNotify
Improper limitation of a pathname to a restricted directory ('Path Traversal') vulnerability in share file list functionality in Synology Active Backup for Business before 2.7.1-13234, 2.7.1-23234 and 2.7.1-3234 allows remote authenticated users with administrator privileges to read specific files containing non-sensitive information via unspecified vectors.
π@cveNotify
Synology
Synology_SA_25_02 | Synology Inc.
Synology Product Security Advisory
π¨ CVE-2025-27378
AES contains a SQL injection vulnerability due to an inactive configuration that prevents the latest SQL parsing logic from being applied. When this configuration is not enabled, crafted input may be improperly handled, allowing attackers to inject and execute arbitrary SQL queries.
π@cveNotify
AES contains a SQL injection vulnerability due to an inactive configuration that prevents the latest SQL parsing logic from being applied. When this configuration is not enabled, crafted input may be improperly handled, allowing attackers to inject and execute arbitrary SQL queries.
π@cveNotify
Altium
Security Advisories | Altium
This page contains important information regarding security vulnerabilities that could affect specific versions of Altium 365 products or services.
π¨ CVE-2025-27379
A stored cross-site scripting (XSS) vulnerability in the BOM Viewer in Altium AES 7.0.3 allows an authenticated attacker to inject arbitrary JavaScript into the Description field of a schematic, which is executed when the BOM Viewer renders the affected content.
π@cveNotify
A stored cross-site scripting (XSS) vulnerability in the BOM Viewer in Altium AES 7.0.3 allows an authenticated attacker to inject arbitrary JavaScript into the Description field of a schematic, which is executed when the BOM Viewer renders the affected content.
π@cveNotify
Altium
Security Advisories | Altium
This page contains important information regarding security vulnerabilities that could affect specific versions of Altium 365 products or services.
π¨ CVE-2025-27380
HTML injection in Project Release in Altium Enterprise Server (AES) 7.0.3 on all platforms allows an authenticated attacker to execute arbitrary JavaScript in the victimβs browser via crafted HTML content.
π@cveNotify
HTML injection in Project Release in Altium Enterprise Server (AES) 7.0.3 on all platforms allows an authenticated attacker to execute arbitrary JavaScript in the victimβs browser via crafted HTML content.
π@cveNotify
Altium
Security Advisories | Altium
This page contains important information regarding security vulnerabilities that could affect specific versions of Altium 365 products or services.