Common Weakness Enumeration

CWE-862

Weakness Allowed-with-Review

Missing 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
ChildOf: CWE-285 · View CWE-1000
  • Behavior-Property: Improper
ChildOf: CWE-284 · View CWE-1340
  • Behavior-Property: Improper
  • Behavior-Type: Access Control
Modes of introduction
Architecture and Design

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.

Implementation

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.

Operation
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
Submission: CWE Content Team · MITRE · 2011-05-24 · CWE 1.13
Contribution: "Mapping CWE to 62443" Sub-Working Group · CWE-CAPEC ICS/OT SIG · 2023-04-25 · CWE 4.11

Suggested mappings to ISA/IEC 62443.

Contribution: Abhi Balakrishnan · 2024-02-29 · CWE 4.16

Provided diagram to improve CWE usability

Modification: CWE Content Team · MITRE · 2011-06-27 · CWE 2.0

updated Demonstrative_Examples, Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2011-09-13 · CWE 2.1

updated Potential_Mitigations, References, Relationships

Modification: CWE Content Team · MITRE · 2012-05-11 · CWE 2.2

updated Demonstrative_Examples, Observed_Examples, References, Relationships

Modification: CWE Content Team · MITRE · 2012-10-30 · CWE 2.3

updated Potential_Mitigations

Modification: CWE Content Team · MITRE · 2014-02-18 · CWE 2.6

updated Relationships

Modification: CWE Content Team · MITRE · 2014-07-30 · CWE 2.8

updated Detection_Factors

Modification: CWE Content Team · MITRE · 2017-01-19 · CWE 2.10

updated Relationships

Modification: CWE Content Team · MITRE · 2017-11-08 · CWE 3.0

updated Applicable_Platforms, Modes_of_Introduction, References, Relationships

Modification: CWE Content Team · MITRE · 2018-03-27 · CWE 3.1

updated References

Modification: CWE Content Team · MITRE · 2019-06-20 · CWE 3.3

updated Relationships

Modification: CWE Content Team · MITRE · 2020-02-24 · CWE 4.0

updated Relationships

Modification: CWE Content Team · MITRE · 2020-08-20 · CWE 4.2

updated Relationships

Modification: CWE Content Team · MITRE · 2020-12-10 · CWE 4.3

updated Relationships

Modification: CWE Content Team · MITRE · 2021-03-15 · CWE 4.4

updated Alternate_Terms, Observed_Examples

Modification: CWE Content Team · MITRE · 2021-07-20 · CWE 4.5

updated Observed_Examples, Related_Attack_Patterns, Relationships

Modification: CWE Content Team · MITRE · 2021-10-28 · CWE 4.6

updated Relationships

Modification: CWE Content Team · MITRE · 2022-06-28 · CWE 4.8

updated Relationships

Modification: CWE Content Team · MITRE · 2022-10-13 · CWE 4.9

updated Observed_Examples

Modification: CWE Content Team · MITRE · 2023-01-31 · CWE 4.10

updated Description, Potential_Mitigations

Modification: CWE Content Team · MITRE · 2023-04-27 · CWE 4.11

updated References, Relationships, Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2023-06-29 · CWE 4.12

updated Mapping_Notes, Relationships, Taxonomy_Mappings

Modification: CWE Content Team · MITRE · 2024-11-19 · CWE 4.16

updated Common_Consequences, Description, Diagram, Relationships, Terminology_Notes

Modification: CWE Content Team · MITRE · 2025-09-09 · CWE 4.18

updated Applicable_Platforms, Detection_Factors, Observed_Examples, References

Modification: CWE Content Team · MITRE · 2025-12-11 · CWE 4.19

updated Applicable_Platforms, Relationships, Weakness_Ordinalities

Modification: CWE Content Team · MITRE · 2026-04-30 · CWE 4.20

updated Applicable_Platforms, Observed_Examples, Relationships

Modification: CWE Content Team · MITRE · 2026-10-28 · CWE 5.0

updated Applicable_Platforms, Dimensions, References, Relationships, Taxonomy_Mappings

19905 vulnerabilities reference this CWE, most recent first.

GHSA-CVPP-HJP6-QCPV

Vulnerability from github – Published: 2026-01-06 18:31 – Updated: 2026-04-28 21:35
VLAI
Details

