CWE-272
AllowedLeast Privilege Violation
Abstraction: Base · Status: Incomplete
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.
54 vulnerabilities reference this CWE, most recent first.
GHSA-V52W-28XH-V562
Vulnerability from github – Published: 2026-06-19 20:47 – Updated: 2026-06-19 20:47Kozou compiles a PostgreSQL schema into an Admin UI, a REST API, and an MCP server. Several hardening gaps in the bundled HTTP surfaces and the scaffolded dev stack are fixed in 1.8.1.
Issues
-
MCP HTTP server lacked DNS-rebinding protection. The Streamable HTTP transport is unauthenticated and loopback by default. Without
Host/Originvalidation, a malicious web page in the operator's browser could rebind a hostname it controls to the loopback address and drive the MCP endpoint — reading schema metadata, or (when the opt-incallexecution tool is enabled) executing exposed functions as the execution role. -
Unbounded request-body buffering (DoS). Both the MCP HTTP server and the in-house REST server read the entire request body into memory with no size limit, so a reachable client could drive the process toward memory exhaustion.
-
Read requests ran in a read/write transaction. The shared role-transaction envelope opened every request with a plain
BEGIN, so aGETran read/write. ASELECTthat reaches a volatile function or a writable /INSTEAD-triggered view could perform a write that then commits — the "a GET only reads" contract was left to the serving role's grants rather than enforced. -
No-auth dev surfaces published on all interfaces by default. The scaffolded
docker-compose.yml(and the quickstart) published the unauthenticated Admin UI and MCP HTTP server — and the default-credential demo database — on every host interface, and the config defaulted those binds to0.0.0.0.
What changed in 1.8.1
- DNS-rebinding guard (MCP HTTP): the server validates the
Hostheader (and a presentOrigin) against an allowlist before handling any request, on every route. Matching is on the hostname; loopback names are always accepted and an operator can add hosts via configuration. A browser cannot forgeHost/Origin, so this closes the rebinding vector. (This is a browser-rebinding defence; network reachability of an unauthenticated server must still be constrained by the network — see workarounds.) - Request-body size cap: both HTTP servers reject an over-large declared
Content-Length(413) and enforce the limit while streaming, so a chunked /Content-Length-less body cannot grow unbounded. A non-JSONContent-Typeon a body is rejected with 415. The cap is configurable. - Read-only read transactions: read methods (
GET) now run in aREAD ONLYtransaction, so the database refuses any write for the duration of the request regardless of the role's grants. - Loopback-by-default network posture: the Admin UI and MCP HTTP server now bind loopback by default; the bundled compose files publish every host port (Admin UI, MCP, database) on
127.0.0.1only, while the container binds all interfaces internally so the loopback mapping still works. Operators opt into a broader bind explicitly.
Impact
The MCP HTTP server's exposure is greatest when the opt-in call execution tool is enabled and/or the server is reachable beyond loopback. The read/write-transaction issue has effect only when the schema exposes a read path that can write (a volatile-function-backed column or a writable/INSTEAD-triggered view) and the serving role holds write grants. The all-interface publish affected anyone who ran the scaffolded docker compose up on a host reachable from an untrusted network. Requests run under SET LOCAL ROLE, so PostgreSQL still enforces grants/RLS at runtime; these are defense-in-depth and read-contract hardening.
Affected / patched
- npm packages
kozou,@kozou/api,@kozou/mcp,@kozou/core(and the lockstep-versioned siblings): affected<= 1.8.0, patched 1.8.1. - Container image
ghcr.io/kozou-dev/kozou: patched at tagv1.8.1.
Workarounds (if you cannot upgrade immediately)
- Bind the Admin UI and MCP HTTP server to loopback and publish their host ports on
127.0.0.1only; do not expose them to untrusted networks. - Do not enable the MCP
callexecution tool on a non-loopback / unauthenticated deployment. - Put an authenticating reverse proxy (with
Host/Originvalidation and a request-body limit) in front of any non-loopback deployment. - Change the demo database's default credentials and restrict its port.
Patches
Upgrade to Kozou 1.8.1 (all npm packages and the ghcr.io/kozou-dev/kozou image).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.0"
},
"package": {
"ecosystem": "npm",
"name": "kozou"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.0"
},
"package": {
"ecosystem": "npm",
"name": "@kozou/api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.0"
},
"package": {
"ecosystem": "npm",
"name": "@kozou/mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.8.0"
},
"package": {
"ecosystem": "npm",
"name": "@kozou/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1188",
"CWE-272",
"CWE-346",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T20:47:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Kozou compiles a PostgreSQL schema into an Admin UI, a REST API, and an MCP server. Several hardening gaps in the bundled HTTP surfaces and the scaffolded dev stack are fixed in **1.8.1**.\n\n## Issues\n\n1. **MCP HTTP server lacked DNS-rebinding protection.** The Streamable HTTP transport is unauthenticated and loopback by default. Without `Host`/`Origin` validation, a malicious web page in the operator\u0027s browser could rebind a hostname it controls to the loopback address and drive the MCP endpoint \u2014 reading schema metadata, or (when the opt-in `call` execution tool is enabled) executing exposed functions as the execution role.\n\n2. **Unbounded request-body buffering (DoS).** Both the MCP HTTP server and the in-house REST server read the entire request body into memory with no size limit, so a reachable client could drive the process toward memory exhaustion.\n\n3. **Read requests ran in a read/write transaction.** The shared role-transaction envelope opened every request with a plain `BEGIN`, so a `GET` ran read/write. A `SELECT` that reaches a volatile function or a writable / `INSTEAD`-triggered view could perform a write that then commits \u2014 the \"a GET only reads\" contract was left to the serving role\u0027s grants rather than enforced.\n\n4. **No-auth dev surfaces published on all interfaces by default.** The scaffolded `docker-compose.yml` (and the quickstart) published the unauthenticated Admin UI and MCP HTTP server \u2014 and the default-credential demo database \u2014 on every host interface, and the config defaulted those binds to `0.0.0.0`.\n\n## What changed in 1.8.1\n\n- **DNS-rebinding guard (MCP HTTP):** the server validates the `Host` header (and a present `Origin`) against an allowlist before handling any request, on every route. Matching is on the hostname; loopback names are always accepted and an operator can add hosts via configuration. A browser cannot forge `Host`/`Origin`, so this closes the rebinding vector. (This is a browser-rebinding defence; network reachability of an unauthenticated server must still be constrained by the network \u2014 see workarounds.)\n- **Request-body size cap:** both HTTP servers reject an over-large declared `Content-Length` (413) and enforce the limit while streaming, so a chunked / `Content-Length`-less body cannot grow unbounded. A non-JSON `Content-Type` on a body is rejected with 415. The cap is configurable.\n- **Read-only read transactions:** read methods (`GET`) now run in a `READ ONLY` transaction, so the database refuses any write for the duration of the request regardless of the role\u0027s grants.\n- **Loopback-by-default network posture:** the Admin UI and MCP HTTP server now bind loopback by default; the bundled compose files publish every host port (Admin UI, MCP, database) on `127.0.0.1` only, while the container binds all interfaces internally so the loopback mapping still works. Operators opt into a broader bind explicitly.\n\n## Impact\n\nThe MCP HTTP server\u0027s exposure is greatest when the opt-in `call` execution tool is enabled and/or the server is reachable beyond loopback. The read/write-transaction issue has effect only when the schema exposes a read path that can write (a volatile-function-backed column or a writable/`INSTEAD`-triggered view) and the serving role holds write grants. The all-interface publish affected anyone who ran the scaffolded `docker compose up` on a host reachable from an untrusted network. Requests run under `SET LOCAL ROLE`, so PostgreSQL still enforces grants/RLS at runtime; these are defense-in-depth and read-contract hardening.\n\n## Affected / patched\n\n- npm packages `kozou`, `@kozou/api`, `@kozou/mcp`, `@kozou/core` (and the lockstep-versioned siblings): affected `\u003c= 1.8.0`, patched **1.8.1**.\n- Container image `ghcr.io/kozou-dev/kozou`: patched at tag `v1.8.1`.\n\n## Workarounds (if you cannot upgrade immediately)\n\n- Bind the Admin UI and MCP HTTP server to loopback and publish their host ports on `127.0.0.1` only; do not expose them to untrusted networks.\n- Do not enable the MCP `call` execution tool on a non-loopback / unauthenticated deployment.\n- Put an authenticating reverse proxy (with `Host`/`Origin` validation and a request-body limit) in front of any non-loopback deployment.\n- Change the demo database\u0027s default credentials and restrict its port.\n\n## Patches\n\nUpgrade to **Kozou 1.8.1** (all npm packages and the `ghcr.io/kozou-dev/kozou` image).",
"id": "GHSA-v52w-28xh-v562",
"modified": "2026-06-19T20:47:19Z",
"published": "2026-06-19T20:47:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kozou-dev/kozou/security/advisories/GHSA-v52w-28xh-v562"
},
{
"type": "PACKAGE",
"url": "https://github.com/kozou-dev/kozou"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Kozou: Unauthenticated MCP HTTP server and bundled dev-stack hardening (DNS-rebinding, request-body limits, read-only reads, default network exposure)"
}
GHSA-W54X-R83C-X79Q
Vulnerability from github – Published: 2026-01-15 20:14 – Updated: 2026-01-16 21:56Severity: LOW Target: /workspace/pepr/src/lib/assets/rbac.ts Endpoint: Kubernetes RBAC configuration Method: Deployment
Response / Rationale
Pepr defaults to rbacMode: "admin" because the initial experience is designed to be frictionless for new users. This mode ensures that users can deploy and run the default hello-pepr.ts module without needing to understand or pre-configure RBAC rules.
It’s important to note that hello-pepr.ts is intended strictly as a demo to showcase Pepr features and workflow. It is not intended for production use, and the documentation explicitly calls out that admin RBAC should not be used in production environments.
That said, if a user skips the documentation and does not review the npx pepr build options, they could deploy a module with broader privileges than necessary.
We consider this low severity because Pepr is a framework: the module author is ultimately responsible for selecting the appropriate RBAC scope for their module and environment as each module has different RBAC needs and requirements.
Our security focus is on ensuring the Pepr controller and runtime components operate securely within Kubernetes, while still allowing developers the flexibility to build modules with the access they require.
In order to fix this we will warn the user in logs that the default ClusterRole is cluster-admin and that it is not recommended for production.
How this can be exploited
This is not an inherently exploitable CVE in the traditional sense. It is being flagged because Pepr defaults to a cluster-admin RBAC configuration and does not explicitly force or enforce least-privilege guidance for module authors.
The default behavior exists to make the “getting started” experience smooth: new users can experiment with Pepr and create resources dynamically without needing to pre-configure RBAC.
Remediation: scope RBAC appropriately before deploying to production. Running:
npx pepr build --rbac-mode=scoped
generates the minimum RBAC required for the controller/informer to watch resources. Any additional permissions must be added based on the specific Kubernetes resources and CRUD operations performed by the module
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "pepr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-23634"
],
"database_specific": {
"cwe_ids": [
"CWE-272",
"CWE-276"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-15T20:14:31Z",
"nvd_published_at": "2026-01-16T20:15:49Z",
"severity": "LOW"
},
"details": "Severity: LOW\nTarget: /workspace/pepr/src/lib/assets/rbac.ts\nEndpoint: Kubernetes RBAC configuration\nMethod: Deployment\n\n## Response / Rationale\nPepr defaults to `rbacMode: \"admin\"` because the initial experience is designed to be frictionless for new users. This mode ensures that users can deploy and run the default `hello-pepr.ts` module without needing to understand or pre-configure RBAC rules.\n\nIt\u2019s important to note that `hello-pepr.ts` is intended strictly as a demo to showcase Pepr features and workflow. It is not intended for production use, and the documentation explicitly calls out that admin RBAC should not be used in production environments.\n\nThat said, if a user skips the documentation and does not review the `npx pepr build` options, they could deploy a module with broader privileges than necessary.\n\nWe consider this low severity because Pepr is a framework: the module author is ultimately responsible for selecting the appropriate RBAC scope for their module and environment as each module has different RBAC needs and requirements. \n\nOur security focus is on ensuring the Pepr controller and runtime components operate securely within Kubernetes, while still allowing developers the flexibility to build modules with the access they require.\n\nIn order to fix this we will warn the user in logs that the default `ClusterRole` is `cluster-admin` and that it is not recommended for production.\n\n## How this can be exploited\n\nThis is not an inherently exploitable CVE in the traditional sense. It is being flagged because Pepr defaults to a cluster-admin RBAC configuration and does not explicitly force or enforce least-privilege guidance for module authors.\n\nThe default behavior exists to make the \u201cgetting started\u201d experience smooth: new users can experiment with Pepr and create resources dynamically without needing to pre-configure RBAC.\n\nRemediation: scope RBAC appropriately before deploying to production. Running:\n\n```bash\nnpx pepr build --rbac-mode=scoped\n```\n\ngenerates the minimum RBAC required for the controller/informer to watch resources. Any additional permissions must be added based on the specific Kubernetes resources and CRUD operations performed by the module",
"id": "GHSA-w54x-r83c-x79q",
"modified": "2026-01-16T21:56:18Z",
"published": "2026-01-15T20:14:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/defenseunicorns/pepr/security/advisories/GHSA-w54x-r83c-x79q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23634"
},
{
"type": "WEB",
"url": "https://github.com/defenseunicorns/pepr/pull/2883"
},
{
"type": "WEB",
"url": "https://github.com/defenseunicorns/pepr/commit/d4675a662b8602fcde7e4bf603432f2f133b1fd1"
},
{
"type": "PACKAGE",
"url": "https://github.com/defenseunicorns/pepr"
},
{
"type": "WEB",
"url": "https://github.com/defenseunicorns/pepr/releases/tag/v1.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Pepr Has Overly Permissive RBAC ClusterRole in Admin Mode"
}
GHSA-X77G-PGWR-8458
Vulnerability from github – Published: 2025-07-14 00:31 – Updated: 2025-07-14 00:31Least Privilege Violation (CWE-272) Vulnerability exists in the communication function between the NJ/NX-series Machine Automation Controllers and the Sysmac Studio Software. An attacker may use this vulnerability to perform unauthorized access and to execute unauthorized code remotely to the controller products.
{
"affected": [],
"aliases": [
"CVE-2025-1384"
],
"database_specific": {
"cwe_ids": [
"CWE-272"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-14T00:15:22Z",
"severity": "HIGH"
},
"details": "Least Privilege Violation (CWE-272) Vulnerability exists in the communication function between the NJ/NX-series Machine Automation Controllers and the Sysmac Studio Software. An attacker may use this vulnerability to perform unauthorized access and to execute unauthorized code remotely to the controller products.",
"id": "GHSA-x77g-pgwr-8458",
"modified": "2025-07-14T00:31:07Z",
"published": "2025-07-14T00:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1384"
},
{
"type": "WEB",
"url": "https://www.fa.omron.co.jp/product/security/assets/pdf/en/OMSR-2025-004_en.pdf"
},
{
"type": "WEB",
"url": "https://www.fa.omron.co.jp/product/security/assets/pdf/ja/OMSR-2025-004_ja.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XX7C-HX38-XM2P
Vulnerability from github – Published: 2024-03-22 12:30 – Updated: 2024-03-22 12:30Least privilege violation and reliance on untrusted inputs in the mk_informix Checkmk agent plugin before Checkmk 2.3.0b4 (beta), 2.2.0p24, 2.1.0p41 and 2.0.0 (EOL) allows local users to escalate privileges.
{
"affected": [],
"aliases": [
"CVE-2024-28824"
],
"database_specific": {
"cwe_ids": [
"CWE-272"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-22T11:15:46Z",
"severity": "HIGH"
},
"details": "Least privilege violation and reliance on untrusted inputs in the mk_informix Checkmk agent plugin before Checkmk 2.3.0b4 (beta), 2.2.0p24, 2.1.0p41 and 2.0.0 (EOL) allows local users to escalate privileges.",
"id": "GHSA-xx7c-hx38-xm2p",
"modified": "2024-03-22T12:30:46Z",
"published": "2024-03-22T12:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28824"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/16198"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-48
Strategy: Separation of Privilege
Follow the principle of least privilege when assigning access rights to entities in a software system.
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.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.