ghsa

# SQL Injection in CustomerTransformerController ## Summary An **error-based SQL Injection vulnerability** was identified in the `CustomerTransformerController` within the CoreShop admin panel. The affected endpoint improperly interpolates user-supplied input into a SQL query, leading to database error disclosure and potential data extraction. This issue is classified as **MEDIUM severity**, as it allows SQL execution in an authenticated admin context. --- ## Details The vulnerability exists in the company name duplication check endpoint: ``` /admin/coreshop/customer-company-modifier/duplication-name-check?value= ``` Source code analysis indicates that user input is directly embedded into a SQL condition without parameterization. **Vulnerable file:** ``` /app/repos/coreshop/src/CoreShop/Bundle/CustomerBundle/Controller/CustomerTransformerController.php ``` **Vulnerable code pattern:** ```php sprintf('name LIKE "%%%s%%"', (string) $value) ``` The `$value` parameter is fully u...

# Summary vLLM loads Hugging Face `auto_map` dynamic modules during model resolution **without gating on `trust_remote_code`**, allowing attacker-controlled Python code in a model repo/path to execute at server startup. --- # Impact An attacker who can influence the model repo/path (local directory or remote Hugging Face repo) can achieve **arbitrary code execution** on the vLLM host during model load. This happens **before any request handling** and does **not require API access**. --- # Affected Versions All versions where `vllm/model_executor/models/registry.py` resolves `auto_map` entries with `try_get_class_from_dynamic_module` **without checking `trust_remote_code`** (at least current `main`). --- # Details During model resolution, vLLM unconditionally iterates `auto_map` entries from the model config and calls `try_get_class_from_dynamic_module`, which delegates to Transformers’ `get_class_from_dynamic_module` and **executes the module code**. This occurs even when ...

## Description The extension extends TYPO3’s FileSpool component, which was vulnerable to Insecure Deserialization prior to [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004). Since the related fix is overwritten by the extension, using the extension with a patched TYPO3 core version still allows for Insecure Deserialization, because the affected vulnerable code was extracted from TYPO3 core to the extension. More information about this vulnerability can be found in the related TYPO3 Core Security Advisory [TYPO3-CORE-SA-2026-004](https://typo3.org/security/advisory/typo3-core-sa-2026-004).

Improper input handling in the JSON deserialization component can lead to arbitrary JavaScript code execution. The vulnerability can be exploited via overriding constant value and error deserialization, which allows indirect access to unsafe JS evaluation. This requires at least the ability to perform 4 separate requests on the same function and partial knowledge of how the serialized data is used during later runtime processing. This vulnerability affects the `fromJSON` and `fromCrossJSON` functions in a client-to-server transmission scenario. No known workarounds or mitigations are known, so please upgrade to the patched version.

Due to improper input validation, a malicious object key can lead to prototype pollution during JSON deserialization. This affects only JSON deserialization functionality. As there is no known workaround, please upgrade to the latest version.

### Impact This vulnerability affects Laravel Reverb versions prior to v1.7.0 when horizontal scaling is enabled (`REVERB_SCALING_ENABLED=true`). The exploitability of this vulnerability is increased because Redis servers are commonly deployed without authentication. With horizontal scaling enabled, Reverb servers communicate via Redis PubSub. Reverb previously passed data from the Redis channel directly into PHP’s `unserialize()` function without restricting which classes could be instantiated. **Risk:** Remote Code Execution (RCE) ### Patches This vulnerability is fixed in Laravel Reverb v1.7.0. Update your dependency to `laravel/reverb: ^1.7.0` immediately. ### Workarounds If you cannot upgrade to v1.7.0, you should apply the following mitigations: * Redis Security: Require a strong password for Redis access and ensure the service is only accessible via a private network or local loopback. * Disable Scaling: If your environment uses only one Reverb node, set `REVERB_SCALING_...

Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components.  Only deployments that meet all of the following criteria are impacted by this vulnerability: * Use of Solr's "RuleBasedAuthorizationPlugin" * A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles" * A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read". * A RuleBasedAuthorizationPlugin permission list that doesn't define the "all" pre-defined permission * A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening pro...

The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.  Solr deployments are subject to this vulnerability if they meet the following criteria: * Solr is running in its "standalone" mode. * Solr's "allowPath" setting is being used to restrict file access to certain directories. * Solr's "create core" API is exposed and accessible to untrusted users.  This can happen if Solr's RuleBasedAuthorizationPlugin https://solr.ap...

A flaw was found in the Keycloak Admin REST API. This vulnerability allows the exposure of backend schema and rules, potentially leading to targeted attacks or privilege escalation via improper access control.

A flaw was found in the keycloak-services component of Keycloak. This vulnerability allows the issuance of access and refresh tokens for disabled users, leading to unauthorized use of previously revoked privileges, via a business logic vulnerability in the Token Exchange implementation when a privileged client invokes the token exchange flow.