Missing Authorization vulnerability in Sfwebservice InWave Jobs allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects InWave Jobs: from n/a through 3.5.8.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-39477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-06T17:15:43Z",
    "severity": "CRITICAL"
  },
  "details": "Missing Authorization vulnerability in Sfwebservice InWave Jobs allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects InWave Jobs: from n/a through 3.5.8.",
  "id": "GHSA-cvpp-hjp6-qcpv",
  "modified": "2026-04-28T21:35:53Z",
  "published": "2026-01-06T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39477"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/iwjob/vulnerability/wordpress-inwave-jobs-plugin-3-5-8-broken-access-control-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:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CVQJ-PPFQ-HH39

Vulnerability from github – Published: 2024-12-12 06:30 – Updated: 2024-12-12 06:30
VLAI
Details

The Child Theme Creator by Orbisius plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the cloud_delete() and cloud_update() functions in all versions up to, and including, 1.5.5. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update and delete cloud snippets. Please note that this vulnerability was present in the Cloud Library Addon used by the plugin and not in the plugin itself, the cloud library has been removed entirely.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-12263"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-12T06:15:23Z",
    "severity": "MODERATE"
  },
  "details": "The Child Theme Creator by Orbisius plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the cloud_delete() and cloud_update() functions in all versions up to, and including, 1.5.5. This makes it possible for authenticated attackers, with Subscriber-level access and above, to update and delete cloud snippets. Please note that this vulnerability was present in the Cloud Library Addon used by the plugin and not in the plugin itself, the cloud library has been removed entirely.",
  "id": "GHSA-cvqj-ppfq-hh39",
  "modified": "2024-12-12T06:30:51Z",
  "published": "2024-12-12T06:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12263"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3205672%40orbisius-child-theme-creator\u0026new=3205672%40orbisius-child-theme-creator\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/dd0eb569-b526-48bd-8198-ff883860e040?source=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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CVVM-4CR9-R436

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-12-16 20:42
VLAI
Summary
Multiple vulnerabilities allow bypassing path filtering of agent-to-controller access control in Jenkins
Details

The agent-to-controller security subsystem limits which files on the Jenkins controller can be accessed by agent processes.

Multiple vulnerabilities in the file path filtering implementation of Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allow agent processes to read and write arbitrary files on the Jenkins controller file system, and obtain some information about Jenkins controller file systems.

SECURITY-2542 / CVE-2021-21695: FilePath#listFiles lists files outside directories with agent read access when following symbolic links.

We expect that most of these vulnerabilities have been present since SECURITY-144 was addressed in the 2014-10-30 security advisory.

Jenkins 2.319, LTS 2.303.3 addresses these security vulnerabilities.

SECURITY-2542 / CVE-2021-21695: FilePath#listFiles checks stat permission on files it returns, preventing listing files outside allowed directories.

As some common operations are now newly subject to access control, it is expected that plugins sending commands from agents to the controller may start failing. Additionally, the newly introduced path canonicalization means that instances using a custom builds directory (Java system property jenkins.model.Jenkins.buildsDir) or partitioning JENKINS_HOME using symbolic links may fail access control checks. See the documentation for how to customize the configuration in case of problems.

If you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the Remoting Security Workaround Plugin. It will prevent all agent-to-controller file access using FilePath APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.303.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.318"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.304"
            },
            {
              "fixed": "2.319"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-23T06:47:14Z",
    "nvd_published_at": "2021-11-04T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The agent-to-controller security subsystem limits which files on the Jenkins controller can be accessed by agent processes.\n\nMultiple vulnerabilities in the file path filtering implementation of Jenkins 2.318 and earlier, LTS 2.303.2 and earlier allow agent processes to read and write arbitrary files on the Jenkins controller file system, and obtain some information about Jenkins controller file systems.\n\nSECURITY-2542 / CVE-2021-21695: `FilePath#listFiles` lists files outside directories with agent read access when following symbolic links.\n\nWe expect that most of these vulnerabilities have been present since [SECURITY-144 was addressed in the 2014-10-30 security advisory](https://www.jenkins.io/security/advisory/2014-10-30/).\n\nJenkins 2.319, LTS 2.303.3 addresses these security vulnerabilities.\n\nSECURITY-2542 / CVE-2021-21695: `FilePath#listFiles` checks `stat` permission on files it returns, preventing listing files outside allowed directories.\n\nAs some common operations are now newly subject to access control, it is expected that plugins sending commands from agents to the controller may start failing. Additionally, the newly introduced path canonicalization means that instances using a custom builds directory ([Java system property jenkins.model.Jenkins.buildsDir](https://www.jenkins.io/doc/book/managing/system-properties/#jenkins-model-jenkins-buildsdir)) or partitioning `JENKINS_HOME` using symbolic links may fail access control checks. See [the documentation](https://www.jenkins.io/doc/book/security/controller-isolation/agent-to-controller/#file-access-rules) for how to customize the configuration in case of problems.\n\nIf you are unable to immediately upgrade to Jenkins 2.319, LTS 2.303.3, you can install the [Remoting Security Workaround Plugin](https://www.jenkins.io/redirect/remoting-security-workaround/). It will prevent all agent-to-controller file access using `FilePath` APIs. Because it is more restrictive than Jenkins 2.319, LTS 2.303.3, more plugins are incompatible with it. Make sure to read the plugin documentation before installing it.",
  "id": "GHSA-cvvm-4cr9-r436",
  "modified": "2022-12-16T20:42:26Z",
  "published": "2022-05-24T19:19:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21695"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/jenkins/commit/63cde2daadc705edf086f2213b48c8c547f98358"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/jenkins"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2021-11-04/#SECURITY-2455"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2021/11/04/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Multiple vulnerabilities allow bypassing path filtering of agent-to-controller access control in Jenkins"
}

