| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Kiteworks Core before version 9.5.0 is vulnerable to Deserialization of Untrusted Data. A deserialization weakness in Kiteworks Core could, under certain conditions, allow crafted data to be deserialized unsafely, potentially resulting in remote code execution on the appliance. Exploitation depends on an attacker first being able to influence the affected data, so this issue is not exploitable on its own. |
| Spring Cloud Gateway Server forwards the X-Forwarded-For and Forwarded headers from untrusted proxies in certain configuration scenarios. This affects both the WebMVC and WebFlux Gateway Servers.
Affected versions:
Spring Cloud Gateway 3.1.x (fix 3.1.13).
Spring Cloud Gateway 4.1.x (fix 4.1.13).
Spring Cloud Gateway 4.2.x (fix 4.2.9).
Spring Cloud Gateway 4.3.x (fix 4.3.5).
Spring Cloud Gateway 5.0.x (fix 5.0.2). |
| LightLLM through 1.2.0 visual_only deployments expose an unauthenticated RPyC service with allow_pickle enabled that deserializes attacker-supplied arguments in the remote_infer_images method. Attackers can reach the visual RPyC port and pass objects with __reduce__ methods to execute arbitrary code with service account privileges. |
| mark3labs mcp-filesystem-server v0.11.1 is vulnerable to Directory Traversal due to an improper link resolution in validatePath (filesystemserver/handler/helper.go). When filepath.EvalSymlinks returns os.IsNotExist for a dangling symlink, the fallback validates only the parent directory and returns the unresolved path, so write_file (and modify_file, copy_file, move_file, create_directory) follows a pre-existing dangling symlink located inside an allowed directory and creates a file outside the configured allowed directories. |
| The HTTPPasswordMgr class in the urllib.request module, along with its subclasses HTTPPasswordMgrWithDefaultRealm and HTTPPasswordMgrWithPriorAuth, did not take the URL scheme into account when matching stored credentials against a requested URL. Credentials added for an https:// URL were also used for requests to the same host over http://, so an attacker able to redirect or downgrade a client to plain HTTP (for example, via an HTTPS-to-HTTP redirect or an on-path position) could capture credentials in cleartext. Credentials added for http:// URLs could likewise be sent over https://.
Credential matching is now scoped by URL scheme. Credentials registered with a URL that includes a scheme are only used for requests with the same scheme. Credentials registered with a bare authority (such as example.com or example.com:8080) continue to match any scheme, preserving compatibility with existing code, including proxy authentication.
Users who cannot upgrade immediately can mitigate by ensuring that applications never make plain http:// requests to hosts for which credentials are registered, for example by not following redirects to http:// URLs. |
| Improper validation of non-secure (NS) pointers in multiple TrustZone-M non-secure callable (NSC) entry functions allows an attacker executing in the non-secure world to supply pointers to secure memory. The secure firmware subsequently dereferences these attacker-controlled pointers without verifying that they reference non-secure memory, resulting in unintended disclosure of secure memory contents. This violates the isolation guarantees provided by Arm TrustZone-M and can be leveraged as a memory disclosure or corruption primitive that may enable recovery of sensitive cryptographic material. |
| Deserialization of untrusted data for some Intel(R) Extension for PyTorch before version 2.8.0 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via local access when attack requirements are not present without special internal knowledge and requires active user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| In CPython 3.13 and earlier, the tarfile module's data and tar extraction filters are vulnerable to crafted archives containing a hard link to a symbolic link. Such archives may cause extraction to modify the permissions or modification time of a file outside the destination directory, or expose the contents of that file within the extracted tree. |
| Apache Airflow's Teradata provider embedded cloud storage credentials directly into SQL statements. `S3ToTeradataOperator` and `AzureBlobStorageToTeradataOperator` interpolate the source bucket's credentials as plain string literals into the `CREATE MULTISET TABLE ... LOCATION` statement whenever the bucket is private and no `teradata_authorization_name` is configured — which is the default credential path for both operators. The statement is then logged and executed, so the credentials reach two places outside the operator's control.
The two operators expose different credentials through different channels, and deployments should check both. `S3ToTeradataOperator` takes its values from `s3_hook.get_credentials()`, which under an instance profile or IRSA returns runtime AWS credentials that were never registered with Airflow's secrets masker — and the STS session token is runtime-generated and therefore unmasked even when an AWS connection is configured. Those credentials appear **in the Airflow task log**, readable by any user with log-view permission on the Dag. `AzureBlobStorageToTeradataOperator` takes its storage account key from the connection, so the masker usually redacts the task-log copy; its exposure is the Teradata side. **Both** operators write the credentials into Teradata's DBQL query logs and live monitoring views, where Airflow's masking never applies and the values persist for that system's log retention period.
Affects deployments using either operator against a private bucket or container without a Teradata `AUTHORIZATION` object. Users are advised to upgrade to `apache-airflow-providers-teradata` `3.7.0` or later, which keeps the credential-bearing statement out of the Airflow task log. Upgrading does not remove the credentials from Teradata's query logs and monitoring views, which Airflow cannot redact: users should configure `teradata_authorization_name` with a Teradata `AUTHORIZATION` object so that credentials are never inlined, and should rotate any credentials previously used through the inline path. |
| Apache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs. The SQL API endpoint is built as `https://{account}.snowflakecomputing.com/api/v2/statements`, so an `account` value containing `/`, `?` or `#` demotes the intended domain to a path, query or fragment and leaves the attacker in control of the request host.
The provider sends that request with an `Authorization: Bearer` header carrying a JWT minted from the connection's private key, or the configured OAuth or programmatic access token. A user who can edit the Snowflake connection but cannot read its secrets — Airflow gives connection-configuration users write-only access to stored credentials, and a `private_key_file` lives on the worker rather than in the connection — can therefore cause a valid token for the account to be delivered to a host of their choosing and replay it against the genuine Snowflake endpoint. No Dag-authoring ability is required: the attacker edits the connection and waits for an existing Dag to use it. The same unvalidated value was also used to build the OAuth token-request URL and the Cortex Agent base URL.
Affects deployments where Snowflake connections are editable by users who are not trusted with the connection's credentials. Users are advised to upgrade to `apache-airflow-providers-snowflake` `6.18.0` or later, which rejects `account` and `region` values containing anything other than letters, digits, `.`, `_` and `-` in every URL the provider builds from them. |
| In Anjvision YSSD‑RTMP‑H5 firmware version 3.3.2.4, two user‑information endpoints can reveal sensitive device and account details under conditions that are not intended for normal operation. |
| The file export endpoint allows any unauthenticated attacker to export arbitrary database tables by sending a crafted POST request. |
| Image Scanner Driver for Linux contains a link following vulnerability. An attacker who can log in to a Linux system where the product is installed may overwrite arbitrary files by using a special method in advance. |
| Pgpool-II inserts sensitive information into log file, which may allow an authenticated attacker to obtain the cluster information. |
| In affected versions of Octopus Server, an authenticated user with permissions to edit an Environment or Project can set specifically crafted JSON content for the object. Insecure deserialization of this content allows the user to execute arbitrary code in the Octopus Server process. |
| Free of non-heap memory in Fonts in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) |
| A trust-boundary flaw in CRI-O's sandbox state persistence allows attacker-influenced pod metadata to overwrite CRI-O's own reserved sandbox bookkeeping; once reloaded as trusted after a restart, a later container recreate in that sandbox can expose a host-side runtime-management resource inside the container, enabling container escape. |
| Contrast (Edgeless Systems) before 1.8.1 logs the workload secret to stderr, and thus to Kubernetes logs, when the Contrast initializer is configured with CONTRAST_LOG_LEVEL set to info or debug. Because info is the default, all installations that do not customize the initializer log level are affected. This exposes workload secrets — normally accessible only to the Contrast Coordinator, the initializer, the seedshare owner, and the workload owner — to Kubernetes users with get or list permission on pods/logs and to anyone with read access to the Kubernetes log storage, such as the cloud provider. Deployments that do not use workload secrets are unaffected. |
| In MONAI 1.6.0, PersistentDataset (monai/data/dataset.py) explicitly rejects the combination track_meta=True with weights_only=True, forcing users who cache MetaTensors (the default tensor type in MONAI >= 1.0) to run torch.load(hashfile, weights_only=False). Related cache helpers in monai/data/utils.py also call pickle.loads on cached content and derive cache keys with hashlib.md5. As a result, a local user with write access to a shared or world-writable cache_dir (e.g. /tmp/monai_cache, HPC scratch, ~/.cache/monai) can place a malicious pickle file that is deserialized the next time another user's MONAI pipeline reads the cache, resulting in arbitrary code execution in that user's context. All released versions of the monai pip package are affected; no patched version is available as of the advisory. |
| Sandbox escape due to incorrect boundary conditions in the Graphics component. This vulnerability was fixed in Thunderbird 140.17, Firefox 156, Firefox ESR 153.3, Thunderbird 156, Thunderbird 153.3, Firefox ESR 115.42, and Firefox ESR 140.17. |
