CVEs

Stored cross-site scripting (XSS) vulnerability in pgAdmin 4 Browser Tree and Explain Visualizer modules. User-controlled PostgreSQL object names (database, schema, table, column, etc.) were assigned to DOM elements via innerHTML, allowing crafted object names containing HTML markup to execute attacker-supplied JavaScript in the browser of any pgAdmin user who navigated to or executed EXPLAIN over the malicious object. Fix replaces innerHTML with textContent. This issue affects pgAdmin 4: before 9.15.

Authorization vulnerability in pgAdmin 4 server mode affecting Server Groups, Servers, Shared Servers, Background Processes, and Debugger modules. Multiple endpoints fetched user-owned objects without filtering by the requesting user's identity. An authenticated user could access another user's private servers, server groups, background processes, and debugger function arguments by guessing object IDs. Additionally, the Shared Servers feature contained multiple issues including credential leakage (passexec_cmd, passfile, SSL keys), privilege escalation via writable passexec_cmd (a shell command executed when establishing the connection) allowing arbitrary command execution in the owner's process context, and owner-data corruption via SQLAlchemy session mutations. Several owner-only fields (passexec_cmd, passexec_expiration, db_res, db_res_type) were writable by non-owners through the API, and additional fields (kerberos_conn, tags, post_connection_sql) lacked per-user persistence so non-owner edits mutated the owner's record. Fix centralises access control via a new server_access module, scopes all user-owned models with a UserScopedMixin, returns HTTP 410 from connection_manager when access is denied in server mode, suppresses owner-only fields for non-owners across the merge / API response / ServerManager paths, and adds an explicit owner-only write guard. The remediation landed in two pull requests; both are referenced. This issue affects pgAdmin 4: before 9.15.

An arbitrary file write vulnerability exists in Casdoor's Local File System storage provider. Due to insufficient path sanitization, an authenticated attacker with administrative privileges can perform a Path Traversal attack to create or overwrite arbitrary files anywhere on the host filesystem, bypassing the application's intended storage sandbox.

Corteza contains a SQL injection vulnerability in its Microsoft SQL Server (MSSQL) backend when filtering Compose records by the meta field.This issue affects corteza: 2024.9.8.

Angular Expressions provides expressions for the Angular.JS web framework as a standalone module. Prior to 1.5.2, an attacker can write a malicious expression using filters that escapes the sandbox to execute arbitrary code on the system. This vulnerability is fixed in 1.5.2.

Wagtail is an open source content management system built on Django. Prior to 7.0.7, 7.3.2, and 7.4, the Documents and Images API incorrectly listed items in private collections. A user with access to the API could see the filename and name of documents and images in private collections. This vulnerability is fixed in 7.0.7, 7.3.2, and 7.4.

Wagtail is an open source content management system built on Django. Prior to 7.0.7, 7.3.2, and 7.4, a CMS user with limited access to pages could copy a page they don't have access to to an area of the site they do. Once coped, they'd be able to view its contents, and potentially publish it. Permissions were correctly checked for the copy destination, but not for the source page. This vulnerability is fixed in 7.0.7, 7.3.2, and 7.4.

Wagtail is an open source content management system built on Django. Prior to 7.0.7, 7.3.2, and 7.4, a CMS user with limited access to form pages could delete submissions to form pages they don't have access to by crafting a form submission to delete submissions on a page they do have access to for submissions they don't. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. This vulnerability is fixed in 7.0.7, 7.3.2, and 7.4.

Wagtail is an open source content management system built on Django. Prior to 7.0.7, 7.3.2, and 7.4, a CMS user without the ability to edit a page could still access the history report for the page, potentially resulting in disclosure of sensitive information. This vulnerability is fixed in 7.0.7, 7.3.2, and 7.4.

