๐จ CVE-2025-14706
A vulnerability was identified in Shiguangwu sgwbox N3 2.0.25. This impacts an unknown function of the file /usr/sbin/http_eshell_server of the component NETREBOOT Interface. Such manipulation leads to command injection. The attack can be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A vulnerability was identified in Shiguangwu sgwbox N3 2.0.25. This impacts an unknown function of the file /usr/sbin/http_eshell_server of the component NETREBOOT Interface. Such manipulation leads to command injection. The attack can be launched remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
๐จ CVE-2025-14707
A security flaw has been discovered in Shiguangwu sgwbox N3 2.0.25. Affected is an unknown function of the file /usr/sbin/http_eshell_server of the component DOCKER Feature. Performing manipulation of the argument params results in command injection. The attack may be initiated remotely. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A security flaw has been discovered in Shiguangwu sgwbox N3 2.0.25. Affected is an unknown function of the file /usr/sbin/http_eshell_server of the component DOCKER Feature. Performing manipulation of the argument params results in command injection. The attack may be initiated remotely. The exploit has been released to the public and may be exploited. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
๐จ CVE-2025-14708
A weakness has been identified in Shiguangwu sgwbox N3 2.0.25. Affected by this vulnerability is an unknown functionality of the file /usr/sbin/http_eshell_server of the component WIREDCFGGET Interface. Executing manipulation of the argument params can lead to buffer overflow. The attack may be launched remotely. The exploit has been made available to the public and could be exploited. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
A weakness has been identified in Shiguangwu sgwbox N3 2.0.25. Affected by this vulnerability is an unknown functionality of the file /usr/sbin/http_eshell_server of the component WIREDCFGGET Interface. Executing manipulation of the argument params can lead to buffer overflow. The attack may be launched remotely. The exploit has been made available to the public and could be exploited. The vendor was contacted early about this disclosure but did not respond in any way.
๐@cveNotify
๐จ CVE-2009-0696
The dns_db_findrdataset function in db.c in named in ISC BIND 9.4 before 9.4.3-P3, 9.5 before 9.5.1-P3, and 9.6 before 9.6.1-P1, when configured as a master server, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via an ANY record in the prerequisite section of a crafted dynamic update message.
๐@cveNotify
The dns_db_findrdataset function in db.c in named in ISC BIND 9.4 before 9.4.3-P3, 9.5 before 9.5.1-P3, and 9.6 before 9.6.1-P1, when configured as a master server, allows remote attackers to cause a denial of service (assertion failure and daemon exit) via an ANY record in the prerequisite section of a crafted dynamic update message.
๐@cveNotify
๐จ CVE-2024-26629
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASE_LOCKOWNER
The test on so_count in nfsd4_release_lockowner() is nonsense and
harmful. Revert to using check_for_locks(), changing that to not sleep.
First: harmful.
As is documented in the kdoc comment for nfsd4_release_lockowner(), the
test on so_count can transiently return a false positive resulting in a
return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is
clearly a protocol violation and with the Linux NFS client it can cause
incorrect behaviour.
If RELEASE_LOCKOWNER is sent while some other thread is still
processing a LOCK request which failed because, at the time that request
was received, the given owner held a conflicting lock, then the nfsd
thread processing that LOCK request can hold a reference (conflock) to
the lock owner that causes nfsd4_release_lockowner() to return an
incorrect error.
The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it
never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so
it knows that the error is impossible. It assumes the lock owner was in
fact released so it feels free to use the same lock owner identifier in
some later locking request.
When it does reuse a lock owner identifier for which a previous RELEASE
failed, it will naturally use a lock_seqid of zero. However the server,
which didn't release the lock owner, will expect a larger lock_seqid and
so will respond with NFS4ERR_BAD_SEQID.
So clearly it is harmful to allow a false positive, which testing
so_count allows.
The test is nonsense because ... well... it doesn't mean anything.
so_count is the sum of three different counts.
1/ the set of states listed on so_stateids
2/ the set of active vfs locks owned by any of those states
3/ various transient counts such as for conflicting locks.
When it is tested against '2' it is clear that one of these is the
transient reference obtained by find_lockowner_str_locked(). It is not
clear what the other one is expected to be.
In practice, the count is often 2 because there is precisely one state
on so_stateids. If there were more, this would fail.
In my testing I see two circumstances when RELEASE_LOCKOWNER is called.
In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in
all the lock states being removed, and so the lockowner being discarded
(it is removed when there are no more references which usually happens
when the lock state is discarded). When nfsd4_release_lockowner() finds
that the lock owner doesn't exist, it returns success.
The other case shows an so_count of '2' and precisely one state listed
in so_stateid. It appears that the Linux client uses a separate lock
owner for each file resulting in one lock state per lock owner, so this
test on '2' is safe. For another client it might not be safe.
So this patch changes check_for_locks() to use the (newish)
find_any_file_locked() so that it doesn't take a reference on the
nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With
this check is it safe to restore the use of check_for_locks() rather
than testing so_count against the mysterious '2'.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix RELEASE_LOCKOWNER
The test on so_count in nfsd4_release_lockowner() is nonsense and
harmful. Revert to using check_for_locks(), changing that to not sleep.
First: harmful.
As is documented in the kdoc comment for nfsd4_release_lockowner(), the
test on so_count can transiently return a false positive resulting in a
return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is
clearly a protocol violation and with the Linux NFS client it can cause
incorrect behaviour.
If RELEASE_LOCKOWNER is sent while some other thread is still
processing a LOCK request which failed because, at the time that request
was received, the given owner held a conflicting lock, then the nfsd
thread processing that LOCK request can hold a reference (conflock) to
the lock owner that causes nfsd4_release_lockowner() to return an
incorrect error.
The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it
never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so
it knows that the error is impossible. It assumes the lock owner was in
fact released so it feels free to use the same lock owner identifier in
some later locking request.
When it does reuse a lock owner identifier for which a previous RELEASE
failed, it will naturally use a lock_seqid of zero. However the server,
which didn't release the lock owner, will expect a larger lock_seqid and
so will respond with NFS4ERR_BAD_SEQID.
So clearly it is harmful to allow a false positive, which testing
so_count allows.
The test is nonsense because ... well... it doesn't mean anything.
so_count is the sum of three different counts.
1/ the set of states listed on so_stateids
2/ the set of active vfs locks owned by any of those states
3/ various transient counts such as for conflicting locks.
When it is tested against '2' it is clear that one of these is the
transient reference obtained by find_lockowner_str_locked(). It is not
clear what the other one is expected to be.
In practice, the count is often 2 because there is precisely one state
on so_stateids. If there were more, this would fail.
In my testing I see two circumstances when RELEASE_LOCKOWNER is called.
In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in
all the lock states being removed, and so the lockowner being discarded
(it is removed when there are no more references which usually happens
when the lock state is discarded). When nfsd4_release_lockowner() finds
that the lock owner doesn't exist, it returns success.
The other case shows an so_count of '2' and precisely one state listed
in so_stateid. It appears that the Linux client uses a separate lock
owner for each file resulting in one lock state per lock owner, so this
test on '2' is safe. For another client it might not be safe.
So this patch changes check_for_locks() to use the (newish)
find_any_file_locked() so that it doesn't take a reference on the
nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With
this check is it safe to restore the use of check_for_locks() rather
than testing so_count against the mysterious '2'.
๐@cveNotify
๐จ CVE-2025-37727
Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex
๐@cveNotify
Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex
๐@cveNotify
Discuss the Elastic Stack
Elasticsearch 8.18.8, 8.19.5, 9.0.8, 9.1.5 Security Update (ESA-2025-18)
Elasticsearch Insertion of sensitive information in log file (ESA-2025-18) Insertion of sensitive information in log file in Elasticsearch can lead to loss of confidentiality under specific preconditions when auditing requests to the reindex API Affectedโฆ
๐จ CVE-2025-14666
A weakness has been identified in itsourcecode COVID Tracking System 1.0. The affected element is an unknown function of the file /admin/?page=user. This manipulation of the argument Username causes sql injection. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be exploited.
๐@cveNotify
A weakness has been identified in itsourcecode COVID Tracking System 1.0. The affected element is an unknown function of the file /admin/?page=user. This manipulation of the argument Username causes sql injection. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be exploited.
๐@cveNotify
GitHub
itsourcecode COVID Tracking System V1.0 "/cts/admin/?page=user" SQL injection ยท Issue #2 ยท bardminx/Lonlydance
itsourcecode COVID Tracking System V1.0 "/cts/admin/?page=user" SQL injection NAME OF AFFECTED PRODUCT(S) COVID Tracking System Vendor Homepage https://itsourcecode.com/free-projects/php-...
๐จ CVE-2025-14667
A security vulnerability has been detected in itsourcecode COVID Tracking System 1.0. The impacted element is an unknown function of the file /admin/?page=system_info. Such manipulation of the argument meta_value leads to sql injection. The attack may be performed from remote. The exploit has been disclosed publicly and may be used.
๐@cveNotify
A security vulnerability has been detected in itsourcecode COVID Tracking System 1.0. The impacted element is an unknown function of the file /admin/?page=system_info. Such manipulation of the argument meta_value leads to sql injection. The attack may be performed from remote. The exploit has been disclosed publicly and may be used.
๐@cveNotify
GitHub
# itsourcecode COVID Tracking System V1.0 "/cts/admin/?page=system_info" SQL injection ยท Issue #3 ยท bardminx/Lonlydance
itsourcecode COVID Tracking System V1.0 "/cts/admin/?page=system_info" SQL injection NAME OF AFFECTED PRODUCT(S) COVID Tracking System Vendor Homepage https://itsourcecode.com/free-projec...
๐จ CVE-2025-66436
An SSTI (Server-Side Template Injection) vulnerability exists in the get_terms_and_conditions method of Frappe ERPNext through 15.89.0. The function renders attacker-controlled Jinja2 templates (terms) using frappe.render_template() with a user-supplied context (doc). Although Frappe uses a custom SandboxedEnvironment, several dangerous globals such as frappe.db.sql are still available in the execution context via get_safe_globals(). An authenticated attacker with access to create or modify a Terms and Conditions document can inject arbitrary Jinja expressions into the terms field, resulting in server-side code execution within a restricted but still unsafe context. This vulnerability can be used to leak database information.
๐@cveNotify
An SSTI (Server-Side Template Injection) vulnerability exists in the get_terms_and_conditions method of Frappe ERPNext through 15.89.0. The function renders attacker-controlled Jinja2 templates (terms) using frappe.render_template() with a user-supplied context (doc). Although Frappe uses a custom SandboxedEnvironment, several dangerous globals such as frappe.db.sql are still available in the execution context via get_safe_globals(). An authenticated attacker with access to create or modify a Terms and Conditions document can inject arbitrary Jinja expressions into the terms field, resulting in server-side code execution within a restricted but still unsafe context. This vulnerability can be used to leak database information.
๐@cveNotify
๐จ CVE-2025-68381
Improper Bounds Check (CWE-787) in Packetbeat can allow a remote unauthenticated attacker to exploit a Buffer Overflow (CAPEC-100) and reliably crash the application or cause significant resource exhaustion via a single crafted UDP packet with an invalid fragment sequence number.
๐@cveNotify
Improper Bounds Check (CWE-787) in Packetbeat can allow a remote unauthenticated attacker to exploit a Buffer Overflow (CAPEC-100) and reliably crash the application or cause significant resource exhaustion via a single crafted UDP packet with an invalid fragment sequence number.
๐@cveNotify
Discuss the Elastic Stack
Packetbeat 8.19.9, 9.1.9, and 9.2.3 Security Update (ESA-2025-30)
Packetbeat Improper Bounds Check (ESA-2025-30) Improper Bounds Check (CWE-787) in Packetbeat can allow a remote unauthenticated attacker to exploit a Buffer Overflow (CAPEC-100) and reliably crash the application or cause significant resource exhaustionโฆ
๐จ CVE-2025-68382
Out-of-bounds read (CWE-125) allows an unauthenticated remote attacker to perform a buffer overflow (CAPEC-100) via the NFS protocol dissector, leading to a denial-of-service (DoS) through a reliable process crash when handling truncated XDR-encoded RPC messages.
๐@cveNotify
Out-of-bounds read (CWE-125) allows an unauthenticated remote attacker to perform a buffer overflow (CAPEC-100) via the NFS protocol dissector, leading to a denial-of-service (DoS) through a reliable process crash when handling truncated XDR-encoded RPC messages.
๐@cveNotify
Discuss the Elastic Stack
Packetbeat 8.19.9, 9.1.9, and 9.2.3 Security Update (ESA-2025-31)
Packetbeat Out-of-bounds Read (ESA-2025-31) Out-of-bounds read (CWE-125) allows an unauthenticated remote attacker to perform a buffer overflow (CAPEC-100) via the NFS protocol dissector, leading to a denial-of-service (DoS) through a reliable process crashโฆ
๐จ CVE-2024-26926
In the Linux kernel, the following vulnerability has been resolved:
binder: check offset alignment in binder_get_object()
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
txn") introduced changes to how binder objects are copied. In doing so,
it unintentionally removed an offset alignment check done through calls
to binder_alloc_copy_from_buffer() -> check_buffer().
These calls were replaced in binder_get_object() with copy_from_user(),
so now an explicit offset alignment check is needed here. This avoids
later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320df
("binder: add function to copy binder object from buffer"), likely
removed due to redundancy at the time.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
binder: check offset alignment in binder_get_object()
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
txn") introduced changes to how binder objects are copied. In doing so,
it unintentionally removed an offset alignment check done through calls
to binder_alloc_copy_from_buffer() -> check_buffer().
These calls were replaced in binder_get_object() with copy_from_user(),
so now an explicit offset alignment check is needed here. This avoids
later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320df
("binder: add function to copy binder object from buffer"), likely
removed due to redundancy at the time.
๐@cveNotify
๐จ CVE-2024-26935
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix unremoved procfs host directory regression
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
directory earlier") fixed a bug related to modules loading/unloading, by
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
to a potential duplicate call to the hostdir_rm() routine, since it's also
called from scsi_host_dev_release(). That triggered a regression report,
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
directory removal regression"). The fix just dropped the hostdir_rm() call
from dev_release().
But it happens that this proc directory is created on scsi_host_alloc(),
and that function "pairs" with scsi_host_dev_release(), while
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
reason for removing the proc directory on dev_release() was meant to cover
cases in which a SCSI host structure was allocated, but the call to
scsi_add_host() didn't happen. And that pattern happens to exist in some
error paths, for example.
Syzkaller causes that by using USB raw gadget device, error'ing on
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
that the BadDevice label leads to a scsi_host_put() after a SCSI host
allocation, but there's no call to scsi_add_host() in such path. That leads
to messages like this in dmesg (and a leak of the SCSI host proc
structure):
usb-storage 4-1:87.51: USB Mass Storage device detected
proc_dir_entry 'scsi/usb-storage' already registered
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
but guard that with the state check for SHOST_CREATED; there is even a
comment in scsi_host_dev_release() detailing that: such conditional is
meant for cases where the SCSI host was allocated but there was no calls to
{add,remove}_host(), like the usb-storage case.
This is what we propose here and with that, the error path of usb-storage
does not trigger the warning anymore.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix unremoved procfs host directory regression
Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
directory earlier") fixed a bug related to modules loading/unloading, by
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
to a potential duplicate call to the hostdir_rm() routine, since it's also
called from scsi_host_dev_release(). That triggered a regression report,
which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
directory removal regression"). The fix just dropped the hostdir_rm() call
from dev_release().
But it happens that this proc directory is created on scsi_host_alloc(),
and that function "pairs" with scsi_host_dev_release(), while
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
reason for removing the proc directory on dev_release() was meant to cover
cases in which a SCSI host structure was allocated, but the call to
scsi_add_host() didn't happen. And that pattern happens to exist in some
error paths, for example.
Syzkaller causes that by using USB raw gadget device, error'ing on
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
that the BadDevice label leads to a scsi_host_put() after a SCSI host
allocation, but there's no call to scsi_add_host() in such path. That leads
to messages like this in dmesg (and a leak of the SCSI host proc
structure):
usb-storage 4-1:87.51: USB Mass Storage device detected
proc_dir_entry 'scsi/usb-storage' already registered
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
but guard that with the state check for SHOST_CREATED; there is even a
comment in scsi_host_dev_release() detailing that: such conditional is
meant for cases where the SCSI host was allocated but there was no calls to
{add,remove}_host(), like the usb-storage case.
This is what we propose here and with that, the error path of usb-storage
does not trigger the warning anymore.
๐@cveNotify
๐จ CVE-2024-0563
Denial of service condition in M-Files Server in versions before 24.2 (excluding 23.2 SR7 and 23.8 SR5) allows anonymous user to cause denial of service against other anonymous users.
๐@cveNotify
Denial of service condition in M-Files Server in versions before 24.2 (excluding 23.2 SR7 and 23.8 SR5) allows anonymous user to cause denial of service against other anonymous users.
๐@cveNotify
๐จ CVE-2024-22412
ClickHouse is an open-source column-oriented database management system. A bug exists in the cloud ClickHouse offering prior to version 24.0.2.54535 and in github.com/clickhouse/clickhouse version 23.1. Query caching bypasses the role based access controls and the policies being enforced on roles. In affected versions, the query cache only respects separate users, however this is not documented and not expected behavior. People relying on ClickHouse roles can have their access control lists bypassed if they are using query caching. Attackers who have control of a role could guess queries and see data they shouldn't have access to. Version 24.1 of ClickHouse and version 24.0.2.54535 of ClickHouse Cloud contain a patch for this issue. Based on the documentation, role based access control should be enforced regardless if query caching is enabled or not.
๐@cveNotify
ClickHouse is an open-source column-oriented database management system. A bug exists in the cloud ClickHouse offering prior to version 24.0.2.54535 and in github.com/clickhouse/clickhouse version 23.1. Query caching bypasses the role based access controls and the policies being enforced on roles. In affected versions, the query cache only respects separate users, however this is not documented and not expected behavior. People relying on ClickHouse roles can have their access control lists bypassed if they are using query caching. Attackers who have control of a role could guess queries and see data they shouldn't have access to. Version 24.1 of ClickHouse and version 24.0.2.54535 of ClickHouse Cloud contain a patch for this issue. Based on the documentation, role based access control should be enforced regardless if query caching is enabled or not.
๐@cveNotify
GitHub
ClickHouse/src/Interpreters/executeQuery.cpp at bd17ee769e337906c4b1f404861e042ad72fcbfc ยท ClickHouse/ClickHouse
ClickHouseยฎ is a real-time analytics database management system - ClickHouse/ClickHouse
๐จ CVE-2024-23333
LDAP Account Manager (LAM) is a webfrontend for managing entries stored in an LDAP directory. LAM's log configuration allows to specify arbitrary paths for log files. Prior to version 8.7, an attacker could exploit this by creating a PHP file and cause LAM to log some PHP code to this file. When the file is then accessed via web the code would be executed. The issue is mitigated by the following: An attacker needs to know LAM's master configuration password to be able to change the main settings; and the webserver needs write access to a directory that is accessible via web. LAM itself does not provide any such directories. The issue has been fixed in 8.7. As a workaround, limit access to LAM configuration pages to authorized users.
๐@cveNotify
LDAP Account Manager (LAM) is a webfrontend for managing entries stored in an LDAP directory. LAM's log configuration allows to specify arbitrary paths for log files. Prior to version 8.7, an attacker could exploit this by creating a PHP file and cause LAM to log some PHP code to this file. When the file is then accessed via web the code would be executed. The issue is mitigated by the following: An attacker needs to know LAM's master configuration password to be able to change the main settings; and the webserver needs write access to a directory that is accessible via web. LAM itself does not provide any such directories. The issue has been fixed in 8.7. As a workaround, limit access to LAM configuration pages to authorized users.
๐@cveNotify
GitHub
Release LAM 8.7 with PHP 8.3 compatibility and passwordless SSO login for self service ยท LDAPAccountManager/lam
PHP 8.3 compatibility
Mail attributes can be configured centrally in LAM's main configuration (273)
LAM Pro:
Cron job to deactivate inactive accounts based on lastBind overlay data (265)
Reque...
Mail attributes can be configured centrally in LAM's main configuration (273)
LAM Pro:
Cron job to deactivate inactive accounts based on lastBind overlay data (265)
Reque...
๐จ CVE-2024-35848
In the Linux kernel, the following vulnerability has been resolved:
eeprom: at24: fix memory corruption race condition
If the eeprom is not accessible, an nvmem device will be registered, the
read will fail, and the device will be torn down. If another driver
accesses the nvmem device after the teardown, it will reference
invalid memory.
Move the failure point before registering the nvmem device.
๐@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
eeprom: at24: fix memory corruption race condition
If the eeprom is not accessible, an nvmem device will be registered, the
read will fail, and the device will be torn down. If another driver
accesses the nvmem device after the teardown, it will reference
invalid memory.
Move the failure point before registering the nvmem device.
๐@cveNotify
๐จ CVE-2023-50868
The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.
๐@cveNotify
The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the "NSEC3" issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.
๐@cveNotify
๐จ CVE-2024-22727
Teltonika TRB1-series devices with firmware before TRB1_R_00.07.05.2 allow attackers to exploit a firmware vulnerability via Ethernet LAN or USB.
๐@cveNotify
Teltonika TRB1-series devices with firmware before TRB1_R_00.07.05.2 allow attackers to exploit a firmware vulnerability via Ethernet LAN or USB.
๐@cveNotify
Teltonika Networks
Critical Security Update for TRB1-series Gateways
Teltonika Networks has recently identified a critical firmware vulnerability in its TRB1-series devices. Click here to learn more.
๐จ CVE-2024-21492
All versions of the package github.com/greenpau/caddy-security are vulnerable to Insufficient Session Expiration due to improper user session invalidation upon clicking the "Sign Out" button. User sessions remain valid even after requests are sent to /logout and /oauth2/google/logout. Attackers who gain access to an active but supposedly logged-out session can perform unauthorized actions on behalf of the user.
๐@cveNotify
All versions of the package github.com/greenpau/caddy-security are vulnerable to Insufficient Session Expiration due to improper user session invalidation upon clicking the "Sign Out" button. User sessions remain valid even after requests are sent to /logout and /oauth2/google/logout. Attackers who gain access to an active but supposedly logged-out session can perform unauthorized actions on behalf of the user.
๐@cveNotify
The Trail of Bits Blog
Security flaws in an SSO plugin for Caddy
We identified 10 security vulnerabilities within the caddy-security plugin for the Caddy web server that could enable a variety of high-severity attacks in web applications, including client-side code execution, OAuth replay attacks, and unauthorized accessโฆ
๐จ CVE-2023-5123
The JSON datasource plugin ( https://grafana.com/grafana/plugins/marcusolsson-json-datasource/ ) is a Grafana Labs maintained plugin for Grafana that allows for retrieving and processing JSON data from a remote endpoint (including a specific sub-path) configured by an administrator. Due to inadequate sanitization of the dashboard-supplied path parameter, it was possible to include path traversal characters (../) in the path parameter and send requests to paths on the configured endpoint outside the configured sub-path.
This means that if the datasource was configured by an administrator to point at some sub-path of a domain (e.g. https://example.com/api/some_safe_api/ ), it was possible for an editor to create a dashboard referencing the datasource which issues queries containing path traversal characters, which would in turn cause the datasource to instead query arbitrary subpaths on the configured domain (e.g. https://example.com/api/admin_api/) .
In the rare case that this plugin is configured by an administrator to point back at the Grafana instance itself, this vulnerability becomes considerably more severe, as an administrator browsing a maliciously configured panel could be compelled to make requests to Grafana administrative API endpoints with their credentials, resulting in the potential for privilege escalation, hence the high score for this vulnerability.
๐@cveNotify
The JSON datasource plugin ( https://grafana.com/grafana/plugins/marcusolsson-json-datasource/ ) is a Grafana Labs maintained plugin for Grafana that allows for retrieving and processing JSON data from a remote endpoint (including a specific sub-path) configured by an administrator. Due to inadequate sanitization of the dashboard-supplied path parameter, it was possible to include path traversal characters (../) in the path parameter and send requests to paths on the configured endpoint outside the configured sub-path.
This means that if the datasource was configured by an administrator to point at some sub-path of a domain (e.g. https://example.com/api/some_safe_api/ ), it was possible for an editor to create a dashboard referencing the datasource which issues queries containing path traversal characters, which would in turn cause the datasource to instead query arbitrary subpaths on the configured domain (e.g. https://example.com/api/admin_api/) .
In the rare case that this plugin is configured by an administrator to point back at the Grafana instance itself, this vulnerability becomes considerably more severe, as an administrator browsing a maliciously configured panel could be compelled to make requests to Grafana administrative API endpoints with their credentials, resulting in the potential for privilege escalation, hence the high score for this vulnerability.
๐@cveNotify
Grafana Labs
Path Traversal in JSON Plugin in Grafana | Grafana Labs
Grafana is an open-source platform for monitoring and observability. The JSON datasource plugin is a Grafana Labs maintained plugin that allows for retrieving and processing JSON data from a remote endpoint (including a specific sub-path) configured by anโฆ