Authenticated OS command injection in the myVesta hosting control panel lets a low-privileged user inject arbitrary shell commands through the v_ftp_user parameter during FTP-account deletion, escalating to full command execution as the admin user and takeover of the panel. Publicly available exploit code exists (documented by ProjectBlack/PRJBLK) and a vendor fix commit has been published, though no CISA KEV listing or EPSS data is provided. Because a scope change moves the attacker from a low-privilege panel account to admin-level command execution, this is a high-impact privilege-escalation-to-RCE path.
PHP object injection in kirilkirkov's Ecommerce-CodeIgniter-Bootstrap allows remote unauthenticated attackers to pass attacker-controlled data into the getCartItems() function of application/libraries/ShoppingCart.php, which deserializes the shopping_cart argument (CWE-502). Depending on available gadget chains in the CodeIgniter application, this can lead to code execution or denial of service. Publicly available exploit code exists (VulDB, GHSA-9g5q-g6m3-v5cr), but there is no public exploit identified as being used in active attacks and the item is not in CISA KEV; EPSS was not provided.
Arbitrary code execution bypass in Trail of Bits fickling (versions ≤ 0.1.10) allows attackers to craft malicious pickle files that the tool's check_safety() gate rates LIKELY_SAFE with zero findings. Because the standard-library modules _posixsubprocess, site, and atexit are missing from the UNSAFE_IMPORTS denylist in fickle.py, payloads invoking _posixsubprocess.fork_exec, site.execsitecustomize, or atexit._run_exitfuncs pass the scanner and are then deserialized and executed by fickling.load(), which chains check_safety() into pickle.loads() as its security gate. No public exploit has been identified at time of analysis, and no EPSS or KEV signals are present in the input, but the advisory documents the exact bypass primitives.
Arbitrary command execution in the n8n workflow automation platform lets authenticated users abuse the built-in Execute Command node to run OS commands directly on the host running n8n. Any user with workflow-editing access or stolen credentials can leverage this by-design node to exfiltrate data, disrupt the service, or fully compromise the underlying host, and CWE-284 (Improper Access Control) reflects that command execution is not restricted to trusted operators. Reported by VulnCheck; no public exploit identified at time of analysis and the flaw is not listed in CISA KEV.
Local privilege escalation in Unity Parsec for Windows (all builds through v2026-05-04.0) lets an unprivileged local user coerce an instance of parsecd.exe to run as NT AUTHORITY\SYSTEM while honoring a user-controlled AppData environment variable, allowing the attacker to redirect the privileged process to resources under their control and gain SYSTEM. The flaw is a CWE-648 misuse of privileged APIs; publicly available exploit code exists (a dedicated CVE GitHub repository and a researcher write-up), and it is fixed in Parsec for Windows 150-104a. It is not listed in CISA KEV and no EPSS score was supplied, so there is no evidence of widespread active exploitation.
Privilege escalation and remote code execution in the HestiaCP control panel allows an authenticated low-privilege user to abuse the panel's cronjob feature, which invokes HestiaCP management scripts via passwordless sudo, to run arbitrary commands and seize administrator accounts and the underlying webserver. Because the cronjob editor lets an ordinary panel user schedule execution of privileged v-scripts, the flaw yields a straight path from a normal hosting account to full host compromise. A detailed public write-up (projectblack.io) documents the exploitation technique, though it is not listed in CISA KEV.
Path traversal in Apache Airflow's Google provider (apache-airflow-providers-google before 22.2.1) lets a principal with write access to a source GCS bucket overwrite arbitrary files on the SFTP server (GCSToSFTPOperator) or the worker host (GCSTimeSpanFileTransformOperator) by crafting a GCS object name containing `..` segments. Because the bucket writer is frequently a lower-trust party than the DAG author (partner uploads, ingest-only service accounts, public-data buckets), exploitation crosses a trust boundary that operators may not have modeled. No public exploit is identified at time of analysis, and CISA SSVC rates exploitation as none, so this is a real but non-default, targeted-risk integrity flaw rather than a mass-exploitable one.
Login CSRF via a missing OAuth 2.0 state parameter in Dancer2::Plugin::Auth::OAuth::Provider (all versions before 0.23) allows a remote, unauthenticated attacker to associate their own OAuth provider identity and access token with a victim's application session, potentially achieving persistent account takeover. The plugin's authentication_url method never generates a state value, and the callback handler never validates one, leaving the entire authorization flow unbound to the session that initiated it. No public exploit code or active exploitation (CISA KEV) has been identified, but the attack concept is well-understood and described in RFC 6749 §10.12 as a known threat to any OAuth 2.0 implementation omitting state binding.
Login cross-site request forgery in Plack::Middleware::OAuth through 0.10 (Perl/PSGI OAuth login middleware) lets an unauthenticated remote attacker bind their own provider identity to a victim's session because the OAuth 2.0 flow omits the anti-CSRF state parameter and never verifies that a callback belongs to the session that initiated the flow. With victim interaction (clicking an attacker-supplied callback URL), the attacker's provider account and access token become associated with the victim's session, and where the app persists this as an account link the attacker retains ongoing access to the victim's account. There is no public exploit identified at time of analysis; EPSS is low (0.13%) and it is not in CISA KEV, but an upstream fix exists in PR #13.
Arbitrary code execution in the NLTK Python library (nltk/nltk 3.9.3 and earlier) allows an attacker to run untrusted Java code when a victim loads a malicious JAR through five Stanford interface wrappers (StanfordPOSTagger, StanfordNERTagger, StanfordParser, StanfordDependencyParser, StanfordNeuralDependencyParser). These classes pass a user-controllable JAR path to an internal java() helper that calls subprocess.Popen() with no SHA256 integrity check, so a substituted or poisoned JAR executes with the user's privileges. This is a regression of CVE-2026-0848, whose SHA256 verification fix was applied only to StanfordSegmenter and never propagated to these five classes; no public exploit is identified at time of analysis, though a huntr bounty report exists.
Detection bypass in picklescan before 0.0.30 lets a crafted pickle smuggle the asyncio.unix_events._UnixSubprocessTransport._start built-in past the scanner's malicious-opcode checks, so a model or pickle that picklescan reports as safe actually executes arbitrary OS commands when a victim deserializes it. Because picklescan is a security scanner used to vet untrusted ML artifacts (e.g. in AI model supply chains), this false-negative turns a trusted safety gate into a blind spot. No public exploit identified at time of analysis and it is not on CISA KEV, but the technique is fully described in the VulnCheck advisory.
Safety-check bypass in picklescan before 0.0.28 allows attackers to smuggle malicious pickle files past the scanner by abusing torch.utils.data.datapipes.utils.decoder.basichandlers as a reduce gadget, so a payload the tool reports as clean still executes arbitrary code when the victim deserializes it. Because picklescan is a defensive scanner used to vet untrusted ML models (notably in Hugging Face workflows), this blind spot converts a trusted safety gate into a false sense of security. No public exploit identified at time of analysis, and it is not on CISA KEV; CVSS 4.0 base score is 7.6.
Security-scanner detection bypass in picklescan before 0.0.34 lets attackers slip malicious pickle files past its checks by invoking _operator.attrgetter inside a reduce method, so a file the scanner reports as clean still executes arbitrary code when pickle.load() deserializes it. The flaw affects ML/AI supply-chain pipelines that rely on picklescan to vet untrusted model files. No public exploit identified at time of analysis; the issue was reported by VulnCheck and fixed in 0.0.34.
Security-scanner evasion in picklescan before 0.0.28 lets attackers slip malicious pickle files past its safety checks by abusing the torch.utils.bottleneck.__main__.run_cprofile call, which the scanner's blocklist does not recognize as dangerous. Any ML pipeline or platform that relies on picklescan to vet untrusted models will therefore approve a weaponized file, and the embedded code runs with arbitrary execution when the victim deserializes it. No public exploit identified at time of analysis; not listed in CISA KEV, but VulnCheck published a dedicated advisory and the technique is fully documented.
Security-scanner evasion in picklescan before 0.0.33 lets attackers smuggle malicious pickle files past its detection engine by abusing the numpy.f2py.crackfortran.param_eval function inside a pickle reduce method, so a payload the scanner declares safe still triggers arbitrary code execution when the application deserializes it. This defeats the exact protection picklescan exists to provide, endangering ML pipelines that rely on it to vet untrusted model/pickle files (e.g., Hugging Face-style workflows). No public exploit is identified at time of analysis and it is not in CISA KEV, though VulnCheck published an advisory.
Detection bypass in picklescan before 0.0.33 lets attackers slip malicious pickle files past its security scanner by using operator.methodcaller, a callable the scanner's blocklist did not recognize. Any ML pipeline, model hub, or workflow that trusts picklescan to vet untrusted pickle/model files is affected, because a crafted payload will be marked safe yet execute arbitrary code the moment the file is deserialized. No public exploit identified at time of analysis and the flaw is not in CISA KEV, but the bypass technique is straightforward and the issue is tagged RCE by the reporting source (VulnCheck).
Detection bypass in picklescan before 0.0.29 lets attackers slip malicious pickle payloads past the scanner by abusing lib2to3.pgen2.grammar.Grammar.loads inside a pickle reduce method, resulting in remote code execution when the file is later deserialized with pickle.load(). Because picklescan is trusted as a safety gate for machine-learning model files, a bypass converts a 'scanned and clean' verdict into silent arbitrary code execution. No public exploit has been identified at time of analysis and the flaw is not listed in CISA KEV, though the technique is concretely described in the VulnCheck advisory.
Malicious-pickle detection bypass in picklescan before 0.0.30 allows attackers to smuggle undetected remote code execution payloads past the scanner by abusing the torch.utils.bottleneck.__main__.run_autograd_prof gadget, which was absent from picklescan's dangerous-import blocklist. Because picklescan is used as a security gate to vet untrusted ML model files, a false-negative here means a crafted model passes as safe and executes arbitrary code when subsequently deserialized. Reported by VulnCheck via GHSA-4whj-rm5r-c2v8; no public exploit identified at time of analysis, and it is not on CISA KEV.
Malicious pickle detection bypass in picklescan before 0.0.30 lets attackers hide code that runs during pickle.load, because the scanner does not flag the idlelib.run.Executive.runcode primitive used in a reduce method. Since picklescan is a security tool relied upon to vet PyTorch/ML model files, this bypass turns a trusted safety check into a false 'clean' verdict, enabling remote code execution and supply-chain attacks against anyone loading an attacker-supplied model. Reported by VulnCheck; no public exploit identified at time of analysis and not listed in CISA KEV.
Security-scanner bypass in Picklescan before 0.0.33 lets attackers smuggle arbitrary-code-execution payloads past its safety checks by abusing the numpy.f2py.crackfortran.getlincoef gadget inside a pickle __reduce__ method, which the scanner fails to flag as dangerous. Because Picklescan is used to vet shared machine-learning model files, a malicious pickle passes as 'clean' and then executes attacker-controlled Python when the trusting downstream consumer deserializes it. No public exploit is identified at time of analysis, and it is not listed in CISA KEV; the CVSS 4.0 score is 7.6 and the attack depends on a victim actually loading the file.
Malicious code execution via scanner bypass affects picklescan before 0.0.34, a security tool used to vet pickle files for unsafe deserialization before loading ML model artifacts. The scanner fails to flag the _operator.methodcaller built-in, so an attacker can craft a pickle that passes picklescan's malware check yet executes arbitrary code the moment a victim calls pickle.load(). No public exploit has been identified at time of analysis, and the flaw is not on CISA KEV; the fix landed in version 0.0.34.
Malicious-pickle detection bypass in picklescan before 0.0.33 lets attackers smuggle arbitrary code past the scanner by abusing numpy.f2py.crackfortran functions that call eval() on attacker-controlled strings. Because picklescan is itself the security tool meant to vet untrusted pickle/model files, this evasion causes a weaponized pickle to be marked safe, so the embedded code executes when the file is later deserialized. Reported by VulnCheck with a CVSS 4.0 score of 7.6; no public exploit identified at time of analysis and it is not in CISA KEV.
Security-control bypass in picklescan before 0.0.29 lets attackers craft malicious pickle files that evade its malware scanner by hiding a reduce-method payload behind Python's idlelib.calltip.get_entity function, so a file the scanner reports as clean executes arbitrary commands when a victim deserializes it. Affected are ML/AI pipelines and users relying on picklescan to vet untrusted model artifacts. No public exploit or CISA KEV listing is identified at time of analysis, though the technique and a GitHub Security Advisory (GHSA-9xph-j2h6-g47v) are documented by VulnCheck.
Security scanner bypass in picklescan before 0.0.28 allows attackers to smuggle arbitrary code past the tool's malware detection by abusing torch.fx.experimental.symbolic_shapes.ShapeEnv.evaluate_guards_expression, which is not on picklescan's dangerous-globals blocklist. Because picklescan is a defensive tool used to vet untrusted ML pickle files (notably in the Hugging Face ecosystem), a bypass causes a malicious model to be marked safe and then execute remote code when the victim deserializes it. There is no public exploit identified at time of analysis and this CVE is not listed in CISA KEV, but the technique is fully described in the VulnCheck advisory.
Detection bypass in picklescan before 0.0.28 lets attackers smuggle malicious pickle files past the scanner by abusing the torch._dynamo.guards.GuardBuilder.get gadget inside a __reduce__ method, so a file that picklescan reports as safe still executes arbitrary commands when deserialized (e.g. via torch.load). This undermines the security control that ML pipelines and model hubs rely on to vet untrusted model artifacts, turning a trusted-scan result into a false negative. Reported by VulnCheck with a vendor GHSA advisory; no public exploit identified at time of analysis and it is not listed in CISA KEV.
Detection bypass in picklescan before 0.0.30 lets attackers smuggle malicious pickle files past the scanner by abusing lib2to3.pgen2.pgen.ParserGenerator.make_label as a reduce callable, so a file that picklescan clears still runs arbitrary commands when downstream code calls pickle.load(). picklescan is the security control itself - a static scanner used to vet ML model artifacts - so this weakness undermines the exact protection teams rely on to catch unsafe pickles. No public exploit identified at time of analysis and it is not on CISA KEV, but the technique is documented in VulnCheck and vendor advisories.
Cross-tenant consent leakage in WSO2 Identity Server and WSO2 API Manager multi-tenant deployments lets a SaaS application in one tenant inherit OAuth/OpenID consent that a user granted to a same-named application in a different tenant, breaking tenant isolation of authorization scopes. Because matching is done by application name rather than a tenant-scoped identifier, an application in attacker-controlled tenant B can read and modify a victim's data in tenant A without that user's explicit authorization. No active exploitation is reported (not in CISA KEV, EPSS 0.15%/4th percentile) and no public exploit is identified, but a vendor patch is available.