CWE-271
Allowed-with-ReviewPrivilege Dropping / Lowering Errors
Abstraction: Class · Status: Incomplete
The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.
22 vulnerabilities reference this CWE, most recent first.
CVE-2020-35513 (GCVE-0-2020-35513)
Vulnerability from cvelistv5 – Published: 2021-01-25 15:58 – Updated: 2024-08-04 17:02| URL | Tags |
|---|---|
| https://bugzilla.redhat.com/show_bug.cgi?id=1911309 | x_refsource_MISC |
| https://patchwork.kernel.org/project/linux-nfs/pa… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T17:02:08.093Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1911309"
},
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://patchwork.kernel.org/project/linux-nfs/patch/20180403203916.GH20297%40fieldses.org/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "kernel",
"vendor": "n/a",
"versions": [
{
"status": "affected",
"version": "before kernel 4.17-rc1"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "A flaw incorrect umask during file or directory modification in the Linux kernel NFS (network file system) functionality was found in the way user create and delete object using NFSv4.2 or newer if both simultaneously accessing the NFS by the other process that is not using new NFSv4.2. A user with access to the NFS could use this flaw to starve the resources causing denial of service."
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-271",
"description": "CWE-271",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2021-01-25T15:58:21.000Z",
"orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"shortName": "redhat"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1911309"
},
{
"tags": [
"x_refsource_MISC"
],
"url": "https://patchwork.kernel.org/project/linux-nfs/patch/20180403203916.GH20297%40fieldses.org/"
}
],
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "secalert@redhat.com",
"ID": "CVE-2020-35513",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "kernel",
"version": {
"version_data": [
{
"version_value": "before kernel 4.17-rc1"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "A flaw incorrect umask during file or directory modification in the Linux kernel NFS (network file system) functionality was found in the way user create and delete object using NFSv4.2 or newer if both simultaneously accessing the NFS by the other process that is not using new NFSv4.2. A user with access to the NFS could use this flaw to starve the resources causing denial of service."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-271"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://bugzilla.redhat.com/show_bug.cgi?id=1911309",
"refsource": "MISC",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1911309"
},
{
"name": "https://patchwork.kernel.org/project/linux-nfs/patch/20180403203916.GH20297@fieldses.org/",
"refsource": "MISC",
"url": "https://patchwork.kernel.org/project/linux-nfs/patch/20180403203916.GH20297@fieldses.org/"
}
]
}
}
}
},
"cveMetadata": {
"assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
"assignerShortName": "redhat",
"cveId": "CVE-2020-35513",
"datePublished": "2021-01-25T15:58:21.000Z",
"dateReserved": "2020-12-17T00:00:00.000Z",
"dateUpdated": "2024-08-04T17:02:08.093Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
CVE-2019-11243 (GCVE-0-2019-11243)
Vulnerability from cvelistv5 – Published: 2019-04-22 14:54 – Updated: 2024-08-04 22:48- CWE-271 - Privilege Dropping / Lowering Errors
| URL | Tags |
|---|---|
| https://github.com/kubernetes/kubernetes/issues/76797 | x_refsource_MISC |
| http://www.securityfocus.com/bid/108053 | vdb-entryx_refsource_BID |
| https://security.netapp.com/advisory/ntap-2019050… | x_refsource_CONFIRM |
| Vendor | Product | Version | |
|---|---|---|---|
| Kubernetes | Kubernetes |
Affected:
v1.12 , ≤ v1.12.4
(custom)
Affected: v1.13 , ≤ v1.13.0 (custom) |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2024-08-04T22:48:09.023Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"tags": [
"x_refsource_MISC",
"x_transferred"
],
"url": "https://github.com/kubernetes/kubernetes/issues/76797"
},
{
"name": "108053",
"tags": [
"vdb-entry",
"x_refsource_BID",
"x_transferred"
],
"url": "http://www.securityfocus.com/bid/108053"
},
{
"tags": [
"x_refsource_CONFIRM",
"x_transferred"
],
"url": "https://security.netapp.com/advisory/ntap-20190509-0002/"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"product": "Kubernetes",
"vendor": "Kubernetes",
"versions": [
{
"lessThanOrEqual": "v1.12.4",
"status": "affected",
"version": "v1.12",
"versionType": "custom"
},
{
"lessThanOrEqual": "v1.13.0",
"status": "affected",
"version": "v1.13",
"versionType": "custom"
}
]
}
],
"credits": [
{
"lang": "en",
"value": "Oleg Bulatov of Red Hat"
}
],
"descriptions": [
{
"lang": "en",
"value": "In Kubernetes v1.12.0-v1.12.4 and v1.13.0, the rest.AnonymousClientConfig() method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data). In the affected versions, rest.AnonymousClientConfig() did not effectively clear service account credentials loaded using rest.InClusterConfig()"
}
],
"metrics": [
{
"cvssV3_0": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 3.1,
"baseSeverity": "LOW",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"version": "3.0"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-271",
"description": "CWE-271 Privilege Dropping / Lowering Errors",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2019-05-09T10:06:03.000Z",
"orgId": "a6081bf6-c852-4425-ad4f-a67919267565",
"shortName": "kubernetes"
},
"references": [
{
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/kubernetes/kubernetes/issues/76797"
},
{
"name": "108053",
"tags": [
"vdb-entry",
"x_refsource_BID"
],
"url": "http://www.securityfocus.com/bid/108053"
},
{
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://security.netapp.com/advisory/ntap-20190509-0002/"
}
],
"source": {
"discovery": "USER"
},
"workarounds": [
{
"lang": "en",
"value": "Clear the config.WrapTransport and config.Transport fields in addition to calling rest.AnonymousClientConfig()"
}
],
"x_generator": {
"engine": "Vulnogram 0.0.6"
},
"x_legacyV4Record": {
"CVE_data_meta": {
"ASSIGNER": "jordan@liggitt.net",
"ID": "CVE-2019-11243",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Kubernetes",
"version": {
"version_data": [
{
"version_affected": "\u003c=",
"version_name": "v1.12",
"version_value": "v1.12.4"
},
{
"version_affected": "\u003c=",
"version_name": "v1.13",
"version_value": "v1.13.0"
}
]
}
}
]
},
"vendor_name": "Kubernetes"
}
]
}
},
"credit": [
{
"lang": "eng",
"value": "Oleg Bulatov of Red Hat"
}
],
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In Kubernetes v1.12.0-v1.12.4 and v1.13.0, the rest.AnonymousClientConfig() method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data). In the affected versions, rest.AnonymousClientConfig() did not effectively clear service account credentials loaded using rest.InClusterConfig()"
}
]
},
"generator": {
"engine": "Vulnogram 0.0.6"
},
"impact": {
"cvss": {
"attackComplexity": "HIGH",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 3.1,
"baseSeverity": "LOW",
"confidentialityImpact": "LOW",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"version": "3.0"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-271 Privilege Dropping / Lowering Errors"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/kubernetes/kubernetes/issues/76797",
"refsource": "MISC",
"url": "https://github.com/kubernetes/kubernetes/issues/76797"
},
{
"name": "108053",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/108053"
},
{
"name": "https://security.netapp.com/advisory/ntap-20190509-0002/",
"refsource": "CONFIRM",
"url": "https://security.netapp.com/advisory/ntap-20190509-0002/"
}
]
},
"source": {
"discovery": "USER"
},
"work_around": [
{
"lang": "en",
"value": "Clear the config.WrapTransport and config.Transport fields in addition to calling rest.AnonymousClientConfig()"
}
]
}
}
},
"cveMetadata": {
"assignerOrgId": "a6081bf6-c852-4425-ad4f-a67919267565",
"assignerShortName": "kubernetes",
"cveId": "CVE-2019-11243",
"datePublished": "2019-04-22T14:54:15.000Z",
"dateReserved": "2019-04-17T00:00:00.000Z",
"dateUpdated": "2024-08-04T22:48:09.023Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
GHSA-423P-G724-FR39
Vulnerability from github – Published: 2026-05-11 15:59 – Updated: 2026-06-09 02:00Impact
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 ConfigMaps, 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:
-
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 thesearch_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. -
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_pathin a scraped database, typically by owning the database (and thereforepublicviapg_database_owner) or by holdingCREATEon a schema already reachable throughsearch_path.PG <15 caveat:
publicgrantsCREATEtoPUBLICby default before PostgreSQL 15, so any authenticated role in a scraped database can plant a shadow object regardless of ownership. -
Limit the scope of
target_databases: '*'queries. Avoidtarget_databases: '*'unless every database in the cluster, and every role that owns one, is fully trusted. Where possible, restricttarget_databasesto specific, known-safe databases. -
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_exporterrole withpg_ident.confpeer mapping" - Reported by: Mehmet Ince
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudnative-pg/cloudnative-pg"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.28.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudnative-pg/cloudnative-pg"
},
"ranges": [
{
"events": [
{
"introduced": "1.29.0"
},
{
"fixed": "1.29.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44477"
],
"database_specific": {
"cwe_ids": [
"CWE-250",
"CWE-271",
"CWE-426"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T15:59:12Z",
"nvd_published_at": "2026-05-28T17:16:30Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nThe 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.\n\nAny 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.\n\nTwo exploitation paths follow from this root cause.\n\n#### Path 1: custom metric queries with unqualified identifiers (all supported releases)\n\nA 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 (\u226430 s). Exploitability requires a custom metric query that contains an unqualified relation or function reference.\n\nAlthough `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.\n\n#### Path 2: stock `default-monitoring.yaml` (all supported releases, no custom metrics required)\n\nThe `pg_extensions` metric shipped in `default-monitoring.yaml` used an unqualified `current_database()` call and ran against every user database (`target_databases: \u0027*\u0027`). 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.\n\n#### Combined impact\n\nThe 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.\n\n#### Who is impacted\n\n- All deployments on any supported release with default monitoring enabled are affected by Path 2.\n- All deployments on any supported release that use custom metric queries containing unqualified catalog references are affected by Path 1.\n- Multi-tenant platforms that allow customers to supply or influence custom metric query bodies are at the highest risk for Path 1.\n\n### Patches\n\nThree separate patches address the vulnerability.\n\n#### Patch 1: PR #10576 \"schema-qualify catalog references in default monitoring queries and documentation samples\"\n\nSchema-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.\n\nBackported to all currently supported releases:\n\n- **v1.29.x** (x \u2265 1)\n- **v1.28.x** (x \u2265 3)\n\n#### Patch 2: \"dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping\"\n\nIntroduces 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.\n\nDemoting 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.\n\nWith 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\u0027s `search_path`, so unqualified catalog identifiers cannot resolve to user-planted shadow objects.\n\nThis patch changes the connection identity but not how queries are evaluated. Custom metric queries within `pg_monitor`\u0027s 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`.\n\nThe 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.\n\nFor 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).\n\nThe patch will be backported to all currently supported releases:\n\n- **v1.29.x** (x \u2265 1)\n- **v1.28.x** (x \u2265 3)\n\n### Workarounds\n\nIf upgrading immediately is not possible:\n\n1. **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.\n\n2. **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\u0027s `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`.\n\n *PG \u003c15 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.\n\n3. **Limit the scope of `target_databases: \u0027*\u0027` queries.** Avoid `target_databases: \u0027*\u0027` 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.\n\n4. **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.\n\n### References\n\n- Fix (Patch 1): PR #10576 \"schema-qualify catalog references in default monitoring queries and documentation samples\"\n- Fix (Patch 2): \"dedicated `cnpg_metrics_exporter` role with `pg_ident.conf` peer mapping\"\n- Reported by: Mehmet Ince",
"id": "GHSA-423p-g724-fr39",
"modified": "2026-06-09T02:00:27Z",
"published": "2026-05-11T15:59:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudnative-pg/cloudnative-pg/security/advisories/GHSA-423p-g724-fr39"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44477"
},
{
"type": "WEB",
"url": "https://github.com/cloudnative-pg/cloudnative-pg/pull/10576"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudnative-pg/cloudnative-pg"
},
{
"type": "WEB",
"url": "https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.28.3"
},
{
"type": "WEB",
"url": "https://github.com/cloudnative-pg/cloudnative-pg/releases/tag/v1.29.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "CloudNativePG\u0027s metrics exporter allows privilege escalation to PostgreSQL superuser and OS RCE"
}
GHSA-4828-5P9M-G4FF
Vulnerability from github – Published: 2024-02-08 15:30 – Updated: 2024-12-20 15:30Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. As part of exploiting this vulnerability, the attacker creates functions that use CREATE RULE to convert the internally-built temporary table to a view. Versions before PostgreSQL 15.6, 14.11, 13.14, and 12.18 are affected. The only known exploit does not work in PostgreSQL 16 and later. For defense in depth, PostgreSQL 16.2 adds the protections that older branches are using to fix their vulnerability.
{
"affected": [],
"aliases": [
"CVE-2024-0985"
],
"database_specific": {
"cwe_ids": [
"CWE-271"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-08T13:15:08Z",
"severity": "HIGH"
},
"details": "Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker\u0027s roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker\u0027s materialized view. As part of exploiting this vulnerability, the attacker creates functions that use CREATE RULE to convert the internally-built temporary table to a view. Versions before PostgreSQL 15.6, 14.11, 13.14, and 12.18 are affected. The only known exploit does not work in PostgreSQL 16 and later. For defense in depth, PostgreSQL 16.2 adds the protections that older branches are using to fix their vulnerability.",
"id": "GHSA-4828-5p9m-g4ff",
"modified": "2024-12-20T15:30:44Z",
"published": "2024-02-08T15:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0985"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/03/msg00017.html"
},
{
"type": "WEB",
"url": "https://saites.dev/projects/personal/postgres-cve-2024-0985"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241220-0005"
},
{
"type": "WEB",
"url": "https://www.postgresql.org/support/security/CVE-2024-0985"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-55F6-4PR5-C7M5
Vulnerability from github – Published: 2026-06-30 18:07 – Updated: 2026-06-30 18:07Kahi releases up to and including v0.1.0-alpha.8 contain three privilege/permission issues, all fixed in v0.1.0-alpha.9. They were identified in a full-codebase security review on 2026-05-26.
Affected versions
All releases <= v0.1.0-alpha.8.
Patched version
v0.1.0-alpha.9.
Details
1. Per-process privilege drop not applied (High)
A process configured with user = "uid:gid" had its credential resolved but never attached to the spawned child, so the process ran with the supervisor's inherited privileges (root, when the supervisor runs as root) instead of the configured lower-privilege user. The intended privilege isolation did not occur, and no error was raised.
2. Privilege drop did not reset supplementary groups (Medium)
When the daemon dropped privileges it set the primary gid and uid but never called setgroups(2), so the launching user's supplementary groups (for example docker, which is root-equivalent) remained active after the drop and were inherited by child processes.
3. FastCGI unix socket world-accessible by default (Medium)
A FastCGI unix-domain socket was chmod-ed only when socket_mode was explicitly configured. With socket_mode unset the socket kept the umask-dependent default (commonly world-accessible), allowing any local user to connect to it.
Remediation
Upgrade to v0.1.0-alpha.9. Privilege handling is now fail-closed: the configured credential is applied or the process refuses to start, supplementary groups are reset via setgroups before setgid/setuid, and FastCGI unix sockets default to 0700.
Workarounds (for <= v0.1.0-alpha.8)
- Do not rely on per-process
user; run the supervisor directly as the intended unprivileged user. - Set an explicit restrictive
socket_modeon FastCGI programs. - Avoid running the supervisor as root where possible.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.0-alpha.8"
},
"package": {
"ecosystem": "Go",
"name": "github.com/kahiteam/kahi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.0-alpha.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-271",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T18:07:44Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Kahi releases up to and including v0.1.0-alpha.8 contain three privilege/permission issues, all fixed in v0.1.0-alpha.9. They were identified in a full-codebase security review on 2026-05-26.\n\n## Affected versions\nAll releases \u003c= v0.1.0-alpha.8.\n\n## Patched version\nv0.1.0-alpha.9.\n\n## Details\n\n### 1. Per-process privilege drop not applied (High)\nA process configured with `user = \"uid:gid\"` had its credential resolved but never attached to the spawned child, so the process ran with the supervisor\u0027s inherited privileges (root, when the supervisor runs as root) instead of the configured lower-privilege user. The intended privilege isolation did not occur, and no error was raised.\n\n### 2. Privilege drop did not reset supplementary groups (Medium)\nWhen the daemon dropped privileges it set the primary gid and uid but never called setgroups(2), so the launching user\u0027s supplementary groups (for example `docker`, which is root-equivalent) remained active after the drop and were inherited by child processes.\n\n### 3. FastCGI unix socket world-accessible by default (Medium)\nA FastCGI unix-domain socket was chmod-ed only when `socket_mode` was explicitly configured. With `socket_mode` unset the socket kept the umask-dependent default (commonly world-accessible), allowing any local user to connect to it.\n\n## Remediation\nUpgrade to v0.1.0-alpha.9. Privilege handling is now fail-closed: the configured credential is applied or the process refuses to start, supplementary groups are reset via setgroups before setgid/setuid, and FastCGI unix sockets default to 0700.\n\n## Workarounds (for \u003c= v0.1.0-alpha.8)\n- Do not rely on per-process `user`; run the supervisor directly as the intended unprivileged user.\n- Set an explicit restrictive `socket_mode` on FastCGI programs.\n- Avoid running the supervisor as root where possible.",
"id": "GHSA-55f6-4pr5-c7m5",
"modified": "2026-06-30T18:07:44Z",
"published": "2026-06-30T18:07:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kahiteam/kahi/security/advisories/GHSA-55f6-4pr5-c7m5"
},
{
"type": "PACKAGE",
"url": "https://github.com/kahiteam/kahi"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Kahi has privilege-drop and socket/log permission issues"
}
GHSA-7QPQ-C35P-WC3C
Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40A flaw incorrect umask during file or directory modification in the Linux kernel NFS (network file system) functionality was found in the way user create and delete object using NFSv4.2 or newer if both simultaneously accessing the NFS by the other process that is not using new NFSv4.2. A user with access to the NFS could use this flaw to starve the resources causing denial of service.
{
"affected": [],
"aliases": [
"CVE-2020-35513"
],
"database_specific": {
"cwe_ids": [
"CWE-271"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-26T18:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw incorrect umask during file or directory modification in the Linux kernel NFS (network file system) functionality was found in the way user create and delete object using NFSv4.2 or newer if both simultaneously accessing the NFS by the other process that is not using new NFSv4.2. A user with access to the NFS could use this flaw to starve the resources causing denial of service.",
"id": "GHSA-7qpq-c35p-wc3c",
"modified": "2022-05-24T17:40:14Z",
"published": "2022-05-24T17:40:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35513"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1911309"
},
{
"type": "WEB",
"url": "https://patchwork.kernel.org/project/linux-nfs/patch/20180403203916.GH20297@fieldses.org"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-84G7-X869-XFGV
Vulnerability from github – Published: 2025-05-26 18:30 – Updated: 2025-05-26 18:30Screen 5.0.0 when it runs with setuid-root privileges does not drop privileges while operating on a user supplied path. This allows unprivileged users to create files in arbitrary locations with root ownership, the invoking user's (real) group ownership and file mode 0644. All data written to the Screen PTY will be logged into this file, allowing to escalate to root privileges
{
"affected": [],
"aliases": [
"CVE-2025-23395"
],
"database_specific": {
"cwe_ids": [
"CWE-271"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-26T16:15:20Z",
"severity": "HIGH"
},
"details": "Screen 5.0.0 when it runs with setuid-root privileges does not drop privileges while operating on a user supplied path. This allows unprivileged users to create files in arbitrary locations with `root` ownership, the invoking user\u0027s (real) group ownership and file mode 0644. All data written to the Screen PTY will be logged into this file, allowing to escalate to root privileges",
"id": "GHSA-84g7-x869-xfgv",
"modified": "2025-05-26T18:30:25Z",
"published": "2025-05-26T18:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23395"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-23395"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2025/05/12/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G5FC-F834-RCR2
Vulnerability from github – Published: 2026-04-03 03:31 – Updated: 2026-07-10 12:31In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2026-35535"
],
"database_specific": {
"cwe_ids": [
"CWE-271",
"CWE-272"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-03T03:16:18Z",
"severity": "HIGH"
},
"details": "In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.",
"id": "GHSA-g5fc-f834-rcr2",
"modified": "2026-07-10T12:31:27Z",
"published": "2026-04-03T03:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35535"
},
{
"type": "WEB",
"url": "https://github.com/sudo-project/sudo/commit/3e474c2f201484be83d994ae10a4e20e8c81bb69"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21656"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21690"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21695"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:23233"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:28887"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30088"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34098"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-35535"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/1130593"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/2143042"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2454714"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-253495.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2026/06/msg00003.html"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-35535.json"
},
{
"type": "WEB",
"url": "https://www.qualys.com/2026/03/10/crack-armor.txt"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:10758"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:11521"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:12310"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13731"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13888"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13889"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13891"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13892"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13895"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13896"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14228"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:14437"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19067"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:19220"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20040"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20087"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:21275"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-GC2P-G4FG-29VH
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2025-04-24 17:41In Kubernetes v1.12.0-v1.12.4 and v1.13.0, the rest.AnonymousClientConfig() method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data). In the affected versions, rest.AnonymousClientConfig() did not effectively clear service account credentials loaded using rest.InClusterConfig()
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.12.0"
},
{
"fixed": "1.12.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "k8s.io/kubernetes"
},
"ranges": [
{
"events": [
{
"introduced": "1.13.0"
},
{
"fixed": "1.13.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-11243"
],
"database_specific": {
"cwe_ids": [
"CWE-212",
"CWE-271"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-24T17:41:45Z",
"nvd_published_at": "2019-04-22T15:29:00Z",
"severity": "HIGH"
},
"details": "In Kubernetes v1.12.0-v1.12.4 and v1.13.0, the rest.AnonymousClientConfig() method returns a copy of the provided config, with credentials removed (bearer token, username/password, and client certificate/key data). In the affected versions, rest.AnonymousClientConfig() did not effectively clear service account credentials loaded using rest.InClusterConfig()",
"id": "GHSA-gc2p-g4fg-29vh",
"modified": "2025-04-24T17:41:45Z",
"published": "2022-05-24T16:44:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11243"
},
{
"type": "WEB",
"url": "https://github.com/kubernetes/kubernetes/issues/76797"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubernetes/kubernetes"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190509-0002"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Kubernetes did not effectively clear service account credentials"
}
GHSA-H5VX-6JH5-QHQ7
Vulnerability from github – Published: 2026-03-30 09:31 – Updated: 2026-04-16 18:31A Privilege Dropping / Lowering Errors/Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in cosmic-greeter can allow an attacker to regain privileges that should have been dropped and abuse them in the racy checking logic.
This issue affects cosmic-greeter before https://github.Com/pop-os/cosmic-greeter/pull/426.
{
"affected": [],
"aliases": [
"CVE-2026-25704"
],
"database_specific": {
"cwe_ids": [
"CWE-271"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-30T08:16:16Z",
"severity": "MODERATE"
},
"details": "A Privilege Dropping / Lowering Errors/Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in\u00a0 cosmic-greeter can allow an attacker to regain privileges that should have been dropped and abuse them in the racy checking logic.\n\n\n\n\nThis issue affects cosmic-greeter before https://github.Com/pop-os/cosmic-greeter/pull/426.",
"id": "GHSA-h5vx-6jh5-qhq7",
"modified": "2026-04-16T18:31:15Z",
"published": "2026-03-30T09:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25704"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-25704"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/04/16/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-49
Strategy: Separation of Privilege
Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
No CAPEC attack patterns related to this CWE.