GHSA-CVW4-55PP-3HFQ

Vulnerability from github – Published: 2026-08-28 17:13 – Updated: 2026-08-28 17:13
VLAI
Summary
Yamcs's Missing Authorization on Role and Privilege Enumeration Endpoints Allows Any Authenticated User to Disclose Full Security Configuration
Details

Summary

Missing authorization checks on three IAM API endpoints (GET /api/roles, GET /api/roles/{name}, GET /api/privileges) allow any authenticated user — regardless of their assigned permissions — to enumerate the complete list of system privileges and role definitions. An attacker with only a low-privilege account (e.g., a read-only operator) can retrieve the full privilege taxonomy of the server, including the names and assignments of all administrator-level capabilities. This information directly enables targeted privilege escalation attacks.


Details

Three handler methods in IamApi.java serve sensitive security metadata without performing any authorization check:

File: yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java

// Line 73 — GET /api/roles
@Override
public void listRoles(Context ctx, Empty request, Observer<ListRolesResponse> observer) {
    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();
    List<Role> roles = securityStore.getDirectory().getRoles();
    // No ctx.checkSystemPrivilege() call — any authenticated user proceeds
    ...
    observer.complete(responseb.build());
}

// Line 87 — GET /api/roles/{name}
@Override
public void getRole(Context ctx, GetRoleRequest request, Observer<RoleInfo> observer) {
    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();
    Role role = securityStore.getDirectory().getRole(request.getName());
    // No ctx.checkSystemPrivilege() call
    observer.complete(toRoleInfo(role));
}

// Line 112 — GET /api/privileges
@Override
public void listPrivileges(Context ctx, Empty request, Observer<ListPrivilegesResponse> observer) {
    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();
    List<SystemPrivilege> privileges = new ArrayList<>(securityStore.getSystemPrivileges());
    // No ctx.checkSystemPrivilege() call
    observer.complete(responseb.build());
}

By contrast, all write operations and user-management endpoints in the same file correctly enforce authorization. For example:

// Line 126 — GET /api/users (correctly protected)
public void listUsers(...) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ← present
    ...
}

// Line 142 — POST /api/users (correctly protected)
public void createUser(...) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ← present
    ...
}

The three vulnerable endpoints share the same ControlAccess protection requirement as the user-management endpoints but were never given the corresponding check.

Route definitions (confirmed in yamcs-api/src/main/proto/yamcs/protobuf/iam/iam.proto):

GET /api/privileges   → IamApi.listPrivileges()
GET /api/roles        → IamApi.listRoles()
GET /api/roles/{name} → IamApi.getRole()

PoC

image

Environment

  • Yamcs version: 5.13.1-SNAPSHOT (latest master)
  • Auth module: YamlAuthModule (default)
  • Two accounts available: admin (Administrator) and operator (Operator)
  • Calculate the Basic Auth credentials for the two accounts (this needs to be done only once). Please modify according to the actual situation. These credentials will be used in subsequent commands. Here, there is a test low-privilege account named "operator" with the password "password".

image

powershell -command "[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('admin:admin'))"

powershell -command "[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('operator:password'))"

Step 1 — Confirm that protected endpoints correctly return 403 for low-privilege users

curl -s -o nul -w "HTTP %{http_code}" http://localhost:8090/api/users -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Expected: HTTP 403 — the user-list endpoint enforces ControlAccess.

Step 2 — Enumerate all system privileges with the operator account

curl -s http://localhost:8090/api/privileges -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Actual response (HTTP 200):

