🚨 CVE-2014-0789
Multiple buffer overflows in the OPC Automation 2.0 Server Object ActiveX control in Schneider Electric OPC Factory Server (OFS) TLXCDSUOFS33 3.5 and earlier, TLXCDSTOFS33 3.5 and earlier, TLXCDLUOFS33 3.5 and earlier, TLXCDLTOFS33 3.5 and earlier, and TLXCDLFOFS33 3.5 and earlier allow remote attackers to cause a denial of service via long arguments to unspecified functions.
🎖@cveNotify
Multiple buffer overflows in the OPC Automation 2.0 Server Object ActiveX control in Schneider Electric OPC Factory Server (OFS) TLXCDSUOFS33 3.5 and earlier, TLXCDSTOFS33 3.5 and earlier, TLXCDLUOFS33 3.5 and earlier, TLXCDLTOFS33 3.5 and earlier, and TLXCDLFOFS33 3.5 and earlier allow remote attackers to cause a denial of service via long arguments to unspecified functions.
🎖@cveNotify
Se
Security notifications
Browse our latest vulnerability disclosures and security notifications.
🚨 CVE-2014-0787
Stack-based buffer overflow in WellinTech KingSCADA before 3.1.2.13 allows remote attackers to execute arbitrary code via a crafted packet.
🎖@cveNotify
Stack-based buffer overflow in WellinTech KingSCADA before 3.1.2.13 allows remote attackers to execute arbitrary code via a crafted packet.
🎖@cveNotify
🚨 CVE-2014-0780
Directory traversal vulnerability in NTWebServer in InduSoft Web Studio 7.1 before SP2 Patch 4 allows remote attackers to read administrative passwords in APP files, and consequently execute arbitrary code, via unspecified web requests.
🎖@cveNotify
Directory traversal vulnerability in NTWebServer in InduSoft Web Studio 7.1 before SP2 Patch 4 allows remote attackers to read administrative passwords in APP files, and consequently execute arbitrary code, via unspecified web requests.
🎖@cveNotify
🚨 CVE-2024-6127
BC Security Empire before 5.9.3 is vulnerable to a path traversal issue that can lead to remote code execution. A remote, unauthenticated attacker can exploit this vulnerability over HTTP by acting as a normal agent, completing all cryptographic handshakes, and then triggering an upload of payload data containing a malicious path.
🎖@cveNotify
BC Security Empire before 5.9.3 is vulnerable to a path traversal issue that can lead to remote code execution. A remote, unauthenticated attacker can exploit this vulnerability over HTTP by acting as a normal agent, completing all cryptographic handshakes, and then triggering an upload of payload data containing a malicious path.
🎖@cveNotify
🚨 CVE-2024-40998
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()
In the following concurrency we will access the uninitialized rs->lock:
ext4_fill_super
ext4_register_sysfs
// sysfs registered msg_ratelimit_interval_ms
// Other processes modify rs->interval to
// non-zero via msg_ratelimit_interval_ms
ext4_orphan_cleanup
ext4_msg(sb, KERN_INFO, "Errors on filesystem, "
__ext4_msg
___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state)
if (!rs->interval) // do nothing if interval is 0
return 1;
raw_spin_trylock_irqsave(&rs->lock, flags)
raw_spin_trylock(lock)
_raw_spin_trylock
__raw_spin_trylock
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_)
lock_acquire
__lock_acquire
register_lock_class
assign_lock_key
dump_stack();
ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10);
raw_spin_lock_init(&rs->lock);
// init rs->lock here
and get the following dump_stack:
=========================================================
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504
[...]
Call Trace:
dump_stack_lvl+0xc5/0x170
dump_stack+0x18/0x30
register_lock_class+0x740/0x7c0
__lock_acquire+0x69/0x13a0
lock_acquire+0x120/0x450
_raw_spin_trylock+0x98/0xd0
___ratelimit+0xf6/0x220
__ext4_msg+0x7f/0x160 [ext4]
ext4_orphan_cleanup+0x665/0x740 [ext4]
__ext4_fill_super+0x21ea/0x2b10 [ext4]
ext4_fill_super+0x14d/0x360 [ext4]
[...]
=========================================================
Normally interval is 0 until s_msg_ratelimit_state is initialized, so
___ratelimit() does nothing. But registering sysfs precedes initializing
rs->lock, so it is possible to change rs->interval to a non-zero value
via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is
uninitialized, and then a call to ext4_msg triggers the problem by
accessing an uninitialized rs->lock. Therefore register sysfs after all
initializations are complete to avoid such problems.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()
In the following concurrency we will access the uninitialized rs->lock:
ext4_fill_super
ext4_register_sysfs
// sysfs registered msg_ratelimit_interval_ms
// Other processes modify rs->interval to
// non-zero via msg_ratelimit_interval_ms
ext4_orphan_cleanup
ext4_msg(sb, KERN_INFO, "Errors on filesystem, "
__ext4_msg
___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state)
if (!rs->interval) // do nothing if interval is 0
return 1;
raw_spin_trylock_irqsave(&rs->lock, flags)
raw_spin_trylock(lock)
_raw_spin_trylock
__raw_spin_trylock
spin_acquire(&lock->dep_map, 0, 1, _RET_IP_)
lock_acquire
__lock_acquire
register_lock_class
assign_lock_key
dump_stack();
ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10);
raw_spin_lock_init(&rs->lock);
// init rs->lock here
and get the following dump_stack:
=========================================================
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504
[...]
Call Trace:
dump_stack_lvl+0xc5/0x170
dump_stack+0x18/0x30
register_lock_class+0x740/0x7c0
__lock_acquire+0x69/0x13a0
lock_acquire+0x120/0x450
_raw_spin_trylock+0x98/0xd0
___ratelimit+0xf6/0x220
__ext4_msg+0x7f/0x160 [ext4]
ext4_orphan_cleanup+0x665/0x740 [ext4]
__ext4_fill_super+0x21ea/0x2b10 [ext4]
ext4_fill_super+0x14d/0x360 [ext4]
[...]
=========================================================
Normally interval is 0 until s_msg_ratelimit_state is initialized, so
___ratelimit() does nothing. But registering sysfs precedes initializing
rs->lock, so it is possible to change rs->interval to a non-zero value
via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is
uninitialized, and then a call to ext4_msg triggers the problem by
accessing an uninitialized rs->lock. Therefore register sysfs after all
initializations are complete to avoid such problems.
🎖@cveNotify
🚨 CVE-2024-41003
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix reg_set_min_max corruption of fake_reg
Juan reported that after doing some changes to buzzer [0] and implementing
a new fuzzing strategy guided by coverage, they noticed the following in
one of the probes:
[...]
13: (79) r6 = *(u64 *)(r0 +0) ; R0=map_value(ks=4,vs=8) R6_w=scalar()
14: (b7) r0 = 0 ; R0_w=0
15: (b4) w0 = -1 ; R0_w=0xffffffff
16: (74) w0 >>= 1 ; R0_w=0x7fffffff
17: (5c) w6 &= w0 ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))
18: (44) w6 |= 2 ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))
19: (56) if w6 != 0x7ffffffd goto pc+1
REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)
REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)
REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)
19: R6_w=0x7fffffff
20: (95) exit
from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
21: (14) w6 -= 2147483632 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))
22: (76) if w6 s>= 0xe goto pc+1 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))
23: (95) exit
from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
24: (14) w6 -= 14 ; R6_w=0
[...]
What can be seen here is a register invariant violation on line 19. After
the binary-or in line 18, the verifier knows that bit 2 is set but knows
nothing about the rest of the content which was loaded from a map value,
meaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in
line 19 the verifier analyzes the branch, it splits the register states
in reg_set_min_max() into the registers of the true branch (true_reg1,
true_reg2) and the registers of the false branch (false_reg1, false_reg2).
Since the test is w6 != 0x7ffffffd, the src_reg is a known constant.
Internally, the verifier creates a "fake" register initialized as scalar
to the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,
for line 19, it is mathematically impossible to take the false branch of
this program, yet the verifier analyzes it. It is impossible because the
second bit of r6 will be set due to the prior or operation and the
constant in the condition has that bit unset (hex(fd) == binary(1111 1101).
When the verifier first analyzes the false / fall-through branch, it will
compute an intersection between the var_off of r6 and of the constant. This
is because the verifier creates a "fake" register initialized to the value
of the constant. The intersection result later refines both registers in
regs_refine_cond_op():
[...]
t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));
reg1->var_o
---truncated---
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix reg_set_min_max corruption of fake_reg
Juan reported that after doing some changes to buzzer [0] and implementing
a new fuzzing strategy guided by coverage, they noticed the following in
one of the probes:
[...]
13: (79) r6 = *(u64 *)(r0 +0) ; R0=map_value(ks=4,vs=8) R6_w=scalar()
14: (b7) r0 = 0 ; R0_w=0
15: (b4) w0 = -1 ; R0_w=0xffffffff
16: (74) w0 >>= 1 ; R0_w=0x7fffffff
17: (5c) w6 &= w0 ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))
18: (44) w6 |= 2 ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))
19: (56) if w6 != 0x7ffffffd goto pc+1
REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)
REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)
REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)
19: R6_w=0x7fffffff
20: (95) exit
from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
21: (14) w6 -= 2147483632 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))
22: (76) if w6 s>= 0xe goto pc+1 ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))
23: (95) exit
from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm
24: (14) w6 -= 14 ; R6_w=0
[...]
What can be seen here is a register invariant violation on line 19. After
the binary-or in line 18, the verifier knows that bit 2 is set but knows
nothing about the rest of the content which was loaded from a map value,
meaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in
line 19 the verifier analyzes the branch, it splits the register states
in reg_set_min_max() into the registers of the true branch (true_reg1,
true_reg2) and the registers of the false branch (false_reg1, false_reg2).
Since the test is w6 != 0x7ffffffd, the src_reg is a known constant.
Internally, the verifier creates a "fake" register initialized as scalar
to the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,
for line 19, it is mathematically impossible to take the false branch of
this program, yet the verifier analyzes it. It is impossible because the
second bit of r6 will be set due to the prior or operation and the
constant in the condition has that bit unset (hex(fd) == binary(1111 1101).
When the verifier first analyzes the false / fall-through branch, it will
compute an intersection between the var_off of r6 and of the constant. This
is because the verifier creates a "fake" register initialized to the value
of the constant. The intersection result later refines both registers in
regs_refine_cond_op():
[...]
t = tnum_intersect(tnum_subreg(reg1->var_off), tnum_subreg(reg2->var_off));
reg1->var_o
---truncated---
🎖@cveNotify
🚨 CVE-2023-41093
Use After Free vulnerability in Silicon Labs Bluetooth SDK on 32 bit, ARM may allow an attacker with precise timing capabilities to intercept a small number of packets intended for a recipient that has left the network.This issue affects Silabs Bluetooth SDK: through 8.0.0.
🎖@cveNotify
Use After Free vulnerability in Silicon Labs Bluetooth SDK on 32 bit, ARM may allow an attacker with precise timing capabilities to intercept a small number of packets intended for a recipient that has left the network.This issue affects Silabs Bluetooth SDK: through 8.0.0.
🎖@cveNotify
🚨 CVE-2022-48831
In the Linux kernel, the following vulnerability has been resolved:
ima: fix reference leak in asymmetric_verify()
Don't leak a reference to the key if its algorithm is unknown.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ima: fix reference leak in asymmetric_verify()
Don't leak a reference to the key if its algorithm is unknown.
🎖@cveNotify
🚨 CVE-2024-41013
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't walk off the end of a directory data block
This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry
to make sure don't stray beyond valid memory region. Before patching, the
loop simply checks that the start offset of the dup and dep is within the
range. So in a crafted image, if last entry is xfs_dir2_data_unused, we
can change dup->length to dup->length-1 and leave 1 byte of space. In the
next traversal, this space will be considered as dup or dep. We may
encounter an out of bound read when accessing the fixed members.
In the patch, we make sure that the remaining bytes large enough to hold
an unused entry before accessing xfs_dir2_data_unused and
xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make
sure that the remaining bytes large enough to hold a dirent with a
single-byte name before accessing xfs_dir2_data_entry.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xfs: don't walk off the end of a directory data block
This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry
to make sure don't stray beyond valid memory region. Before patching, the
loop simply checks that the start offset of the dup and dep is within the
range. So in a crafted image, if last entry is xfs_dir2_data_unused, we
can change dup->length to dup->length-1 and leave 1 byte of space. In the
next traversal, this space will be considered as dup or dep. We may
encounter an out of bound read when accessing the fixed members.
In the patch, we make sure that the remaining bytes large enough to hold
an unused entry before accessing xfs_dir2_data_unused and
xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make
sure that the remaining bytes large enough to hold a dirent with a
single-byte name before accessing xfs_dir2_data_entry.
🎖@cveNotify
🚨 CVE-2024-41090
In the Linux kernel, the following vulnerability has been resolved:
tap: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.
In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.
This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.
CVE: CVE-2024-41090
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
tap: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.
In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.
This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.
CVE: CVE-2024-41090
🎖@cveNotify
🚨 CVE-2024-41091
In the Linux kernel, the following vulnerability has been resolved:
tun: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.
In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.
This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.
CVE: CVE-2024-41091
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
tun: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.
In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.
This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.
CVE: CVE-2024-41091
🎖@cveNotify
🚨 CVE-2024-41020
In the Linux kernel, the following vulnerability has been resolved:
filelock: Fix fcntl/close race recovery compat path
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
fcntl/close race is detected"), I missed that there are two copies of the
code I was patching: The normal version, and the version for 64-bit offsets
on 32-bit kernels.
Thanks to Greg KH for stumbling over this while doing the stable
backport...
Apply exactly the same fix to the compat path for 32-bit kernels.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
filelock: Fix fcntl/close race recovery compat path
When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when
fcntl/close race is detected"), I missed that there are two copies of the
code I was patching: The normal version, and the version for 64-bit offsets
on 32-bit kernels.
Thanks to Greg KH for stumbling over this while doing the stable
backport...
Apply exactly the same fix to the compat path for 32-bit kernels.
🎖@cveNotify
🚨 CVE-2024-43789
Discourse is an open source platform for community discussion. A user can create a post with many replies, and then attempt to fetch them all at once. This can potentially reduce the availability of a Discourse instance. This problem has been patched in the latest version of Discourse. All users area are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
Discourse is an open source platform for community discussion. A user can create a post with many replies, and then attempt to fetch them all at once. This can potentially reduce the availability of a Discourse instance. This problem has been patched in the latest version of Discourse. All users area are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
GitHub
DoS by the absence of restrictions on replies to posts
### Impact
A user can create a post with many replies, and then attempt to fetch them all at once. This can potentially reduce the availability of a Discourse instance.
### Patches
The problem...
A user can create a post with many replies, and then attempt to fetch them all at once. This can potentially reduce the availability of a Discourse instance.
### Patches
The problem...
🚨 CVE-2024-45051
Discourse is an open source platform for community discussion. A maliciously crafted email address could allow an attacker to bypass domain-based restrictions and gain access to private sites, categories and/or groups. This issue has been patched in the latest stable, beta and tests-passed version of Discourse. All users area are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
Discourse is an open source platform for community discussion. A maliciously crafted email address could allow an attacker to bypass domain-based restrictions and gain access to private sites, categories and/or groups. This issue has been patched in the latest stable, beta and tests-passed version of Discourse. All users area are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
GitHub
Bypass of email address validation via encoded email addresses
### Impact
A maliciously crafted email address could allow an attacker to bypass domain-based restrictions and gain access to private sites, categories and/or groups.
### Patches
The issue is...
A maliciously crafted email address could allow an attacker to bypass domain-based restrictions and gain access to private sites, categories and/or groups.
### Patches
The issue is...
🚨 CVE-2024-45297
Discourse is an open source platform for community discussion. Users can see topics with a hidden tag if they know the label/name of that tag. This issue has been patched in the latest stable, beta and tests-passed version of Discourse. All users area are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
Discourse is an open source platform for community discussion. Users can see topics with a hidden tag if they know the label/name of that tag. This issue has been patched in the latest stable, beta and tests-passed version of Discourse. All users area are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
GitHub
Prevent topic list filtering by hidden tags for unauthorized users
### Impact
Users can see topics with a hidden tag if they know the label/name of that tag.
### Patches
The issue is patched in the latest stable, beta and tests-passed version of Discourse. ...
Users can see topics with a hidden tag if they know the label/name of that tag.
### Patches
The issue is patched in the latest stable, beta and tests-passed version of Discourse. ...
🚨 CVE-2024-47772
Discourse is an open source platform for community discussion. An attacker can execute arbitrary JavaScript on users' browsers by sending a maliciously crafted chat message and replying to it. This issue only affects sites with CSP disabled. This problem is patched in the latest version of Discourse. All users are advised to upgrade. Users unable to upgrade should ensure CSP is enabled on the forum. Users who do upgrade should also consider enabling a CSP as well as a proactive measure.
🎖@cveNotify
Discourse is an open source platform for community discussion. An attacker can execute arbitrary JavaScript on users' browsers by sending a maliciously crafted chat message and replying to it. This issue only affects sites with CSP disabled. This problem is patched in the latest version of Discourse. All users are advised to upgrade. Users unable to upgrade should ensure CSP is enabled on the forum. Users who do upgrade should also consider enabling a CSP as well as a proactive measure.
🎖@cveNotify
MDN Web Docs
Content Security Policy (CSP) - HTTP | MDN
Content Security Policy (CSP) is a feature that helps to prevent or minimize the risk of certain types of security threats. It consists of a series of instructions from a website to a browser, which instruct the browser to place restrictions on the things…
🚨 CVE-2025-22601
Discourse is an open source platform for community discussion. In affected versions an attacker can trick a target user to make changes to their own username via carefully crafted link using the `activate-account` route. This problem has been patched in the latest version of Discourse. Users are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
Discourse is an open source platform for community discussion. In affected versions an attacker can trick a target user to make changes to their own username via carefully crafted link using the `activate-account` route. This problem has been patched in the latest version of Discourse. Users are advised to upgrade. There are no known workarounds for this vulnerability.
🎖@cveNotify
GitHub
Client Side Path Traversal using activate account route
### Impact
An attacker can trick a target user to make changes to their own username via carefully crafted link using the `activate-account` route.
### Patches
This problem is patched in the ...
An attacker can trick a target user to make changes to their own username via carefully crafted link using the `activate-account` route.
### Patches
This problem is patched in the ...
🚨 CVE-2024-53266
Discourse is an open source platform for community discussion. In affected versions with some combinations of plugins, and with CSP disabled, activity streams in the user's profile page may be vulnerable to XSS. This has been patched in the latest version of Discourse core. Users are advised to upgrade. Users unable to upgrade should ensure CSP is enabled.
🎖@cveNotify
Discourse is an open source platform for community discussion. In affected versions with some combinations of plugins, and with CSP disabled, activity streams in the user's profile page may be vulnerable to XSS. This has been patched in the latest version of Discourse core. Users are advised to upgrade. Users unable to upgrade should ensure CSP is enabled.
🎖@cveNotify
GitHub
XSS via topic titles when CSP disabled
### Impact
With some combinations of plugins, and with CSP disabled, activity streams in the user's profile page may be vulnerable to XSS.
### Patches
Patched in the latest version of Dis...
With some combinations of plugins, and with CSP disabled, activity streams in the user's profile page may be vulnerable to XSS.
### Patches
Patched in the latest version of Dis...
🚨 CVE-2023-31100
Improper Access Control in SMI handler vulnerability in Phoenix SecureCore™ Technology™ 4 allows SPI flash modification.
This issue affects SecureCore™ Technology™ 4:
* from 4.3.0.0 before 4.3.0.203
*
from
4.3.1.0 before 4.3.1.163
*
from
4.4.0.0 before 4.4.0.217
*
from
4.5.0.0 before 4.5.0.138
🎖@cveNotify
Improper Access Control in SMI handler vulnerability in Phoenix SecureCore™ Technology™ 4 allows SPI flash modification.
This issue affects SecureCore™ Technology™ 4:
* from 4.3.0.0 before 4.3.0.203
*
from
4.3.1.0 before 4.3.1.163
*
from
4.4.0.0 before 4.4.0.217
*
from
4.5.0.0 before 4.5.0.138
🎖@cveNotify
Phoenix Technologies - Leading PC Innovation since 1979 - Phoenix Technologies Website
Phoenix Technologies SPI SMM Driver Vulnerability - Phoenix Technologies - Leading PC Innovation since 1979
CVE-2023-31100 Phoenix Technologies has been notified by IOActive researchers of a security issue in its SecureCore Technology SPI SMM Driver that could allow unauthorized access to the SPI flash on some platforms.
🚨 CVE-2023-5058
Improper Input Validation in the processing of user-supplied splash screen during system boot in Phoenix SecureCore™ Technology™ 4 potentially allows denial-of-service attacks or arbitrary code execution.
🎖@cveNotify
Improper Input Validation in the processing of user-supplied splash screen during system boot in Phoenix SecureCore™ Technology™ 4 potentially allows denial-of-service attacks or arbitrary code execution.
🎖@cveNotify
Phoenix Technologies - Leading PC Innovation since 1979 - Phoenix Technologies Website
Phoenix Technologies LogoFAIL Vulnerability - Phoenix Technologies - Leading PC Innovation since 1979
CVE-2023-5058 Phoenix Technologies has been informed of a serious flaw in Phoenix SecureCore™ Technology™ 4, which is a BIOS firmware that provides advanced security features for various devices.
🚨 CVE-2024-0762
Potential buffer overflow
in unsafe UEFI variable handling
in Phoenix SecureCore™ for select Intel platforms
This issue affects:
Phoenix
SecureCore™ for Intel Kaby Lake: from 4.0.1.1 before 4.0.1.998;
Phoenix
SecureCore™ for Intel Coffee Lake: from 4.1.0.1 before 4.1.0.562;
Phoenix
SecureCore™ for Intel Ice Lake: from 4.2.0.1 before 4.2.0.323;
Phoenix
SecureCore™ for Intel Comet Lake: from 4.2.1.1 before 4.2.1.287;
Phoenix
SecureCore™ for Intel Tiger Lake: from 4.3.0.1 before 4.3.0.236;
Phoenix
SecureCore™ for Intel Jasper Lake: from 4.3.1.1 before 4.3.1.184;
Phoenix
SecureCore™ for Intel Alder Lake: from 4.4.0.1 before 4.4.0.269;
Phoenix
SecureCore™ for Intel Raptor Lake: from 4.5.0.1 before 4.5.0.218;
Phoenix
SecureCore™ for Intel Meteor Lake: from 4.5.1.1 before 4.5.1.15.
🎖@cveNotify
Potential buffer overflow
in unsafe UEFI variable handling
in Phoenix SecureCore™ for select Intel platforms
This issue affects:
Phoenix
SecureCore™ for Intel Kaby Lake: from 4.0.1.1 before 4.0.1.998;
Phoenix
SecureCore™ for Intel Coffee Lake: from 4.1.0.1 before 4.1.0.562;
Phoenix
SecureCore™ for Intel Ice Lake: from 4.2.0.1 before 4.2.0.323;
Phoenix
SecureCore™ for Intel Comet Lake: from 4.2.1.1 before 4.2.1.287;
Phoenix
SecureCore™ for Intel Tiger Lake: from 4.3.0.1 before 4.3.0.236;
Phoenix
SecureCore™ for Intel Jasper Lake: from 4.3.1.1 before 4.3.1.184;
Phoenix
SecureCore™ for Intel Alder Lake: from 4.4.0.1 before 4.4.0.269;
Phoenix
SecureCore™ for Intel Raptor Lake: from 4.5.0.1 before 4.5.0.218;
Phoenix
SecureCore™ for Intel Meteor Lake: from 4.5.1.1 before 4.5.1.15.
🎖@cveNotify
Eclypsium | Supply Chain Security for the Modern Enterprise
UEFIcanhazbufferoverflow: Widespread Impact from Vulnerability in Popular PC and Server Firmware
Summary Eclypsium Automata, our automated binary analysis system, has identified a high impact vulnerability (CVE-2024-0762 with a reported CVSS of 7.5) in the Phoenix SecureCore UEFI firmware that runs on multiple families of Intel Core desktop and mobile…