Python
Monthly
virtualenv versions prior to 21.7.12 cache and seed pip/setuptools wheels without verifying their bytes, so an attacker who controls the wheel delivery path can substitute a different wheel under the requested distribution, version, and filename and have it injected into every environment virtualenv subsequently creates. The flaw is exploitable unauthenticated but requires an active man-in-the-middle position, a compromised index, or a stale/poisoned mirror, and requires a user to actually create or seed a virtual environment. No public exploit code was identified at time of analysis, and the digest check is intentionally skipped whenever PIP_INDEX_URL, PIP_EXTRA_INDEX_URL, or PIP_INDEX points at a custom index - meaning custom-index users remain unverified even after upgrading.
Command injection in the bash, zsh, and fish activation scripts generated by virtualenv releases prior to 21.7.13 lets a crafted virtual environment path or interpreter Tcl/Tk library path execute arbitrary commands with the privileges of any user who sources the activate script. The root cause is double quoting: values already escaped by shlex.quote are embedded inside an additional quoted context, so the surplus quotes terminate the data-only quoted run and leave shell metacharacters parsed as commands - reaching __VIRTUAL_ENV__ in bash/zsh when a relocated environment's recorded directory is absent, and __TCL_LIBRARY__/__TK_LIBRARY__ in fish. Exploitation requires attacker control of the affected path string plus the victim sourcing the script (CVSS 3.1 score 7.8, AV:L/AC:L/PR:N/UI:R, CWE-78 OS command injection); no public exploit identified at time of analysis, and the flaw is fixed in virtualenv 21.7.13 per PyPA advisory GHSA-p58f-9548-mpm2.
Unauthenticated remote code execution in Open GenAI Stack (ogx-ai, 2026-06-11 build) lets any attacker who can submit a prompt to an affected endpoint execute arbitrary server-side code, because prompt content is rendered as an unsanitized Jinja2 template (CWE-94, classic server-side template injection). The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8), with no authentication, user-interaction, or non-default-configuration prerequisite, so exploitation reduces to reaching the vulnerable template-rendering path. No public exploit code has been identified at time of analysis, and the widely repeated claim that this stack underpins the Meta AI backend for WhatsApp is unconfirmed by any vendor advisory. Real-world risk is bounded by deployment scope: only systems actually running the vulnerable ogx-ai prompt-to-template path are exposed.
Denial of service in SGLang 0.5.20 and earlier: the /generate HTTP endpoint in prefill/decode (PD) disaggregation deployments using the Mooncake KV transfer backend does not validate duplicate bootstrap_room identifiers, so remote unauthenticated attackers who fire concurrent requests carrying the same bootstrap_room value can crash scheduler processes or stall other users' requests until the transfer times out. The attack is trivial and requires no authentication or user interaction (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, availability-only VA:H), but it only affects the non-default multi-node PD disaggregation configuration with the Mooncake backend; single-node and default deployments are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the impact is purely availability-related with no confidentiality or integrity loss.
Unbounded memory allocation in urllib3 (1.10.3 through 2.7.x) lets a malicious or machine-in-the-middle HTTP server exhaust the memory of a Python client process by streaming an unterminated chunk-size line in a 'Transfer-Encoding: chunked' response. Only clients that consume the response through the streaming path (HTTPResponse.stream() or HTTPResponse.read_chunked()) are affected; the non-streaming .read() path was already bounded to http.client._MAXLINE. Exploitation is unauthenticated (CVSS:4.0 vector PR:N, assessed CVSS:3.1 PR:N) but requires the client to reach an attacker-controlled or intercepted endpoint, so SSRF-prone, proxy, crawler, and webhook-fetching services are the realistic exposure; impact is denial of service only (C:N/I:N/A:H, no RCE), and no public exploit identified at time of analysis.
Certificate validation bypass in urllib3 1.26.0 through 2.7.x allows a man-in-the-middle attacker who can impersonate the configured HTTPS proxy to intercept, observe, or modify traffic forwarded through that proxy, and in some configurations to obtain the target TLS client certificate. The flaw only affects applications that route requests through an HTTPS proxy while also setting target-server TLS options - proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, or CERT_NONE - because those target settings are incorrectly applied to the proxy TLS handshake; in particular, cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place and the mutation persists across reused connections, silently disabling proxy certificate verification. End-to-end target TLS via CONNECT tunneling remains protected, and no public exploit identified at time of analysis; the issue is fixed in urllib3 2.8.0.
Argument injection in Weblate's Mercurial backend lets an authenticated user with project-scoped component.edit permission plant a dash-prefixed repository filename that Mercurial later interprets as a command-line option instead of a literal path, resulting in arbitrary command execution with the privileges of the Weblate service account when the repository is next updated. The issue affects Weblate 4.11.1 through 2026.7.1 and is a residual, incomplete fix for CVE-2022-23915; although it carries a CVSS of 8.5, exploitation requires a Mercurial-backed RESX component using the 'Update RESX files' add-on plus a subsequent repository update, so the realistic attack surface is narrow. A vendor patch is available in Weblate 2026.8, and no public exploit identified at time of analysis.
Memory exhaustion in Nicotine+ versions prior to 3.3.11 allows a remote Soulseek peer running a modified client to crash the victim's machine by sending a zlib-compressed peer message crafted as a decompression bomb. The vulnerable code path decompressed incoming peer messages without any cap on the uncompressed output size, so the client inflates attacker-supplied data until the operating system runs out of available memory. No authentication or user interaction is required beyond the victim being connected to the Soulseek network (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor-published CVSS 4.0 score 8.7); impact is limited to availability, with no data access or code execution, and no public exploit code or CISA KEV entry was identified at time of analysis. Vendor-released patch: 3.3.11.
Deserialization of untrusted data in the GluonTS model-loading component allows arbitrary OS command execution with the privileges of the loading process when a victim loads a crafted serialized model directory in versions before 0.17.0. The flaw is scored 8.4 under CVSS 4.0 (assessed as CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), meaning no authentication is required but exploitation is local and depends on a user actively loading the malicious model artifact; the attacker must first place that artifact in the victim's load path (untrusted model hub, shared directory, or compromised pipeline), and environments that only load self-generated trusted models are not affected. AWS has released a fix in GluonTS 0.17.0 (upstream PR #3304, '[Security] Resolve security issue for torch.load'), and no public exploit code and no confirmed active exploitation were identified at time of analysis; EPSS data was not provided for this CVE.
Improper validation in PyJWT 2.1.0 through 2.14.0 allows an attacker who already holds a stolen sender-constrained (DPoP-bound) access token to replay it without possessing the legitimate holder's private key, because OKPAlgorithm.from_jwk imports an Ed25519/Ed448 private JWK from the d parameter without checking that the public key derived from d matches the declared x. An attacker-supplied JWK that pairs the victim's x with the attacker's own d therefore satisfies RFC 7638 thumbprint binding (cnf.jkt) while all signing operations use the attacker's key. Publicly available exploit code exists (a public gist reproducer), but EPSS is only 0.14% (3rd percentile) and there is no KEV listing - this is a conditional, integration-dependent flaw rather than a default-configuration remote compromise, and standard signature-verification use of PyJWT with trusted server-side keys is not affected.
Denial of service in PyJWT 2.9.0 through 2.13.0: a single malformed RSA JWK embedded in a JWK Set aborts construction of the entire set, causing authentication failures or request-level outages for applications that rely on that key set. The root cause is PyJWKSet's per-key error-skipping logic, which only catches PyJWTError and therefore misses the plain ValueError raised by RSAAlgorithm.from_jwk when an RSA key supplies d/e/n with an incorrect private exponent and omits the CRT parameters. The issue is remotely reachable without authentication or user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N, availability-only), publicly available exploit code exists (no confirmed active exploitation), EPSS is low at 0.35% (26th percentile), and the vendor-released patch is version 2.14.0.
Signature forgery in PyJWT 2.13.0 lets an attacker forge arbitrary JWT claims when an application verifies tokens using both HMAC and asymmetric algorithms and hands a public JWK container (a JWKS document, a bare array, a nested array, or a BOM-prefixed variant) directly to the library as the raw key. Because the version 2.13.0 HMAC key guard only recognizes top-level public JWK objects and misses these container wrappers, public asymmetric key material - which is not secret - is accepted as the HMAC secret, so anyone who knows the target's public key can sign a token with any claims and have it validate. The flaw is an improper-signature-verification issue (CWE-347) rated CVSS 3.1 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) and unauthenticated in the sense that no credentials are needed, but real-world urgency is lower than the headline score: exploitation requires a non-default application design that mixes algorithm families and passes container-form keys, and no public exploit code or confirmed active exploitation was identified at time of analysis. Vendor-released patch: PyJWT 2.14.0.
Token forgery in PyJWT 2.13.x lets unauthenticated remote attackers mint tokens that the library will accept as authentic: when a public JWK is prefixed with a UTF-8 byte-order mark and passed directly as the raw HMAC secret inside a mixed-algorithm verification path, HMACAlgorithm.prepare_key fails to recognize the material as an asymmetric key and uses the publicly known JWK bytes as the shared secret, so anyone who knows the public key can sign arbitrary claims that verify successfully. The flaw carries an assessed CVSS of 7.4 (integrity-only impact, AC:H, PR:N) and per our independent assessment is conditionally scoped: it requires PyJWT 2.13.0 through 2.13.x, an application that permits HMAC alongside asymmetric algorithms, code that hands a raw public JWK to prepare_key instead of loading it via PyJWK/HMACAlgorithm.from_jwk, and BOM-prefixed key material. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; the vendor-released patch is 2.14.0.
Signature forgery in the PyJWT Python library (versions 2.4.0 through 2.13.x) lets a remote, unauthenticated attacker mint forged HMAC tokens whenever an application is misconfigured to accept both HMAC and asymmetric algorithms and passes a DER-encoded public key as the shared verification secret. PyJWT's HMACAlgorithm.prepare_key only rejected PEM- and SSH-formatted asymmetric keys using textual markers, so a DER public key (SubjectPublicKeyInfo, PKCS1, or a DER x509 certificate) slipped through and its public bytes were used directly as the HMAC secret - meaning anyone who knows the public key can sign valid tokens. The flaw is rated CVSS 7.4 with High attack complexity precisely because it requires that specific non-default application configuration; no public exploit code has been identified at time of analysis, and the vendor-released patch is PyJWT 2.14.0.
Signature forgery in PyJWT before 2.14.0 allows an attacker who knows a target's asymmetric public key to forge HMAC-authenticated JWTs when the application mixes HMAC and asymmetric algorithms and passes asymmetric public-key PEM bytes into HMAC verification. The flaw is in is_pem_format in jwt/utils.py, which fails to recognize all PEM formatting variants accepted by the cryptography loader, causing HMACAlgorithm.prepare_key to treat a mutated public-key PEM as an HMAC secret. Exploitation requires a specific non-default deployment pattern-mixed algorithm verification with raw PEM key bytes-and the assessed CVSS vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N; no public exploit identified at time of analysis, and no CISA KEV status was provided.
JWKS trust-boundary bypass in PyJWT's PyJWKClient allows a configured trusted JWKS endpoint that returns an HTTP 3xx redirect to steer the client to an attacker-chosen host, which is then consumed as authoritative key material; the same mechanism can forward caller-supplied request headers such as Authorization to that destination. Only PyJWT 2.13.0 and earlier are affected (fixed in 2.14.0), and exploitation is not unconditional: it requires the application to actually use PyJWKClient for remote JWKS fetching, attacker influence over the trusted endpoint's redirect response, and - for credential leakage - caller-supplied headers passed into the client, or - for forged-JWT acceptance - a mixed-configuration deployment. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; EPSS is low at 0.16% (4th percentile), and CISA SSVC rates Exploitation as 'none' and Automatable as 'no', so the practical risk sits well below the headline 9.1 base score.
Forged HS256 JSON Web Tokens can be accepted as authentic by PyJWT (pip package PyJWT) versions 2.13.0 through 2.13.x when an application verifies tokens through the PyJWK or PyJWKSet path and its trusted JWK Set already contains a symmetric oct entry with an empty key value ({"kty":"oct","k":""}), an unusual precondition typically caused by a missing Base64URL configuration or secret-manager value. Because the PyJWK verification path passes the decoded zero-length key straight to the HMAC check instead of running it through HMACAlgorithm.prepare_key, unauthenticated remote attackers (CVSS PR:N) who know this pre-existing misconfiguration can independently compute HMAC-SHA256(b"", signing_input) and mint valid tokens carrying arbitrary authenticated claims, giving high confidentiality and integrity impact. Public proof-of-concept exploit code exists, but the issue is not in CISA KEV, EPSS is low at 0.18% (6th percentile), and the independent assessment rates attack complexity as High rather than Low, so the headline CVSS 9.1 overstates real-world urgency; the vendor-released patch is version 2.14.0 (commit f91ed44dd65baaf457f4b3353ed35e98a753934c).
Unauthenticated denial of service in the PyJWT Python library (versions 2.0.0a1 through 2.14.0) allows a remote attacker to crash the calling application's authentication handler by supplying a JWT whose payload is valid JSON but nested roughly 20,000 levels deep. The vulnerable code paths - PyJWKClient.get_signing_key_from_jwt(), the documented JWKS verification flow, and any jwt.decode(token, options={"verify_signature": False}) call - parse the attacker-controlled payload with json.loads before any signature check, and a catch clause that handles only ValueError lets RecursionError escape as an undocumented exception (CWE-248), producing an HTTP 500 or dead worker with no credentials, valid signature, user interaction, or JWKS network lookup required. Publicly available exploit code exists (a PoC gist is referenced in the advisory data) and CISA's SSVC assessment rates the issue as automatable with partial technical impact; EPSS is low at 0.29% (20th percentile) and there is no indication of confirmed active exploitation. Impact is confined to availability - no data exposure, integrity loss, or code execution.
Unauthenticated attackers can amplify outbound HTTP traffic from any application that validates JWTs with PyJWT's PyJWKClient against a remote JWKS endpoint, because prior to 2.14.0 an unknown 'kid' in the token header forces a full JWKS refresh on every call with no negative cache or minimum refresh interval. One attacker request produces one outbound JWKS fetch plus full JSON parsing on the victim server, and because the 'kid' is read from the unverified token header, no valid token or authentication is required - even enabling key caching does not help, since a repeated identical unknown 'kid' re-fetches every time. A verified proof-of-concept exists (CISA SSVC records exploitation as 'poc', no CISA KEV listing), so this is treated as publicly available exploit code; EPSS is low (0.35%, 27th percentile). The issue is fixed in 2.14.0, which introduces a 30-second cooldown between forced refreshes.
Signature verification bypass in Authlib 1.7.2 and earlier allows unauthenticated remote attackers to have crafted JWS JSON Serialization payloads accepted as valid, because JsonWebSignature.deserialize_json() returns the payload without checking for a signature or requiring a cryptographic key. The flaw affects applications that use that method to process incoming tokens and then trust the returned payload for authentication, authorization, or integrity decisions; applications using only compact JWS or independently verifying signatures are not exposed. No public exploit code has been identified at time of analysis, and EPSS is low at 0.12% (2nd percentile), but the issue is remotely exploitable with no authentication or user interaction and is assessed as high severity.
Authentication bypass in the LiteLLM proxy lets any party who already holds a valid JWT issued by the configured external identity provider impersonate an existing user - including accounts with proxy_admin privileges - by presenting a token whose unverified email claim matches the victim's address. The JWT authentication flow performs an email-based fallback lookup without validating the email_verified claim, so the attacker inherits the victim's role and can permanently overwrite the victim's stored identity binding, retaining persistent access to administrative endpoints that expose API keys and user management. The attacker must possess a legitimately signed token from the same IdP (CVSS PR:L, AC:H), deployments that do not use JWT/IdP authentication are unaffected, and publicly available exploit code exists; no confirmed in-the-wild exploitation has been reported.
Unauthenticated access to Bluehood's /api/* endpoints in releases before 0.7.1 lets any network attacker who can reach the dashboard HTTP port read Bluetooth tracking data and rewrite application state - the heartbeat URL, prune retention, device groups and per-device notes - whenever the operator has enabled the opt-in auth_enabled setting. The root cause is a missing authorization check: only the HTML page handlers called the session-validation routine, while the settings, devices, groups and /api/device/{mac}/notes handlers performed no check at all, allowing requests carrying no session cookie to succeed (CWE-306, CVSS 3.1 9.1 with PR:N/AC:L). Real-world urgency is tempered by the niche deployment and the fact that the dashboard must be reachable over the network rather than bound to localhost; no public exploit code has been identified at time of analysis and the CVE is not listed in CISA KEV.
Server-side request forgery in fast-mcp-telegram prior to version 30.1 allows an authenticated MCP client (CVSS PR:L) to make the server fetch arbitrary internal HTTP(S) endpoints and receive the response body back as a Telegram file attachment. The send_message and send_message_to_phone tools accept URL lists that the server downloads via httpx.AsyncClient.get, but the _validate_url_security guard only inspects the literal hostname string and never resolves DNS, so any attacker-controlled domain that resolves to a loopback, private, or link-local address passes validation - even with the secure defaults block_private_ips=True and allow_http_urls=False. Because the fetched content is exfiltrated through the Telegram attachment rather than merely observed, this is a full-read SSRF; exploitation requires an authorized MCP session and a resolving hostname (raw private-IP literals remain blocked), and no public exploit code was identified at time of analysis.
Loading a malicious model into Unsloth Zoo 2025.9.9 through 2026.8.13 (as shipped in Unsloth 2025.9.9 through 2026.8.19) lets that model's config.json run arbitrary Python in the loading user's process, because a nested model_type value containing a newline escapes into an exec()-generated import statement. Exploitation requires the victim to load an attacker-controlled model for training or inference - a user-interaction gate, but no authentication on the attacker side (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; vendor score 8.6). No public exploit code has been identified at time of analysis, and the practical exposure is concentrated in pipelines that automatically ingest third-party or user-supplied models from public hubs rather than those loading only vetted first-party checkpoints.
OS command injection in aaPanel BaoTa through 11.8.0 lets an authenticated panel operator execute arbitrary shell commands on the underlying host by supplying a crafted Password value to the archive-extraction routine. The defect sits in the function panelTask.bt_task._unzip within /www/server/panel/class/panelTask.py, and because the panel normally runs as root a successful injection yields full server compromise; a user-interaction step is required to invoke the unzip workflow. Publicly available exploit code exists (disclosed via a public gist referenced by VulDB), the vendor was contacted early but did not respond, and no vendor-released patch has been identified at time of analysis - this is the third near-identical command-injection flaw in the same release line alongside CVE-2026-101007 and CVE-2026-101008.
Command injection in the aaPanel (BaoTa) server management panel through version 11.8.0 lets an authenticated high-privilege panel user execute arbitrary operating-system commands by manipulating the split_file_path argument handled by merge_split_file in /www/server/panel/class/files.py. The flaw is network-reachable and requires no user interaction, but it demands an existing administrator-level session (PR:H), so realistic risk is concentrated on panels with untrusted account holders, exposed management interfaces protected by weak or default credentials, or environments where admin credentials have already been stolen. Publicly available exploit code exists, exploitation evidence is rated E:P, and the vendor was contacted early but did not respond, so no fix is currently available; this is a genuine but conditional risk rather than a pre-auth emergency.
OS command injection in aaPanel/BaoTa versions up to 11.8.0 allows an authenticated attacker with access to the administrative interface to execute arbitrary operating system commands on the underlying host by manipulating the Password argument during a database backup operation. The vulnerability requires user interaction to trigger the backup workflow, but because aaPanel typically runs with root privileges, successful exploitation leads to full host compromise. A public exploit has been disclosed and may be used, though there is no confirmed active exploitation (CISA KEV) at this time.
python-utcp versions before 1.1.4 allow server-side request forgery through the utcp-http plugin's HttpCommunicationProtocol.call_tool, which validates the initial tool URL but follows HTTP redirects with no per-hop re-validation, so an attacker-controlled tool endpoint can return a 3xx Location that drives the UTCP client into internal HTTP services or the cloud metadata endpoint (169.254.169.254) and returns the response body to the tool caller. The vulnerable path is the core UTCP pattern of registering a tool or manual/OpenAPI spec from a runtime-supplied URL and then invoking it; the initial URL only needs to pass ensure_secure_url (any https:// or a benign attacker-owned host), with the attacker supplying the redirect. Exploitation is remote and requires no privileges (CVSS 4.0 PR:N, assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), but it is gated on the host ingesting and invoking an attacker-influenced tool spec and on an internal HTTP service being reachable from the client, which keeps practical priority moderate rather than critical; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 1.1.4.
Credential exfiltration and server-side request forgery in utcp-http 1.1.3 and earlier allow an attacker who supplies a malicious OpenAPI specification to redirect a victim's OAuth2 client_id and client_secret to an arbitrary token endpoint. The library validates discovery and tool-invocation URLs via ensure_secure_url() but never applies the same guard to the OAuth2 tokenUrl taken from a remote spec, so the attacker-chosen endpoint receives the credentials in cleartext when a generated OAuth2-protected tool is invoked. Exploitation requires victim interaction (the victim must register the attacker-controlled spec and call the generated tool) and no attacker authentication; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N (7.1), with the unvalidated endpoint also usable for SSRF against internal HTTP ranges. No public exploit identified at time of analysis.
Server-side request forgery in python-utcp (utcp-http) before 1.1.12 allows an unauthenticated remote attacker to cause a victim's client to issue requests to loopback services and return response bodies if the victim registers a malicious UTCP manual served from a non-loopback origin. Exploitation requires user interaction (registering the manual) and is limited to loopback interfaces, with further prerequisites of a loopback service that answers unauthenticated requests with useful data. No public exploit code exists, and the issue is fixed in utcp-http 1.1.12; this is a conditional-severity issue rather than a mass-exploitation threat.
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-Secret-Token header whenever the endpoint has no credential_id or an empty secret_token, so remote unauthenticated attackers who know the webhook URL can POST forged Telegram updates and cause the owner's configured workflows to run with the owner's stored credentials. The flaw is a fail-open authentication check (CWE-287) rated 8.3 with an assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N profile - confidentiality exposure is limited while integrity impact is high, since attacker-supplied input is processed under the victim's credentials. No public exploit code has been identified at time of analysis, and exploitation requires the precondition of an unset or empty secret token plus at least one workflow wired to Telegram updates.
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Slack request-signature verification whenever a Slack trigger node has no credential ID or an empty signing secret (a fail-open code path). The bypass is unauthenticated (CVSS 4.0 PR:N) but conditionally gated: it only works against trigger nodes that are misconfigured this way, and the attacker must know or discover the target's webhook URL - a properly configured node with a valid signing secret is not exploitable, which is why the assessed severity carries AC:H. Impact is primarily integrity (I:H) with limited confidentiality exposure (C:L), and the vendor fixes it in 0.0.53 by making signature verification fail closed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Python eval()-based remote code execution in Heym (heymrun/heym) before 0.0.53 lets an authenticated user who can edit a workflow branch or condition node - or a victim who imports a workflow template containing a malicious condition node - run arbitrary Python as the backend process user whenever the workflow executes. The same release bundles four further flaws: fail-open Slack and Telegram webhook verification that allows unauthenticated workflow triggering with the owner's credentials when a trigger node has no credentialId or an empty signing secret, an OAuth redirect_uri scheme-validation gap that permits javascript:/data: URIs and script execution in the Heym origin, and plaintext storage of WorkflowExecutionToken, PortalSession, HITLRequest.public_token and OAuthAuthorizationCode values. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the 0.0.x pre-release product has a very small deployment base.
Sandbox escape in the heym workflow platform before 0.0.91 allows an authenticated user who can author or edit workflow expressions to execute arbitrary Python and run operating-system commands as the backend process. The flaw lives in the expression engine's DotList map/filter item expressions and its fallback resolver, which fail to block dunder attribute traversal, letting an attacker chain attributes to reach functions such as os.system. Exploitation requires a valid account with workflow-authoring rights (PR:L) but no user interaction, making this a network-reachable, low-complexity compromise of confidentiality, integrity, and availability; no public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation.
Deserialization of untrusted data in MONAI's auto3dseg utility (monai/auto3dseg/utils.py) allows arbitrary code execution when algo_from_pickle() is called on an attacker-supplied .pkl file: the function reads the raw file bytes and hands them to pickle.loads() without any source or content validation, so any object defining __reduce__ runs in the victim application's context. Exploitation is conditional rather than remote-against-a-service: an attacker must first deliver a malicious pickle (model exchange, shared storage, or a pipeline input) and the victim's code must invoke this specific function, and per the authoritative assessment the vector is local with user interaction required (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) rather than unauthenticated network exploitation. A working proof-of-concept is documented in the upstream GitHub advisory GHSA-89gg-p5r5-q6r4 (publicly available exploit code exists), but there is no confirmed active exploitation (CISA KEV).
Arbitrary code execution in MONAI versions prior to 1.6.0 occurs when a crafted .npy or .npz file is loaded through the NumpyReader class, which hardcodes numpy.load with allow_pickle=True. An unauthenticated attacker who can place a malicious file on a path the victim opens can trigger pickle deserialization, leading to full compromise of confidentiality, integrity, and availability. Exploitation requires user interaction (the victim must load the file) and the attack vector is local; no public exploit code has been identified at time of analysis.
OS command injection in MONAI's nnUNetV2Runner (monai.apps.nnunet.nnunetv2_runner) allows arbitrary command execution with the privileges of the user running an nnU-Net training or validation job, because values such as dataset_name_or_id from a YAML config - or from CLI/kwargs arguments - are concatenated into a command string and passed to subprocess with shell=True without quoting or validation. All MONAI releases before 1.6.0 are affected; exploitation is not network-facing and requires the victim to load an attacker-supplied configuration file and then launch a job such as train_single_model(), so the real-world risk is config-trust dependent rather than remotely triggerable. Publicly available exploit code exists (a Windows-verified proof of concept is included in the GHSA advisory), no authentication is required in the assessed vector (PR:N), and no confirmed active exploitation (CISA KEV) has been reported at time of analysis. Vendor-released patch: MONAI 1.6.0.
Deserialization of attacker-controlled pickle data in MONAI's Auto3DSeg module (monai/auto3dseg/utils.py) lets code run inside any process that calls algo_from_pickle() on a file the attacker can supply or substitute, with full read/write/execute impact on that process and its data. Versions before 1.6.0 are affected (pip package monai < 1.6.0, CPE cpe:2.3:a:project-monai:monai); the vulnerable pickle.loads() at line 321 fires before any isinstance or key checks, so no special configuration flag is needed to reach the sink. The exposure is conditional rather than remote: the vector is local (AV:L) with passive user interaction (UI:P) - a victim, typically a medical-imaging or ML pipeline exchanging algorithm bundles or model checkpoints, must load the crafted .pkl file, and no authentication is required on the loading side (PR:N) - scored 8.5. There is no evidence of confirmed active exploitation (no CISA KEV entry), but publicly available exploit code exists: the upstream advisory ships a working proof-of-concept, and users who upgraded to v1.5.2 believing GHSA-89gg-p5r5-q6r4 fixed this remain fully vulnerable because that earlier patch was never actually implemented in the code.
MONAI through 1.6.0 lets a user who can supply or tamper with a bundle's metadata achieve code execution by abusing an eval()-based sandbox in _get_fake_spatial_shape() (monai/bundle/scripts.py). The vulnerable function screens shape expressions with a helper that walks the AST and only rejects ast.Name nodes outside the 'p'/'n' allowlist, so payloads assembled purely from constants and attribute, subscript, or call nodes - such as "(1).__class__.__bases__[0].__subclasses__()" - pass validation and then reach eval(), enabling object-introspection chains that escape to arbitrary code execution. The path is reachable through the non-default bundle 'verify_net_in_out' CLI verification flow (_get_real_input_data / verify_net_in_out), so exploitation is limited to authenticated local users (CVSS:3.1/AV:L/AC:H/PR:L/UI:N, CVA:H) who run that verification on an untrusted or modified bundle; default MONAI workflows that never verify untrusted bundles are not exposed, and no public exploit code was identified at time of analysis.
Local code execution in MONAI 1.6.0 and all released versions allows an authenticated low-privileged local attacker to run arbitrary code as another user by writing a malicious pickle file to a shared or world-writable MONAI cache directory (e.g., /tmp/monai_cache, HPC scratch, ~/.cache/monai). The victim must subsequently run a PersistentDataset pipeline that caches MetaTensors (the default in MONAI >= 1.0), which forces torch.load(weights_only=False) and pickle.loads on the poisoned file. No vendor-released patch identified at time of analysis; no public exploit identified at time of analysis.
MONAI through 1.6.0 will execute arbitrary code in the victim's process when it loads an attacker-supplied bundle, because the bundle configuration engine resolves '_target_' values to any importable callable without an allow list and passes '$' expressions straight to Python's eval(). An attacker who publishes or shares a crafted bundle achieves code execution as soon as an operator calls monai.bundle.load() or monai.bundle.run() on it; no credentials are required against the victim (PR:N), but the attack does depend on user interaction (UI:R) since the operator must obtain and load an untrusted bundle, and the payload runs with the privileges of the loading process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; the primary exposure is to environments that pull third-party or community-contributed MONAI bundles rather than first-party trusted ones.
GitPython before 3.1.62 is vulnerable to a path traversal (CWE-22) in Submodule.update() that allows unauthenticated remote attackers to create, populate from a submodule URL, and potentially delete directories outside the repository working tree when an application updates submodules at a non-HEAD (historical) commit. The flaw stems from the `path` field in an untrusted .gitmodules file being used without the _to_relative_path() containment guard that is applied in add() and move(). Exploitation requires an application flow that checks out submodules at a historical commit and an attacker-controlled repository; the standard clone-then-update flow re-derives the path from a canonical tree lookup and is not affected. No public exploit code or confirmed active exploitation (CISA KEV) exists at time of analysis, and the independent assessment rates real-world priority as low-to-medium despite the vendor's CVSS 4.0 score of 8.7.
Denial of service in vLLM before 0.29.0 allows an authenticated API user to permanently disrupt the inference service with a single malformed request to the OpenAI-compatible POST /v1/completions or POST /v1/chat/completions endpoints. The server accepts user-supplied stop_token_ids and checks only that they are integers, not that they fall within the model's vocabulary/logits range; when min_tokens > 0 those ids are used as logits indices to suppress stop tokens, so an out-of-range value reaches a CUDA index_put_ operation and trips a device-side assertion that returns HTTP 500 and leaves EngineCore in a fatal state until the service is restarted. The impact is bounded to availability (no code execution or data disclosure) and exploitation requires valid API credentials plus exposure of the OpenAI-compatible endpoints; no public exploit code was identified at time of analysis, and the vendor has released a fix.
Pinned vLLM deployments (0.22.1 through 0.28.0) running the FunAudioChat or Tarsier2 architectures silently ignore the operator's --revision/--code-revision pin for several Hugging Face artifacts, allowing a subsequent change to the upstream repository's default branch to alter audio preprocessing, speech-tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. The result is a supply-chain integrity and reproducibility failure rather than a code-execution flaw: the advisory explicitly states it is residual to CVE-2026-47155 / GHSA-3ww4-5jv9-j5gm and does not constitute remote code execution or a trust_remote_code=False bypass, despite an 'RCE' tag appearing in some threat-feed metadata. There is no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); exploitation requires the narrow combination of an affected architecture, an operator using a revision pin, and an actor able to modify the upstream Hugging Face repository's default revision, so default general-purpose vLLM deployments are unaffected.
Out-of-vocabulary stop_token_ids in vLLM 0.22.0 through 0.23.0 cause a CUDA tensor indexing failure that drives EngineCore into a fatal state and forces a manual service restart. The trigger is a generation request that simultaneously sets min_tokens greater than zero and includes stop_token_ids outside the model's vocabulary bounds, slipping past missing validation in the Rust HTTP and gRPC frontends to reach MinTokensLogitsProcessor; CVSS 4.0 scores this 8.2, but the assessed impact is availability-only (C:N/I:N/A:H) and deployments enabling vLLM's optional API-key authentication would require a valid key, so real-world severity is lower than the headline score. No public exploit code or confirmed active exploitation is identified at time of analysis (not in CISA KEV), and a vendor patch is available per advisory GHSA-qff2-492f-9fm4, with ENISA EUVD-2026-87746 recording the affected range as 0.22.0 up to but not including 0.24.0.
Denial of service in vLLM deployments running versions before 0.29.0: an attacker with low-privilege access to the disaggregated serving endpoint /inference/v1/generate can submit an overlong token_ids list accompanied by a 'features' (multimodal) payload, bypassing prompt-length validation and causing a worker failure that takes down inference capacity. The issue is availability-only (no confidentiality or integrity impact) and is reachable over the network without user interaction, but exploitation requires that the deployment run in non-default disaggregated serving mode with a multimodal model whose processor reports skip_prompt_length_check=True (Nemotron Parse, Whisper, or FireRedLID), so standard single-node text-only vLLM installations are not exposed. Vendor-released patch: 0.29.0; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Pre-inference resource exhaustion in vLLM up to and including 0.29.0 lets remote attackers force the API server or batch runner to fully download, base64-decode and materialize attacker-controlled media before the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed-audio cap (25 MB default) and the per-modality --limit-mm-per-prompt item limits are enforced. Four ingress paths are affected - the shared media-acquisition layer (HTTPConnection.get_bytes()/async_get_bytes()), the chat completions audio_url/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route - with the /tokenize path unauthenticated by design and the chat/batch surfaces gated only when an API key is actually configured, so an attacker can allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size or media-item count. Impact is availability-only (no code execution or data disclosure); the vendor CVSS 4.0 vector scores 7.1 with PR:L, while the independent assessment scores it 7.5 under CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) to reflect the unauthenticated /tokenize path, and no public exploit code was identified at time of analysis.
OpenClaw npm package versions 2026.3.28 through 2026.8.0 can be coerced into executing attacker-supplied Python code when an operator opens OpenClaw against an untrusted workspace whose .env file sets CLOUDSDK_PYTHON_ARGS and then runs the Gmail setup flow. The poisoned value is inherited by the gcloud launcher, which forwards it as arguments to the trusted Python interpreter, giving the attacker code execution with the OpenClaw host user's permissions - enough to read credentials, modify files, or spawn further processes. The issue is rated 8.5 (CVSS 4.0 AV:L/AC:L/AT:N/PR:N/UI:P; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and is fully local and interaction-dependent: the malicious workspace content must already be present and the operator must both launch OpenClaw on it and actively trigger Gmail setup, so it cannot be fired remotely or unattended; no public exploit code was identified at time of analysis. Version 2026.8.1 fixes the flaw.
Authenticated code injection in Horilla HR (horilla-hr) before 2.0.0 lets any user with access to the HorillaListView export functionality run arbitrary operating-system commands with the privileges of the application process - root, in the project's shipped horilla/horilla-hr Docker image. The issue is rated CVSS v3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): exploitable remotely over the network with low privileges, requiring only a valid account able to reach the list/export endpoint, with no user interaction and no non-default configuration. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor released a fix in version 2.0.0.
Reflected cross-site scripting in Horilla HR (horilla-hr) before 1.6.0 allows a remote, unauthenticated attacker to execute arbitrary JavaScript in the browser of an authenticated employee or administrator by tricking that user into opening a crafted link to /employee/employee-filter-view. The search parameter is written into the DOM through jQuery's .html() in employee/templates/employee_nav.html, so the injected markup is rendered and executed rather than displayed as text; because the payload runs in the victim's session, the attacker can read browser-visible session data and perform actions with the victim's application privileges. There is no public exploit identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV); impact is capped at the client/browser layer (VC:H/VI:H but VA:N and no scope change to the server in the vendor's CVSS 4.0 vector, with our independent assessment scoring CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
The AetherBrowser API server shipped with SCBE-AETHERMOORE versions 4.0.2 through 4.2.0 exposes the POST /api/ops/check-email endpoint with no authentication check whatsoever, letting any remote, unauthenticated attacker invoke the email_reader.py subprocess, which logs into configured ProtonMail or Gmail accounts over IMAP and returns email metadata (sender, subject, and body snippets) in the JSON response. The server listens on 0.0.0.0:8100 by default and sets CORS allow_origins=["*"], so the endpoint is reachable from any network host and callable from any browser origin, though meaningful mailbox disclosure requires that IMAP credentials have actually been configured for the reader. Version 4.2.1 resolves the missing authentication (CWE-306); no public exploit code has been identified at time of analysis.
A tenant isolation bypass in BerriAI LiteLLM versions before 1.101.0-rc.1 lets an authenticated holder of a valid virtual key read other tenants' entries from the semantic cache and, in the worst case, have attacker-supplied tool calls executed under a victim's credentials. The flaw stems from an inconsistency in how the cache layer derives the tenant scope versus the metadata variable name, so semantically similar prompts sent to routes such as /v1/responses and /bedrock/* can collide with and return another tenant's cached response - potentially exposing PII, financial data, or source code. Exploitation requires a multi-tenant deployment with semantic caching enabled and a sufficiently similar prompt to hit the victim's cache entry, and it is rated CVSS 8.7 with a vendor patch already released (commit 16db51e2, fixed in v1.101.0-rc.1); no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV.
Stored cross-site scripting in AIL Framework allows an authenticated attacker who can influence matched, tracked, or tagged content to inject HTML or JavaScript into Bootstrap popovers rendered with data-html="true", executing in a victim analyst's session when they view the affected popover. The vulnerability affects versions prior to the fix commit ee63a0a and requires victim interaction (opening the popover, typically on hover); no public exploit code was identified at time of analysis. A vendor patch is available via the referenced commit, but practical risk is moderate given the authenticated attacker prerequisite, required victim interaction, and the niche threat-intelligence context of the tool.
A server-side request forgery in the VMware datastore driver of OpenStack glance_store lets an authenticated OpenStack user supply a crafted image location URI pointing at an attacker-controlled server, causing the driver's _retry_request function to attach sensitive vCenter authentication headers to that outbound request and disclose them. The deployment must be configured with the non-default VMware/vCenter datastore backend, and the attacker needs an account with the ability to set or override image locations (typically gated behind the set_location / show_multiple_locations policy); SSVC rates the issue as Exploitation=poc with publicly available exploit code on GitHub (sadandbset/CVE-2026-51772-CVE-2026-51773), Technical Impact=total, but Automatable=no, so it is a targeted attack rather than a mass-exploitation candidate and there is no confirmed active exploitation (CISA KEV) at time of analysis. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1) reflects high confidentiality impact from credential theft; our independent assessment adjusts the integrity impact to Low because the primary outcome is leakage of authentication material rather than direct modification of data.
The Perl CPAN distribution IO::Socket::SSL::SelfCertificate version 1.00 is itself the attack artifact: its generate_certificate() routine writes a Python script disguised as a certificate file and executes it, causing base64-obfuscated code to be fetched from a hardcoded HTTP URL and run in memory without ever dropping a script to disk. Anyone who installs the 1.00 tarball and calls that function is exposed - a local, unauthenticated action requiring user interaction (assessed CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), rather than the remote pre-authentication scenario implied by the CNA's 9.8 network vector - and outbound HTTP egress must be reachable for the payload to be retrieved. The advisory notes there are no test scripts or build hooks, so nothing fires automatically at install time and the payload must be manually triggered; no public exploit code beyond the malicious package itself has been identified at time of analysis, EPSS is negligible at 0.12% (1st percentile), and the nearly identical CVE-2026-95831 covers the sibling Crypt::SelfCertificate module.
An integer overflow in the BSON encoder of the MongoDB Python Driver's bundled native C extension (PyMongo before 4.18.2) can cause an out-of-bounds write inside the process hosting the driver when an application encodes a single document built from an unusually large (~2 GB) caller-supplied value. Only builds that link the C extension are affected - the pure-Python BSON fallback is not - and successfully triggering it requires that a large attacker-influenced value actually reach the encoding path, so most applications are exposed only through data they already accept from untrusted sources. The flaw is not confirmed as actively exploited (CISA KEV) and no public exploit code has been identified at time of analysis; the vendor has released 4.18.2 as the fixed version, and because impact is confined to the hosting application's own process, risk is best treated as a genuine but precondition-heavy memory-corruption issue.
Attackers can inject arbitrary additional servers into a PyMongo (MongoDB Python Driver) client's connection topology by smuggling the percent-encoded form of a host-list delimiter (for example %2C) inside a hostname value that an application places into a connection string, because PyMongo decodes percent-escapes before it splits the host list. The request is unauthenticated (CVSS 4.0 PR:N) but carries an attack-requirement prerequisite (AT:P): the target application must build a URI at runtime from a host the attacker can influence, meaning static or hardcoded connection strings are not exploitable. MongoDB's own CVSS 4.0 rating of 8.3 (High) is driven by a high integrity impact - the client may route its authentication exchange and subsequent database operations to the rogue host, which can observe limited information and return altered query results. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in PyMongo 4.18.2.
Authentication bypass in Python Social Auth (social-core) versions prior to 5.0.0 allows unauthenticated remote attackers to impersonate any VK user when an application uses the vk-app backend, as the backend skips signature verification if the auth_key parameter is omitted. An attacker can forge callback fields such as viewer_id, access_token, api_id, and api_result to authenticate as an arbitrary VK identity, potentially taking over accounts in the target application. The vulnerability is fixed in version 5.0.0, and no public exploit code or active exploitation has been identified at this time.
Path traversal in the pulpcore content upload API allows an authenticated user holding only low-privilege file-repository permissions to read arbitrary files accessible to the Pulp server process by submitting a crafted 'file:' URL through the 'file_url' parameter, which is dispatched to the file downloader despite an intended scheme check. Baseline impact is confidentiality loss on the Pulp host; in deployments that include Pulp Container the same flaw escalates to theft of the container registry token signing private key, enabling forged bearer tokens and unauthorized access to every private container repository in the registry. Downstream products embedding pulpcore are affected, including Red Hat Satellite 6, Red Hat Ansible Automation Platform 2, and Red Hat Update Infrastructure 4/5. There is no public exploit identified at time of analysis, and EPSS data was not provided; Red Hat tracks the issue under advisory https://access.redhat.com/security/cve/CVE-2026-90959.
Command injection in the automation controller's external logging (rsyslog) configuration of Red Hat Ansible Automation Platform 2 allows a superuser to achieve arbitrary command execution inside the control-plane rsyslog component, exposing the controller SECRET_KEY and database credentials and enabling decryption of all stored credentials. Exploitation requires authenticated superuser privileges (CVSS 3.1 7.2, PR:H, no user interaction) and only takes effect when external logging is in use, so the malicious RainerScript configuration is actually generated and loaded. No public exploit code was identified and there is no CISA KEV listing indicating active exploitation, meaning real-world risk is strongly gated by the elevated privilege requirement even though the post-exploitation impact is a full control-plane compromise.
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated organization workflow-admin - a delegated, non-superuser role - to escalate into the control plane by copying a WorkflowJobTemplate and then launching jobs pinned to instance groups they hold no use_role on. The deep-copy permission sanitizer re-validates only the inventory, unified_job_template, and credentials of each cloned node, silently carrying over instance_groups, execution_environment, and labels, so the copier becomes administrator of a workflow that executes attacker-influenced automation in the control-plane execution context (CVSS 9.9, scope changed, high confidentiality, integrity, and availability impact). Exploitation is confirmed to require only a normal multi-tenant deployment plus workflow-admin rights; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, and no vendor-released patch version was confirmed in the available intelligence.
Authenticated but low-privileged users of Red Hat Ansible Automation Platform 2 can bypass the automation-controller's sanitize_jinja() input-validation guard and have ansible-core evaluate attacker-supplied Jinja inside the execution environment, yielding arbitrary command execution and disclosure of secrets belonging to credentials the attacker cannot normally read. The flaw is exploitable remotely with no user interaction (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N per independent assessment) and requires only a controller account able to set one of the affected launch-time fields. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; priority is bounded by the required authenticated foothold and the niche deployment footprint.
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
An authenticated automation-controller administrator in Red Hat Ansible Automation Platform 2 can turn the administrator-controlled format template for API 4XX log messages into a secret-reading primitive, using Python string-format traversal to walk from the interpolated user object into Django settings and pull out the SECRET_KEY and the database password. Because the log destination (external aggregator) is also administrator-controlled, the formatted message - and therefore the secrets - can be shipped off the host, giving the administrator the master key protecting all stored credentials, the ability to forge signed user sessions, and direct database access; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N (8.7) with high confidentiality and integrity impact and scope change, since secrets leave the controller's security boundary. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, so this is a high-priority hardening issue rather than an actively exploited one: the practical risk is driven by the very high value of the assets reachable once a privileged administrator account or the log pipeline is compromised.
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an authenticated low-privileged user embed a javascript: hyperlink into job, ad hoc command, project update, or inventory update standard output, which is then rendered as a text/html link in the controller's stdout view. Because the HTML conversion escapes HTML metacharacters but never strips ANSI terminal escape sequences, an OSC 8 hyperlink becomes an unfiltered HTML anchor, and the response carries no Content-Security-Policy; a higher-privileged user (for example an administrator) who views that output page and clicks the link executes attacker-controlled JavaScript in their authenticated session, allowing actions up to full platform takeover. The vector is network-reachable with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7), but exploitation hinges on a privileged victim actively clicking the crafted link; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Authenticated remote code execution in OpenC3 COSMOS (Ruby gem 'openc3' versions 5.1.0 through 7.2.1) lets any logged-in user, including one with only low-tier permissions, execute arbitrary Ruby and Python code on the COSMOS server and its per-target decom microservices. COSMOS reads configuration from a user-writable overlay (targets_modified/) before its read-only targets/ tree and then executes that content - rendering it as ERB, eval-ing GENERIC_READ/WRITE_CONVERSION blocks, or require-ing Script Runner procedure files - so an attacker who can write to the overlay via the screen-save or storage-upload endpoints achieves code execution as the openc3 user, which holds Redis and object-store credentials and sits on the internal service network. A working proof-of-concept is published in the vendor GitHub advisory, and the vendor has released 7.3.0 as the fix; no confirmed active exploitation (CISA KEV) has been reported. Reachability is limited on default single-host installs because the shipped docker-compose binds Traefik to 127.0.0.1:2900, so exploitation is realistic on multi-user deployments that expose the web port.
Authenticated OS command injection in OpenC3 COSMOS 5.12.0 through 7.2.1 allows a user with a valid session to run arbitrary operating-system commands as the openc3 service user by writing shell metacharacters into the pypi_url setting and then installing a plugin that carries Python dependency metadata. The injected value is interpolated into a shell backtick inside PluginModel.install_phase2, so commands execute with access to the service's Redis and bucket storage credentials; in the open-source edition any authenticated user can reach both the setting-write and plugin-install operations, whereas the Enterprise edition requires the administrator role, and the vendor has fixed the issue in 7.3.0. There is no CISA KEV listing or confirmed in-the-wild exploitation, but the public vendor advisory GHSA-vp3w-52v9-q57f includes confirmed end-to-end proof-of-concept steps, and the independent assessment rates this as a genuine high-priority issue rather than CVSS inflation.
Stored password survey answers in Red Hat Ansible Automation Platform 2's automation-controller can be recovered in plaintext by an authenticated user holding the delegated JobTemplate Admin role. The attacker tightens the minimum/maximum length constraint on a password-type survey question, then forces revalidation of a schedule or workflow job template node created by a higher-privileged user, causing the controller to decrypt the stored secret and embed it in the HTTP length-validation error response. No public exploit identified at time of analysis; exploitation is not unauthenticated (CVSS PR:L) and requires both the delegated role and an existing password-type survey value, making this a lateral, privilege-crossing credential-disclosure issue rather than a mass-exploitable perimeter break.
Authenticated users who hold permission to create or modify a project within a single organization can execute arbitrary commands on the Ansible Automation Platform 2 automation-controller task pod by setting the Project scm_url to a value beginning with a dash, for example '--upload-pack=<command>:x'. The automation-controller's git SCM module passes that URL verbatim as a positional argument to 'git ls-remote' without a '--' end-of-options separator, so git treats it as the --upload-pack option and executes the attacker's command via a shell, with output reflected through the project update stdout endpoint, enabling cross-tenant compromise and in-cluster lateral movement (CVSS 3.1 9.9, scope changed). Exploitation needs valid platform credentials and the git project type but no admin or cross-organization rights, and no public exploit code has been identified at time of analysis.
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 because the automation-controller exposes the provisioning-callback secret (host_config_key) to anyone holding only read-level view_jobtemplate permission and accepts a client-supplied X-Forwarded-For header as proof of caller identity when the gateway proxy allow-list is empty. An attacker who reads the secret from the job template API representation or the activity stream and spoofs X-Forwarded-For to match any host in the target job template's inventory can launch that template against arbitrary managed hosts using the template's stored credentials; CVSS 3.1 base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), no public exploit code was identified at time of analysis, and the decisive enabler is a non-default deployment condition - an empty proxy allow-list combined with provisioning callbacks actually being in use.
Unauthenticated remote attackers can stall job dispatch for every tenant on Red Hat Ansible Automation Platform 2 by repeatedly calling four debug scheduler views that are routed in production builds because their URL include is not gated on the debug setting. Each call lets any network-reachable client acquire the cluster-wide scheduler advisory lock, and since the legitimate scheduler takes that same lock without waiting, genuine scheduler runs are skipped, job dispatch is delayed or halted, and controller web workers are consumed. The debug root view also discloses the list of debug endpoints to unauthenticated callers, and no public exploit code has been identified at time of analysis.
Missing object-level authorization in the JobTemplate copy endpoint (CopyAPIView) of AWX and Red Hat Ansible Automation Platform 2 lets an authenticated user duplicate a JobTemplate they are not permitted to read, disclosing the template's configuration - playbook reference, associated credentials, inventory and extra variables - that RBAC was intended to protect. The root cause is CWE-862 (Missing Authorization): the copy view's GET path enforces a read check on the source object, but the POST path that performs the copy only validates add and copy-related permissions, none of which imply read access on the source template. Per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N; vendor score 8.5), exploitation requires an authenticated account already holding inventory.use_role, project.use_role, execution_environment.read_role and credentials.use_role, so this is an insider/multi-tenant privilege-boundary flaw rather than unauthenticated remote compromise; no public exploit code was identified at time of analysis.
Remote code execution in MLflow's statsmodel flavor (versions 2.1.0 through 3.14.0) occurs because _load_model() omits the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False safeguard, allowing a crafted MLmodel artifact to trigger unsafe pickle deserialization (CWE-502). An authenticated low-privileged attacker (PR:L) who can register or supply a malicious artifact to the model registry or artifact store can achieve arbitrary code execution when a victim's pipeline or serving process loads it, although the victim must load the untrusted artifact (UI:R). The independent assessment notes that no public exploit was identified at time of analysis (SSVC Exploitation: none), and exposure is limited to environments that load untrusted statsmodel artifacts; those using only trusted internal models are not realistically exposed.
OS command injection in the frictionless-py framework through 5.20.0rc1 lets unauthenticated remote attackers execute arbitrary operating system commands in the victim's security context when the victim runs the `frictionless explore` console command against an attacker-supplied Data Package. The flaw is reachable because resource path values from an untrusted datapackage.json are concatenated unsanitized into a shell invocation (`vd {paths}` via os.system), so shell metacharacters placed in a path are interpreted by the shell rather than treated as a filename. Exploitation requires victim interaction (CVSS UI:A) - the user must deliberately explore the malicious package - and publicly available exploit code exists, including a proof-of-concept repository; there is no data provided indicating confirmed active exploitation, and the assessed CVSS:3.1 vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (vendor CVSS:4.0 8.6, PR:N/UI:A), so impact is high on confidentiality, integrity and availability of the user's environment but gate-controlled by the social-engineering step.
Arbitrary code execution in MLflow (versions 2.0 and later) via the dspy flavor, where an attacker-crafted MLflow model artifact causes remote code execution when loaded by a victim. The vulnerability arises because the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False safety control is enforced only when the model_path ends in '.pkl'; any other path (or extension) silently skips the check and unpickles attacker-controlled data. Per the CVSS vector (AV:N/AC:L/PR:N/UI:R) an unauthenticated remote attacker can exploit this, but success depends on user interaction: a person or automated pipeline must fetch and load the malicious model. Exploitation has not been confirmed as active (not in CISA KEV) and no public exploit code was identified at time of analysis, and CISA SSVC rates exploitation as 'none' with automatable 'no', though technical impact is total (full confidentiality, integrity, and availability loss on the host that loads the model). The CVSS 8.8 score is well-justified by the technical impact rather than inflated.
Remote code execution affects LightLLM deployments through version 1.2.0 that run the KV-transfer worker with the non-default '--pd_trans_mode nccl' option, which exposes an unauthenticated RPyC ThreadedServer control channel on the network. An attacker with network reachability can send a malicious pickled object to that channel, triggering unsafe deserialization and executing arbitrary code with the privileges of the LightLLM service account (CVSS 9.3; PR:N/UI:N). The vulnerability is not known to be actively exploited and no public exploit code has been identified at time of analysis, though the non-default configuration limits exposure to deployments that explicitly enable NCCL-based prefill/decode disaggregation.
Unauthenticated code installation on the Reachy Mini robot daemon (Pollen Robotics) allows any host on the same LAN to execute arbitrary Python code on the robot by posting an attacker-controlled Hugging Face Space to POST /apps/install. The endpoint is reachable without credentials because the wireless variant of the daemon binds to 0.0.0.0, and the handler's dependency chain (Depends(get_app_manager)) never performs an authorization check; the chosen Space's build/setup code is then executed by the daemon via uv or pip. Affected are all Reachy Mini units before the vendor's v1.11.0 patched release (CPE cpe:2.3:a:pollen_robotics:reachy_mini:*); there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), though the attacker prerequisites are trivial for anyone sharing the robot's Wi-Fi network. Scoring is AV:A/AC:L/PR:N/UI:N with high confidentiality, integrity and availability impact, consistent with full compromise of the robot host.
Symlink-based path traversal in the `tar` source plugin of Apache BuildStream (versions up to and including 2.8.0, running on Python < 3.12) lets a malicious source tarball write arbitrary files on the host with the privileges of the user running BuildStream, resulting in full confidentiality, integrity, and availability impact to that user's environment. The vendor-published CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), but the assessed vector adds UI:R: exploitation requires the victim to fetch and extract an attacker-controlled or otherwise untrusted source tarball, and it is not exploitable against projects that use only trusted, tracked sources, since SHA256 hash pinning of tracked tarballs prevents MITM substitution. No public exploit code and no confirmed active exploitation were identified at time of analysis (CISA SSVC exploitation: none; EPSS 0.19%, 10th percentile); the vendor-released patch is BuildStream 2.8.1, and hosts running Python >= 3.12 with BuildStream >= 2.3.0 are already protected because the Python `tarfile` extraction filter blocks the symlink escape.
Server-side template injection in web.py 0.76 allows an attacker who can write to the application's template source directory to achieve arbitrary Python code and OS command execution on the server, but only when the application precompiles those templates and later renders them through the precompiled template loader; that specific deployment pattern is what defeats the template engine's built-in sandbox. The flaw is a genuine RCE-class issue (CWE-94) at CVSS 8.5, yet it is gated by real prerequisites: the CVSS vector indicates authenticated access (PR:L) and high attack complexity (AC:H), because the attacker must first obtain write access to the template directory and the application must use the precompiled code path rather than direct sandboxed rendering. It is not a remote-unauthenticated exploit against stock configurations, and no public exploit identified at time of analysis; exploitation is not confirmed actively exploited (CISA KEV) and no KEV entry is present in the source data.
Cross-audience Google ID token reuse in the toolbox-core module of mcp-toolbox-sdk-python causes a credential intended for one service to be silently handed to a different service within the same process. Because the module-level token cache is not keyed by audience, an application that fetches ID tokens for two or more audiences in one process can send a Service A token to Service B; an attacker who operates, compromises, or passively monitors Service B can capture that token and replay it against Service A to impersonate the victim application. Exploitation is unauthenticated against the vulnerable app (PR:N) but conditional: it requires a multi-audience deployment plus attacker visibility into Service B traffic, and the leaked token is time-bounded by its expiry. No public exploit code has been identified at time of analysis, and the flaw is not confirmed as actively exploited (no CISA KEV listing).
Arbitrary server-side code execution in the Plone process is possible through the Classic portlet shipped in plone.app.portlets 5.0.0 through 7.0.1, where user-supplied template and macro fields are assembled into a TALES path expression and then evaluated by the TAL path() helper, allowing a crafted value to be interpreted as a full expression rather than a constrained path. Any authenticated user who can add or edit a Classic portlet can execute code, and under Plone's default role map that includes ordinary registered users on their personal dashboard, so the issue amounts to a post-authentication privilege escalation across the trust boundary between a web user and the server-side Plone process (CVSS 3.1 9.9, scope changed: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). There is no confirmed active exploitation (no CISA KEV listing) and no public exploit identified at time of analysis, but vendor patches are available in 5.0.8, 6.0.4, and 7.0.2.
Denial of service in psd-tools before 1.17.4: PSDImage.composite() and PSDImage.numpy() size their output buffers directly from the geometry declared in an untrusted PSD header (width, height, channels, depth, and per-layer rectangles) before validating those values against the bytes actually present in the file, so a 49-byte crafted PSD can force a roughly 3.35 GB allocation. Any service that composites or rasterizes attacker-supplied PSD files - an upload-and-thumbnail pipeline, for example - can be driven out of memory and terminated, and no authentication, privileges, or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Impact is confined to availability, no public exploit has been identified at time of analysis, and the issue is fixed in 1.17.4.
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote caller to read any file accessible to the MCP process and have it uploaded to an attacker-controlled endpoint. The issue affects only deployments running the HTTP transports (streamable-http or sse) with READ_ONLY_MODE=false, where a request that carries X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token but no Authorization header is accepted as a 'pat' identity, so the attacker-chosen Atlassian URL is used to build the attachment client and the confluence_upload_attachment (or Jira attachment) tool accepts an arbitrary server-side file_path. CVSS 3.1 rates it 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact, a public Docker-based proof of concept was confirmed by the reporter so publicly available exploit code exists, and EPSS is low at 0.30% (23rd percentile) with no confirmed actively exploited (CISA KEV) status; version 0.22.0 fixes the flaw.
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network caller abuse the streamable HTTP transport, which accepts requests carrying no user identity and silently falls back to the operator's global Atlassian credentials, to force the upload_attachment tool to read any file readable by the MCP process and push its contents into an attacker-chosen Jira issue or Confluence page, where the attacker can retrieve them. Exploitation requires the server to be running the streamable HTTP transport, reachable by the attacker, and configured with shared operator credentials - stdio-only deployments and deployments that enforce per-user identity/tokens are not exposed - and impact is confidentiality-only (file exfiltration), with no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the underlying issue is a path-traversal flaw (CWE-22) fixed in version 0.22.0, and the practical risk is bounded more by who actually deploys this MCP server over the network than by exploit maturity.
MCP Atlassian servers before 0.22.0 write their plaintext OAuth fallback token file using permissions inherited from the process umask, so on a shared host with a permissive or default umask another local account can read the file and reuse the stored refresh and access tokens for Atlassian (Confluence/Jira) access. The flaw is a local, multi-user exposure rather than a remote one: the attacker must already hold a separate account on the same machine and the deployment must actually use the plaintext fallback storage path, which is why the independent assessment scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N instead of the vendor's AV:N rating. Because the leaked refresh token keeps working even after access-token rotation, credential rotation alone does not close the exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in the vendor-released version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an accepted MCP caller to read arbitrary files from the host on which the server runs: the confluence_upload_attachment tool opens a caller-supplied file_path after only converting it with os.path.abspath, with no check that the resolved path stays inside the workspace, and then uploads the contents as a Confluence attachment the caller can download back. The vulnerability is an access-gated, confused-deputy arbitrary-file-read (CWE-22, assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, no integrity or availability impact); exploitation requires an authenticated MCP caller (PR:L), a server older than 0.22.0 configured with Confluence credentials that can write attachments, and a space the attacker can read back - single-user local stdio deployments where the caller already owns the host gain nothing. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in version 0.22.0.
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to 0.22.0, where the Jira update_issue tool converts a caller-supplied attachments argument into local filesystem paths and passes them to the attachment upload implementation without any workspace confinement. A caller able to invoke the update_issue tool can therefore use the server as a confused deputy, reading arbitrary files (e.g. credentials, config, SSH keys) readable by the server process and attaching their contents to a Jira issue the caller controls, with confidentiality impact only - no write or code execution through this flaw. Exploitation is access-gated: the vendor rates it AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6), while our independent assessment scores it PR:L/S:U, since a permitted MCP caller and a shared-credential deployment are realistic prerequisites; no public exploit code has been identified at time of analysis.
Crypt::SelfCertificate versions 1.01 through 1.05 for Perl ship embedded malware: the module's generate_certificate routine launches a Python dropper disguised as a certificate sample file, which decodes a base64-obfuscated URL, fetches the response body over HTTP, and executes it in memory under the privileges of the invoking user. Any host that installs one of these CPAN releases and then calls the function is exposed to arbitrary code execution with high confidentiality, integrity, and availability impact (assessed CVSS 3.1 base 7.8, AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H); exploitation is unauthenticated per the vector but requires the victim to install the package and trigger the function, and there is no public exploit identified at time of analysis. Because the payload is fetched and run without writing a script to disk, it behaves as a fileless stage and leaves minimal on-host artifact beyond the installed module itself - a genuine, high-priority supply-chain compromise rather than an inflated score.
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read arbitrary files readable by the server's OS user and exfiltrate them by pushing them to Confluence as attachments. The upload code path converts a caller-supplied file_path to an absolute path without the workspace confinement that had already been added to the download path (CVE-2026-27825), so relative or absolute traversal sequences escape the intended workspace. The independent assessment scores the flaw CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only, no integrity or availability impact), requiring an authenticated caller with access to the MCP tool; the vendor's advisory scored it 8.6 with PR:N and S:C. No public exploit identified at time of analysis, and instances at 0.22.0 or later are not affected.
virtualenv versions prior to 21.7.12 cache and seed pip/setuptools wheels without verifying their bytes, so an attacker who controls the wheel delivery path can substitute a different wheel under the requested distribution, version, and filename and have it injected into every environment virtualenv subsequently creates. The flaw is exploitable unauthenticated but requires an active man-in-the-middle position, a compromised index, or a stale/poisoned mirror, and requires a user to actually create or seed a virtual environment. No public exploit code was identified at time of analysis, and the digest check is intentionally skipped whenever PIP_INDEX_URL, PIP_EXTRA_INDEX_URL, or PIP_INDEX points at a custom index - meaning custom-index users remain unverified even after upgrading.
Command injection in the bash, zsh, and fish activation scripts generated by virtualenv releases prior to 21.7.13 lets a crafted virtual environment path or interpreter Tcl/Tk library path execute arbitrary commands with the privileges of any user who sources the activate script. The root cause is double quoting: values already escaped by shlex.quote are embedded inside an additional quoted context, so the surplus quotes terminate the data-only quoted run and leave shell metacharacters parsed as commands - reaching __VIRTUAL_ENV__ in bash/zsh when a relocated environment's recorded directory is absent, and __TCL_LIBRARY__/__TK_LIBRARY__ in fish. Exploitation requires attacker control of the affected path string plus the victim sourcing the script (CVSS 3.1 score 7.8, AV:L/AC:L/PR:N/UI:R, CWE-78 OS command injection); no public exploit identified at time of analysis, and the flaw is fixed in virtualenv 21.7.13 per PyPA advisory GHSA-p58f-9548-mpm2.
Unauthenticated remote code execution in Open GenAI Stack (ogx-ai, 2026-06-11 build) lets any attacker who can submit a prompt to an affected endpoint execute arbitrary server-side code, because prompt content is rendered as an unsanitized Jinja2 template (CWE-94, classic server-side template injection). The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8), with no authentication, user-interaction, or non-default-configuration prerequisite, so exploitation reduces to reaching the vulnerable template-rendering path. No public exploit code has been identified at time of analysis, and the widely repeated claim that this stack underpins the Meta AI backend for WhatsApp is unconfirmed by any vendor advisory. Real-world risk is bounded by deployment scope: only systems actually running the vulnerable ogx-ai prompt-to-template path are exposed.
Denial of service in SGLang 0.5.20 and earlier: the /generate HTTP endpoint in prefill/decode (PD) disaggregation deployments using the Mooncake KV transfer backend does not validate duplicate bootstrap_room identifiers, so remote unauthenticated attackers who fire concurrent requests carrying the same bootstrap_room value can crash scheduler processes or stall other users' requests until the transfer times out. The attack is trivial and requires no authentication or user interaction (CVSS 4.0 AV:N/AC:L/PR:N/UI:N, availability-only VA:H), but it only affects the non-default multi-node PD disaggregation configuration with the Mooncake backend; single-node and default deployments are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the impact is purely availability-related with no confidentiality or integrity loss.
Unbounded memory allocation in urllib3 (1.10.3 through 2.7.x) lets a malicious or machine-in-the-middle HTTP server exhaust the memory of a Python client process by streaming an unterminated chunk-size line in a 'Transfer-Encoding: chunked' response. Only clients that consume the response through the streaming path (HTTPResponse.stream() or HTTPResponse.read_chunked()) are affected; the non-streaming .read() path was already bounded to http.client._MAXLINE. Exploitation is unauthenticated (CVSS:4.0 vector PR:N, assessed CVSS:3.1 PR:N) but requires the client to reach an attacker-controlled or intercepted endpoint, so SSRF-prone, proxy, crawler, and webhook-fetching services are the realistic exposure; impact is denial of service only (C:N/I:N/A:H, no RCE), and no public exploit identified at time of analysis.
Certificate validation bypass in urllib3 1.26.0 through 2.7.x allows a man-in-the-middle attacker who can impersonate the configured HTTPS proxy to intercept, observe, or modify traffic forwarded through that proxy, and in some configurations to obtain the target TLS client certificate. The flaw only affects applications that route requests through an HTTPS proxy while also setting target-server TLS options - proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, or CERT_NONE - because those target settings are incorrectly applied to the proxy TLS handshake; in particular, cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place and the mutation persists across reused connections, silently disabling proxy certificate verification. End-to-end target TLS via CONNECT tunneling remains protected, and no public exploit identified at time of analysis; the issue is fixed in urllib3 2.8.0.
Argument injection in Weblate's Mercurial backend lets an authenticated user with project-scoped component.edit permission plant a dash-prefixed repository filename that Mercurial later interprets as a command-line option instead of a literal path, resulting in arbitrary command execution with the privileges of the Weblate service account when the repository is next updated. The issue affects Weblate 4.11.1 through 2026.7.1 and is a residual, incomplete fix for CVE-2022-23915; although it carries a CVSS of 8.5, exploitation requires a Mercurial-backed RESX component using the 'Update RESX files' add-on plus a subsequent repository update, so the realistic attack surface is narrow. A vendor patch is available in Weblate 2026.8, and no public exploit identified at time of analysis.
Memory exhaustion in Nicotine+ versions prior to 3.3.11 allows a remote Soulseek peer running a modified client to crash the victim's machine by sending a zlib-compressed peer message crafted as a decompression bomb. The vulnerable code path decompressed incoming peer messages without any cap on the uncompressed output size, so the client inflates attacker-supplied data until the operating system runs out of available memory. No authentication or user interaction is required beyond the victim being connected to the Soulseek network (CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor-published CVSS 4.0 score 8.7); impact is limited to availability, with no data access or code execution, and no public exploit code or CISA KEV entry was identified at time of analysis. Vendor-released patch: 3.3.11.
Deserialization of untrusted data in the GluonTS model-loading component allows arbitrary OS command execution with the privileges of the loading process when a victim loads a crafted serialized model directory in versions before 0.17.0. The flaw is scored 8.4 under CVSS 4.0 (assessed as CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), meaning no authentication is required but exploitation is local and depends on a user actively loading the malicious model artifact; the attacker must first place that artifact in the victim's load path (untrusted model hub, shared directory, or compromised pipeline), and environments that only load self-generated trusted models are not affected. AWS has released a fix in GluonTS 0.17.0 (upstream PR #3304, '[Security] Resolve security issue for torch.load'), and no public exploit code and no confirmed active exploitation were identified at time of analysis; EPSS data was not provided for this CVE.
Improper validation in PyJWT 2.1.0 through 2.14.0 allows an attacker who already holds a stolen sender-constrained (DPoP-bound) access token to replay it without possessing the legitimate holder's private key, because OKPAlgorithm.from_jwk imports an Ed25519/Ed448 private JWK from the d parameter without checking that the public key derived from d matches the declared x. An attacker-supplied JWK that pairs the victim's x with the attacker's own d therefore satisfies RFC 7638 thumbprint binding (cnf.jkt) while all signing operations use the attacker's key. Publicly available exploit code exists (a public gist reproducer), but EPSS is only 0.14% (3rd percentile) and there is no KEV listing - this is a conditional, integration-dependent flaw rather than a default-configuration remote compromise, and standard signature-verification use of PyJWT with trusted server-side keys is not affected.
Denial of service in PyJWT 2.9.0 through 2.13.0: a single malformed RSA JWK embedded in a JWK Set aborts construction of the entire set, causing authentication failures or request-level outages for applications that rely on that key set. The root cause is PyJWKSet's per-key error-skipping logic, which only catches PyJWTError and therefore misses the plain ValueError raised by RSAAlgorithm.from_jwk when an RSA key supplies d/e/n with an incorrect private exponent and omits the CRT parameters. The issue is remotely reachable without authentication or user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N, availability-only), publicly available exploit code exists (no confirmed active exploitation), EPSS is low at 0.35% (26th percentile), and the vendor-released patch is version 2.14.0.
Signature forgery in PyJWT 2.13.0 lets an attacker forge arbitrary JWT claims when an application verifies tokens using both HMAC and asymmetric algorithms and hands a public JWK container (a JWKS document, a bare array, a nested array, or a BOM-prefixed variant) directly to the library as the raw key. Because the version 2.13.0 HMAC key guard only recognizes top-level public JWK objects and misses these container wrappers, public asymmetric key material - which is not secret - is accepted as the HMAC secret, so anyone who knows the target's public key can sign a token with any claims and have it validate. The flaw is an improper-signature-verification issue (CWE-347) rated CVSS 3.1 7.4 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) and unauthenticated in the sense that no credentials are needed, but real-world urgency is lower than the headline score: exploitation requires a non-default application design that mixes algorithm families and passes container-form keys, and no public exploit code or confirmed active exploitation was identified at time of analysis. Vendor-released patch: PyJWT 2.14.0.
Token forgery in PyJWT 2.13.x lets unauthenticated remote attackers mint tokens that the library will accept as authentic: when a public JWK is prefixed with a UTF-8 byte-order mark and passed directly as the raw HMAC secret inside a mixed-algorithm verification path, HMACAlgorithm.prepare_key fails to recognize the material as an asymmetric key and uses the publicly known JWK bytes as the shared secret, so anyone who knows the public key can sign arbitrary claims that verify successfully. The flaw carries an assessed CVSS of 7.4 (integrity-only impact, AC:H, PR:N) and per our independent assessment is conditionally scoped: it requires PyJWT 2.13.0 through 2.13.x, an application that permits HMAC alongside asymmetric algorithms, code that hands a raw public JWK to prepare_key instead of loading it via PyJWK/HMACAlgorithm.from_jwk, and BOM-prefixed key material. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; the vendor-released patch is 2.14.0.
Signature forgery in the PyJWT Python library (versions 2.4.0 through 2.13.x) lets a remote, unauthenticated attacker mint forged HMAC tokens whenever an application is misconfigured to accept both HMAC and asymmetric algorithms and passes a DER-encoded public key as the shared verification secret. PyJWT's HMACAlgorithm.prepare_key only rejected PEM- and SSH-formatted asymmetric keys using textual markers, so a DER public key (SubjectPublicKeyInfo, PKCS1, or a DER x509 certificate) slipped through and its public bytes were used directly as the HMAC secret - meaning anyone who knows the public key can sign valid tokens. The flaw is rated CVSS 7.4 with High attack complexity precisely because it requires that specific non-default application configuration; no public exploit code has been identified at time of analysis, and the vendor-released patch is PyJWT 2.14.0.
Signature forgery in PyJWT before 2.14.0 allows an attacker who knows a target's asymmetric public key to forge HMAC-authenticated JWTs when the application mixes HMAC and asymmetric algorithms and passes asymmetric public-key PEM bytes into HMAC verification. The flaw is in is_pem_format in jwt/utils.py, which fails to recognize all PEM formatting variants accepted by the cryptography loader, causing HMACAlgorithm.prepare_key to treat a mutated public-key PEM as an HMAC secret. Exploitation requires a specific non-default deployment pattern-mixed algorithm verification with raw PEM key bytes-and the assessed CVSS vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N; no public exploit identified at time of analysis, and no CISA KEV status was provided.
JWKS trust-boundary bypass in PyJWT's PyJWKClient allows a configured trusted JWKS endpoint that returns an HTTP 3xx redirect to steer the client to an attacker-chosen host, which is then consumed as authoritative key material; the same mechanism can forward caller-supplied request headers such as Authorization to that destination. Only PyJWT 2.13.0 and earlier are affected (fixed in 2.14.0), and exploitation is not unconditional: it requires the application to actually use PyJWKClient for remote JWKS fetching, attacker influence over the trusted endpoint's redirect response, and - for credential leakage - caller-supplied headers passed into the client, or - for forged-JWT acceptance - a mixed-configuration deployment. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; EPSS is low at 0.16% (4th percentile), and CISA SSVC rates Exploitation as 'none' and Automatable as 'no', so the practical risk sits well below the headline 9.1 base score.
Forged HS256 JSON Web Tokens can be accepted as authentic by PyJWT (pip package PyJWT) versions 2.13.0 through 2.13.x when an application verifies tokens through the PyJWK or PyJWKSet path and its trusted JWK Set already contains a symmetric oct entry with an empty key value ({"kty":"oct","k":""}), an unusual precondition typically caused by a missing Base64URL configuration or secret-manager value. Because the PyJWK verification path passes the decoded zero-length key straight to the HMAC check instead of running it through HMACAlgorithm.prepare_key, unauthenticated remote attackers (CVSS PR:N) who know this pre-existing misconfiguration can independently compute HMAC-SHA256(b"", signing_input) and mint valid tokens carrying arbitrary authenticated claims, giving high confidentiality and integrity impact. Public proof-of-concept exploit code exists, but the issue is not in CISA KEV, EPSS is low at 0.18% (6th percentile), and the independent assessment rates attack complexity as High rather than Low, so the headline CVSS 9.1 overstates real-world urgency; the vendor-released patch is version 2.14.0 (commit f91ed44dd65baaf457f4b3353ed35e98a753934c).
Unauthenticated denial of service in the PyJWT Python library (versions 2.0.0a1 through 2.14.0) allows a remote attacker to crash the calling application's authentication handler by supplying a JWT whose payload is valid JSON but nested roughly 20,000 levels deep. The vulnerable code paths - PyJWKClient.get_signing_key_from_jwt(), the documented JWKS verification flow, and any jwt.decode(token, options={"verify_signature": False}) call - parse the attacker-controlled payload with json.loads before any signature check, and a catch clause that handles only ValueError lets RecursionError escape as an undocumented exception (CWE-248), producing an HTTP 500 or dead worker with no credentials, valid signature, user interaction, or JWKS network lookup required. Publicly available exploit code exists (a PoC gist is referenced in the advisory data) and CISA's SSVC assessment rates the issue as automatable with partial technical impact; EPSS is low at 0.29% (20th percentile) and there is no indication of confirmed active exploitation. Impact is confined to availability - no data exposure, integrity loss, or code execution.
Unauthenticated attackers can amplify outbound HTTP traffic from any application that validates JWTs with PyJWT's PyJWKClient against a remote JWKS endpoint, because prior to 2.14.0 an unknown 'kid' in the token header forces a full JWKS refresh on every call with no negative cache or minimum refresh interval. One attacker request produces one outbound JWKS fetch plus full JSON parsing on the victim server, and because the 'kid' is read from the unverified token header, no valid token or authentication is required - even enabling key caching does not help, since a repeated identical unknown 'kid' re-fetches every time. A verified proof-of-concept exists (CISA SSVC records exploitation as 'poc', no CISA KEV listing), so this is treated as publicly available exploit code; EPSS is low (0.35%, 27th percentile). The issue is fixed in 2.14.0, which introduces a 30-second cooldown between forced refreshes.
Signature verification bypass in Authlib 1.7.2 and earlier allows unauthenticated remote attackers to have crafted JWS JSON Serialization payloads accepted as valid, because JsonWebSignature.deserialize_json() returns the payload without checking for a signature or requiring a cryptographic key. The flaw affects applications that use that method to process incoming tokens and then trust the returned payload for authentication, authorization, or integrity decisions; applications using only compact JWS or independently verifying signatures are not exposed. No public exploit code has been identified at time of analysis, and EPSS is low at 0.12% (2nd percentile), but the issue is remotely exploitable with no authentication or user interaction and is assessed as high severity.
Authentication bypass in the LiteLLM proxy lets any party who already holds a valid JWT issued by the configured external identity provider impersonate an existing user - including accounts with proxy_admin privileges - by presenting a token whose unverified email claim matches the victim's address. The JWT authentication flow performs an email-based fallback lookup without validating the email_verified claim, so the attacker inherits the victim's role and can permanently overwrite the victim's stored identity binding, retaining persistent access to administrative endpoints that expose API keys and user management. The attacker must possess a legitimately signed token from the same IdP (CVSS PR:L, AC:H), deployments that do not use JWT/IdP authentication are unaffected, and publicly available exploit code exists; no confirmed in-the-wild exploitation has been reported.
Unauthenticated access to Bluehood's /api/* endpoints in releases before 0.7.1 lets any network attacker who can reach the dashboard HTTP port read Bluetooth tracking data and rewrite application state - the heartbeat URL, prune retention, device groups and per-device notes - whenever the operator has enabled the opt-in auth_enabled setting. The root cause is a missing authorization check: only the HTML page handlers called the session-validation routine, while the settings, devices, groups and /api/device/{mac}/notes handlers performed no check at all, allowing requests carrying no session cookie to succeed (CWE-306, CVSS 3.1 9.1 with PR:N/AC:L). Real-world urgency is tempered by the niche deployment and the fact that the dashboard must be reachable over the network rather than bound to localhost; no public exploit code has been identified at time of analysis and the CVE is not listed in CISA KEV.
Server-side request forgery in fast-mcp-telegram prior to version 30.1 allows an authenticated MCP client (CVSS PR:L) to make the server fetch arbitrary internal HTTP(S) endpoints and receive the response body back as a Telegram file attachment. The send_message and send_message_to_phone tools accept URL lists that the server downloads via httpx.AsyncClient.get, but the _validate_url_security guard only inspects the literal hostname string and never resolves DNS, so any attacker-controlled domain that resolves to a loopback, private, or link-local address passes validation - even with the secure defaults block_private_ips=True and allow_http_urls=False. Because the fetched content is exfiltrated through the Telegram attachment rather than merely observed, this is a full-read SSRF; exploitation requires an authorized MCP session and a resolving hostname (raw private-IP literals remain blocked), and no public exploit code was identified at time of analysis.
Loading a malicious model into Unsloth Zoo 2025.9.9 through 2026.8.13 (as shipped in Unsloth 2025.9.9 through 2026.8.19) lets that model's config.json run arbitrary Python in the loading user's process, because a nested model_type value containing a newline escapes into an exec()-generated import statement. Exploitation requires the victim to load an attacker-controlled model for training or inference - a user-interaction gate, but no authentication on the attacker side (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H; vendor score 8.6). No public exploit code has been identified at time of analysis, and the practical exposure is concentrated in pipelines that automatically ingest third-party or user-supplied models from public hubs rather than those loading only vetted first-party checkpoints.
OS command injection in aaPanel BaoTa through 11.8.0 lets an authenticated panel operator execute arbitrary shell commands on the underlying host by supplying a crafted Password value to the archive-extraction routine. The defect sits in the function panelTask.bt_task._unzip within /www/server/panel/class/panelTask.py, and because the panel normally runs as root a successful injection yields full server compromise; a user-interaction step is required to invoke the unzip workflow. Publicly available exploit code exists (disclosed via a public gist referenced by VulDB), the vendor was contacted early but did not respond, and no vendor-released patch has been identified at time of analysis - this is the third near-identical command-injection flaw in the same release line alongside CVE-2026-101007 and CVE-2026-101008.
Command injection in the aaPanel (BaoTa) server management panel through version 11.8.0 lets an authenticated high-privilege panel user execute arbitrary operating-system commands by manipulating the split_file_path argument handled by merge_split_file in /www/server/panel/class/files.py. The flaw is network-reachable and requires no user interaction, but it demands an existing administrator-level session (PR:H), so realistic risk is concentrated on panels with untrusted account holders, exposed management interfaces protected by weak or default credentials, or environments where admin credentials have already been stolen. Publicly available exploit code exists, exploitation evidence is rated E:P, and the vendor was contacted early but did not respond, so no fix is currently available; this is a genuine but conditional risk rather than a pre-auth emergency.
OS command injection in aaPanel/BaoTa versions up to 11.8.0 allows an authenticated attacker with access to the administrative interface to execute arbitrary operating system commands on the underlying host by manipulating the Password argument during a database backup operation. The vulnerability requires user interaction to trigger the backup workflow, but because aaPanel typically runs with root privileges, successful exploitation leads to full host compromise. A public exploit has been disclosed and may be used, though there is no confirmed active exploitation (CISA KEV) at this time.
python-utcp versions before 1.1.4 allow server-side request forgery through the utcp-http plugin's HttpCommunicationProtocol.call_tool, which validates the initial tool URL but follows HTTP redirects with no per-hop re-validation, so an attacker-controlled tool endpoint can return a 3xx Location that drives the UTCP client into internal HTTP services or the cloud metadata endpoint (169.254.169.254) and returns the response body to the tool caller. The vulnerable path is the core UTCP pattern of registering a tool or manual/OpenAPI spec from a runtime-supplied URL and then invoking it; the initial URL only needs to pass ensure_secure_url (any https:// or a benign attacker-owned host), with the attacker supplying the redirect. Exploitation is remote and requires no privileges (CVSS 4.0 PR:N, assessed as CVSS:3.1 AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N), but it is gated on the host ingesting and invoking an attacker-influenced tool spec and on an internal HTTP service being reachable from the client, which keeps practical priority moderate rather than critical; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 1.1.4.
Credential exfiltration and server-side request forgery in utcp-http 1.1.3 and earlier allow an attacker who supplies a malicious OpenAPI specification to redirect a victim's OAuth2 client_id and client_secret to an arbitrary token endpoint. The library validates discovery and tool-invocation URLs via ensure_secure_url() but never applies the same guard to the OAuth2 tokenUrl taken from a remote spec, so the attacker-chosen endpoint receives the credentials in cleartext when a generated OAuth2-protected tool is invoked. Exploitation requires victim interaction (the victim must register the attacker-controlled spec and call the generated tool) and no attacker authentication; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N (7.1), with the unvalidated endpoint also usable for SSRF against internal HTTP ranges. No public exploit identified at time of analysis.
Server-side request forgery in python-utcp (utcp-http) before 1.1.12 allows an unauthenticated remote attacker to cause a victim's client to issue requests to loopback services and return response bodies if the victim registers a malicious UTCP manual served from a non-loopback origin. Exploitation requires user interaction (registering the manual) and is limited to loopback interfaces, with further prerequisites of a loopback service that answers unauthenticated requests with useful data. No public exploit code exists, and the issue is fixed in utcp-http 1.1.12; this is a conditional-severity issue rather than a mass-exploitation threat.
Heym deployments prior to 0.0.53 leave their Telegram webhook endpoints without verification of the X-Telegram-Bot-Api-Secret-Token header whenever the endpoint has no credential_id or an empty secret_token, so remote unauthenticated attackers who know the webhook URL can POST forged Telegram updates and cause the owner's configured workflows to run with the owner's stored credentials. The flaw is a fail-open authentication check (CWE-287) rated 8.3 with an assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N profile - confidentiality exposure is limited while integrity impact is high, since attacker-supplied input is processed under the victim's credentials. No public exploit code has been identified at time of analysis, and exploitation requires the precondition of an unset or empty secret token plus at least one workflow wired to Telegram updates.
Forged Slack webhook events can trigger Heym workflows with the owner's credentials because Heym before 0.0.53 skips Slack request-signature verification whenever a Slack trigger node has no credential ID or an empty signing secret (a fail-open code path). The bypass is unauthenticated (CVSS 4.0 PR:N) but conditionally gated: it only works against trigger nodes that are misconfigured this way, and the attacker must know or discover the target's webhook URL - a properly configured node with a valid signing secret is not exploitable, which is why the assessed severity carries AC:H. Impact is primarily integrity (I:H) with limited confidentiality exposure (C:L), and the vendor fixes it in 0.0.53 by making signature verification fail closed; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Python eval()-based remote code execution in Heym (heymrun/heym) before 0.0.53 lets an authenticated user who can edit a workflow branch or condition node - or a victim who imports a workflow template containing a malicious condition node - run arbitrary Python as the backend process user whenever the workflow executes. The same release bundles four further flaws: fail-open Slack and Telegram webhook verification that allows unauthenticated workflow triggering with the owner's credentials when a trigger node has no credentialId or an empty signing secret, an OAuth redirect_uri scheme-validation gap that permits javascript:/data: URIs and script execution in the Heym origin, and plaintext storage of WorkflowExecutionToken, PortalSession, HITLRequest.public_token and OAuthAuthorizationCode values. No public exploit code and no confirmed in-the-wild exploitation were identified at time of analysis, and the 0.0.x pre-release product has a very small deployment base.
Sandbox escape in the heym workflow platform before 0.0.91 allows an authenticated user who can author or edit workflow expressions to execute arbitrary Python and run operating-system commands as the backend process. The flaw lives in the expression engine's DotList map/filter item expressions and its fallback resolver, which fail to block dunder attribute traversal, letting an attacker chain attributes to reach functions such as os.system. Exploitation requires a valid account with workflow-authoring rights (PR:L) but no user interaction, making this a network-reachable, low-complexity compromise of confidentiality, integrity, and availability; no public exploit code has been identified at time of analysis and there is no CISA KEV confirmation of active exploitation.
Deserialization of untrusted data in MONAI's auto3dseg utility (monai/auto3dseg/utils.py) allows arbitrary code execution when algo_from_pickle() is called on an attacker-supplied .pkl file: the function reads the raw file bytes and hands them to pickle.loads() without any source or content validation, so any object defining __reduce__ runs in the victim application's context. Exploitation is conditional rather than remote-against-a-service: an attacker must first deliver a malicious pickle (model exchange, shared storage, or a pipeline input) and the victim's code must invoke this specific function, and per the authoritative assessment the vector is local with user interaction required (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) rather than unauthenticated network exploitation. A working proof-of-concept is documented in the upstream GitHub advisory GHSA-89gg-p5r5-q6r4 (publicly available exploit code exists), but there is no confirmed active exploitation (CISA KEV).
Arbitrary code execution in MONAI versions prior to 1.6.0 occurs when a crafted .npy or .npz file is loaded through the NumpyReader class, which hardcodes numpy.load with allow_pickle=True. An unauthenticated attacker who can place a malicious file on a path the victim opens can trigger pickle deserialization, leading to full compromise of confidentiality, integrity, and availability. Exploitation requires user interaction (the victim must load the file) and the attack vector is local; no public exploit code has been identified at time of analysis.
OS command injection in MONAI's nnUNetV2Runner (monai.apps.nnunet.nnunetv2_runner) allows arbitrary command execution with the privileges of the user running an nnU-Net training or validation job, because values such as dataset_name_or_id from a YAML config - or from CLI/kwargs arguments - are concatenated into a command string and passed to subprocess with shell=True without quoting or validation. All MONAI releases before 1.6.0 are affected; exploitation is not network-facing and requires the victim to load an attacker-supplied configuration file and then launch a job such as train_single_model(), so the real-world risk is config-trust dependent rather than remotely triggerable. Publicly available exploit code exists (a Windows-verified proof of concept is included in the GHSA advisory), no authentication is required in the assessed vector (PR:N), and no confirmed active exploitation (CISA KEV) has been reported at time of analysis. Vendor-released patch: MONAI 1.6.0.
Deserialization of attacker-controlled pickle data in MONAI's Auto3DSeg module (monai/auto3dseg/utils.py) lets code run inside any process that calls algo_from_pickle() on a file the attacker can supply or substitute, with full read/write/execute impact on that process and its data. Versions before 1.6.0 are affected (pip package monai < 1.6.0, CPE cpe:2.3:a:project-monai:monai); the vulnerable pickle.loads() at line 321 fires before any isinstance or key checks, so no special configuration flag is needed to reach the sink. The exposure is conditional rather than remote: the vector is local (AV:L) with passive user interaction (UI:P) - a victim, typically a medical-imaging or ML pipeline exchanging algorithm bundles or model checkpoints, must load the crafted .pkl file, and no authentication is required on the loading side (PR:N) - scored 8.5. There is no evidence of confirmed active exploitation (no CISA KEV entry), but publicly available exploit code exists: the upstream advisory ships a working proof-of-concept, and users who upgraded to v1.5.2 believing GHSA-89gg-p5r5-q6r4 fixed this remain fully vulnerable because that earlier patch was never actually implemented in the code.
MONAI through 1.6.0 lets a user who can supply or tamper with a bundle's metadata achieve code execution by abusing an eval()-based sandbox in _get_fake_spatial_shape() (monai/bundle/scripts.py). The vulnerable function screens shape expressions with a helper that walks the AST and only rejects ast.Name nodes outside the 'p'/'n' allowlist, so payloads assembled purely from constants and attribute, subscript, or call nodes - such as "(1).__class__.__bases__[0].__subclasses__()" - pass validation and then reach eval(), enabling object-introspection chains that escape to arbitrary code execution. The path is reachable through the non-default bundle 'verify_net_in_out' CLI verification flow (_get_real_input_data / verify_net_in_out), so exploitation is limited to authenticated local users (CVSS:3.1/AV:L/AC:H/PR:L/UI:N, CVA:H) who run that verification on an untrusted or modified bundle; default MONAI workflows that never verify untrusted bundles are not exposed, and no public exploit code was identified at time of analysis.
Local code execution in MONAI 1.6.0 and all released versions allows an authenticated low-privileged local attacker to run arbitrary code as another user by writing a malicious pickle file to a shared or world-writable MONAI cache directory (e.g., /tmp/monai_cache, HPC scratch, ~/.cache/monai). The victim must subsequently run a PersistentDataset pipeline that caches MetaTensors (the default in MONAI >= 1.0), which forces torch.load(weights_only=False) and pickle.loads on the poisoned file. No vendor-released patch identified at time of analysis; no public exploit identified at time of analysis.
MONAI through 1.6.0 will execute arbitrary code in the victim's process when it loads an attacker-supplied bundle, because the bundle configuration engine resolves '_target_' values to any importable callable without an allow list and passes '$' expressions straight to Python's eval(). An attacker who publishes or shares a crafted bundle achieves code execution as soon as an operator calls monai.bundle.load() or monai.bundle.run() on it; no credentials are required against the victim (PR:N), but the attack does depend on user interaction (UI:R) since the operator must obtain and load an untrusted bundle, and the payload runs with the privileges of the loading process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis; the primary exposure is to environments that pull third-party or community-contributed MONAI bundles rather than first-party trusted ones.
GitPython before 3.1.62 is vulnerable to a path traversal (CWE-22) in Submodule.update() that allows unauthenticated remote attackers to create, populate from a submodule URL, and potentially delete directories outside the repository working tree when an application updates submodules at a non-HEAD (historical) commit. The flaw stems from the `path` field in an untrusted .gitmodules file being used without the _to_relative_path() containment guard that is applied in add() and move(). Exploitation requires an application flow that checks out submodules at a historical commit and an attacker-controlled repository; the standard clone-then-update flow re-derives the path from a canonical tree lookup and is not affected. No public exploit code or confirmed active exploitation (CISA KEV) exists at time of analysis, and the independent assessment rates real-world priority as low-to-medium despite the vendor's CVSS 4.0 score of 8.7.
Denial of service in vLLM before 0.29.0 allows an authenticated API user to permanently disrupt the inference service with a single malformed request to the OpenAI-compatible POST /v1/completions or POST /v1/chat/completions endpoints. The server accepts user-supplied stop_token_ids and checks only that they are integers, not that they fall within the model's vocabulary/logits range; when min_tokens > 0 those ids are used as logits indices to suppress stop tokens, so an out-of-range value reaches a CUDA index_put_ operation and trips a device-side assertion that returns HTTP 500 and leaves EngineCore in a fatal state until the service is restarted. The impact is bounded to availability (no code execution or data disclosure) and exploitation requires valid API credentials plus exposure of the OpenAI-compatible endpoints; no public exploit code was identified at time of analysis, and the vendor has released a fix.
Pinned vLLM deployments (0.22.1 through 0.28.0) running the FunAudioChat or Tarsier2 architectures silently ignore the operator's --revision/--code-revision pin for several Hugging Face artifacts, allowing a subsequent change to the upstream repository's default branch to alter audio preprocessing, speech-tokenizer behavior, or Tarsier2 configuration without any change to the operator's configured pin. The result is a supply-chain integrity and reproducibility failure rather than a code-execution flaw: the advisory explicitly states it is residual to CVE-2026-47155 / GHSA-3ww4-5jv9-j5gm and does not constitute remote code execution or a trust_remote_code=False bypass, despite an 'RCE' tag appearing in some threat-feed metadata. There is no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); exploitation requires the narrow combination of an affected architecture, an operator using a revision pin, and an actor able to modify the upstream Hugging Face repository's default revision, so default general-purpose vLLM deployments are unaffected.
Out-of-vocabulary stop_token_ids in vLLM 0.22.0 through 0.23.0 cause a CUDA tensor indexing failure that drives EngineCore into a fatal state and forces a manual service restart. The trigger is a generation request that simultaneously sets min_tokens greater than zero and includes stop_token_ids outside the model's vocabulary bounds, slipping past missing validation in the Rust HTTP and gRPC frontends to reach MinTokensLogitsProcessor; CVSS 4.0 scores this 8.2, but the assessed impact is availability-only (C:N/I:N/A:H) and deployments enabling vLLM's optional API-key authentication would require a valid key, so real-world severity is lower than the headline score. No public exploit code or confirmed active exploitation is identified at time of analysis (not in CISA KEV), and a vendor patch is available per advisory GHSA-qff2-492f-9fm4, with ENISA EUVD-2026-87746 recording the affected range as 0.22.0 up to but not including 0.24.0.
Denial of service in vLLM deployments running versions before 0.29.0: an attacker with low-privilege access to the disaggregated serving endpoint /inference/v1/generate can submit an overlong token_ids list accompanied by a 'features' (multimodal) payload, bypassing prompt-length validation and causing a worker failure that takes down inference capacity. The issue is availability-only (no confidentiality or integrity impact) and is reachable over the network without user interaction, but exploitation requires that the deployment run in non-default disaggregated serving mode with a multimodal model whose processor reports skip_prompt_length_check=True (Nemotron Parse, Whisper, or FireRedLID), so standard single-node text-only vLLM installations are not exposed. Vendor-released patch: 0.29.0; no public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV.
Pre-inference resource exhaustion in vLLM up to and including 0.29.0 lets remote attackers force the API server or batch runner to fully download, base64-decode and materialize attacker-controlled media before the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed-audio cap (25 MB default) and the per-modality --limit-mm-per-prompt item limits are enforced. Four ingress paths are affected - the shared media-acquisition layer (HTTPConnection.get_bytes()/async_get_bytes()), the chat completions audio_url/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route - with the /tokenize path unauthenticated by design and the chat/batch surfaces gated only when an API key is actually configured, so an attacker can allocate memory and consume outbound bandwidth proportional to an attacker-chosen body size or media-item count. Impact is availability-only (no code execution or data disclosure); the vendor CVSS 4.0 vector scores 7.1 with PR:L, while the independent assessment scores it 7.5 under CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) to reflect the unauthenticated /tokenize path, and no public exploit code was identified at time of analysis.
OpenClaw npm package versions 2026.3.28 through 2026.8.0 can be coerced into executing attacker-supplied Python code when an operator opens OpenClaw against an untrusted workspace whose .env file sets CLOUDSDK_PYTHON_ARGS and then runs the Gmail setup flow. The poisoned value is inherited by the gcloud launcher, which forwards it as arguments to the trusted Python interpreter, giving the attacker code execution with the OpenClaw host user's permissions - enough to read credentials, modify files, or spawn further processes. The issue is rated 8.5 (CVSS 4.0 AV:L/AC:L/AT:N/PR:N/UI:P; independent assessment CVSS 3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) and is fully local and interaction-dependent: the malicious workspace content must already be present and the operator must both launch OpenClaw on it and actively trigger Gmail setup, so it cannot be fired remotely or unattended; no public exploit code was identified at time of analysis. Version 2026.8.1 fixes the flaw.
Authenticated code injection in Horilla HR (horilla-hr) before 2.0.0 lets any user with access to the HorillaListView export functionality run arbitrary operating-system commands with the privileges of the application process - root, in the project's shipped horilla/horilla-hr Docker image. The issue is rated CVSS v3.1 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H): exploitable remotely over the network with low privileges, requiring only a valid account able to reach the list/export endpoint, with no user interaction and no non-default configuration. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor released a fix in version 2.0.0.
Reflected cross-site scripting in Horilla HR (horilla-hr) before 1.6.0 allows a remote, unauthenticated attacker to execute arbitrary JavaScript in the browser of an authenticated employee or administrator by tricking that user into opening a crafted link to /employee/employee-filter-view. The search parameter is written into the DOM through jQuery's .html() in employee/templates/employee_nav.html, so the injected markup is rendered and executed rather than displayed as text; because the payload runs in the victim's session, the attacker can read browser-visible session data and perform actions with the victim's application privileges. There is no public exploit identified at time of analysis and the flaw is not confirmed actively exploited (CISA KEV); impact is capped at the client/browser layer (VC:H/VI:H but VA:N and no scope change to the server in the vendor's CVSS 4.0 vector, with our independent assessment scoring CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
The AetherBrowser API server shipped with SCBE-AETHERMOORE versions 4.0.2 through 4.2.0 exposes the POST /api/ops/check-email endpoint with no authentication check whatsoever, letting any remote, unauthenticated attacker invoke the email_reader.py subprocess, which logs into configured ProtonMail or Gmail accounts over IMAP and returns email metadata (sender, subject, and body snippets) in the JSON response. The server listens on 0.0.0.0:8100 by default and sets CORS allow_origins=["*"], so the endpoint is reachable from any network host and callable from any browser origin, though meaningful mailbox disclosure requires that IMAP credentials have actually been configured for the reader. Version 4.2.1 resolves the missing authentication (CWE-306); no public exploit code has been identified at time of analysis.
A tenant isolation bypass in BerriAI LiteLLM versions before 1.101.0-rc.1 lets an authenticated holder of a valid virtual key read other tenants' entries from the semantic cache and, in the worst case, have attacker-supplied tool calls executed under a victim's credentials. The flaw stems from an inconsistency in how the cache layer derives the tenant scope versus the metadata variable name, so semantically similar prompts sent to routes such as /v1/responses and /bedrock/* can collide with and return another tenant's cached response - potentially exposing PII, financial data, or source code. Exploitation requires a multi-tenant deployment with semantic caching enabled and a sufficiently similar prompt to hit the victim's cache entry, and it is rated CVSS 8.7 with a vendor patch already released (commit 16db51e2, fixed in v1.101.0-rc.1); no public exploit code has been identified at time of analysis and the CVE is not in CISA KEV.
Stored cross-site scripting in AIL Framework allows an authenticated attacker who can influence matched, tracked, or tagged content to inject HTML or JavaScript into Bootstrap popovers rendered with data-html="true", executing in a victim analyst's session when they view the affected popover. The vulnerability affects versions prior to the fix commit ee63a0a and requires victim interaction (opening the popover, typically on hover); no public exploit code was identified at time of analysis. A vendor patch is available via the referenced commit, but practical risk is moderate given the authenticated attacker prerequisite, required victim interaction, and the niche threat-intelligence context of the tool.
A server-side request forgery in the VMware datastore driver of OpenStack glance_store lets an authenticated OpenStack user supply a crafted image location URI pointing at an attacker-controlled server, causing the driver's _retry_request function to attach sensitive vCenter authentication headers to that outbound request and disclose them. The deployment must be configured with the non-default VMware/vCenter datastore backend, and the attacker needs an account with the ability to set or override image locations (typically gated behind the set_location / show_multiple_locations policy); SSVC rates the issue as Exploitation=poc with publicly available exploit code on GitHub (sadandbset/CVE-2026-51772-CVE-2026-51773), Technical Impact=total, but Automatable=no, so it is a targeted attack rather than a mass-exploitation candidate and there is no confirmed active exploitation (CISA KEV) at time of analysis. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, base 8.1) reflects high confidentiality impact from credential theft; our independent assessment adjusts the integrity impact to Low because the primary outcome is leakage of authentication material rather than direct modification of data.
The Perl CPAN distribution IO::Socket::SSL::SelfCertificate version 1.00 is itself the attack artifact: its generate_certificate() routine writes a Python script disguised as a certificate file and executes it, causing base64-obfuscated code to be fetched from a hardcoded HTTP URL and run in memory without ever dropping a script to disk. Anyone who installs the 1.00 tarball and calls that function is exposed - a local, unauthenticated action requiring user interaction (assessed CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H), rather than the remote pre-authentication scenario implied by the CNA's 9.8 network vector - and outbound HTTP egress must be reachable for the payload to be retrieved. The advisory notes there are no test scripts or build hooks, so nothing fires automatically at install time and the payload must be manually triggered; no public exploit code beyond the malicious package itself has been identified at time of analysis, EPSS is negligible at 0.12% (1st percentile), and the nearly identical CVE-2026-95831 covers the sibling Crypt::SelfCertificate module.
An integer overflow in the BSON encoder of the MongoDB Python Driver's bundled native C extension (PyMongo before 4.18.2) can cause an out-of-bounds write inside the process hosting the driver when an application encodes a single document built from an unusually large (~2 GB) caller-supplied value. Only builds that link the C extension are affected - the pure-Python BSON fallback is not - and successfully triggering it requires that a large attacker-influenced value actually reach the encoding path, so most applications are exposed only through data they already accept from untrusted sources. The flaw is not confirmed as actively exploited (CISA KEV) and no public exploit code has been identified at time of analysis; the vendor has released 4.18.2 as the fixed version, and because impact is confined to the hosting application's own process, risk is best treated as a genuine but precondition-heavy memory-corruption issue.
Attackers can inject arbitrary additional servers into a PyMongo (MongoDB Python Driver) client's connection topology by smuggling the percent-encoded form of a host-list delimiter (for example %2C) inside a hostname value that an application places into a connection string, because PyMongo decodes percent-escapes before it splits the host list. The request is unauthenticated (CVSS 4.0 PR:N) but carries an attack-requirement prerequisite (AT:P): the target application must build a URI at runtime from a host the attacker can influence, meaning static or hardcoded connection strings are not exploitable. MongoDB's own CVSS 4.0 rating of 8.3 (High) is driven by a high integrity impact - the client may route its authentication exchange and subsequent database operations to the rogue host, which can observe limited information and return altered query results. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in PyMongo 4.18.2.
Authentication bypass in Python Social Auth (social-core) versions prior to 5.0.0 allows unauthenticated remote attackers to impersonate any VK user when an application uses the vk-app backend, as the backend skips signature verification if the auth_key parameter is omitted. An attacker can forge callback fields such as viewer_id, access_token, api_id, and api_result to authenticate as an arbitrary VK identity, potentially taking over accounts in the target application. The vulnerability is fixed in version 5.0.0, and no public exploit code or active exploitation has been identified at this time.
Path traversal in the pulpcore content upload API allows an authenticated user holding only low-privilege file-repository permissions to read arbitrary files accessible to the Pulp server process by submitting a crafted 'file:' URL through the 'file_url' parameter, which is dispatched to the file downloader despite an intended scheme check. Baseline impact is confidentiality loss on the Pulp host; in deployments that include Pulp Container the same flaw escalates to theft of the container registry token signing private key, enabling forged bearer tokens and unauthorized access to every private container repository in the registry. Downstream products embedding pulpcore are affected, including Red Hat Satellite 6, Red Hat Ansible Automation Platform 2, and Red Hat Update Infrastructure 4/5. There is no public exploit identified at time of analysis, and EPSS data was not provided; Red Hat tracks the issue under advisory https://access.redhat.com/security/cve/CVE-2026-90959.
Command injection in the automation controller's external logging (rsyslog) configuration of Red Hat Ansible Automation Platform 2 allows a superuser to achieve arbitrary command execution inside the control-plane rsyslog component, exposing the controller SECRET_KEY and database credentials and enabling decryption of all stored credentials. Exploitation requires authenticated superuser privileges (CVSS 3.1 7.2, PR:H, no user interaction) and only takes effect when external logging is in use, so the malicious RainerScript configuration is actually generated and loaded. No public exploit code was identified and there is no CISA KEV listing indicating active exploitation, meaning real-world risk is strongly gated by the elevated privilege requirement even though the post-exploitation impact is a full control-plane compromise.
Missing authorization checks in the Red Hat Ansible Automation Platform 2 automation-controller allow an authenticated organization workflow-admin - a delegated, non-superuser role - to escalate into the control plane by copying a WorkflowJobTemplate and then launching jobs pinned to instance groups they hold no use_role on. The deep-copy permission sanitizer re-validates only the inventory, unified_job_template, and credentials of each cloned node, silently carrying over instance_groups, execution_environment, and labels, so the copier becomes administrator of a workflow that executes attacker-influenced automation in the control-plane execution context (CVSS 9.9, scope changed, high confidentiality, integrity, and availability impact). Exploitation is confirmed to require only a normal multi-tenant deployment plus workflow-admin rights; no public exploit code has been identified at time of analysis and there is no CISA KEV entry, and no vendor-released patch version was confirmed in the available intelligence.
Authenticated but low-privileged users of Red Hat Ansible Automation Platform 2 can bypass the automation-controller's sanitize_jinja() input-validation guard and have ansible-core evaluate attacker-supplied Jinja inside the execution environment, yielding arbitrary command execution and disclosure of secrets belonging to credentials the attacker cannot normally read. The flaw is exploitable remotely with no user interaction (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N per independent assessment) and requires only a controller account able to set one of the affected launch-time fields. No public exploit code has been identified at time of analysis, and the issue is not listed in CISA KEV; priority is bounded by the required authenticated foothold and the niche deployment footprint.
Remote code execution in Red Hat Ansible Automation Platform 2's automation-controller is possible when a privileged, authenticated user (CVSS PR:H) defines a custom Credential Type and abuses its environment-variable injector to set a process-hijacking loader variable such as BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP, or GIT_SSH_COMMAND, which the existing ANSIBLE_* prefix check and fixed ENV_BLOCKLIST fail to catch. Paired with the credential file injector, the attacker plants a script in the execution environment and points the loader variable at it, so arbitrary code executes inside the execution-environment container for any job that later attaches a credential of that type; this requires both the high privilege to author the credential type and a subsequent job consuming it. Red Hat's published CVSS of 7.6 (C:L/I:H/A:N) is lower than our independent assessment of the full vector (C:H/I:H/A:H), and because the vulnerable controller and the impacted execution-environment container are different security scopes, S:C applies. There is no CISA KEV listing and no public exploit identified at time of analysis.
An authenticated automation-controller administrator in Red Hat Ansible Automation Platform 2 can turn the administrator-controlled format template for API 4XX log messages into a secret-reading primitive, using Python string-format traversal to walk from the interpolated user object into Django settings and pull out the SECRET_KEY and the database password. Because the log destination (external aggregator) is also administrator-controlled, the formatted message - and therefore the secrets - can be shipped off the host, giving the administrator the master key protecting all stored credentials, the ability to forge signed user sessions, and direct database access; the assessed vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N (8.7) with high confidentiality and integrity impact and scope change, since secrets leave the controller's security boundary. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, so this is a high-priority hardening issue rather than an actively exploited one: the practical risk is driven by the very high value of the assets reachable once a privileged administrator account or the log pipeline is compromised.
Stored cross-site scripting in the automation-controller component of Red Hat Ansible Automation Platform 2 lets an authenticated low-privileged user embed a javascript: hyperlink into job, ad hoc command, project update, or inventory update standard output, which is then rendered as a text/html link in the controller's stdout view. Because the HTML conversion escapes HTML metacharacters but never strips ANSI terminal escape sequences, an OSC 8 hyperlink becomes an unfiltered HTML anchor, and the response carries no Content-Security-Policy; a higher-privileged user (for example an administrator) who views that output page and clicks the link executes attacker-controlled JavaScript in their authenticated session, allowing actions up to full platform takeover. The vector is network-reachable with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7), but exploitation hinges on a privileged victim actively clicking the crafted link; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Authenticated remote code execution in OpenC3 COSMOS (Ruby gem 'openc3' versions 5.1.0 through 7.2.1) lets any logged-in user, including one with only low-tier permissions, execute arbitrary Ruby and Python code on the COSMOS server and its per-target decom microservices. COSMOS reads configuration from a user-writable overlay (targets_modified/) before its read-only targets/ tree and then executes that content - rendering it as ERB, eval-ing GENERIC_READ/WRITE_CONVERSION blocks, or require-ing Script Runner procedure files - so an attacker who can write to the overlay via the screen-save or storage-upload endpoints achieves code execution as the openc3 user, which holds Redis and object-store credentials and sits on the internal service network. A working proof-of-concept is published in the vendor GitHub advisory, and the vendor has released 7.3.0 as the fix; no confirmed active exploitation (CISA KEV) has been reported. Reachability is limited on default single-host installs because the shipped docker-compose binds Traefik to 127.0.0.1:2900, so exploitation is realistic on multi-user deployments that expose the web port.
Authenticated OS command injection in OpenC3 COSMOS 5.12.0 through 7.2.1 allows a user with a valid session to run arbitrary operating-system commands as the openc3 service user by writing shell metacharacters into the pypi_url setting and then installing a plugin that carries Python dependency metadata. The injected value is interpolated into a shell backtick inside PluginModel.install_phase2, so commands execute with access to the service's Redis and bucket storage credentials; in the open-source edition any authenticated user can reach both the setting-write and plugin-install operations, whereas the Enterprise edition requires the administrator role, and the vendor has fixed the issue in 7.3.0. There is no CISA KEV listing or confirmed in-the-wild exploitation, but the public vendor advisory GHSA-vp3w-52v9-q57f includes confirmed end-to-end proof-of-concept steps, and the independent assessment rates this as a genuine high-priority issue rather than CVSS inflation.
Stored password survey answers in Red Hat Ansible Automation Platform 2's automation-controller can be recovered in plaintext by an authenticated user holding the delegated JobTemplate Admin role. The attacker tightens the minimum/maximum length constraint on a password-type survey question, then forces revalidation of a schedule or workflow job template node created by a higher-privileged user, causing the controller to decrypt the stored secret and embed it in the HTTP length-validation error response. No public exploit identified at time of analysis; exploitation is not unauthenticated (CVSS PR:L) and requires both the delegated role and an existing password-type survey value, making this a lateral, privilege-crossing credential-disclosure issue rather than a mass-exploitable perimeter break.
Authenticated users who hold permission to create or modify a project within a single organization can execute arbitrary commands on the Ansible Automation Platform 2 automation-controller task pod by setting the Project scm_url to a value beginning with a dash, for example '--upload-pack=<command>:x'. The automation-controller's git SCM module passes that URL verbatim as a positional argument to 'git ls-remote' without a '--' end-of-options separator, so git treats it as the --upload-pack option and executes the attacker's command via a shell, with output reflected through the project update stdout endpoint, enabling cross-tenant compromise and in-cluster lateral movement (CVSS 3.1 9.9, scope changed). Exploitation needs valid platform credentials and the git project type but no admin or cross-organization rights, and no public exploit code has been identified at time of analysis.
Privilege escalation and remote code execution on managed hosts is possible in Red Hat Ansible Automation Platform 2 because the automation-controller exposes the provisioning-callback secret (host_config_key) to anyone holding only read-level view_jobtemplate permission and accepts a client-supplied X-Forwarded-For header as proof of caller identity when the gateway proxy allow-list is empty. An attacker who reads the secret from the job template API representation or the activity stream and spoofs X-Forwarded-For to match any host in the target job template's inventory can launch that template against arbitrary managed hosts using the template's stored credentials; CVSS 3.1 base score is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), no public exploit code was identified at time of analysis, and the decisive enabler is a non-default deployment condition - an empty proxy allow-list combined with provisioning callbacks actually being in use.
Unauthenticated remote attackers can stall job dispatch for every tenant on Red Hat Ansible Automation Platform 2 by repeatedly calling four debug scheduler views that are routed in production builds because their URL include is not gated on the debug setting. Each call lets any network-reachable client acquire the cluster-wide scheduler advisory lock, and since the legitimate scheduler takes that same lock without waiting, genuine scheduler runs are skipped, job dispatch is delayed or halted, and controller web workers are consumed. The debug root view also discloses the list of debug endpoints to unauthenticated callers, and no public exploit code has been identified at time of analysis.
Missing object-level authorization in the JobTemplate copy endpoint (CopyAPIView) of AWX and Red Hat Ansible Automation Platform 2 lets an authenticated user duplicate a JobTemplate they are not permitted to read, disclosing the template's configuration - playbook reference, associated credentials, inventory and extra variables - that RBAC was intended to protect. The root cause is CWE-862 (Missing Authorization): the copy view's GET path enforces a read check on the source object, but the POST path that performs the copy only validates add and copy-related permissions, none of which imply read access on the source template. Per the independent assessment (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N; vendor score 8.5), exploitation requires an authenticated account already holding inventory.use_role, project.use_role, execution_environment.read_role and credentials.use_role, so this is an insider/multi-tenant privilege-boundary flaw rather than unauthenticated remote compromise; no public exploit code was identified at time of analysis.
Remote code execution in MLflow's statsmodel flavor (versions 2.1.0 through 3.14.0) occurs because _load_model() omits the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False safeguard, allowing a crafted MLmodel artifact to trigger unsafe pickle deserialization (CWE-502). An authenticated low-privileged attacker (PR:L) who can register or supply a malicious artifact to the model registry or artifact store can achieve arbitrary code execution when a victim's pipeline or serving process loads it, although the victim must load the untrusted artifact (UI:R). The independent assessment notes that no public exploit was identified at time of analysis (SSVC Exploitation: none), and exposure is limited to environments that load untrusted statsmodel artifacts; those using only trusted internal models are not realistically exposed.
OS command injection in the frictionless-py framework through 5.20.0rc1 lets unauthenticated remote attackers execute arbitrary operating system commands in the victim's security context when the victim runs the `frictionless explore` console command against an attacker-supplied Data Package. The flaw is reachable because resource path values from an untrusted datapackage.json are concatenated unsanitized into a shell invocation (`vd {paths}` via os.system), so shell metacharacters placed in a path are interpreted by the shell rather than treated as a filename. Exploitation requires victim interaction (CVSS UI:A) - the user must deliberately explore the malicious package - and publicly available exploit code exists, including a proof-of-concept repository; there is no data provided indicating confirmed active exploitation, and the assessed CVSS:3.1 vector is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (vendor CVSS:4.0 8.6, PR:N/UI:A), so impact is high on confidentiality, integrity and availability of the user's environment but gate-controlled by the social-engineering step.
Arbitrary code execution in MLflow (versions 2.0 and later) via the dspy flavor, where an attacker-crafted MLflow model artifact causes remote code execution when loaded by a victim. The vulnerability arises because the MLFLOW_ALLOW_PICKLE_DESERIALIZATION=False safety control is enforced only when the model_path ends in '.pkl'; any other path (or extension) silently skips the check and unpickles attacker-controlled data. Per the CVSS vector (AV:N/AC:L/PR:N/UI:R) an unauthenticated remote attacker can exploit this, but success depends on user interaction: a person or automated pipeline must fetch and load the malicious model. Exploitation has not been confirmed as active (not in CISA KEV) and no public exploit code was identified at time of analysis, and CISA SSVC rates exploitation as 'none' with automatable 'no', though technical impact is total (full confidentiality, integrity, and availability loss on the host that loads the model). The CVSS 8.8 score is well-justified by the technical impact rather than inflated.
Remote code execution affects LightLLM deployments through version 1.2.0 that run the KV-transfer worker with the non-default '--pd_trans_mode nccl' option, which exposes an unauthenticated RPyC ThreadedServer control channel on the network. An attacker with network reachability can send a malicious pickled object to that channel, triggering unsafe deserialization and executing arbitrary code with the privileges of the LightLLM service account (CVSS 9.3; PR:N/UI:N). The vulnerability is not known to be actively exploited and no public exploit code has been identified at time of analysis, though the non-default configuration limits exposure to deployments that explicitly enable NCCL-based prefill/decode disaggregation.
Unauthenticated code installation on the Reachy Mini robot daemon (Pollen Robotics) allows any host on the same LAN to execute arbitrary Python code on the robot by posting an attacker-controlled Hugging Face Space to POST /apps/install. The endpoint is reachable without credentials because the wireless variant of the daemon binds to 0.0.0.0, and the handler's dependency chain (Depends(get_app_manager)) never performs an authorization check; the chosen Space's build/setup code is then executed by the daemon via uv or pip. Affected are all Reachy Mini units before the vendor's v1.11.0 patched release (CPE cpe:2.3:a:pollen_robotics:reachy_mini:*); there is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV), though the attacker prerequisites are trivial for anyone sharing the robot's Wi-Fi network. Scoring is AV:A/AC:L/PR:N/UI:N with high confidentiality, integrity and availability impact, consistent with full compromise of the robot host.
Symlink-based path traversal in the `tar` source plugin of Apache BuildStream (versions up to and including 2.8.0, running on Python < 3.12) lets a malicious source tarball write arbitrary files on the host with the privileges of the user running BuildStream, resulting in full confidentiality, integrity, and availability impact to that user's environment. The vendor-published CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), but the assessed vector adds UI:R: exploitation requires the victim to fetch and extract an attacker-controlled or otherwise untrusted source tarball, and it is not exploitable against projects that use only trusted, tracked sources, since SHA256 hash pinning of tracked tarballs prevents MITM substitution. No public exploit code and no confirmed active exploitation were identified at time of analysis (CISA SSVC exploitation: none; EPSS 0.19%, 10th percentile); the vendor-released patch is BuildStream 2.8.1, and hosts running Python >= 3.12 with BuildStream >= 2.3.0 are already protected because the Python `tarfile` extraction filter blocks the symlink escape.
Server-side template injection in web.py 0.76 allows an attacker who can write to the application's template source directory to achieve arbitrary Python code and OS command execution on the server, but only when the application precompiles those templates and later renders them through the precompiled template loader; that specific deployment pattern is what defeats the template engine's built-in sandbox. The flaw is a genuine RCE-class issue (CWE-94) at CVSS 8.5, yet it is gated by real prerequisites: the CVSS vector indicates authenticated access (PR:L) and high attack complexity (AC:H), because the attacker must first obtain write access to the template directory and the application must use the precompiled code path rather than direct sandboxed rendering. It is not a remote-unauthenticated exploit against stock configurations, and no public exploit identified at time of analysis; exploitation is not confirmed actively exploited (CISA KEV) and no KEV entry is present in the source data.
Cross-audience Google ID token reuse in the toolbox-core module of mcp-toolbox-sdk-python causes a credential intended for one service to be silently handed to a different service within the same process. Because the module-level token cache is not keyed by audience, an application that fetches ID tokens for two or more audiences in one process can send a Service A token to Service B; an attacker who operates, compromises, or passively monitors Service B can capture that token and replay it against Service A to impersonate the victim application. Exploitation is unauthenticated against the vulnerable app (PR:N) but conditional: it requires a multi-audience deployment plus attacker visibility into Service B traffic, and the leaked token is time-bounded by its expiry. No public exploit code has been identified at time of analysis, and the flaw is not confirmed as actively exploited (no CISA KEV listing).
Arbitrary server-side code execution in the Plone process is possible through the Classic portlet shipped in plone.app.portlets 5.0.0 through 7.0.1, where user-supplied template and macro fields are assembled into a TALES path expression and then evaluated by the TAL path() helper, allowing a crafted value to be interpreted as a full expression rather than a constrained path. Any authenticated user who can add or edit a Classic portlet can execute code, and under Plone's default role map that includes ordinary registered users on their personal dashboard, so the issue amounts to a post-authentication privilege escalation across the trust boundary between a web user and the server-side Plone process (CVSS 3.1 9.9, scope changed: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). There is no confirmed active exploitation (no CISA KEV listing) and no public exploit identified at time of analysis, but vendor patches are available in 5.0.8, 6.0.4, and 7.0.2.
Denial of service in psd-tools before 1.17.4: PSDImage.composite() and PSDImage.numpy() size their output buffers directly from the geometry declared in an untrusted PSD header (width, height, channels, depth, and per-layer rectangles) before validating those values against the bytes actually present in the file, so a 49-byte crafted PSD can force a roughly 3.35 GB allocation. Any service that composites or rasterizes attacker-supplied PSD files - an upload-and-thumbnail pipeline, for example - can be driven out of memory and terminated, and no authentication, privileges, or user interaction are required (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Impact is confined to availability, no public exploit has been identified at time of analysis, and the issue is fixed in 1.17.4.
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote caller to read any file accessible to the MCP process and have it uploaded to an attacker-controlled endpoint. The issue affects only deployments running the HTTP transports (streamable-http or sse) with READ_ONLY_MODE=false, where a request that carries X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token but no Authorization header is accepted as a 'pat' identity, so the attacker-chosen Atlassian URL is used to build the attachment client and the confluence_upload_attachment (or Jira attachment) tool accepts an arbitrary server-side file_path. CVSS 3.1 rates it 8.6 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) with confidentiality-only impact, a public Docker-based proof of concept was confirmed by the reporter so publicly available exploit code exists, and EPSS is low at 0.30% (23rd percentile) with no confirmed actively exploited (CISA KEV) status; version 0.22.0 fixes the flaw.
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network caller abuse the streamable HTTP transport, which accepts requests carrying no user identity and silently falls back to the operator's global Atlassian credentials, to force the upload_attachment tool to read any file readable by the MCP process and push its contents into an attacker-chosen Jira issue or Confluence page, where the attacker can retrieve them. Exploitation requires the server to be running the streamable HTTP transport, reachable by the attacker, and configured with shared operator credentials - stdio-only deployments and deployments that enforce per-user identity/tokens are not exposed - and impact is confidentiality-only (file exfiltration), with no integrity or availability effect. There is no evidence of active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the underlying issue is a path-traversal flaw (CWE-22) fixed in version 0.22.0, and the practical risk is bounded more by who actually deploys this MCP server over the network than by exploit maturity.
MCP Atlassian servers before 0.22.0 write their plaintext OAuth fallback token file using permissions inherited from the process umask, so on a shared host with a permissive or default umask another local account can read the file and reuse the stored refresh and access tokens for Atlassian (Confluence/Jira) access. The flaw is a local, multi-user exposure rather than a remote one: the attacker must already hold a separate account on the same machine and the deployment must actually use the plaintext fallback storage path, which is why the independent assessment scores it CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N instead of the vendor's AV:N rating. Because the leaked refresh token keeps working even after access-token rotation, credential rotation alone does not close the exposure. No public exploit code has been identified at time of analysis, and the issue is fixed in the vendor-released version 0.22.0.
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an accepted MCP caller to read arbitrary files from the host on which the server runs: the confluence_upload_attachment tool opens a caller-supplied file_path after only converting it with os.path.abspath, with no check that the resolved path stays inside the workspace, and then uploads the contents as a Confluence attachment the caller can download back. The vulnerability is an access-gated, confused-deputy arbitrary-file-read (CWE-22, assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, high confidentiality impact, no integrity or availability impact); exploitation requires an authenticated MCP caller (PR:L), a server older than 0.22.0 configured with Confluence credentials that can write attachments, and a space the attacker can read back - single-user local stdio deployments where the caller already owns the host gain nothing. No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in version 0.22.0.
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to 0.22.0, where the Jira update_issue tool converts a caller-supplied attachments argument into local filesystem paths and passes them to the attachment upload implementation without any workspace confinement. A caller able to invoke the update_issue tool can therefore use the server as a confused deputy, reading arbitrary files (e.g. credentials, config, SSH keys) readable by the server process and attaching their contents to a Jira issue the caller controls, with confidentiality impact only - no write or code execution through this flaw. Exploitation is access-gated: the vendor rates it AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6), while our independent assessment scores it PR:L/S:U, since a permitted MCP caller and a shared-credential deployment are realistic prerequisites; no public exploit code has been identified at time of analysis.
Crypt::SelfCertificate versions 1.01 through 1.05 for Perl ship embedded malware: the module's generate_certificate routine launches a Python dropper disguised as a certificate sample file, which decodes a base64-obfuscated URL, fetches the response body over HTTP, and executes it in memory under the privileges of the invoking user. Any host that installs one of these CPAN releases and then calls the function is exposed to arbitrary code execution with high confidentiality, integrity, and availability impact (assessed CVSS 3.1 base 7.8, AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H); exploitation is unauthenticated per the vector but requires the victim to install the package and trigger the function, and there is no public exploit identified at time of analysis. Because the payload is fetched and run without writing a script to disk, it behaves as a fileless stage and leaves minimal on-host artifact beyond the installed module itself - a genuine, high-priority supply-chain compromise rather than an inflated score.
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read arbitrary files readable by the server's OS user and exfiltrate them by pushing them to Confluence as attachments. The upload code path converts a caller-supplied file_path to an absolute path without the workspace confinement that had already been added to the download path (CVE-2026-27825), so relative or absolute traversal sequences escape the intended workspace. The independent assessment scores the flaw CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only, no integrity or availability impact), requiring an authenticated caller with access to the MCP tool; the vendor's advisory scored it 8.6 with PR:N and S:C. No public exploit identified at time of analysis, and instances at 0.22.0 or later are not affected.