C:\Users\20616>curl -s http://localhost:8090/api/privileges -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="
{
  "systemPrivileges": ["ChangeMissionDatabase", "CommandOptions", "ControlAccess", "ControlActivities", "ControlAlarms", "ControlArchiving", "ControlCommandClearances", "ControlCommandQueue", "ControlFileTransfers", "ControlLinks", "ControlProcessor", "ControlServices", "ControlTimeCorrelation", "ControlTimeline", "CreateInstances", "GetMissionDatabase", "ManageAnyBucket", "ManageParameterLists", "ModifyCommandHistory", "ReadActivities", "ReadAlarms", "ReadCommandHistory", "ReadEvents", "ReadFileTransfers", "ReadLinks", "ReadSystemInfo", "ReadTables", "ReadTimeline", "WriteEvents", "WriteTables", "web.AccessAdminArea"]
}

The operator account receives the server's complete privilege taxonomy — all 31 system privileges including ControlAccess (full user management) and ChangeMissionDatabase (algorithm-level RCE, see related advisory).

Step 3 — Enumerate all defined roles with the operator account

curl -s http://localhost:8090/api/roles -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Actual response (HTTP 200):

C:\Users\20616>curl -s http://localhost:8090/api/roles -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="
{
}

The endpoint returns HTTP 200 (no authorization check triggered). The empty body reflects the test environment: the YamlAuthModule stores role names as plain strings in users.yaml and does not persist Role objects into the security store's Directory. In any Yamcs instance where roles have been created through the REST API (POST /api/roles), this endpoint returns the full role-to-privilege mapping for every defined role.

Step 4 — Attempt to read a specific role by name

curl -s http://localhost:8090/api/roles/Administrator -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="

Actual response:

C:\Users\20616>curl -s http://localhost:8090/api/roles/Administrator -H "Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ="
{
  "code": 404,
  "type": "NotFoundException",
  "msg": "Resource not found"
}

The 404 is a business-logic outcome (the role object does not exist in the Directory for this test configuration), not an authorization rejection. The server never checked whether the caller is permitted to read role data — it proceeded to the lookup and returned the lookup result. In a deployment where roles are registered as objects, this endpoint returns their full privilege configuration to any authenticated user.

Observed vs Expected

Request Expected Actual Note
GET /api/users (operator) 403 403 ✓ Auth check present
GET /api/privileges (operator) 403 200 ✗ Confirmed — full privilege list leaked
GET /api/roles (operator) 403 200 ✗ Auth check absent; empty only in this test setup
GET /api/roles/Administrator (operator) 403 404 ✗ No auth check; 404 = role not in Directory, not access denied

Impact

Vulnerability type: Broken Function Level Authorization (BFLA) / Missing Authorization (OWASP API Security Top 10 2023: API5)

Who is impacted:
Any deployment of Yamcs that has authentication enabled (the default for production setups) and has more than one user tier. This includes the vast majority of operational Yamcs installations in ground station, satellite operations, and mission control contexts.

Direct impact:
- Any authenticated user, including operators, guest accounts, or service accounts with minimal privileges, can retrieve the server's complete privilege taxonomy and all role-to-privilege mappings.

Chained impact:
The disclosed privilege names and role definitions provide an attacker with a precise roadmap for privilege escalation: 1. Identify which privilege grants the capability they need (e.g., ChangeMissionDatabase for RCE via the algorithm engine, ControlAccess for full user management). 2. Identify which roles carry that privilege. 3. Target the accounts that hold those roles for credential theft, session hijacking, or social engineering.

In mission-critical environments (spacecraft operations, industrial control), unauthorized privilege escalation via this information leak could have safety implications beyond IT security.


Fix

Add ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess) as the first statement in each of the three affected methods, matching the pattern already used by adjacent endpoints in the same file:

// IamApi.java — apply to all three methods

public void listRoles(Context ctx, Empty request, Observer<ListRolesResponse> observer) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE
    ...
}

public void getRole(Context ctx, GetRoleRequest request, Observer<RoleInfo> observer) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE
    ...
}

