CWE-862
Weakness Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
Dimensions
- Behavior-Property: Missing
- Behavior-Type: Authorization
Mapping guidance
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit
Relationships and members
Modes of introduction
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Authorization weaknesses may arise when a single-user application is ported to a multi-user environment.
A developer may introduce authorization weaknesses because of a lack of understanding about the underlying technologies. For example, a developer may assume that attackers cannot modify certain inputs such as headers or cookies.
Detection methods
Automated Static Analysis
Automated static analysis is useful for detecting commonly-used idioms for authorization. A tool may be able to analyze related configuration files, such as .htaccess in Apache web servers, or detect the usage of commonly-used authorization libraries.
Generally, automated static analysis tools have difficulty detecting custom authorization schemes. In addition, the software's design may include some functionality that is accessible to any user and does not require an authorization check; an automated technique that detects the absence of authorization may report false positives.
Effectiveness: Limited
Automated Dynamic Analysis
Automated dynamic analysis may find many or all possible interfaces that do not require authorization, but manual analysis is required to determine if the lack of authorization violates business logic.
Manual Analysis
This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of custom authorization mechanisms.
Effectiveness: Moderate
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules. However, manual efforts might not achieve desired code coverage within limited time constraints.
Manual Static Analysis - Binary or Bytecode
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies
Effectiveness: SOAR Partial
Dynamic Analysis with Automated Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Web Application Scanner
Web Services Scanner
Database Scanners
Effectiveness: SOAR Partial
Dynamic Analysis with Manual Results Interpretation
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Host Application Interface Scanner
Fuzz Tester
Framework-based Fuzzer
Effectiveness: SOAR Partial
Manual Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)
Effectiveness: SOAR Partial
Automated Static Analysis - Source Code
According to SOAR [REF-1479], the following detection techniques may be useful:
Cost effective for partial coverage:
Source code Weakness Analyzer
Context-configured Source Code Weakness Analyzer
Effectiveness: SOAR Partial
Architecture or Design Review
According to SOAR [REF-1479], the following detection techniques may be useful:
Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Formal Methods / Correct-By-Construction
Effectiveness: High
Notes
Terminology
Assuming a user with a given identity, authorization is the process of determining whether that user can access a given resource, based on the user's privileges and any permissions or other access-control specifications that apply to the resource.
Content history
Suggested mappings to ISA/IEC 62443.
Provided diagram to improve CWE usability
updated Demonstrative_Examples, Related_Attack_Patterns, Relationships
updated Potential_Mitigations, References, Relationships
updated Demonstrative_Examples, Observed_Examples, References, Relationships
updated Potential_Mitigations
updated Relationships
updated Detection_Factors
updated Relationships
updated Applicable_Platforms, Modes_of_Introduction, References, Relationships
updated References
updated Relationships
updated Relationships
updated Relationships
updated Relationships
updated Alternate_Terms, Observed_Examples
updated Observed_Examples, Related_Attack_Patterns, Relationships
updated Relationships
updated Relationships
updated Observed_Examples
updated Description, Potential_Mitigations
updated References, Relationships, Taxonomy_Mappings
updated Mapping_Notes, Relationships, Taxonomy_Mappings
updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes
updated Applicable_Platforms, Detection_Factors, Observed_Examples, References
updated Applicable_Platforms, Relationships, Weakness_Ordinalities
updated Applicable_Platforms, Observed_Examples, Relationships
updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings
20063 vulnerabilities reference this CWE, most recent first.
GHSA-HWFX-J423-6X8P
Vulnerability from github – Published: 2026-10-29 18:30 – Updated: 2026-10-29 18:30Missing Authorization vulnerability in weDevs Happy Addons for Elementor happy-elementor-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Happy Addons for Elementor: from n/a through 3.50.1.
{
"affected": [],
"aliases": [
"CVE-2026-109891"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-29T16:17:55Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in weDevs Happy Addons for Elementor happy-elementor-addons allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Happy Addons for Elementor: from n/a through 3.50.1.",
"id": "GHSA-hwfx-j423-6x8p",
"modified": "2026-10-29T18:30:52Z",
"published": "2026-10-29T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109891"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/happy-elementor-addons/vulnerability/wordpress-happy-addons-for-elementor-plugin-3-50-1-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HWG6-3X4X-RVVC
Vulnerability from github – Published: 2026-11-10 21:33 – Updated: 2026-11-10 21:33Improper access control in Windows Win32K allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-119899"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-10T19:20:10Z",
"severity": "HIGH"
},
"details": "Improper access control in Windows Win32K allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-hwg6-3x4x-rvvc",
"modified": "2026-11-10T21:33:34Z",
"published": "2026-11-10T21:33:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-119899"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-119899"
}
],
"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-HWH3-4G93-44FG
Vulnerability from github – Published: 2026-10-22 00:32 – Updated: 2026-10-22 00:32In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the "admin" or "power" Splunk roles could move field extractions or field transformations to apps for which the user does not have read access. The vulnerability is possible because the Representational State Transfer (REST) API does not validate destination app access before it processes field extraction and field transformation move operations. For more information see Use the Field extractions page (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.6/use-the-settings-pages-for-field-extractions-in-splunk-web/use-the-field-extractions-page) and Manage knowledge object permissions (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.6/get-started-with-knowledge-objects/manage-knowledge-object-permissions) in the Splunk documentation.
{
"affected": [],
"aliases": [
"CVE-2026-76294"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-21T23:17:27Z",
"severity": "MODERATE"
},
"details": "In Splunk Enterprise versions below 10.4.4, 10.2.8, 10.0.11, and 9.4.16, a user who does not hold the \"admin\" or \"power\" Splunk roles could move field extractions or field transformations to apps for which the user does not have read access.\nThe vulnerability is possible because the Representational State Transfer (REST) API does not validate destination app access before it processes field extraction and field transformation move operations.\nFor more information see Use the Field extractions page (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.6/use-the-settings-pages-for-field-extractions-in-splunk-web/use-the-field-extractions-page) and Manage knowledge object permissions (https://help.splunk.com/en/splunk-enterprise/manage-knowledge-objects/knowledge-management-manual/10.6/get-started-with-knowledge-objects/manage-knowledge-object-permissions) in the Splunk documentation.",
"id": "GHSA-hwh3-4g93-44fg",
"modified": "2026-10-22T00:32:00Z",
"published": "2026-10-22T00:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76294"
},
{
"type": "WEB",
"url": "https://advisory.splunk.com/advisories/SVD-2026-1007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HWH8-W9P9-FF96
Vulnerability from github – Published: 2025-05-16 18:31 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in QuanticaLabs CSS3 Accordions for WordPress allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects CSS3 Accordions for WordPress: from n/a through 3.0.
{
"affected": [],
"aliases": [
"CVE-2025-31923"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-16T16:15:38Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in QuanticaLabs CSS3 Accordions for WordPress allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects CSS3 Accordions for WordPress: from n/a through 3.0.",
"id": "GHSA-hwh8-w9p9-ff96",
"modified": "2026-04-01T18:35:05Z",
"published": "2025-05-16T18:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31923"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/css3_accordions/vulnerability/wordpress-css3-accordions-for-wordpress-3-0-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HWJ9-2855-V4VX
Vulnerability from github – Published: 2025-10-27 12:32 – Updated: 2025-10-27 12:32A remote unauthenticated attacker may use the unauthenticated C++ API to access or modify sensitive data and disrupt services.
{
"affected": [],
"aliases": [
"CVE-2025-59461"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-27T11:15:40Z",
"severity": "HIGH"
},
"details": "A remote unauthenticated attacker may use the unauthenticated C++ API to access or modify sensitive data and disrupt services.",
"id": "GHSA-hwj9-2855-v4vx",
"modified": "2025-10-27T12:32:52Z",
"published": "2025-10-27T12:32:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59461"
},
{
"type": "WEB",
"url": "https://sick.com/psirt"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/resources-tools/resources/ics-recommended-practices"
},
{
"type": "WEB",
"url": "https://www.first.org/cvss/calculator/3.1"
},
{
"type": "WEB",
"url": "https://www.sick.com/.well-known/csaf/white/2025/sca-2025-0013.json"
},
{
"type": "WEB",
"url": "https://www.sick.com/.well-known/csaf/white/2025/sca-2025-0013.pdf"
},
{
"type": "WEB",
"url": "https://www.sick.com/media/docs/9/19/719/special_information_sick_operating_guidelines_cybersecurity_by_sick_en_im0106719.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HWM2-4PH6-W6M5
Vulnerability from github – Published: 2026-03-03 14:51 – Updated: 2026-03-03 14:51Impact
The restricted pod security policy (PSP), provided in Rancher versions from 2.0 up to and including 2.6.3, has a deviation from the upstream restricted policy provided in Kubernetes, in which Rancher's PSP has runAsUser set to runAsAny, while upstream has runAsUser set to MustRunAsNonRoot. This allows containers to run as any user, including a privileged user (root), even when Rancher's restricted policy is enforced on a project or at cluster level.
A new restricted-noroot PSP was created to prevent pods from running as root when this policy is enforced. This new policy was introduced, instead of patching the current provided restricted policy, in order to avoid breaking users' workloads that are using the restricted PSP and that might be running as a privileged user.
Note: Running containers as root increases the risk of a compromised container being used by a malicious actor as an attack platform to further exploit the user's environment. It is a security best practice to avoid running containers as a privileged user and to limit its usage to workloads where it is strictly necessary.
Patches
Patched versions include release 2.6.4 and later versions. The existing restricted PSP in Rancher 2.6.4 was not modified and still allows containers to run as a privileged user, as explained above. This fix was not backported to previous releases.
For Rancher 2.6.4 and later releases, users using the current restricted PSP and that want to prevent containers from running as root, are advised to migrate to the new restricted-noroot policy. Before doing this migration, it is necessary to verify if affected workloads are currently running as a privileged user and modify them accordingly to the users' own environment to run as a non-privileged user. A redeployment of the affected workload is necessary in order for the new PSP to take effect.
Workarounds
For users running Rancher 2.6.3 and previous releases, which did not received this backport and that want to benefit from this fix, they can manually create a new restricted-noroot PSP on their clusters through Rancher UI. The template of the restricted-noroot policy provided in Rancher 2.6.4 is available in the source code. As a reminder, it is also necessary to manually verify and redeploy the running workload before enabling a more restricted pod security policy.
References
For instructions on how to configure pod security policies using Rancher, please refer to the documentation page. For more information on PSPs in Kubernetes, please refer to the Kubernetes documentation (permalink).
Important reminder: Pod security policies are considered deprecated since Kubernetes v1.21, and will be removed in Kubernetes v1.25. Consult Kubernetes' documentation (permalink) regarding how to migrate from PodSecurityPolicy to Kubernetes' built-in PodSecurity Admission Controller. For the list of supported Kubernetes versions in Rancher, please consult our support matrix.
For more information
If you have any questions or comments about this advisory: * Reach out to SUSE Rancher Security team for security related inquiries. * Open an issue in Rancher repository. * Verify our support matrix and product support lifecycle.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T14:51:36Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\nThe `restricted` pod security policy (PSP), provided in Rancher versions from 2.0 up to and including 2.6.3, has a deviation from the [upstream](https://github.com/kubernetes/website/blob/6d22e08903d7dd44b049c4689fa882ae07f67de9/content/en/examples/policy/restricted-psp.yaml) `restricted` policy provided in Kubernetes, in which Rancher\u0027s PSP has `runAsUser` set to `runAsAny`, while upstream has `runAsUser` set to `MustRunAsNonRoot`. This allows containers to run as any user, including a privileged user (`root`), even when Rancher\u0027s `restricted` policy is enforced on a project or at cluster level.\n\nA new `restricted-noroot` PSP was created to prevent pods from running as `root` when this policy is enforced. This new policy was introduced, instead of patching the current provided `restricted` policy, in order to avoid breaking users\u0027 workloads that are using the `restricted` PSP and that might be running as a privileged user.\n\n**Note**: Running containers as `root` increases the risk of a compromised container being used by a malicious actor as an attack platform to further exploit the user\u0027s environment. It is a security best practice to avoid running containers as a privileged user and to limit its usage to workloads where it is strictly necessary.\n\n### Patches\nPatched versions include release 2.6.4 and later versions. The existing `restricted` PSP in Rancher 2.6.4 was not modified and still allows containers to run as a privileged user, as explained above. This fix was not backported to previous releases.\n\nFor Rancher 2.6.4 and later releases, users using the current `restricted` PSP and that want to prevent containers from running as `root`, are advised to migrate to the new `restricted-noroot` policy. Before doing this migration, it is necessary to verify if affected workloads are currently running as a privileged user and modify them accordingly to the users\u0027 own environment to run as a non-privileged user. A redeployment of the affected workload is necessary in order for the new PSP to take effect.\n\n### Workarounds\nFor users running Rancher 2.6.3 and previous releases, which did not received this backport and that want to benefit from this fix, they can manually create a new `restricted-noroot` PSP on their clusters through Rancher UI. The template of the `restricted-noroot` policy provided in Rancher 2.6.4 is available in the [source code](https://github.com/rancher/rancher/blob/7410cef256c9ed22e8bf4609e5b2e9a1f63a0d05/pkg/data/management/podsecuritypolicytemplate_data.go#L101-L145). As a reminder, it is also necessary to manually verify and redeploy the running workload before enabling a more restricted pod security policy.\n\n### References\nFor instructions on how to configure pod security policies using Rancher, please refer to the [documentation](https://rancher.com/docs/rancher/v2.6/en/admin-settings/pod-security-policies/) page. For more information on PSPs in Kubernetes, please refer to the Kubernetes [documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/concepts/policy/pod-security-policy.md)).\n\n**Important reminder:** Pod security policies are considered deprecated since Kubernetes v1.21, and will be removed in Kubernetes v1.25. Consult Kubernetes\u0027 [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md)) regarding how to migrate from PodSecurityPolicy to Kubernetes\u0027 built-in PodSecurity Admission Controller. For the list of supported Kubernetes versions in Rancher, please consult our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
"id": "GHSA-hwm2-4ph6-w6m5",
"modified": "2026-03-03T14:51:36Z",
"published": "2026-03-03T14:51:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-hwm2-4ph6-w6m5"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Rancher\u0027s restricted PodSecurityPolicy does not prevent containers from running as a privileged user"
}
GHSA-HWPG-C95H-3GC7
Vulnerability from github – Published: 2026-04-15 18:31 – Updated: 2026-04-15 18:31Missing Authorization vulnerability in Plisio Accept Cryptocurrencies with Plisio allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Accept Cryptocurrencies with Plisio: from n/a through 2.0.5.
{
"affected": [],
"aliases": [
"CVE-2026-6372"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-15T17:17:06Z",
"severity": "HIGH"
},
"details": "Missing Authorization vulnerability in Plisio Accept Cryptocurrencies with Plisio allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Accept Cryptocurrencies with Plisio: from n/a through 2.0.5.",
"id": "GHSA-hwpg-c95h-3gc7",
"modified": "2026-04-15T18:31:58Z",
"published": "2026-04-15T18:31:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6372"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/plisio-payment-gateway-for-woocommerce/vulnerability/wordpress-accept-cryptocurrencies-with-plisio-plugin-2-0-5-payment-bypass-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HWPH-8X7C-9R99
Vulnerability from github – Published: 2026-09-19 09:32 – Updated: 2026-09-19 09:32The Ibtana – Ecommerce Product Addons plugin for WordPress is vulnerable to unauthorized post meta modification due to a missing capability check on the 'iepa_use_gt_editor' AJAX action in all versions up to, and including, 0.4.7.7. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update or delete arbitrary post meta entries via the 'iepa_builder' meta key.
{
"affected": [],
"aliases": [
"CVE-2026-1984"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-19T08:16:53Z",
"severity": "MODERATE"
},
"details": "The Ibtana \u2013 Ecommerce Product Addons plugin for WordPress is vulnerable to unauthorized post meta modification due to a missing capability check on the \u0027iepa_use_gt_editor\u0027 AJAX action in all versions up to, and including, 0.4.7.7. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update or delete arbitrary post meta entries via the \u0027iepa_builder\u0027 meta key.",
"id": "GHSA-hwph-8x7c-9r99",
"modified": "2026-09-19T09:32:11Z",
"published": "2026-09-19T09:32:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1984"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ibtana-ecommerce-product-addons/tags/0.4.7.5/inc/class-pro.php#L58"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ibtana-ecommerce-product-addons/trunk/inc/class-pro.php#L25"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/ibtana-ecommerce-product-addons/trunk/inc/class-pro.php#L58"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3587239%40ibtana-ecommerce-product-addons\u0026new=3587239%40ibtana-ecommerce-product-addons"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e1e20253-4002-467a-9dca-10bc2bfe4514?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HWQ5-3473-H97Q
Vulnerability from github – Published: 2026-03-10 21:32 – Updated: 2026-03-11 15:31PX4 Autopilot versions 1.12.x through 1.15.x contain a logic flaw in the mode switching mechanism. When switching from Auto mode to Manual mode while the drone is in the "ARMED" state (after landing and before the automatic disarm triggered by the COM_DISARM_LAND parameter), the system lacks a throttle threshold safety check for the physical throttle stick. This flaw can directly cause the drone to lose control, experience rapid uncontrolled ascent (flyaway), and result in property damage
{
"affected": [],
"aliases": [
"CVE-2026-26741"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-10T19:17:17Z",
"severity": "HIGH"
},
"details": "PX4 Autopilot versions 1.12.x through 1.15.x contain a logic flaw in the mode switching mechanism. When switching from Auto mode to Manual mode while the drone is in the \"ARMED\" state (after landing and before the automatic disarm triggered by the COM_DISARM_LAND parameter), the system lacks a throttle threshold safety check for the physical throttle stick. This flaw can directly cause the drone to lose control, experience rapid uncontrolled ascent (flyaway), and result in property damage",
"id": "GHSA-hwq5-3473-h97q",
"modified": "2026-03-11T15:31:46Z",
"published": "2026-03-10T21:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26741"
},
{
"type": "WEB",
"url": "https://github.com/npuwyw/PX4-Autopilot/blob/audit-v1.12.3-mode-transition-logic-flaw/PX4_Autopilot_Mode_Switching_Logic_Vulnerability.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HWQ6-XX43-JMG7
Vulnerability from github – Published: 2026-11-11 15:31 – Updated: 2026-11-11 15:31Contao 4.0.0 before 5.3.54, 5.4.0 before 5.7.17, and 6.0.0 before 6.0.6 contains an access control bypass vulnerability that allows filemount-restricted backend users to modify folders outside their filemount via the file manager Edit-Multiple operation. Attackers holding the protected or syncExclude field permission can submit outside folder paths in the IDS parameter to publish protected folders or exclude them from DBAFS synchronization, exposing files for public download.
{
"affected": [],
"aliases": [
"CVE-2026-126662"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-11-11T13:17:24Z",
"severity": "HIGH"
},
"details": "Contao 4.0.0 before 5.3.54, 5.4.0 before 5.7.17, and 6.0.0 before 6.0.6 contains an access control bypass vulnerability that allows filemount-restricted backend users to modify folders outside their filemount via the file manager Edit-Multiple operation. Attackers holding the protected or syncExclude field permission can submit outside folder paths in the IDS parameter to publish protected folders or exclude them from DBAFS synchronization, exposing files for public download.",
"id": "GHSA-hwq6-xx43-jmg7",
"modified": "2026-11-11T15:31:02Z",
"published": "2026-11-11T15:31:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/contao/contao/security/advisories/GHSA-9jfh-v443-w3fj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-126662"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/240e169441796bb703819ee0e22728708f946b70"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/a104202df2b532bb64805a0856fc94bb0bddbb66"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/commit/c01898f99c5d5af50a227ee85f27270c5427f900"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/blob/5.3.53/core-bundle/contao/drivers/DC_Folder.php#L1716-L1720"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/releases/tag/5.3.54"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/releases/tag/5.7.17"
},
{
"type": "WEB",
"url": "https://github.com/contao/contao/releases/tag/6.0.6"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/contao-4.0.0-before-5.3.54-5.4.0-before-5.7.17-and-6.0.0-before-6.0.6-filemount-bypass-via-edit-multiple"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.