Security Vulnerabilities
- CVEs Published In June 2024
Actiontec WCB6200Q Cookie Format String Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Actiontec WCB6200Q routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the HTTP server. A crafted Cookie header in an HTTP request can trigger the use of a format specifier from a user-supplied string. An attacker can leverage this vulnerability to execute code in the context of the HTTP server. Was ZDI-CAN-21417.
Actiontec WCB6200Q uh_get_postdata_withupload Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Actiontec WCB6200Q routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the HTTP server. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the HTTP server. Was ZDI-CAN-21418.
Actiontec WCB6200Q uh_tcp_recv_content Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Actiontec WCB6200Q routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the HTTP server. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length buffer. An attacker can leverage this vulnerability to execute code in the context of the HTTP server. Was ZDI-CAN-21410.
Actiontec WCB6200Q uh_tcp_recv_header Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Actiontec WCB6200Q routers. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the HTTP server. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length buffer. An attacker can leverage this vulnerability to execute code in the context of the HTTP server. Was ZDI-CAN-21414.
A vulnerability, which was classified as problematic, was found in spa-cartcms 1.9.0.6. Affected is an unknown function of the file /login of the component Username Handler. The manipulation of the argument email leads to observable behavioral discrepancy. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-268896.
A vulnerability, which was classified as problematic, has been found in spa-cartcms 1.9.0.6. This issue affects some unknown processing of the file /checkout of the component Checkout Page. The manipulation of the argument quantity with the input -10 leads to enforcement of behavioral workflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-268895.
Incorrect CSRF token checks resulted in multiple CSRF risks.
A unique key should be generated for a user's QR login key and their auto-login key, so the same key cannot be used interchangeably between the two.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,
taprio_parse_mqprio_opt() must validate it, or userspace
can inject arbitrary data to the kernel, the second time
taprio_change() is called.
First call (with valid attributes) sets dev->num_tc
to a non zero value.
Second call (with arbitrary mqprio attributes)
returns early from taprio_parse_mqprio_opt()
and bad things can happen.
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Do not use WARN when encode fails
When asn1_encode_sequence() fails, WARN is not the correct solution.
1. asn1_encode_sequence() is not an internal function (located
in lib/asn1_encode.c).
2. Location is known, which makes the stack trace useless.
3. Results a crash if panic_on_warn is set.
It is also noteworthy that the use of WARN is undocumented, and it
should be avoided unless there is a carefully considered rationale to
use it.
Replace WARN with pr_err, and print the return value instead, which is
only useful piece of information.