public void listPrivileges(Context ctx, Empty request, Observer<ListPrivilegesResponse> observer) {
    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE
    ...
}
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.13.1"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.yamcs:yamcs-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.13.0"
            },
            {
              "fixed": "5.13.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.12.7"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.yamcs:yamcs-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.12.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55547"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T17:13:23Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nMissing authorization checks on three IAM API endpoints (`GET /api/roles`, `GET /api/roles/{name}`, `GET /api/privileges`) allow any authenticated user \u2014 regardless of their assigned permissions \u2014 to enumerate the complete list of system privileges and role definitions. An attacker with only a low-privilege account (e.g., a read-only operator) can retrieve the full privilege taxonomy of the server, including the names and assignments of all administrator-level capabilities. This information directly enables targeted privilege escalation attacks.\n\n---\n\n## Details\n\nThree handler methods in `IamApi.java` serve sensitive security metadata without performing any authorization check:\n\n**File:** `yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java`\n\n```java\n// Line 73 \u2014 GET /api/roles\n@Override\npublic void listRoles(Context ctx, Empty request, Observer\u003cListRolesResponse\u003e observer) {\n    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();\n    List\u003cRole\u003e roles = securityStore.getDirectory().getRoles();\n    // No ctx.checkSystemPrivilege() call \u2014 any authenticated user proceeds\n    ...\n    observer.complete(responseb.build());\n}\n\n// Line 87 \u2014 GET /api/roles/{name}\n@Override\npublic void getRole(Context ctx, GetRoleRequest request, Observer\u003cRoleInfo\u003e observer) {\n    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();\n    Role role = securityStore.getDirectory().getRole(request.getName());\n    // No ctx.checkSystemPrivilege() call\n    observer.complete(toRoleInfo(role));\n}\n\n// Line 112 \u2014 GET /api/privileges\n@Override\npublic void listPrivileges(Context ctx, Empty request, Observer\u003cListPrivilegesResponse\u003e observer) {\n    SecurityStore securityStore = YamcsServer.getServer().getSecurityStore();\n    List\u003cSystemPrivilege\u003e privileges = new ArrayList\u003c\u003e(securityStore.getSystemPrivileges());\n    // No ctx.checkSystemPrivilege() call\n    observer.complete(responseb.build());\n}\n```\n\nBy contrast, all write operations and user-management endpoints in the same file correctly enforce authorization. For example:\n\n```java\n// Line 126 \u2014 GET /api/users (correctly protected)\npublic void listUsers(...) {\n    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // \u2190 present\n    ...\n}\n\n// Line 142 \u2014 POST /api/users (correctly protected)\npublic void createUser(...) {\n    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // \u2190 present\n    ...\n}\n```\n\nThe three vulnerable endpoints share the same `ControlAccess` protection requirement as the user-management endpoints but were never given the corresponding check.\n\n**Route definitions** (confirmed in `yamcs-api/src/main/proto/yamcs/protobuf/iam/iam.proto`):\n\n```\nGET /api/privileges   \u2192 IamApi.listPrivileges()\nGET /api/roles        \u2192 IamApi.listRoles()\nGET /api/roles/{name} \u2192 IamApi.getRole()\n```\n\n---\n\n## PoC\n\u003cimg width=\"2324\" height=\"1086\" alt=\"image\" src=\"https://github.com/user-attachments/assets/98ec3e81-556d-41e1-9211-10a5b9ad0d59\" /\u003e\n\n\n### Environment\n\n- Yamcs version: 5.13.1-SNAPSHOT (latest master)\n- Auth module: YamlAuthModule (default)\n- Two accounts available: `admin` (Administrator) and `operator` (Operator)\n- Calculate the Basic Auth credentials for the two accounts (this needs to be done only once). Please modify according to the actual situation. These credentials will be used in subsequent commands. Here, there is a test low-privilege account named \"operator\" with the password \"password\".\n\n\u003cimg width=\"2243\" height=\"223\" alt=\"image\" src=\"https://github.com/user-attachments/assets/5614013c-2143-4f61-aba3-eab1cba24b67\" /\u003e\n\n`powershell -command \"[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(\u0027admin:admin\u0027))\"`\n\n`powershell -command \"[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(\u0027operator:password\u0027))\"`\n\n### Step 1 \u2014 Confirm that protected endpoints correctly return 403 for low-privilege users\n\n```cmd\ncurl -s -o nul -w \"HTTP %{http_code}\" http://localhost:8090/api/users -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n```\n\nExpected: `HTTP 403` \u2014 the user-list endpoint enforces `ControlAccess`.\n\n### Step 2 \u2014 Enumerate all system privileges with the operator account\n\n```cmd\ncurl -s http://localhost:8090/api/privileges -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n```\n\n**Actual response (HTTP 200):**\n\n```\nC:\\Users\\20616\u003ecurl -s http://localhost:8090/api/privileges -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n{\n  \"systemPrivileges\": [\"ChangeMissionDatabase\", \"CommandOptions\", \"ControlAccess\", \"ControlActivities\", \"ControlAlarms\", \"ControlArchiving\", \"ControlCommandClearances\", \"ControlCommandQueue\", \"ControlFileTransfers\", \"ControlLinks\", \"ControlProcessor\", \"ControlServices\", \"ControlTimeCorrelation\", \"ControlTimeline\", \"CreateInstances\", \"GetMissionDatabase\", \"ManageAnyBucket\", \"ManageParameterLists\", \"ModifyCommandHistory\", \"ReadActivities\", \"ReadAlarms\", \"ReadCommandHistory\", \"ReadEvents\", \"ReadFileTransfers\", \"ReadLinks\", \"ReadSystemInfo\", \"ReadTables\", \"ReadTimeline\", \"WriteEvents\", \"WriteTables\", \"web.AccessAdminArea\"]\n}\n```\n\nThe operator account receives the server\u0027s complete privilege taxonomy \u2014 all 31 system privileges including `ControlAccess` (full user management) and `ChangeMissionDatabase` (algorithm-level RCE, see related advisory).\n\n### Step 3 \u2014 Enumerate all defined roles with the operator account\n\n```cmd\ncurl -s http://localhost:8090/api/roles -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n```\n\n**Actual response (HTTP 200):**\n\n```\nC:\\Users\\20616\u003ecurl -s http://localhost:8090/api/roles -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n{\n}\n```\n\nThe endpoint returns HTTP 200 (no authorization check triggered). The empty body reflects the test environment: the `YamlAuthModule` stores role names as plain strings in `users.yaml` and does not persist `Role` objects into the security store\u0027s `Directory`. In any Yamcs instance where roles have been created through the REST API (`POST /api/roles`), this endpoint returns the full role-to-privilege mapping for every defined role.\n\n### Step 4 \u2014 Attempt to read a specific role by name\n\n```cmd\ncurl -s http://localhost:8090/api/roles/Administrator -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n```\n\n**Actual response:**\n\n```\nC:\\Users\\20616\u003ecurl -s http://localhost:8090/api/roles/Administrator -H \"Authorization: Basic b3BlcmF0b3I6cGFzc3dvcmQ=\"\n{\n  \"code\": 404,\n  \"type\": \"NotFoundException\",\n  \"msg\": \"Resource not found\"\n}\n```\n\nThe 404 is a business-logic outcome (the role object does not exist in the `Directory` for this test configuration), **not** an authorization rejection. The server never checked whether the caller is permitted to read role data \u2014 it proceeded to the lookup and returned the lookup result. In a deployment where roles are registered as objects, this endpoint returns their full privilege configuration to any authenticated user.\n\n### Observed vs Expected\n\n| Request | Expected | Actual | Note |\n|---------|----------|--------|------|\n| `GET /api/users` (operator) | 403 | **403** \u2713 | Auth check present |\n| `GET /api/privileges` (operator) | 403 | **200** \u2717 | **Confirmed \u2014 full privilege list leaked** |\n| `GET /api/roles` (operator) | 403 | **200** \u2717 | Auth check absent; empty only in this test setup |\n| `GET /api/roles/Administrator` (operator) | 403 | **404** \u2717 | No auth check; 404 = role not in Directory, not access denied |\n\n---\n\n## Impact\n\n**Vulnerability type:** Broken Function Level Authorization (BFLA) / Missing Authorization (OWASP API Security Top 10 2023: API5)\n\n**Who is impacted:**  \nAny deployment of Yamcs that has authentication enabled (the default for production setups) and has more than one user tier. This includes the vast majority of operational Yamcs installations in ground station, satellite operations, and mission control contexts.\n\n**Direct impact:**  \n- Any authenticated user, including operators, guest accounts, or service accounts with minimal privileges, can retrieve the server\u0027s complete privilege taxonomy and all role-to-privilege mappings.\n\n**Chained impact:**  \nThe disclosed privilege names and role definitions provide an attacker with a precise roadmap for privilege escalation:\n1. Identify which privilege grants the capability they need (e.g., `ChangeMissionDatabase` for RCE via the algorithm engine, `ControlAccess` for full user management).\n2. Identify which roles carry that privilege.\n3. Target the accounts that hold those roles for credential theft, session hijacking, or social engineering.\n\nIn mission-critical environments (spacecraft operations, industrial control), unauthorized privilege escalation via this information leak could have safety implications beyond IT security.\n\n---\n\n## Fix\n\nAdd `ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess)` as the first statement in each of the three affected methods, matching the pattern already used by adjacent endpoints in the same file:\n\n```java\n// IamApi.java \u2014 apply to all three methods\n\npublic void listRoles(Context ctx, Empty request, Observer\u003cListRolesResponse\u003e observer) {\n    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE\n    ...\n}\n\npublic void getRole(Context ctx, GetRoleRequest request, Observer\u003cRoleInfo\u003e observer) {\n    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE\n    ...\n}\n\npublic void listPrivileges(Context ctx, Empty request, Observer\u003cListPrivilegesResponse\u003e observer) {\n    ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess);  // ADD THIS LINE\n    ...\n}\n```",
  "id": "GHSA-cvw4-55pp-3hfq",
  "modified": "2026-08-28T17:13:23Z",
  "published": "2026-08-28T17:13:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/security/advisories/GHSA-cvw4-55pp-3hfq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/commit/c2aec1c242e656e48b52c7f87deea88183bb592d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/commit/dcaec5f0b2f4231b8e313e94d79a937169c9e0ba"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/yamcs/yamcs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/releases/tag/yamcs-5.12.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/yamcs/yamcs/releases/tag/yamcs-5.13.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Yamcs\u0027s Missing Authorization on Role and Privilege Enumeration Endpoints Allows Any Authenticated User to Disclose Full Security Configuration"
}