Wagtail is an open source content management system built on Django. Prior to 7.0.7, 7.3.2, and 7.4, a CMS user without the ability to edit a page could access revisions of the page through the revision compare view if they knew the primary key of two revisions. This could potentially result in disclosure of sensitive information. This vulnerability is fixed in 7.0.7, 7.3.2, and 7.4.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, an authenticated user with page editing permissions can inject an executable JavaScript event-handler attribute into rendered image HTML through Grav's Markdown media action syntax. The issue is caused by Markdown image query parameters being converted into callable media actions. The public attribute() media method can be reached this way, allowing an editor to set an arbitrary HTML attribute name and value on the generated image element. This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, the Login::register() method in the Login plugin accepts attacker-controlled groups and access fields from the registration POST data without server-side validation. When registration is enabled and groups or access are included in the configured allowed fields list, an unauthenticated user can self-register with admin.super privileges by injecting these fields into the registration request. This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, a stored Cross-Site Scripting (XSS) vulnerability in getgrav/grav allows publisher-level accounts to execute arbitrary JavaScript. The issue arises from a blacklist bypass in the detectXss() function when handling unquoted HTML event attributes. This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, a low-privileged (with the ability to create a page) user can cause XSS with the injection of svg element. The XSS can further be escalated to dump the entire system information available under /admin/config/info whenever a Super Admin visits the page; which can further be chained with the use of admin-nonce to do a complete server compromise (RCE). This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, a low-privileged user (EX: Content Editor with only pages.update permissions) can bypass the existing Twig sandbox restrictions by utilizing the grav['accounts'] service. Attacker can programmatically load administrative user objects and extract sensitive data, including Bcrypt password hashes and the security salt. This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, a business logic vulnerability in the Grav Admin Panel allows a low-privileged user (with only user creation permissions) to overwrite existing accounts, including the primary administrator. By creating a new user with a username that already exists, the system updates the existing account's metadata and permissions instead of rejecting the request. This leads to a Denial of Service (DoS) on administrative functions and Privilege De-escalation of the root account. This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, there is a Path Traversal vulnerability within the FormFlash core component. By manipulating the session_id (passed as __form-flash-id in POST requests), an unauthenticated attacker can traverse the filesystem to create arbitrary directories and write an index.yaml file containing attacker-controlled data. This vulnerability can lead to unauthorized modification of application behavior, potential data integrity issues, and service disruption in production environments. This vulnerability is fixed in 2.0.0-beta.2.

Grav is a file-based Web platform. Prior to 2.0.0-beta.2, an authenticated user with administrative privileges can achieve Remote Code Execution (RCE) by uploading a specially crafted ZIP file through the "Direct Install" tool. While the system attempts to block direct .php file uploads, it fails to inspect the contents of uploaded ZIP archives. Once a malicious plugin is extracted, it can execute arbitrary PHP code or drop a persistent web shell on the server. This vulnerability is fixed in 2.0.0-beta.2.

Reflected Cross-Site Scripting (XSS) in the latest demo version of the Cradle eCommerce platform. User-controlled input is insecurely reflected in the HTML output in the endpoint /product/. Exploitation of this vulnerability would allow an attacker to execute arbitrary JavaScript code.

Reflected Cross-Site Scripting (XSS) in the latest demo version of the Cradle eCommerce platform. User-controlled input is insecurely reflected in the HTML output in the endpoint /collection/. Exploitation of this vulnerability would allow an attacker to execute arbitrary JavaScript code.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/Skin/Skin.Php. This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation MediaWiki. This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation CheckUser. This issue affects CheckUser: from 1.45.0 before 1.45.2.

Vulnerability in Wikimedia Foundation Scribunto. This issue affects Scribunto: from 1.45.0 before 1.45.2.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation MediaWiki. This issue affects MediaWiki: from * before 1.43.7, 1.44.4, 1.45.2.

Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Wikimedia Foundation OATHAuth. This issue affects OATHAuth: from * before 1.43.7, 1.44.4, 1.45.2.

Vulnerability in Wikimedia Foundation AbuseFilter. This issue affects AbuseFilter: from * before 1.43.7, 1.44.4, 1.45.2.

Docling's JATS XML backend is vulnerable to XML Entity Expansion (XXE) attacks thru 2.61.0. The backend uses etree.parse() to parse XML files without disabling entity resolution. An attacker can craft a malicious XML file containing a nested entity expansion payload (XML Bomb). When processed by Docling, the exponential expansion of entities leads to excessive resource consumption, resulting in a denial of service (DoS) condition on the system running the Docling parser.

GPT-Pilot thru commit 0819827ce20346ef5f25b3fe29293cb448840565 (2025-09-03) contains a command injection vulnerability (CWE-78) in the Executor.run() method. During project execution, when the system prompts the user to confirm or modify a command to be run, it accepts free-text input without proper validation. The user-supplied input is directly passed to asyncio.create_subprocess_shell() for execution. This allows an attacker to replace the intended command with arbitrary shell commands, leading to remote code execution with the privileges of the GPT-Pilot process.

docuFORM Managed Print Service Client 11.11c is vulnerable to a directory traversal allowing attackers to read arbitrary files via crafted url.

docuFORM Managed Print Service Client 11.11c is vulnerable to a reflected cross site scripting attack via the login page of the application.

docuFORM Managed Print Service Client 11.11c is vulnerable to arbitrary file upload via pmupdate.php.

docuFORM Managed Print Service Client 11.11c is vulnerable to a session fixation attack via the login page of the application.

Rejected reason: DO NOT USE THIS CVE RECORD. ConsultIDs: CVE-2026-21709. Reason: This record is a duplicate of CVE-2026-21709. Notes: All CVE users should reference CVE-2026-21709 instead of this record. All references and descriptions in this record have been removed to prevent accidental usage.

A reflected cross-site scripted (XSS) vulnerability in the dfm-menu_orderopt.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_markeralerts.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_pricess.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_alerts.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_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.