#rce

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Friday added a critical security flaw affecting Broadcom VMware vCenter Server that was patched in June 2024 to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation in the wild. The vulnerability in question is CVE-2024-37079 (CVSS score: 9.8), which refers to a heap overflow in the

### Impact A PyYAML-related Remote Code Execution (RCE) vulnerability, namely CVE-2020-14343, is exposed in `docling-core >=2.21.0, <2.48.4` and, specifically only if the application uses `pyyaml < 5.4` and invokes `docling_core.types.doc.DoclingDocument.load_from_yaml()` passing it untrusted YAML data. ### Patches The vulnerability has been patched in `docling-core` version **2.48.4**. The fix mitigates the issue by switching `PyYAML` deserialization from `yaml.FullLoader` to `yaml.SafeLoader`, ensuring that untrusted data cannot trigger code execution. ### Workarounds Users who cannot immediately upgrade `docling-core` can alternatively ensure that the installed version of `PyYAML` is **5.4 or greater**, which supposedly patches CVE-2020-14343. ### References * GitHub Issue: #482 * Upstream Advisory: CVE-2020-14343 * Fix Release: [v2.48.4](https://github.com/docling-project/docling-core/releases/tag/v2.48.4)

Most of this week’s threats didn’t rely on new tricks. They relied on familiar systems behaving exactly as designed, just in the wrong hands. Ordinary files, routine services, and trusted workflows were enough to open doors without forcing them. What stands out is how little friction attackers now need. Some activity focused on quiet reach and coverage, others on timing and reuse. The emphasis

A new security flaw in SmarterTools SmarterMail email software has come under active exploitation in the wild, two days after the release of a patch. The vulnerability, which currently does not have a CVE identifier, is tracked by watchTowr Labs as WT-2026-0001. It was patched by SmarterTools on January 15, 2026, with Build 9511, following responsible disclosure by the exposure management

A critical deserialization vulnerability exists in Tendenci Helpdesk module (NOTE, by default, Helpdesk is NOT enabled), affecting the version 15.3.11 and earlier. This vulnerability allows remote code execution (RCE) by an authenticated user with staff security level due to using Python's pickle module on the helpdesk /reports/. The damage is contained to the user that your Tendenci application runs. **Key Finding:** The original CVE-2020-14942 was incompletely patched. While `ticket_list()` was fixed to use safe JSON deserialization, the `run_report()` function still uses unsafe `pickle.loads()`. **Permission Scoping:** The impact is limited to the permissions of the user running the application, typically www-data, which generally lacks write (except for upload directories) and execute permissions. ## Vulnerability Details ### Affected Version - **Version:** Tendenci 15.3.11 and earlier (all versions since incomplete CVE-2020-14942 patch) - **Component:** `tendenci/apps/helpdesk...

# 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 ...

Zoom and GitLab have released security updates to resolve a number of security vulnerabilities that could result in denial-of-service (DoS) and remote code execution. The most severe of the lot is a critical security flaw impacting Zoom Node Multimedia Routers (MMRs) that could permit a meeting participant to conduct remote code execution attacks. The vulnerability, tracked as CVE-2026-22844

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.

### 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_...

### Summary A vulnerability was discovered during a manual security audit of the AlchemyCMS source code. The application uses the Ruby `eval()` function to dynamically execute a string provided by the `resource_handler.engine_name` attribute in `Alchemy::ResourcesHelper#resource_url_proxy`. ### Details The vulnerability exists in `app/helpers/alchemy/resources_helper.rb` at line 28. The code explicitly bypasses security linting with `# rubocop:disable Security/Eval`, indicating that the use of a dangerous function was known but not properly mitigated. Since `engine_name` is sourced from module definitions that can be influenced by administrative configurations, it allows an authenticated attacker to escape the Ruby sandbox and execute arbitrary system commands on the host OS. But, for this attack to be possible local file access to the alchemy project or the source on a remote server is necessary in order to manipulate the module config file, though. ### PoC (Proof of Concept) The...