GHSA-CVWJ-6C9H-JG6V

Vulnerability from github – Published: 2026-02-25 18:59 – Updated: 2026-02-25 18:59
VLAI
Summary
Parse Dashboard is Missing Authorization for its Agent Endpoint
Details

Impact

The AI Agent API endpoint (POST /apps/:appId/agent) does not enforce authorization. Authenticated users scoped to specific apps can access any other app's agent endpoint by changing the app ID in the URL. Read-only users are given the full master key instead of the read-only master key and can supply write permissions in the request body to perform write and delete operations.

Affected are only dashboards with agent configuration enabled.

Patches

The fix adds per-app authorization checks and restricts read-only users to the readOnlyMasterKey with write permissions stripped server-side.

Workarounds

Remove the agent configuration block from your dashboard configuration. Dashboards without an agent config are not affected.

Resources

  • GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-cvwj-6c9h-jg6v
  • Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.0.0-alpha.7"
      },
      "package": {
        "ecosystem": "npm",
        "name": "parse-dashboard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.3.0-alpha.42"
            },
            {
              "fixed": "9.0.0-alpha.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27608"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-25T18:59:44Z",
    "nvd_published_at": "2026-02-25T03:16:04Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nThe AI Agent API endpoint (`POST /apps/:appId/agent`) does not enforce authorization. Authenticated users scoped to specific apps can access any other app\u0027s agent endpoint by changing the app ID in the URL. Read-only users are given the full master key instead of the read-only master key and can supply write permissions in the request body to perform write and delete operations.\n\nAffected are only dashboards with `agent` configuration enabled.\n\n### Patches\n\nThe fix adds per-app authorization checks and restricts read-only users to the `readOnlyMasterKey` with write permissions stripped server-side.\n\n### Workarounds\n\nRemove the `agent` configuration block from your dashboard configuration. Dashboards without an `agent` config are not affected.\n\n### Resources\n\n- GitHub advisory: https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-cvwj-6c9h-jg6v\n- Fixed in: https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8",
  "id": "GHSA-cvwj-6c9h-jg6v",
  "modified": "2026-02-25T18:59:44Z",
  "published": "2026-02-25T18:59:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-dashboard/security/advisories/GHSA-cvwj-6c9h-jg6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27608"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-dashboard"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-dashboard/releases/tag/9.0.0-alpha.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Parse Dashboard is Missing Authorization for its Agent Endpoint"
}

