CWE-284
DiscouragedImproper Access Control
Abstraction: Pillar · Status: Incomplete
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
8494 vulnerabilities reference this CWE, most recent first.
GHSA-F2F3-9XW6-R52M
Vulnerability from github – Published: 2022-12-03 09:30 – Updated: 2022-12-06 15:30A vulnerability, which was classified as critical, has been found in FeMiner wms. Affected by this issue is some unknown functionality of the file /product/savenewproduct.php?flag=1. The manipulation of the argument upfile leads to unrestricted upload. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-214760.
{
"affected": [],
"aliases": [
"CVE-2022-4272"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-284",
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-03T09:15:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability, which was classified as critical, has been found in FeMiner wms. Affected by this issue is some unknown functionality of the file /product/savenewproduct.php?flag=1. The manipulation of the argument upfile leads to unrestricted upload. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-214760.",
"id": "GHSA-f2f3-9xw6-r52m",
"modified": "2022-12-06T15:30:30Z",
"published": "2022-12-03T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4272"
},
{
"type": "WEB",
"url": "https://github.com/FeMiner/wms/issues/14"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.214760"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/04/26/1"
}
],
"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-F2G3-HH2R-CWGC
Vulnerability from github – Published: 2026-04-06 17:53 – Updated: 2026-04-06 23:14summary:
distribution can restore read access in repo a after an explicit delete when storage.cache.blobdescriptor: redis and storage.delete.enabled: true are both enabled. the delete path clears the shared digest descriptor but leaves stale repo-scoped membership behind, so a later Stat or Get from repo b repopulates the shared descriptor and makes the deleted blob readable from repo a again.
Severity
HIGH
justification: this is a repo-local authorization bypass after explicit delete, with concrete confidentiality impact and no requirement for write access after the delete event. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5). CWE-284.
affected version
- repository: https://github.com/distribution/distribution
- commit: ab67ffa0bda3712991194841d0fde727464feeb9
- affected versions: \<= 3.0.x, \<= 2.8.x when redis blob descriptor cache and delete are both enabled
- affected file:
- https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/cache/redis/redis.go#L212-L226
- related callsites:
- https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/cache/cachedblobdescriptorstore.go#L66-L76
- https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/linkedblobstore.go#L218-L224
- https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/linkedblobstore.go#L396-L403
details
the backend access model is repository-link based: once repo a deletes its blob link, later reads from repo a should continue returning ErrBlobUnknown even if the same digest remains linked in repo b.
the issue is the split invalidation path in the redis cache backend:
linkedBlobStore.DeletecallsblobAccessController.Clearduring repository delete handling.cachedBlobStatter.Clearforwards that invalidation into the cache layer.repositoryScopedRedisBlobDescriptorService.Clearchecks that the digest is a member ofrepo a, but then only callsupstream.Clear.upstream.Cleardeletes the shared digest descriptor and does not remove the digest from the repository membership set forrepo a.- when
repo blater stats or gets the same digest, the shared descriptor is recreated. repositoryScopedRedisBlobDescriptorService.Statforrepo aaccepts the stale membership and now trusts the repopulated shared descriptor, restoring access in the repository that already deleted its link.
this creates a revocation gap at the repository boundary. the blob is briefly inaccessible from repo a right after delete, which confirms the backend link was removed, and then becomes accessible again only because stale redis membership survived while a peer repository repopulated the shared descriptor.
attack scenario
- an operator runs distribution with
storage.cache.blobdescriptor: redisandstorage.delete.enabled: true. - the same digest exists in both
repo aandrepo b. - the operator deletes the blob from
repo aand expects repository-local access to be revoked. repo acorrectly returnsblob unknownimmediately after the delete.- an anonymous or unprivileged user requests the same digest from
repo b, which still legitimately owns it and repopulates the shared descriptor. - a later request for the digest from
repo asucceeds again because stale repo-a membership was never revoked from redis.
PoC
attachment: poc.zip
the attached PoC is a deterministic integration harness using miniredis and the pinned distribution source tree.
steps to reproduce
canonical:
unzip -q -o poc.zip -d poc
cd poc
make canonical
expected output:
[CALLSITE_HIT]: repositoryScopedRedisBlobDescriptorService.Clear->upstream.Clear->repositoryScopedRedisBlobDescriptorService.Stat
[PROOF_MARKER]: repo_a_access_restored=true repo_a_delete_miss=true repo_b_peer_warm=true
[IMPACT_MARKER]: repo_a_post_delete_read=true confidentiality_boundary_broken=true
control:
unzip -q -o poc.zip -d poc
cd poc
make control
expected control output:
[CALLSITE_HIT]: repositoryScopedRedisBlobDescriptorService.Clear->repositoryScopedRedisBlobDescriptorService.Stat
[NC_MARKER]: repo_a_access_restored=false repo_b_peer_warm=true
expected vs actual
- expected: after
repo adeletes its blob link, later reads fromrepo ashould keep returningblob unknowneven ifrepo bstill references the same digest and warms cache state. - actual:
repo afirst returnsblob unknown, thenrepo brepopulates the shared descriptor, andrepo aserves the deleted digest again through stale repo-scoped redis membership.
impact
the confirmed impact is repository-local confidentiality failure after explicit delete. an operator can remove sensitive content from repo a, observe revocation working immediately after the delete, and still have the same content become readable from repo a again as soon as repo b refreshes the shared descriptor for that digest.
this is not a claim about global blob deletion. the bounded claim is that repository-local revocation fails, which breaks the expectation that deleting a blob link from one repository prevents further reads from that repository.
remediation
the safest fix is to make redis invalidation revoke repo-scoped state together with the backend link deletion. in practice that means removing the digest from the repository membership set, deleting the repo-scoped descriptor hash, and keeping that cleanup atomic enough that peer-repository warming cannot restore access in the repository that already deleted its link.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/distribution/distribution/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/distribution/distribution"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.8.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35172"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-06T17:53:40Z",
"nvd_published_at": "2026-04-06T20:16:25Z",
"severity": "HIGH"
},
"details": "## summary:\ndistribution can restore read access in `repo a` after an explicit delete when `storage.cache.blobdescriptor: redis` and `storage.delete.enabled: true` are both enabled. the delete path clears the shared digest descriptor but leaves stale repo-scoped membership behind, so a later `Stat` or `Get` from `repo b` repopulates the shared descriptor and makes the deleted blob readable from `repo a` again.\n\n## Severity\n\nHIGH\n\njustification: this is a repo-local authorization bypass after explicit delete, with concrete confidentiality impact and no requirement for write access after the delete event. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5). CWE-284.\n\n# affected version\n\n- repository: https://github.com/distribution/distribution\n- commit: ab67ffa0bda3712991194841d0fde727464feeb9\n- affected versions: \\\u003c= 3.0.x, \\\u003c= 2.8.x when redis blob descriptor cache and delete are both enabled\n- affected file:\n - https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/cache/redis/redis.go#L212-L226\n- related callsites:\n - https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/cache/cachedblobdescriptorstore.go#L66-L76\n - https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/linkedblobstore.go#L218-L224\n - https://github.com/distribution/distribution/blob/ab67ffa0bda3712991194841d0fde727464feeb9/registry/storage/linkedblobstore.go#L396-L403\n\n# details\n\nthe backend access model is repository-link based: once `repo a` deletes its blob link, later reads from `repo a` should continue returning `ErrBlobUnknown` even if the same digest remains linked in `repo b`.\n\nthe issue is the split invalidation path in the redis cache backend:\n\n1. `linkedBlobStore.Delete` calls `blobAccessController.Clear` during repository delete handling.\n2. `cachedBlobStatter.Clear` forwards that invalidation into the cache layer.\n3. `repositoryScopedRedisBlobDescriptorService.Clear` checks that the digest is a member of `repo a`, but then only calls `upstream.Clear`.\n4. `upstream.Clear` deletes the shared digest descriptor and does not remove the digest from the repository membership set for `repo a`.\n5. when `repo b` later stats or gets the same digest, the shared descriptor is recreated.\n6. `repositoryScopedRedisBlobDescriptorService.Stat` for `repo a` accepts the stale membership and now trusts the repopulated shared descriptor, restoring access in the repository that already deleted its link.\n\nthis creates a revocation gap at the repository boundary. the blob is briefly inaccessible from `repo a` right after delete, which confirms the backend link was removed, and then becomes accessible again only because stale redis membership survived while a peer repository repopulated the shared descriptor.\n\n# attack scenario\n\n1. an operator runs distribution with `storage.cache.blobdescriptor: redis` and `storage.delete.enabled: true`.\n2. the same digest exists in both `repo a` and `repo b`.\n3. the operator deletes the blob from `repo a` and expects repository-local access to be revoked.\n4. `repo a` correctly returns `blob unknown` immediately after the delete.\n5. an anonymous or unprivileged user requests the same digest from `repo b`, which still legitimately owns it and repopulates the shared descriptor.\n6. a later request for the digest from `repo a` succeeds again because stale repo-a membership was never revoked from redis.\n\n# PoC\n\nattachment: `poc.zip`\n\nthe attached PoC is a deterministic integration harness using `miniredis` and the pinned distribution source tree.\n\n## steps to reproduce\n\ncanonical:\n\n```bash\nunzip -q -o poc.zip -d poc\ncd poc\nmake canonical\n```\n\nexpected output:\n\n```text\n[CALLSITE_HIT]: repositoryScopedRedisBlobDescriptorService.Clear-\u003eupstream.Clear-\u003erepositoryScopedRedisBlobDescriptorService.Stat\n[PROOF_MARKER]: repo_a_access_restored=true repo_a_delete_miss=true repo_b_peer_warm=true\n[IMPACT_MARKER]: repo_a_post_delete_read=true confidentiality_boundary_broken=true\n```\n\ncontrol:\n\n```bash\nunzip -q -o poc.zip -d poc\ncd poc\nmake control\n```\n\nexpected control output:\n\n```text\n[CALLSITE_HIT]: repositoryScopedRedisBlobDescriptorService.Clear-\u003erepositoryScopedRedisBlobDescriptorService.Stat\n[NC_MARKER]: repo_a_access_restored=false repo_b_peer_warm=true\n```\n\n# expected vs actual\n\n- expected: after `repo a` deletes its blob link, later reads from `repo a` should keep returning `blob unknown` even if `repo b` still references the same digest and warms cache state.\n- actual: `repo a` first returns `blob unknown`, then `repo b` repopulates the shared descriptor, and `repo a` serves the deleted digest again through stale repo-scoped redis membership.\n\n# impact\n\nthe confirmed impact is repository-local confidentiality failure after explicit delete. an operator can remove sensitive content from `repo a`, observe revocation working immediately after the delete, and still have the same content become readable from `repo a` again as soon as `repo b` refreshes the shared descriptor for that digest.\n\nthis is not a claim about global blob deletion. the bounded claim is that repository-local revocation fails, which breaks the expectation that deleting a blob link from one repository prevents further reads from that repository.\n\n# remediation\n\nthe safest fix is to make redis invalidation revoke repo-scoped state together with the backend link deletion. in practice that means removing the digest from the repository membership set, deleting the repo-scoped descriptor hash, and keeping that cleanup atomic enough that peer-repository warming cannot restore access in the repository that already deleted its link.\n\n[poc.zip](https://github.com/user-attachments/files/25813827/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25813828/PR_DESCRIPTION.md)\n[attack_scenario.md](https://github.com/user-attachments/files/25813829/attack_scenario.md)",
"id": "GHSA-f2g3-hh2r-cwgc",
"modified": "2026-04-06T23:14:51Z",
"published": "2026-04-06T17:53:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/distribution/distribution/security/advisories/GHSA-f2g3-hh2r-cwgc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35172"
},
{
"type": "WEB",
"url": "https://github.com/distribution/distribution/commit/078b0783f239b4115d1a979e66f08832084e9d1d"
},
{
"type": "PACKAGE",
"url": "https://github.com/distribution/distribution"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Distribution: stale blob access resurrection via repo-scoped redis descriptor cache invalidation"
}
GHSA-F2HC-7F9P-XFQM
Vulnerability from github – Published: 2025-03-18 21:32 – Updated: 2025-03-25 18:30An issue was discovered on G-Net Dashcam BB GONX devices. A Public Domain name is Used for the Internal Domain Name. It uses an unregistered public domain name as an internal domain, creating a security risk. This domain was not owned by GNET originally, allowing an attacker to register it and potentially intercept sensitive device traffic (it has since been registered by the vulnerability discoverer). If the dashcam or related services attempt to resolve this domain over the public Internet instead of locally, it could lead to data exfiltration or man-in-the-middle attacks.
{
"affected": [],
"aliases": [
"CVE-2025-30140"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-18T21:15:32Z",
"severity": "HIGH"
},
"details": "An issue was discovered on G-Net Dashcam BB GONX devices. A Public Domain name is Used for the Internal Domain Name. It uses an unregistered public domain name as an internal domain, creating a security risk. This domain was not owned by GNET originally, allowing an attacker to register it and potentially intercept sensitive device traffic (it has since been registered by the vulnerability discoverer). If the dashcam or related services attempt to resolve this domain over the public Internet instead of locally, it could lead to data exfiltration or man-in-the-middle attacks.",
"id": "GHSA-f2hc-7f9p-xfqm",
"modified": "2025-03-25T18:30:53Z",
"published": "2025-03-18T21:32:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30140"
},
{
"type": "WEB",
"url": "https://github.com/geo-chen/GNET"
},
{
"type": "WEB",
"url": "https://www.gnetsystem.com/eng/product/list?viewMode=view\u0026idx=246\u0026ca_id=0201"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F2MG-JX3H-8FXX
Vulnerability from github – Published: 2026-06-17 18:35 – Updated: 2026-06-17 18:35Vulnerability in the Siebel CRM Deployment product of Oracle Siebel CRM (component: Database Upgrade). Supported versions that are affected are 17.0-26.5. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Siebel CRM Deployment executes to compromise Siebel CRM Deployment. Successful attacks of this vulnerability can result in takeover of Siebel CRM Deployment. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-46888"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-17T10:54:06Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Siebel CRM Deployment product of Oracle Siebel CRM (component: Database Upgrade). Supported versions that are affected are 17.0-26.5. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Siebel CRM Deployment executes to compromise Siebel CRM Deployment. Successful attacks of this vulnerability can result in takeover of Siebel CRM Deployment. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-f2mg-jx3h-8fxx",
"modified": "2026-06-17T18:35:34Z",
"published": "2026-06-17T18:35:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46888"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cspujun2026.html"
}
],
"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"
}
]
}
GHSA-F2QF-2MF5-VG4C
Vulnerability from github – Published: 2022-05-17 01:17 – Updated: 2025-04-12 13:06PHP object injection vulnerabilities exist in multiple widget files in AlienVault OSSIM and USM before 5.3.2. These vulnerabilities allow arbitrary PHP code execution via magic methods in included classes.
{
"affected": [],
"aliases": [
"CVE-2016-8580"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-10-28T15:59:00Z",
"severity": "CRITICAL"
},
"details": "PHP object injection vulnerabilities exist in multiple widget files in AlienVault OSSIM and USM before 5.3.2. These vulnerabilities allow arbitrary PHP code execution via magic methods in included classes.",
"id": "GHSA-f2qf-2mf5-vg4c",
"modified": "2025-04-12T13:06:05Z",
"published": "2022-05-17T01:17:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-8580"
},
{
"type": "WEB",
"url": "https://www.alienvault.com/forums/discussion/7766/security-advisory-alienvault-5-3-2-address-70-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/40682"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93864"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F2V6-G3VM-R6FG
Vulnerability from github – Published: 2022-05-17 03:40 – Updated: 2022-05-17 03:40IBM WebSphere Portal 6.1.0 through 6.1.0.6 CF27, 6.1.5 through 6.1.5.3 CF27, 7.0.0 through 7.0.0.2 CF30, 8.0.0 through 8.0.0.1 CF21, and 8.5.0 before CF12 allows remote authenticated users to cause a denial of service by uploading temporary files.
{
"affected": [],
"aliases": [
"CVE-2016-5954"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-09-12T10:59:00Z",
"severity": "MODERATE"
},
"details": "IBM WebSphere Portal 6.1.0 through 6.1.0.6 CF27, 6.1.5 through 6.1.5.3 CF27, 7.0.0 through 7.0.0.2 CF30, 8.0.0 through 8.0.0.1 CF21, and 8.5.0 before CF12 allows remote authenticated users to cause a denial of service by uploading temporary files.",
"id": "GHSA-f2v6-g3vm-r6fg",
"modified": "2022-05-17T03:40:10Z",
"published": "2022-05-17T03:40:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5954"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg1PI67037"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg21989993"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93017"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1036762"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F2X4-MHQ2-99X5
Vulnerability from github – Published: 2024-03-06 00:31 – Updated: 2025-11-04 21:31Multilaser RE160 v5.07.51_pt_MTL01 and v5.07.52_pt_MTL01, Multilaser RE160V v12.03.01.08_pt and V12.03.01.09_pt, and Multilaser RE163V v12.03.01.08_pt allows attackers to bypass the access control and gain complete access to the application via supplying a crafted URL.
{
"affected": [],
"aliases": [
"CVE-2023-38945"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T00:15:52Z",
"severity": "HIGH"
},
"details": "Multilaser RE160 v5.07.51_pt_MTL01 and v5.07.52_pt_MTL01, Multilaser RE160V v12.03.01.08_pt and V12.03.01.09_pt, and Multilaser RE163V v12.03.01.08_pt allows attackers to bypass the access control and gain complete access to the application via supplying a crafted URL.",
"id": "GHSA-f2x4-mhq2-99x5",
"modified": "2025-11-04T21:31:16Z",
"published": "2024-03-06T00:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38945"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Mar/1"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Mar/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F342-W736-J52R
Vulnerability from github – Published: 2025-12-27 21:30 – Updated: 2026-02-24 09:31A flaw has been found in jackq XCMS up to 3fab5342cc509945a7ce1b8ec39d19f701b89261. This impacts an unknown function of the file Public/javascripts/admin/plupload-2.1.2/examples/upload.php. This manipulation causes unrestricted upload. It is possible to initiate the attack remotely. The exploit has been published and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2025-15109"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-27T19:15:41Z",
"severity": "MODERATE"
},
"details": "A flaw has been found in jackq XCMS up to 3fab5342cc509945a7ce1b8ec39d19f701b89261. This impacts an unknown function of the file Public/javascripts/admin/plupload-2.1.2/examples/upload.php. This manipulation causes unrestricted upload. It is possible to initiate the attack remotely. The exploit has been published and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-f342-w736-j52r",
"modified": "2026-02-24T09:31:18Z",
"published": "2025-12-27T21:30:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15109"
},
{
"type": "WEB",
"url": "https://gitee.com/jackq/XCMS"
},
{
"type": "WEB",
"url": "https://gitee.com/jackq/XCMS/issues/IDC4ZT"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.338480"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.338480"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.711696"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-F38V-GW54-MX6W
Vulnerability from github – Published: 2023-08-11 03:30 – Updated: 2024-01-11 21:31Improper access control in the Intel(R) Ethernet Controller RDMA driver for linux before version 1.9.30 may allow an unauthenticated user to potentially enable escalation of privilege via network access.
{
"affected": [],
"aliases": [
"CVE-2023-25775"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-11T03:15:18Z",
"severity": "CRITICAL"
},
"details": "Improper access control in the Intel(R) Ethernet Controller RDMA driver for linux before version 1.9.30 may allow an unauthenticated user to potentially enable escalation of privilege via network access.",
"id": "GHSA-f38v-gw54-mx6w",
"modified": "2024-01-11T21:31:15Z",
"published": "2023-08-11T03:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25775"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230915-0013"
},
{
"type": "WEB",
"url": "http://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00794.html"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-F39W-3RJP-955J
Vulnerability from github – Published: 2022-05-17 02:23 – Updated: 2022-05-17 02:23Unspecified vulnerability in the Oracle iProcurement component in Oracle E-Business Suite 12.1.1 through 12.1.3 and 12.2.3 through 12.2.6 allows remote authenticated users to affect confidentiality and integrity via unknown vectors.
{
"affected": [],
"aliases": [
"CVE-2016-5562"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-10-25T14:30:00Z",
"severity": "HIGH"
},
"details": "Unspecified vulnerability in the Oracle iProcurement component in Oracle E-Business Suite 12.1.1 through 12.1.3 and 12.2.3 through 12.2.6 allows remote authenticated users to affect confidentiality and integrity via unknown vectors.",
"id": "GHSA-f39w-3rjp-955j",
"modified": "2022-05-17T02:23:29Z",
"published": "2022-05-17T02:23:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-5562"
},
{
"type": "WEB",
"url": "http://www.oracle.com/technetwork/security-advisory/cpuoct2016-2881722.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/93739"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037038"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N",
"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-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-19: Embedding Scripts within Scripts
An adversary leverages the capability to execute their own script by embedding it within other scripts that the target software is likely to execute due to programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts.
CAPEC-441: Malicious Logic Insertion
An adversary installs or adds malicious logic (also known as malware) into a seemingly benign component of a fielded system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. With the proliferation of mass digital storage and inexpensive multimedia devices, Bluetooth and 802.11 support, new attack vectors for spreading malware are emerging for things we once thought of as innocuous greeting cards, picture frames, or digital projectors. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems and their components that are still under development and part of the supply chain.
CAPEC-478: Modification of Windows Service Configuration
An adversary exploits a weakness in access control to modify the execution parameters of a Windows service. The goal of this attack is to execute a malicious binary in place of an existing service.
CAPEC-479: Malicious Root Certificate
An adversary exploits a weakness in authorization and installs a new root certificate on a compromised system. Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.
CAPEC-502: Intent Spoof
An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.
CAPEC-503: WebView Exposure
An adversary, through a malicious web page, accesses application specific functionality by leveraging interfaces registered through WebView's addJavascriptInterface API. Once an interface is registered to WebView through addJavascriptInterface, it becomes global and all pages loaded in the WebView can call this interface.
CAPEC-536: Data Injected During Configuration
An attacker with access to data files and processes on a victim's system injects malicious data into critical operational data during configuration or recalibration, causing the victim's system to perform in a suboptimal manner that benefits the adversary.
CAPEC-546: Incomplete Data Deletion in a Multi-Tenant Environment
An adversary obtains unauthorized information due to insecure or incomplete data deletion in a multi-tenant environment. If a cloud provider fails to completely delete storage and data from former cloud tenants' systems/resources, once these resources are allocated to new, potentially malicious tenants, the latter can probe the provided resources for sensitive information still there.
CAPEC-550: Install New Service
When an operating system starts, it also starts programs called services or daemons. Adversaries may install a new service which will be executed at startup (on a Windows system, by modifying the registry). The service name may be disguised by using a name from a related operating system or benign software. Services are usually run with elevated privileges.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-552: Install Rootkit
An adversary exploits a weakness in authentication to install malware that alters the functionality and information provide by targeted operating system API calls. Often referred to as rootkits, it is often used to hide the presence of programs, files, network connections, services, drivers, and other system components.
CAPEC-556: Replace File Extension Handlers
When a file is opened, its file handler is checked to determine which program opens the file. File handlers are configuration properties of many operating systems. Applications can modify the file handler for a given file extension to call an arbitrary program when a file with the given extension is opened.
CAPEC-558: Replace Trusted Executable
An adversary exploits weaknesses in privilege management or access control to replace a trusted executable with a malicious version and enable the execution of malware when that trusted executable is called.
CAPEC-562: Modify Shared File
An adversary manipulates the files in a shared location by adding malicious programs, scripts, or exploit code to valid content. Once a user opens the shared content, the tainted content is executed.
CAPEC-563: Add Malicious File to Shared Webroot
An adversaries may add malicious content to a website through the open file share and then browse to that content with a web browser to cause the server to execute the content. The malicious content will typically run under the context and permissions of the web server process, often resulting in local system or administrative privileges depending on how the web server is configured.
CAPEC-564: Run Software at Logon
Operating system allows logon scripts to be run whenever a specific user or users logon to a system. If adversaries can access these scripts, they may insert additional code into the logon script. This code can allow them to maintain persistence or move laterally within an enclave because it is executed every time the affected user or users logon to a computer. Modifying logon scripts can effectively bypass workstation and enclave firewalls. Depending on the access configuration of the logon scripts, either local credentials or a remote administrative account may be necessary.
CAPEC-578: Disable Security Software
An adversary exploits a weakness in access control to disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.