deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-m6hq-p25p-ffr2
Package: github.com/containerd/containerd/v2 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Vulnerable versions: >= 2.2.0-beta.0, < 2.2.0
Patched in: 2.2.0

Summary: containerd CRI server: Host memory exhaustion through Attach goroutine leak

Details:
### Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. 

Repetitive calls of CRI Attach (e.g., [`kubectl attach`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_attach/)) could increase the memory usage of containerd.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.

### Workarounds

Set up an admission controller to control accesses to `pods/attach` resources.
e.g., [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).

### Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-m6hq-p25p-ffr2
Package: github.com/containerd/containerd/v2 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Vulnerable versions: >= 2.1.0-beta.0, < 2.1.5
Patched in: 2.1.5

Summary: containerd CRI server: Host memory exhaustion through Attach goroutine leak

Details:
### Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. 

Repetitive calls of CRI Attach (e.g., [`kubectl attach`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_attach/)) could increase the memory usage of containerd.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.

### Workarounds

Set up an admission controller to control accesses to `pods/attach` resources.
e.g., [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).

### Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-m6hq-p25p-ffr2
Package: github.com/containerd/containerd/v2 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Vulnerable versions: < 2.0.7
Patched in: 2.0.7

Summary: containerd CRI server: Host memory exhaustion through Attach goroutine leak

Details:
### Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. 

Repetitive calls of CRI Attach (e.g., [`kubectl attach`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_attach/)) could increase the memory usage of containerd.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.

### Workarounds

Set up an admission controller to control accesses to `pods/attach` resources.
e.g., [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).

### Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-m6hq-p25p-ffr2
Package: github.com/containerd/containerd (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Vulnerable versions: < 1.7.29
Patched in: 1.7.29

Summary: containerd CRI server: Host memory exhaustion through Attach goroutine leak

Details:
### Impact

A bug was found in containerd's CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. 

Repetitive calls of CRI Attach (e.g., [`kubectl attach`](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_attach/)) could increase the memory usage of containerd.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.

### Workarounds

Set up an admission controller to control accesses to `pods/attach` resources.
e.g., [Validating Admission Policy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/).

### Credits

The containerd project would like to thank @Wheat2018 for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### References

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-64329

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-pwhc-rpq9-4c8w
Package: github.com/containerd/containerd/v2 (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-279: Incorrect Execution-Assigned Permissions
Vulnerable versions: >= 2.2.0-beta.0, < 2.2.0
Patched in: 2.2.0

Summary: containerd affected by a local privilege escalation via wide permissions on CRI directory

Details:
### Impact

An overly broad default permission vulnerability was found in containerd.

- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700
  - Allowed local users on the host to potentially access the metadata store and the content store
- `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700
  - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
- `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration.
When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.

> [!NOTE]
>
> `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711.
> This is an expected behavior for supporting userns-remapped containers.

### Workarounds

The system administrator on the host can manually chmod the directories to not 
have group or world accessible permisisons:

```
chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
```

An alternative mitigation would be to run containerd in [rootless mode](https://github.com/containerd/containerd/blob/main/docs/rootless.md).

### Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-pwhc-rpq9-4c8w
Package: github.com/containerd/containerd/v2 (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-279: Incorrect Execution-Assigned Permissions
Vulnerable versions: >= 2.1.0-beta.0, < 2.1.5
Patched in: 2.1.5

Summary: containerd affected by a local privilege escalation via wide permissions on CRI directory

Details:
### Impact

An overly broad default permission vulnerability was found in containerd.

- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700
  - Allowed local users on the host to potentially access the metadata store and the content store
- `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700
  - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
- `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration.
When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.

> [!NOTE]
>
> `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711.
> This is an expected behavior for supporting userns-remapped containers.

### Workarounds

The system administrator on the host can manually chmod the directories to not 
have group or world accessible permisisons:

```
chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
```

An alternative mitigation would be to run containerd in [rootless mode](https://github.com/containerd/containerd/blob/main/docs/rootless.md).

### Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-pwhc-rpq9-4c8w
Package: github.com/containerd/containerd/v2 (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-279: Incorrect Execution-Assigned Permissions
Vulnerable versions: < 2.0.7
Patched in: 2.0.7

Summary: containerd affected by a local privilege escalation via wide permissions on CRI directory

Details:
### Impact

An overly broad default permission vulnerability was found in containerd.

- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700
  - Allowed local users on the host to potentially access the metadata store and the content store
- `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700
  - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
- `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration.
When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.

> [!NOTE]
>
> `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711.
> This is an expected behavior for supporting userns-remapped containers.

### Workarounds

The system administrator on the host can manually chmod the directories to not 
have group or world accessible permisisons:

```
chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
```

An alternative mitigation would be to run containerd in [rootless mode](https://github.com/containerd/containerd/blob/main/docs/rootless.md).

### Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-pwhc-rpq9-4c8w
Package: github.com/containerd/containerd (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-279: Incorrect Execution-Assigned Permissions
Vulnerable versions: < 1.7.29
Patched in: 1.7.29

Summary: containerd affected by a local privilege escalation via wide permissions on CRI directory

Details:
### Impact

An overly broad default permission vulnerability was found in containerd.

- `/var/lib/containerd` was created with the permission bits 0o711, while it should be created with 0o700
  - Allowed local users on the host to potentially access the metadata store and the content store
- `/run/containerd/io.containerd.grpc.v1.cri` was created with 0o755, while it should be created with 0o700
  - Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
- `/run/containerd/io.containerd.sandbox.controller.v1.shim` was created with 0o711, while it should be created with 0o700

The directory paths may differ depending on the daemon configuration.
When the `temp` directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.

### Patches

This bug has been fixed in the following containerd versions:

* 2.2.0
* 2.1.5
* 2.0.7
* 1.7.29

Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.

> [!NOTE]
>
> `/run/containerd` and `/run/containerd/io.containerd.runtime.v2.task` are still created with 0o711.
> This is an expected behavior for supporting userns-remapped containers.

### Workarounds

The system administrator on the host can manually chmod the directories to not 
have group or world accessible permisisons:

```
chmod 700 /var/lib/containerd
chmod 700 /run/containerd/io.containerd.grpc.v1.cri
chmod 700 /run/containerd/io.containerd.sandbox.controller.v1.shim
```

An alternative mitigation would be to run containerd in [rootless mode](https://github.com/containerd/containerd/blob/main/docs/rootless.md).

### Credits

The containerd project would like to thank David Leadbeater for responsibly disclosing this issue in accordance with the [containerd security policy](https://github.com/containerd/project/blob/main/SECURITY.md).

### For more information

If you have any questions or comments about this advisory:

* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)
* Email us at [security@containerd.io](mailto:security@containerd.io)

To report a security issue in containerd:

* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)
GitHub Security Advisory: GHSA-cpf4-pmr4-w6cx
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 1.80.0-v2.20.0[PII_REDACTED]5945-f365cee73242, < 1.80.0-v2.20.0[PII_REDACTED]3648-8dcfff97ed52
Patched in: 1.80.0-v2.20.0[PII_REDACTED]3648-8dcfff97ed52

Summary: IDOR Vulnerabilities in ZITADEL's Organization API allows Cross-Tenant Data Tempering

Details:
### Summary

ZITADEL's Organization V2Beta API contains Insecure Direct Object Reference (IDOR) vulnerabilities that allow authenticated users with specific **administrator** roles within one organization to access and modify data belonging to **other** organizations.

### Impact

ZITADEL's Organization V2Beta API, intended for managing ZITADEL organizations, contains multiple endpoints that fail to properly authorize authenticated users. An attacker with an administrator role for a specific organization could exploit this to bypass access controls and perform unauthorized actions on other organizations within the same ZITADEL instance.

This could allow an attacker to:

- **Read** organization data, including the name, domains and metadata.
- **Manipulate** (modify) the corresponding organization data.
- **Delete** the corresponding data, up to and including the entire organization.

Note that this vulnerability is limited to organization-level data (name, domains, metadata). **No other related data (such as users, projects, applications, etc.) is affected.**

### Affected Versions

Systems running one of the following versions are affected:
- **v4.x**: `4.0.0-rc.1` through `4.6.2`

### Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the caller's permission against the target organization.

- v4.x: Upgrade to version [4.6.3](https://github.com/zitadel/zitadel/releases/tag/v4.6.3) or later.

### Workarounds

Upgrading to a patched version is the recommended solution.

If an immediate upgrade is not possible, mitigation can be achieved by disabling the affected Organization V2Beta API endpoints (e.g., /v2beta/organizations/...) at a reverse proxy or Web Application Firewall (WAF) level.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)
GitHub Security Advisory: GHSA-cpf4-pmr4-w6cx
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 4.0.0-rc.1, < 4.6.2
Patched in: 4.6.3

Summary: IDOR Vulnerabilities in ZITADEL's Organization API allows Cross-Tenant Data Tempering

Details:
### Summary

ZITADEL's Organization V2Beta API contains Insecure Direct Object Reference (IDOR) vulnerabilities that allow authenticated users with specific **administrator** roles within one organization to access and modify data belonging to **other** organizations.

### Impact

ZITADEL's Organization V2Beta API, intended for managing ZITADEL organizations, contains multiple endpoints that fail to properly authorize authenticated users. An attacker with an administrator role for a specific organization could exploit this to bypass access controls and perform unauthorized actions on other organizations within the same ZITADEL instance.

This could allow an attacker to:

- **Read** organization data, including the name, domains and metadata.
- **Manipulate** (modify) the corresponding organization data.
- **Delete** the corresponding data, up to and including the entire organization.

Note that this vulnerability is limited to organization-level data (name, domains, metadata). **No other related data (such as users, projects, applications, etc.) is affected.**

### Affected Versions

Systems running one of the following versions are affected:
- **v4.x**: `4.0.0-rc.1` through `4.6.2`

### Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the caller's permission against the target organization.

- v4.x: Upgrade to version [4.6.3](https://github.com/zitadel/zitadel/releases/tag/v4.6.3) or later.

### Workarounds

Upgrading to a patched version is the recommended solution.

If an immediate upgrade is not possible, mitigation can be achieved by disabling the affected Organization V2Beta API endpoints (e.g., /v2beta/organizations/...) at a reverse proxy or Web Application Firewall (WAF) level.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)