GHSA-CVXJ-CHGR-R353

Vulnerability from github – Published: 2026-08-05 21:31 – Updated: 2026-08-05 21:31
VLAI
Details

Spacebar Server before commit dcfd910 contains a missing authorization vulnerability that allows any authenticated attacker to add themselves to arbitrary group DM channels by sending a PUT request to the channels recipient endpoint without membership verification. Attackers can exploit the unguarded PUT /channels/{channel_id}/recipients/{user_id} handler to join private group DMs, read complete message history, post messages as a participant, and force-add third-party users without their consent.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-70617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T20:17:17Z",
    "severity": "HIGH"
  },
  "details": "Spacebar Server before commit dcfd910 contains a missing authorization vulnerability that allows any authenticated attacker to add themselves to arbitrary group DM channels by sending a PUT request to the channels recipient endpoint without membership verification. Attackers can exploit the unguarded PUT /channels/{channel_id}/recipients/{user_id} handler to join private group DMs, read complete message history, post messages as a participant, and force-add third-party users without their consent.",
  "id": "GHSA-cvxj-chgr-r353",
  "modified": "2026-08-05T21:31:39Z",
  "published": "2026-08-05T21:31:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/spacebarchat/server/security/advisories/GHSA-g38j-78fh-jm74"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-70617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/spacebarchat/server/commit/dcfd91035e3da42abf5f32d8d86a35219225b3d4"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/spacebar-server-missing-authorization-via-group-dm-recipient-endpoint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/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"
    }
  ]
}

