CVE-2024-1024
published 2024-01-30CVE-2024-1024: A vulnerability has been found in SourceCodester Facebook News Feed Like 1.0 and classified as problematic. This vulnerability affects unknown code of the…
PriorityP429medium6.1CVSS 3.1
AVNACLPRNUIRSCCLILAN
EPSS
0.31%
23.2th percentile
A vulnerability has been found in SourceCodester Facebook News Feed Like 1.0 and classified as problematic. This vulnerability affects unknown code of the component New Account Handler. The manipulation of the argument First Name/Last Name with the input alert(1) leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-252292.
Affected
6 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| apollo | gateway | >= 2.0.0 < 2.8.5 | 2.8.5 |
| apollo | query-planner | >= 2.0.0 < 2.8.5 | 2.8.5 |
| apollographql | apollo-router | >= 0 < 1.52.1 | 1.52.1 |
| dave_mills | ntpd | >= 0.3.1 < 1.1.3 | 1.1.3 |
| oretnom23 | facebook_news_feed_like | — | — |
| sourcecodester | facebook_news_feed_like | — | — |
CVSS provenance
nvdv3.16.1MEDIUMCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
nvdv2.04.0MEDIUMAV:N/AC:L/Au:S/C:N/I:P/A:N
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
Apollo Query Planner and Apollo Gateway may infinitely loop on sufficiently complex queries
ghsa·2024-08-27
CVE-2024-43414 [HIGH] CWE-673 Apollo Query Planner and Apollo Gateway may infinitely loop on sufficiently complex queries
Apollo Query Planner and Apollo Gateway may infinitely loop on sufficiently complex queries
### Impact
Instances of @apollo/query-planner >=2.0.0 and =2.0.0 and `Number.MAX_VALUE`:
```graphql
query {
field_1: field
field_2: field
# ...
field_1023: field
field_1024: field
}
```
However, in a graph that provided 5 options to solve a given field, the bug could be encountered in a query that aliased the field approximately 440 times.
### Patches
@apollo/query-planner 2.8.5
@apollo/gateway 2.8.5
Apollo Router 1.52.1
### Workarounds
This issue can be avoided by ensuring there are no fields resolvable from multiple subgraphs. If all subgraphs are using Federation 2, you can confirm that you are not impacted by ensuring that none of your subgraph schemas use the `@shareable` directive. If y
GHSA
Unlimited number of NTS-KE connections can crash ntpd-rs server
ghsa·2024-06-28
CVE-2024-38528 [HIGH] CWE-770 Unlimited number of NTS-KE connections can crash ntpd-rs server
Unlimited number of NTS-KE connections can crash ntpd-rs server
### Summary
Missing limit for accepted NTS-KE connections allows an unauthenticated remote attacker to crash ntpd-rs when an NTS-KE server is configured. Non NTS-KE server configurations, such as the default ntpd-rs configuration, are unaffected.
### Details
Operating systems have a limit for the number of open file descriptors (which includes sockets) in a single process, e.g. 1024 on Linux by default. When ntpd-rs is configured as an NTS server, it accepts TCP connections for the NTS-KE service. If the process has reached the descriptor limit and tries to accept a new TCP connection, the accept() system call will return with the EMFILE error and cause ntpd-rs to abort.
A remote attacker can open a large number of parallel
GHSA
GHSA-pwq2-rpq6-5x8x: A vulnerability has been found in SourceCodester Facebook News Feed Like 1
ghsa_unreviewed·2024-01-30
CVE-2024-1024 [MEDIUM] CWE-79 GHSA-pwq2-rpq6-5x8x: A vulnerability has been found in SourceCodester Facebook News Feed Like 1
A vulnerability has been found in SourceCodester Facebook News Feed Like 1.0 and classified as problematic. This vulnerability affects unknown code of the component New Account Handler. The manipulation of the argument First Name/Last Name with the input alert(1) leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-252292.
GHSA
encoded_id-rails potential DOS vulnerability due to URIs with extremely long encoded IDs
ghsa·2023-10-24
CVE-2024-0241 [HIGH] CWE-400 encoded_id-rails potential DOS vulnerability due to URIs with extremely long encoded IDs
encoded_id-rails potential DOS vulnerability due to URIs with extremely long encoded IDs
### Impact
The length of URIs and the various parts (eg path segments, query parameters) is usually limited by the webserver processing the incoming request. In the case of Puma the defaults are :
- path segment length: 8192
- Max URI length: 1024 * 12
- Max query length: 1024 * 10
See https://github.com/puma/puma/blob/master/docs/compile_options.md
If too long Puma raises:
> Puma caught this error: HTTP element REQUEST_PATH is longer than the (8192) allowed length (was 12503) (Puma::HttpParserError)
However due to the performance of `hashids` extremely long encoded IDs will consume a large amount of CPU and allocate a huge number of intermediate objects.
For example:
```
curl -vvv https://loca
Red Hat
kernel: dm cache: fix out-of-bounds access to the dirty bitset when resizing
vendor_redhat·2024-11-19·CVSS 7.1
CVE-2024-50279 [HIGH] CWE-125 kernel: dm cache: fix out-of-bounds access to the dirty bitset when resizing
kernel: dm cache: fix out-of-bounds access to the dirty bitset when resizing
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix out-of-bounds access to the dirty bitset when resizing
dm-cache checks the dirty bits of the cache blocks to be dropped when
shrinking the fast device, but an index bug in bitset iteration causes
out-of-bounds access.
Reproduce steps:
1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"
dmsetup create cdata --table "0 131072 linear /dev/sdc 8192"
dmsetup create corig --table "0 524288 linear /dev/sdc 262144"
dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct
dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \
/dev/mapper/cdata /dev/ma
Red Hat
kernel: smb: client: fix OOBs when building SMB2_IOCTL request
vendor_redhat·2024-11-07·CVSS 7.8
CVE-2024-50151 [HIGH] CWE-787 kernel: smb: client: fix OOBs when building SMB2_IOCTL request
kernel: smb: client: fix OOBs when building SMB2_IOCTL request
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix OOBs when building SMB2_IOCTL request
When using encryption, either enforced by the server or when using
'seal' mount option, the client will squash all compound request buffers
down for encryption into a single iov in smb2_set_next_command().
SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the
SMB2_IOCTL request in the first iov, and if the user passes an input
buffer that is greater than 328 bytes, smb2_set_next_command() will
end up writing off the end of @rqst->iov[0].iov_base as shown below:
mount.cifs //srv/share /mnt -o ...,seal
ln -s $(perl -e "print('a')for 1..1024") /mnt/link
BUG: KASAN: slab-out-of-bounds in
smb2_set_
Red Hat
kernel: block: fix integer overflow in BLKSECDISCARD
vendor_redhat·2024-10-21·CVSS 5.5
CVE-2024-49994 [MEDIUM] CWE-190 kernel: block: fix integer overflow in BLKSECDISCARD
kernel: block: fix integer overflow in BLKSECDISCARD
In the Linux kernel, the following vulnerability has been resolved:
block: fix integer overflow in BLKSECDISCARD
I independently rediscovered
commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155
block: fix overflow in blk_ioctl_discard()
but for secure erase.
Same problem:
uint64_t r[2] = {512, 18446744073709551104ULL};
ioctl(fd, BLKSECDISCARD, r);
will enter near infinite loop inside blkdev_issue_secure_erase():
a.out: attempt to access beyond end of device
loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048
bio_check_eod: 3286214 callbacks suppressed
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: kernel (Red Hat Enterprise Linux 7) - Out of support scope
Package: kernel-rt (Red Hat Enterprise Linux 7) - Ou
Red Hat
kernel: Input: MT - limit max slots
vendor_redhat·2024-09-04·CVSS 5.5
CVE-2024-45008 [MEDIUM] CWE-789 kernel: Input: MT - limit max slots
kernel: Input: MT - limit max slots
In the Linux kernel, the following vulnerability has been resolved:
Input: MT - limit max slots
syzbot is reporting too large allocation at input_mt_init_slots(), for
num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
Since nobody knows possible max slots, this patch chose 1024.
Package: kernel (Red Hat Enterprise Linux 6) - Out of support scope
Package: kernel (Red Hat Enterprise Linux 7) - Out of support scope
Package: kernel-rt (Red Hat Enterprise Linux 7) - Out of support scope
Package: kernel (Red Hat Enterprise Linux 8) - Will not fix
Package: kernel-rt (Red Hat Enterprise Linux 8) - Will not fix
Package: kernel (Red Hat Enterprise Linux 9) - Will not fix
Package: kernel-rt (Red Hat Enterprise Linux 9) - Will not fix
Red Hat
kernel: PCI: endpoint: Clean up error handling in vpci_scan_bus()
vendor_redhat·2024-08-21·CVSS 5.5
CVE-2024-43875 [MEDIUM] CWE-476 kernel: PCI: endpoint: Clean up error handling in vpci_scan_bus()
kernel: PCI: endpoint: Clean up error handling in vpci_scan_bus()
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Clean up error handling in vpci_scan_bus()
Smatch complains about inconsistent NULL checking in vpci_scan_bus():
drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021)
Instead of printing an error message and then crashing we should return
an error code and clean up.
Also the NULL check is reversed so it prints an error for success
instead of failure.
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: kernel (Red Hat Enterprise Linux 7) - Not affected
Package: kernel-rt (Red Hat Enterprise Linux 7) - Not affected
Package: kernel (Red Hat En
Red Hat
kernel: f2fs: multidev: fix to recognize valid zero block address
vendor_redhat·2024-06-21·CVSS 5.5
CVE-2024-38636 [MEDIUM] CWE-20 kernel: f2fs: multidev: fix to recognize valid zero block address
kernel: f2fs: multidev: fix to recognize valid zero block address
In the Linux kernel, the following vulnerability has been resolved:
f2fs: multidev: fix to recognize valid zero block address
As reported by Yi Zhang in mailing list [1], kernel warning was catched
during zbd/010 test as below:
./check zbd/010
zbd/010 (test gap zone support with F2FS) [failed]
runtime ... 3.752s
something found in dmesg:
[ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13
[ 4378.192349] null_blk: module loaded
[ 4378.209860] null_blk: disk nullb0 created
[ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim
poll_queues to 0. poll_q/nr_hw = (0/1)
[ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]
dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0
[ 4378.434922] scsi 15:0:
Red Hat
kernel: drm/amd/display: Fix memory leak in dm_sw_fini()
vendor_redhat·2024-04-17·CVSS 5.5
CVE-2024-26833 [MEDIUM] CWE-402 kernel: drm/amd/display: Fix memory leak in dm_sw_fini()
kernel: drm/amd/display: Fix memory leak in dm_sw_fini()
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix memory leak in dm_sw_fini()
After destroying dmub_srv, the memory associated with it is
not freed, causing a memory leak:
unreferenced object 0xffff896302b45800 (size 1024):
comm "(udev-worker)", pid 222, jiffies 4294894636
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 6265fd77):
[] kmalloc_trace+0x29d/0x340
[] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
[] dm_sw_init+0x15/0x2b0 [amdgpu]
[] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
[] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
[] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
[] local_pci
Red Hat
kernel: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
vendor_redhat·2024-04-17·CVSS 6.0
CVE-2024-26894 [MEDIUM] CWE-401 kernel: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
kernel: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
comm "swapper/0", pid 1, jiffies 4294893170
hex dump (first 32 bytes):
00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 8836a742):
[] kmalloc_trace+0x29d/0x340
[] acpi_processor_power_init+0xf3/0x1c0
[] __acpi_processor_start+0xd3/0xf0
[] acpi_processor_start+0x2c/0x50
[] really_probe+0xe2/0x480
[] __driver_probe_device+0x78
Red Hat
kernel: tools/rtla: Fix clang warning about mount_point var size
vendor_redhat·2024-04-17·CVSS 5.5
CVE-2024-26818 [MEDIUM] CWE-120 kernel: tools/rtla: Fix clang warning about mount_point var size
kernel: tools/rtla: Fix clang warning about mount_point var size
In the Linux kernel, the following vulnerability has been resolved:
tools/rtla: Fix clang warning about mount_point var size
clang is reporting this warning:
$ make HOSTCC=clang CC=clang LLVM_IAS=1
[...]
clang -O -g -DVERSION=\"6.8.0-rc3\" -flto=auto -fexceptions
-fstack-protector-strong -fasynchronous-unwind-tables
-fstack-clash-protection -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
$(pkg-config --cflags libtracefs) -c -o src/utils.o src/utils.c
src/utils.c:548:66: warning: 'fscanf' may overflow; destination buffer in argument 3 has size 1024, but the corresponding specifier may require size 1025 [-Wfortify-source]
548 | while (fscanf(fp, "%*s %" STR(MAX_PATH) "s %99s %*s %*d %*d\n", moun
Suricata
ET MALWARE Stuxnet index.php
suricata·2010-09-28
CVE-2010-2568 ET MALWARE Stuxnet index.php
ET MALWARE Stuxnet index.php
Rule: alert http $HOME_NET 1024: -> $EXTERNAL_NET any (msg:"ET MALWARE Stuxnet index.php"; flow:established,to_server; http.uri; content:"/index.php?data=66a96e28"; nocase; reference:url,research.zscaler.com/2010/07/lnk-cve-2010-2568-stuxnet-incident.html; classtype:trojan-activity; sid:2011300; rev:6; metadata:created_at 2010_09_28, signature_severity Major, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2024_03_06;)
Suricata
GPL NETBIOS DCERPC Workstation Service direct service bind attempt
suricata·2010-09-23
CVE-2003-0812 GPL NETBIOS DCERPC Workstation Service direct service bind attempt
GPL NETBIOS DCERPC Workstation Service direct service bind attempt
Rule: alert tcp $EXTERNAL_NET any -> $HOME_NET 1024: (msg:"GPL NETBIOS DCERPC Workstation Service direct service bind attempt"; flow:established,to_server; content:"|05 00 0B|"; depth:3; byte_test:1,&,16,1,relative; content:"|98 D0 FF|k|12 A1 10|6|98|3F|C3 F8|~4Z"; within:16; distance:29; reference:bugtraq,9011; reference:cve,2003-0812; reference:url,www.microsoft.com/technet/security/bulletin/MS03-049.mspx; classtype:misc-attack; sid:2102315; rev:8; metadata:created_at 2010_09_23, cve CVE_2003_0812, signature_severity Informational, updated_at 2024_03_08;)
Suricata
GPL RPC snmpXdmi overflow attempt TCP
suricata·2010-09-23
CVE-2001-0236 GPL RPC snmpXdmi overflow attempt TCP
GPL RPC snmpXdmi overflow attempt TCP
Rule: alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL RPC snmpXdmi overflow attempt TCP"; flow:established,to_server; content:"|00 01 87 99|"; depth:4; offset:16; content:"|00 00 01 01|"; within:4; distance:4; byte_jump:4,4,relative,align; byte_jump:4,4,relative,align; byte_test:4,>,1024,20,relative; content:"|00 00 00 00|"; depth:4; offset:8; reference:bugtraq,2417; reference:cve,2001-0236; reference:url,www.cert.org/advisories/CA-2001-05.html; classtype:attempted-admin; sid:2100569; rev:16; metadata:created_at 2010_09_23, cve CVE_2001_0236, confidence Medium, signature_severity Informational, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2024_03_08;)
Suricata
GPL RPC CMSD TCP CMSD_CREATE buffer overflow attempt
suricata·2010-09-23
CVE-1999-0696 GPL RPC CMSD TCP CMSD_CREATE buffer overflow attempt
GPL RPC CMSD TCP CMSD_CREATE buffer overflow attempt
Rule: alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL RPC CMSD TCP CMSD_CREATE buffer overflow attempt"; flow:established,to_server; content:"|00 01 86 E4|"; depth:4; offset:16; content:"|00 00 00 15|"; within:4; distance:4; byte_jump:4,4,relative,align; byte_jump:4,4,relative,align; byte_test:4,>,1024,0,relative; content:"|00 00 00 00|"; depth:4; offset:8; reference:bugtraq,524; reference:cve,1999-0696; classtype:attempted-admin; sid:2101908; rev:11; metadata:created_at 2010_09_23, cve CVE_1999_0696, confidence High, signature_severity Major, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2024_03_08;)
Nuclei
Lightdash v0.1024.6 - Server-Side Request Forgery
nuclei·CVSS 7.3
CVE-2024-6586 [HIGH] Lightdash v0.1024.6 - Server-Side Request Forgery
Lightdash v0.1024.6 - Server-Side Request Forgery
Server-Side Request Forgery (“SSRF”) in the export dashboard functionality of Lightdash version 0.1024.6 allows remote authenticated threat actors to obtain the session cookie of any user who exports a crafted dashboard. When they are exported, dashboards containing HTML elements can trigger HTTP requests to an external domain that contain the exporting user’s session cookie. The cookie could be stolen by a threat actor and used to hijack application user sessions.
Template:
id: CVE-2024-6586
info:
name: Lightdash v0.1024.6 - Server-Side Request Forgery
author: iamnoooob,rootxharsh,pdresearch
severity: high
description: |
Server-Side Request Forgery (“SSRF”) in the export dashboard functionality of Lightdash version 0.1024.6 allows remo
No writeups or analysis indexed.
2024-01-30
Published