Vulnerabilities

RedisBloom is a probabilistic data structures module for Redis. In all versions of RedisBloom before 2.8.20, the module does not properly validate serialized values processed through the Redis RESTORE command. An authenticated attacker with permission to execute RESTORE on a server with the RedisBloom module loaded can supply a crafted serialized payload that triggers invalid memory access and may lead to remote code execution. A workaround is to restrict access to the RESTORE command with ACL rules. This issue is fixed in version 2.8.20.

RedisTimeSeries is a time-series module for Redis. In all versions before 1.12.14 of RedisTimeSeries, the module does not properly validate serialized values processed through the Redis RESTORE command. An authenticated attacker with permission to execute RESTORE on a server with the RedisTimeSeries module loaded can supply a crafted serialized payload that triggers invalid memory access and may lead to remote code execution. A workaround is to restrict access to the RESTORE command with ACL rules. This has been patched in version 1.12.14.

Redis is an in-memory data structure store. In redis-server from 7.2.0 until 8.6.3, the unblock client flow does not handle an error return from `processCommandAndResetClient` when re-executing a blocked command. If a blocked client is evicted during this flow, an authenticated attacker can trigger a use-after-free that may lead to remote code execution. This has been patched in version 8.6.3.

A flaw has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. This issue affects the function PIL.Image.tobytes of the file libs/chatchat-server/chatchat/webui_pages/dialogue/dialogue.py of the component Vision Chat Paste Image Handler. This manipulation of the argument paste_image.image_data causes use of weak hash. The attacker needs to be present on the local network. The attack is considered to have high complexity. The exploitability is assessed as difficult. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was detected in chatchat-space Langchain-Chatchat up to 0.3.1.3. This vulnerability affects the function files/list_files/retrieve_file/retrieve_file_content/delete_file of the file libs/chatchat-server/chatchat/server/api_server/openai_routes.py of the component Compatible File Service. The manipulation results in missing authentication. The attacker must have access to the local network to execute the attack. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability has been found in chatchat-space Langchain-Chatchat up to 0.3.1.3. Impacted is the function files of the file libs/chatchat-server/chatchat/server/api_server/openai_routes.py of the component OpenAI-Compatible File Upload API. Such manipulation of the argument file.filename leads to time-of-check time-of-use. Access to the local network is required for this attack to succeed. The attack requires a high level of complexity. The exploitability is considered difficult. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.

A hidden console command is vulnerable to command injection<br /> flaw when control characters are passed to its second argument. <br /> <br /> A third party researcher Eugene Lim had discovered vulnerability<br /> in the way console command passes to a popen function call. Attackers with<br /> authenticated access to SSH console of Crestron devices may use to run<br /> underlying OS commands.

In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, inadequate path normalization in the Submodel HTTP API allows an unauthenticated remote attacker to perform a path traversal attack. By supplying a maliciously crafted fileName parameter during a file upload operation, an attacker can bypass intended storage boundaries and write arbitrary files to any location on the host filesystem accessible by the Java process. This can lead to Remote Code Execution (RCE) and complete system compromise.

In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, the Operation Delegation feature fails to validate the destination URI of delegated requests. An unauthenticated remote attacker can exploit this design flaw to force the BaSyx server to execute blind HTTP POST requests to arbitrary internal or external targets. This allows an attacker to bypass network segmentation and pivot into isolated internal IT/OT infrastructure or target Cloud Metadata services (IMDS).

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14.<br /> `django.middleware.cache.UpdateCacheMiddleware` erroneously caches requests where the `Vary` header contained an asterisk (`&amp;#39;*&amp;#39;`). This can lead to private data being stored and served.<br /> Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.<br /> Django would like to thank Ahmad Sadeddin for reporting this issue.

An issue was discovered in 6.0 before 6.0.5 and 5.2 before 5.2.14.<br /> ASGI requests with a missing or understated `Content-Length` header can bypass the `FILE_UPLOAD_MAX_MEMORY_SIZE` limit, potentially loading large files into memory and causing service degradation.<br /> <br /> As a reminder, Django expects a limit to be configured at the web server level rather than solely relying on `FILE_UPLOAD_MAX_MEMORY_SIZE`.<br /> Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.<br /> Django would like to thank Kyle Agronick for reporting this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()<br /> <br /> There&amp;#39;s issue as follows:<br /> ...<br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): error count since last fsck: 1<br /> EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760<br /> EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760<br /> ...<br /> <br /> According to the log analysis, blocks are always requested from the<br /> corrupted block group. This may happen as follows:<br /> ext4_mb_find_by_goal<br /> ext4_mb_load_buddy<br /> ext4_mb_load_buddy_gfp<br /> ext4_mb_init_cache<br /> ext4_read_block_bitmap_nowait<br /> ext4_wait_block_bitmap<br /> ext4_validate_block_bitmap<br /> if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))<br /> return -EFSCORRUPTED; // There&amp;#39;s no logs.<br /> if (err)<br /> return err; // Will return error<br /> ext4_lock_group(ac-&gt;ac_sb, group);<br /> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info))) // Unreachable<br /> goto out;<br /> <br /> After commit 9008a58e5dce ("ext4: make the bitmap read routines return<br /> real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group<br /> as corrupt on block bitmap error") is no real solution for allocating<br /> blocks from corrupted block groups. This is because if<br /> &amp;#39;EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info)&amp;#39; is true, then<br /> &amp;#39;ext4_mb_load_buddy()&amp;#39; may return an error. This means that the block<br /> allocation will fail.<br /> Therefore, check block group if corrupted when ext4_mb_load_buddy()<br /> returns error.