GHSA-CW24-GR2Q-5J2R

Vulnerability from github – Published: 2026-06-26 15:32 – Updated: 2026-06-26 15:32
VLAI
Details

Unauthenticated Broken Access Control in Subscriptions for WooCommerce <= 1.9.5 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56061"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-26T15:16:45Z",
    "severity": "HIGH"
  },
  "details": "Unauthenticated Broken Access Control in Subscriptions for WooCommerce \u003c= 1.9.5 versions.",
  "id": "GHSA-cw24-gr2q-5j2r",
  "modified": "2026-06-26T15:32:16Z",
  "published": "2026-06-26T15:32:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56061"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/subscriptions-for-woocommerce/vulnerability/wordpress-subscriptions-for-woocommerce-plugin-1-9-5-broken-access-control-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-CW2P-J4HM-RRP2

Vulnerability from github – Published: 2023-09-11 21:30 – Updated: 2024-04-04 07:36
VLAI
Details

In multiple files, there is a possible way to import a contact from another user due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-35665"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-11T21:15:41Z",
    "severity": "HIGH"
  },
  "details": "In multiple files, there is a possible way to import a contact from another user due to a missing permission check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-cw2p-j4hm-rrp2",
  "modified": "2024-04-04T07:36:29Z",
  "published": "2023-09-11T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35665"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/services/Telephony/+/674039e70e1c5bf29b808899ac80c709acc82290"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-09-01"
    }
  ],
  "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-CW2V-Q9HW-55MQ

Vulnerability from github – Published: 2026-06-16 15:33 – Updated: 2026-06-16 15:33
VLAI
Details

A security issue was identified in Pavilion due to improper authorization enforcement in API endpoints. This vulnerability can allow an unauthorized actor to execute privileged operations, including user/role management and other administrative actions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-14272"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-16T15:16:33Z",
    "severity": "HIGH"
  },
  "details": "A security issue was\u00a0identified\u00a0in Pavilion due to improper\u00a0authorization\u00a0enforcement in API endpoints.\u00a0This vulnerability can\u00a0allow an unauthorized actor to execute privileged operations, including user/role management and other administrative actions.",
  "id": "GHSA-cw2v-q9hw-55mq",
  "modified": "2026-06-16T15:33:51Z",
  "published": "2026-06-16T15:33:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14272"
    },
    {
      "type": "WEB",
      "url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD1777.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:L/VA:L/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"
    }
  ]
}

GHSA-CW3Q-PVF8-6FVQ

Vulnerability from github – Published: 2026-11-06 12:30 – Updated: 2026-11-06 12:30
VLAI
Details

The VOD Infomaniak plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.5.15. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to initiate unauthorized video imports using the site owner's Infomaniak API credentials, consume the site owner's VOD account quota, and insert arbitrary rows into the wp_vod_upload table causing public shortcodes to resolve to attacker-chosen video content. This action is explicitly reserved for Contributor-level and above by the plugin's own role-rights system, meaning subscriber access is intentionally forbidden by design — the AJAX handler simply omits the enforcement.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-115831"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-11-06T10:16:36Z",
    "severity": "MODERATE"
  },
  "details": "The VOD Infomaniak plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.5.15. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to initiate unauthorized video imports using the site owner\u0027s Infomaniak API credentials, consume the site owner\u0027s VOD account quota, and insert arbitrary rows into the wp_vod_upload table causing public shortcodes to resolve to attacker-chosen video content. This action is explicitly reserved for Contributor-level and above by the plugin\u0027s own role-rights system, meaning subscriber access is intentionally forbidden by design \u2014 the AJAX handler simply omits the enforcement.",
  "id": "GHSA-cw3q-pvf8-6fvq",
  "modified": "2026-11-06T12:30:36Z",
  "published": "2026-11-06T12:30:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-115831"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/vod-infomaniak/tags/1.5.15/vod.class.php#L1790"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/vod-infomaniak/tags/1.5.15/vod.class.php#L388"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/vod-infomaniak/tags/1.5.15/vod.class.php#L92"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?reponame=\u0026old=3781274%40vod-infomaniak\u0026new=3781274%40vod-infomaniak"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c1c79256-3f59-4137-b81b-e2bb5402c148?source=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:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design
  • 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
Architecture and Design

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
Architecture and Design

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
Architecture and Design
  • 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
System Configuration Installation

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.