An issue was discovered on G-Net Dashcam BB GONX devices. A Public Domain name is Used for the Internal Domain Name. It uses an unregistered public domain name as an internal domain, creating a security risk. This domain was not owned by GNET originally, allowing an attacker to register it and potentially intercept sensitive device traffic (it has since been registered by the vulnerability discoverer). If the dashcam or related services attempt to resolve this domain over the public Internet instead of locally, it could lead to data exfiltration or man-in-the-middle attacks.
Search vulnerabilities
vLLM using built-in hash() from Python 3.12 leads to predictable hash collisions in vLLM prefix cache
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Maliciously constructed statements can lead to hash collisions, resulting in cache reuse, which can interfere with subsequent responses and cause unintended behavior. Prefix caching makes use of Python's built-in hash() function. As of Python 3.12, the behavior of hash(None) has changed to be a predictable constant value. This makes it more feasible that someone could try exploit hash collisions. The impact of a collision would be using cache that was generated using different content. Given knowledge of prompts in use and predictable hashing behavior, someone could intentionally populate the cache using a prompt known to collide with another prompt in use. This issue has been addressed in version 0.7.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
vLLM Allows Remote Code Execution via Mooncake Integration
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. When vLLM is configured to use Mooncake, unsafe deserialization exposed directly over ZMQ/TCP on all network interfaces will allow attackers to execute remote code on distributed hosts. This is a remote code execution vulnerability impacting any deployments using Mooncake to distribute KV across distributed hosts. This vulnerability is fixed in 0.8.0.
vLLM Tool Schema allows DoS via Malformed pattern and type Fields
vLLM is an inference and serving engine for large language models (LLMs). In version 0.8.0 up to but excluding 0.9.0, the vLLM backend used with the /v1/chat/completions OpenAPI endpoint fails to validate unexpected or malformed input in the "pattern" and "type" fields when the tools functionality is invoked. These inputs are not validated before being compiled or parsed, causing a crash of the inference worker with a single request. The worker will remain down until it is restarted. Version 0.9.0 fixes the issue.
REDAXO allows Authenticated Reflected Cross Site Scripting - packages installation
REDAXO is a PHP-based CMS. In Redaxo from 5.0.0 through 5.18.2, the rex-api-result parameter is vulnerable to Reflected cross-site scripting (XSS) on the page of AddOns. This vulnerability is fixed in 5.18.3.
REDAXO allows Arbitrary File Upload in the mediapool page
REDAXO is a PHP-based CMS. In Redaxo before 5.18.3, the mediapool/media page is vulnerable to arbitrary file upload. This vulnerability is fixed in 5.18.3.
Qualitor up to 8.24 is vulnerable to Remote Code Execution (RCE) via Arbitrary File Upload in checkAcesso.php.
Qualitor v8.24 was discovered to contain a remote code execution (RCE) vulnerability via the gridValoresPopHidden parameter.
Qualitor v8.24 was discovered to contain a Server-Side Request Forgery (SSRF) via the component /request/viewValidacao.php.
Apache Ozone: Improper authentication when generating S3 secrets
Improper authentication of an HTTP endpoint in the S3 Gateway of Apache Ozone 1.4.0 allows any authenticated Kerberos user to revoke and regenerate the S3 secrets of any other user. This is only possible if: * ozone.s3g.secret.http.enabled is set to true. The default value of this configuration is false. * The user configured in ozone.s3g.kerberos.principal is also configured in ozone.s3.administrators or ozone.administrators. Users are recommended to upgrade to Apache Ozone version 1.4.1 which disables the affected endpoint.
Apache Answer: Predictable Authorization Token Using UUIDv1
Inadequate Encryption Strength vulnerability in Apache Answer. This issue affects Apache Answer: through 1.4.0. The ids generated using the UUID v1 version are to some extent not secure enough. It can cause the generated token to be predictable. Users are recommended to upgrade to version 1.4.1, which fixes the issue.
Apache CloudStack: Uploaded and registered templates and volumes can be used to abuse KVM-based infrastructure
Account users in Apache CloudStack by default are allowed to upload and register templates for deploying instances and volumes for attaching them as data disks to their existing instances. Due to missing validation checks for KVM-compatible templates or volumes in CloudStack 4.0.0 through 4.18.2.3 and 4.19.0.0 through 4.19.1.1, an attacker that can upload or register templates and volumes, can use them to deploy malicious instances or attach uploaded volumes to their existing instances on KVM-based environments and exploit this to gain access to the host filesystems that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of KVM-based infrastructure managed by CloudStack. Users are recommended to upgrade to Apache CloudStack 4.18.2.4 or 4.19.1.2, or later, which addresses this issue. Additionally, all user-uploaded or registered KVM-compatible templates and volumes can be scanned and checked that they are flat files that should not be using any additional or unnecessary features. For example, operators can run this on their secondary storage(s) and inspect output. An empty output for the disk being validated means it has no references to the host filesystems; on the other hand, if the output for the disk being validated is not empty, it might indicate a compromised disk. for file in $(find /path/to/storage/ -type f -regex [a-f0-9\-]*.*); do echo "Retrieving file [$file] info. If the output is not empty, that might indicate a compromised disk; check it carefully."; qemu-img info -U $file | grep file: ; printf "\n\n"; done The command can also be run for the file-based primary storages; however, bear in mind that (i) volumes created from templates will have references for the templates at first and (ii) volumes can be consolidated while migrating, losing their references to the templates. Therefore, the command execution for the primary storages can show both false positives and false negatives. For checking the whole template/volume features of each disk, operators can run the following command: for file in $(find /path/to/storage/ -type f -regex [a-f0-9\-]*.*); do echo "Retrieving file [$file] info."; qemu-img info -U $file; printf "\n\n"; done
Apache Solr: ConfigSets created during a backup restore command are trusted implicitly
Insecure Default Initialization of Resource vulnerability in Apache Solr. New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the "trusted" metadata. ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to "trusted" ConfigSets that may not have been created with an Authenticated request. "trusted" ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized. This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization. Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise.
Apache Solr: Authentication bypass possible using a fake URL Path ending
Improper Authentication vulnerability in Apache Solr. Solr instances using the PKIAuthenticationPlugin, which is enabled by default when Solr Authentication is used, are vulnerable to Authentication bypass. A fake ending at the end of any Solr API URL path, will allow requests to skip Authentication while maintaining the API contract with the original URL Path. This fake ending looks like an unprotected API path, however it is stripped off internally after authentication but before API routing. This issue affects Apache Solr: from 5.3.0 before 8.11.4, from 9.0.0 before 9.7.0. Users are recommended to upgrade to version 9.7.0, or 8.11.4, which fix the issue.
Apache HertzBeat: RCE by snakeYaml deser load malicious xml
SnakeYaml Deser Load Malicious xml rce vulnerability in Apache HertzBeat (incubating). This vulnerability can only be exploited by authorized attackers. This issue affects Apache HertzBeat (incubating): before 1.6.0. Users are recommended to upgrade to version 1.6.0, which fixes the issue.
Apache HTTP Server: source code disclosure with handlers configured via AddType
A regression in the core of Apache HTTP Server 2.4.60 ignores some use of the legacy content-type based configuration of handlers. "AddType" and similar configuration, under some circumstances where files are requested indirectly, result in source code disclosure of local content. For example, PHP scripts may be served instead of interpreted. Users are recommended to upgrade to version 2.4.61, which fixes this issue.
Apache HTTP Server proxy encoding problem
Encoding problem in mod_proxy in Apache HTTP Server 2.4.59 and earlier allows request URLs with incorrect encoding to be sent to backend services, potentially bypassing authentication via crafted requests. Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Discord WINSTA.dll uncontrolled search path
A vulnerability, which was classified as critical, has been found in Discord 1.0.9188 on Windows. Affected by this issue is some unknown functionality in the library WINSTA.dll. The manipulation leads to uncontrolled search path. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
Carlo Gavazzi EOS Box Hard-Coded Credentials
The Carlo Gavazzi EOS-Box stores hard-coded passwords in the PHP file of the device. By using the hard-coded passwords, attackers can log into the device with administrative privileges. This could allow the attacker to have unauthorized access.
Carlo Gavazzi EOS Box SQL Injection
The Carlo Gavazzi EOS-Box does not check the validity of the data before executing queries. By accessing the SQL table of certain pages that do not require authentication, attackers can leak information from the device. This could allow the attacker to compromise confidentiality.