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
20040 vulnerabilities reference this CWE, most recent first.
GHSA-GQCH-G4W5-7QCW
Vulnerability from github – Published: 2026-08-17 21:59 – Updated: 2026-08-17 21:59Summary
The _validate_source_run and _validate_source_model functions in mlflow/server/handlers.py verify that a model version source path is within the artifact directory of a specified run or logged model, but do not check whether the caller has READ permission on that run or model. An authenticated MLflow user can therefore reference another user's run_id in CreateModelVersion, creating a model version whose artifact URI points at the victim's artifact directory. If the calling user has MANAGE permission on the registered model (which they do after creation), they can then read arbitrary files from the victim's artifact directory via GET /model-versions/get-artifact, bypassing the experiment-level READ permission gate on GET /get-artifact.
Details
POST /api/2.0/mlflow/model-versions/create is protected: the caller must have UPDATE permission on the registered model. However, the source/run_id validation performed inside _validate_source_run only verifies path containment, not caller authorization:
# mlflow/server/handlers.py _validate_source_run()
def _validate_source_run(source: str, run_id: str) -> None:
if is_local_uri(source):
if run_id:
store = _get_tracking_store()
run = store.get_run(run_id) # <-- no permission check on run_id
source = pathlib.Path(local_file_uri_to_path(source)).resolve()
if is_local_uri(run.info.artifact_uri):
run_artifact_dir = pathlib.Path(...).resolve()
if run_artifact_dir in [source, *source.parents]:
return # validation passes
raise MlflowException(...)
After creation, the model version's source and run_id point at the victim's artifact directory. The caller can read files from that directory via the model version artifact handler, which derives the artifact path from the stored source:
GET /model-versions/get-artifact?name=<model>&version=<v>&path=<file>
This bypass matters in deployments where experiment-level permissions are explicitly restricted -- i.e., where the default_permission is NO_PERMISSIONS or the target experiment has no grant for the attacker. Without the bypass, GET /get-artifact for the victim's run would return 403; via the model version artifact handler it returns 200.
PoC
Prerequisites: MLflow v3.13.0, --app-name basic-auth, default_permission=NO_PERMISSIONS (or alice's experiment restricted). Alice owns experiment 2 and run ALICE_RUN_ID. Bob owns experiment 4. Bob has READ on his own resources but NOT on alice's experiment.
- Alice uploads a private file:
# file is at /mlruns/2/ALICE_RUN_ID/artifacts/secret_weights.txt
echo "ALICE_SECRET_MODEL_WEIGHTS=0.42" > secret_weights.txt
- Bob directly tries to read alice's artifact -- blocked:
GET /get-artifact?run_id=ALICE_RUN_ID&path=secret_weights.txt HTTP/1.1
Authorization: Basic <bob credentials>
Response: HTTP 403 (when alice's experiment is private)
- Bob creates a model version referencing alice's run_id as source anchor:
POST /api/2.0/mlflow/model-versions/create HTTP/1.1
Authorization: Basic <bob credentials>
Content-Type: application/json
{"name":"bob-model","source":"/mlruns/2/ALICE_RUN_ID/artifacts","run_id":"ALICE_RUN_ID"}
Response: HTTP 200
{"model_version":{"name":"bob-model","version":"1","source":"/mlruns/2/ALICE_RUN_ID/artifacts","run_id":"ALICE_RUN_ID"}}
- Bob reads alice's private file via the model version artifact handler:
GET /model-versions/get-artifact?name=bob-model&version=1&path=secret_weights.txt HTTP/1.1
Authorization: Basic <bob credentials>
Response: HTTP 200 -- body contains ALICE_SECRET_MODEL_WEIGHTS=0.42
Live-validated on v3.13.0 with default_permission=READ (the file download is confirmed 200 OK); impact escalates to a true bypass when default_permission=NO_PERMISSIONS.
Impact
An authenticated user who can create registered models can read arbitrary files from any other user's artifact directory, bypassing the experiment-level READ permission gate. Model weights, training data samples, and evaluation reports stored in a run's artifact directory are accessible. The attacker needs UPDATE (or MANAGE) permission on at least one registered model; with default_permission=READ, that is automatically granted to the model creator.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "mlflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-69148"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-17T21:59:09Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe `_validate_source_run` and `_validate_source_model` functions in `mlflow/server/handlers.py` verify that a model version source path is within the artifact directory of a specified run or logged model, but do not check whether the caller has READ permission on that run or model. An authenticated MLflow user can therefore reference another user\u0027s run_id in `CreateModelVersion`, creating a model version whose artifact URI points at the victim\u0027s artifact directory. If the calling user has MANAGE permission on the registered model (which they do after creation), they can then read arbitrary files from the victim\u0027s artifact directory via `GET /model-versions/get-artifact`, bypassing the experiment-level READ permission gate on `GET /get-artifact`.\n\n### Details\n\n`POST /api/2.0/mlflow/model-versions/create` is protected: the caller must have UPDATE permission on the registered model. However, the source/run_id validation performed inside `_validate_source_run` only verifies path containment, not caller authorization:\n\n```python\n# mlflow/server/handlers.py _validate_source_run()\ndef _validate_source_run(source: str, run_id: str) -\u003e None:\n if is_local_uri(source):\n if run_id:\n store = _get_tracking_store()\n run = store.get_run(run_id) # \u003c-- no permission check on run_id\n source = pathlib.Path(local_file_uri_to_path(source)).resolve()\n if is_local_uri(run.info.artifact_uri):\n run_artifact_dir = pathlib.Path(...).resolve()\n if run_artifact_dir in [source, *source.parents]:\n return # validation passes\n raise MlflowException(...)\n```\n\nAfter creation, the model version\u0027s `source` and `run_id` point at the victim\u0027s artifact directory. The caller can read files from that directory via the model version artifact handler, which derives the artifact path from the stored `source`:\n\n```\nGET /model-versions/get-artifact?name=\u003cmodel\u003e\u0026version=\u003cv\u003e\u0026path=\u003cfile\u003e\n```\n\nThis bypass matters in deployments where experiment-level permissions are explicitly restricted -- i.e., where the default_permission is NO_PERMISSIONS or the target experiment has no grant for the attacker. Without the bypass, `GET /get-artifact` for the victim\u0027s run would return 403; via the model version artifact handler it returns 200.\n\n### PoC\n\nPrerequisites: MLflow v3.13.0, `--app-name basic-auth`, default_permission=NO_PERMISSIONS (or alice\u0027s experiment restricted). Alice owns experiment 2 and run ALICE_RUN_ID. Bob owns experiment 4. Bob has READ on his own resources but NOT on alice\u0027s experiment.\n\n1. Alice uploads a private file:\n\n```bash\n# file is at /mlruns/2/ALICE_RUN_ID/artifacts/secret_weights.txt\necho \"ALICE_SECRET_MODEL_WEIGHTS=0.42\" \u003e secret_weights.txt\n```\n\n2. Bob directly tries to read alice\u0027s artifact -- blocked:\n\n```\nGET /get-artifact?run_id=ALICE_RUN_ID\u0026path=secret_weights.txt HTTP/1.1\nAuthorization: Basic \u003cbob credentials\u003e\n```\n\nResponse: HTTP 403 (when alice\u0027s experiment is private)\n\n3. Bob creates a model version referencing alice\u0027s run_id as source anchor:\n\n```\nPOST /api/2.0/mlflow/model-versions/create HTTP/1.1\nAuthorization: Basic \u003cbob credentials\u003e\nContent-Type: application/json\n\n{\"name\":\"bob-model\",\"source\":\"/mlruns/2/ALICE_RUN_ID/artifacts\",\"run_id\":\"ALICE_RUN_ID\"}\n```\n\nResponse: HTTP 200\n```json\n{\"model_version\":{\"name\":\"bob-model\",\"version\":\"1\",\"source\":\"/mlruns/2/ALICE_RUN_ID/artifacts\",\"run_id\":\"ALICE_RUN_ID\"}}\n```\n\n4. Bob reads alice\u0027s private file via the model version artifact handler:\n\n```\nGET /model-versions/get-artifact?name=bob-model\u0026version=1\u0026path=secret_weights.txt HTTP/1.1\nAuthorization: Basic \u003cbob credentials\u003e\n```\n\nResponse: HTTP 200 -- body contains `ALICE_SECRET_MODEL_WEIGHTS=0.42`\n\nLive-validated on v3.13.0 with default_permission=READ (the file download is confirmed 200 OK); impact escalates to a true bypass when default_permission=NO_PERMISSIONS.\n\n### Impact\n\nAn authenticated user who can create registered models can read arbitrary files from any other user\u0027s artifact directory, bypassing the experiment-level READ permission gate. Model weights, training data samples, and evaluation reports stored in a run\u0027s artifact directory are accessible. The attacker needs UPDATE (or MANAGE) permission on at least one registered model; with default_permission=READ, that is automatically granted to the model creator.",
"id": "GHSA-gqch-g4w5-7qcw",
"modified": "2026-08-17T21:59:09Z",
"published": "2026-08-17T21:59:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/security/advisories/GHSA-gqch-g4w5-7qcw"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/pull/24293"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/commit/4bb7474771c3be808cd9e129defef9305f2869be"
},
{
"type": "PACKAGE",
"url": "https://github.com/mlflow/mlflow"
},
{
"type": "WEB",
"url": "https://github.com/mlflow/mlflow/releases/tag/v3.15.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "MLflow: CreateModelVersion source validation does not check READ permission on referenced run_id"
}
GHSA-GQCQ-9XJX-87R8
Vulnerability from github – Published: 2025-01-02 12:32 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in Saurav Sharma Generate Dummy Posts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Generate Dummy Posts: from n/a through 1.0.0.
{
"affected": [],
"aliases": [
"CVE-2023-46637"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-02T12:15:14Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Saurav Sharma Generate Dummy Posts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Generate Dummy Posts: from n/a through 1.0.0.",
"id": "GHSA-gqcq-9xjx-87r8",
"modified": "2026-04-28T21:35:29Z",
"published": "2025-01-02T12:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46637"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/generate-dummy-posts/vulnerability/wordpress-generate-dummy-posts-plugin-1-0-0-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:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQGM-6HG6-VRVF
Vulnerability from github – Published: 2025-01-22 15:32 – Updated: 2026-04-01 18:33Missing Authorization vulnerability in NotFound Database Sync allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Database Sync: from n/a through 0.5.1.
{
"affected": [],
"aliases": [
"CVE-2025-23486"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-22T15:15:16Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in NotFound Database Sync allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Database Sync: from n/a through 0.5.1.",
"id": "GHSA-gqgm-6hg6-vrvf",
"modified": "2026-04-01T18:33:19Z",
"published": "2025-01-22T15:32:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23486"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/database-sync/vulnerability/wordpress-database-sync-plugin-0-5-1-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQH3-7856-RJJG
Vulnerability from github – Published: 2026-10-20 18:14 – Updated: 2026-10-20 18:14Summary
The REST route GET /api/v1/<piece-type>/:_id/locales (and the equivalent page route) does not apply the publicApiCheckAsync gate that ApostropheCMS's other read routes enforce. An unauthenticated caller can therefore query this route for any document _id and learn whether the document exists and which locales it is published in — a document-existence and locale-metadata disclosure that the read-API is otherwise supposed to gate.
Affected
- Repository:
apostrophecms/apostrophe(monorepo packageapostrophe). - Confirmed at 4.32.2 (commit
d3ff8c9== the shipped 4.32.2; unchanged at current HEAD). No fix at time of report. - Stack: Node.js / Express + MongoDB.
- Endpoints:
GET /api/v1/<piece-type>/:_id/localesandGET /api/v1/@apostrophecms/page/:_id/locales.
Technical detail
- Unsafe:
modules/@apostrophecms/piece-type/index.js:397registers the:_id/localesroute with nopublicApiCheckAsync. The page module has the same omission atmodules/@apostrophecms/page/index.js:925. - Gated siblings: the read routes in the same module (e.g.
getAllatpiece-type/index.js:256-263) callpublicApiCheckAsync(:263) to enforce the public-API access policy. - So the
localeshandler (which callsgetLocales()for the document) runs for any caller regardless of the public-API gate the other read routes apply, returning the document's locale/publication metadata without authorization.
Impact
An unauthenticated caller can confirm the existence of a document by _id and enumerate its locales/publication state — information the read-API is meant to gate. Defensibly 4.3 (AC:H) given the opaque _id precondition (the caller needs a document id).
How it was verified (local only)
Reproduced against apostrophe@4.32.2 (== commit d3ff8c9) locally with synthetic content:
- Source review confirmed the :_id/locales route lacks publicApiCheckAsync while the sibling read routes have it.
- An unauthenticated GET /api/v1/<piece-type>/<_id>/locales returned the document's locale metadata (existence + locales), while the gated read routes (e.g. getAll) correctly required the public-API policy.
- Control: the same route with the publicApiCheckAsync gate added (matching the siblings) denies the unauthenticated request — isolating the missing gate as the cause.
Synthetic content only; nothing hosted was touched.
Remediation
Add the publicApiCheckAsync (or equivalent) authorization gate to the :_id/locales route in both the piece-type and page modules, matching the sibling read routes, so the locale/existence metadata is only returned to callers permitted by the public-API policy.
Credit
Please credit Santosh Kumar Puppala (https://github.com/Santoshkumarpuppala).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "apostrophe"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.33.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-113668"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-20T18:14:32Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nThe REST route `GET /api/v1/\u003cpiece-type\u003e/:_id/locales` (and the equivalent page route) does not apply the `publicApiCheckAsync` gate that ApostropheCMS\u0027s other read routes enforce. An unauthenticated caller can therefore query this route for any document `_id` and learn whether the document exists and which locales it is published in \u2014 a document-existence and locale-metadata disclosure that the read-API is otherwise supposed to gate.\n \n## Affected\n- Repository: `apostrophecms/apostrophe` (monorepo package `apostrophe`).\n- Confirmed at **4.32.2** (commit `d3ff8c9` == the shipped 4.32.2; unchanged at current HEAD). No fix at time of report.\n- Stack: Node.js / Express + MongoDB.\n- Endpoints: `GET /api/v1/\u003cpiece-type\u003e/:_id/locales` and `GET /api/v1/@apostrophecms/page/:_id/locales`.\n\n## Technical detail\n- Unsafe: `modules/@apostrophecms/piece-type/index.js:397` registers the `:_id/locales` route with **no** `publicApiCheckAsync`. The page module has the same omission at `modules/@apostrophecms/page/index.js:925`.\n- Gated siblings: the read routes in the same module (e.g. `getAll` at `piece-type/index.js:256-263`) call `publicApiCheckAsync` (`:263`) to enforce the public-API access policy.\n- So the `locales` handler (which calls `getLocales()` for the document) runs for any caller regardless of the public-API gate the other read routes apply, returning the document\u0027s locale/publication metadata without authorization.\n\n## Impact\n\nAn unauthenticated caller can confirm the existence of a document by `_id` and enumerate its locales/publication state \u2014 information the read-API is meant to gate. Defensibly 4.3 (AC:H) given the opaque `_id` precondition (the caller needs a document id).\n \n## How it was verified (local only)\nReproduced against `apostrophe@4.32.2` (== commit `d3ff8c9`) locally with synthetic content:\n- Source review confirmed the `:_id/locales` route lacks `publicApiCheckAsync` while the sibling read routes have it.\n- An **unauthenticated** `GET /api/v1/\u003cpiece-type\u003e/\u003c_id\u003e/locales` returned the document\u0027s locale metadata (existence + locales), while the gated read routes (e.g. `getAll`) correctly required the public-API policy.\n- Control: the same route with the `publicApiCheckAsync` gate added (matching the siblings) denies the unauthenticated request \u2014 isolating the missing gate as the cause.\nSynthetic content only; nothing hosted was touched.\n \n## Remediation\nAdd the `publicApiCheckAsync` (or equivalent) authorization gate to the `:_id/locales` route in both the piece-type and page modules, matching the sibling read routes, so the locale/existence metadata is only returned to callers permitted by the public-API policy.\n \n## Credit\nPlease credit **Santosh Kumar Puppala** (https://github.com/Santoshkumarpuppala).",
"id": "GHSA-gqh3-7856-rjjg",
"modified": "2026-10-20T18:14:33Z",
"published": "2026-10-20T18:14:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-gqh3-7856-rjjg"
},
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/commit/9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce"
},
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/commit/f84fd41cbf6c22eb8d0008fc9c25df1f7130b350"
},
{
"type": "PACKAGE",
"url": "https://github.com/apostrophecms/apostrophe"
},
{
"type": "WEB",
"url": "https://github.com/apostrophecms/apostrophe/releases/tag/apostrophe@4.33.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "ApostropheCMS: :_id/locales REST route omits the public-API authorization gate its sibling read routes enforce (unauthenticated doc-existence + locale metadata disclosure)"
}
GHSA-GQHV-VCHR-9QQ9
Vulnerability from github – Published: 2025-11-04 15:31 – Updated: 2025-11-05 17:48A lack of authorisation vulnerability has been detected in CanalDenuncia.app. This vulnerability allows an attacker to access other users' information by sending a POST through the parameter 'web' in '/backend/api/buscarConfiguracionParametros.php'.
{
"affected": [],
"aliases": [
"CVE-2025-41336"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T14:15:35Z",
"severity": "HIGH"
},
"details": "A lack of authorisation vulnerability has been detected in CanalDenuncia.app. This vulnerability allows an attacker to access other users\u0027 information by sending a POST through the\u00a0parameter \u0027web\u0027 in \u0027/backend/api/buscarConfiguracionParametros.php\u0027.",
"id": "GHSA-gqhv-vchr-9qq9",
"modified": "2025-11-05T17:48:27Z",
"published": "2025-11-04T15:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41336"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-canaldenunciaapp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/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-GQJ6-WGGH-FX6M
Vulnerability from github – Published: 2025-06-06 15:30 – Updated: 2026-04-01 18:35Missing Authorization vulnerability in Thad Allender GPP Slideshow allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects GPP Slideshow: from n/a through 1.3.5.
{
"affected": [],
"aliases": [
"CVE-2025-28996"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-06T13:15:30Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Thad Allender GPP Slideshow allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects GPP Slideshow: from n/a through 1.3.5.",
"id": "GHSA-gqj6-wggh-fx6m",
"modified": "2026-04-01T18:35:18Z",
"published": "2025-06-06T15:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28996"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/gpp-slideshow/vulnerability/wordpress-gpp-slideshow-1-3-5-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQJ9-G6J7-JF68
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in AWESOME TOGI Product Category Tree allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Product Category Tree: from n/a through 2.5.
{
"affected": [],
"aliases": [
"CVE-2023-29173"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:26Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in AWESOME TOGI Product Category Tree allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Product Category Tree: from n/a through 2.5.",
"id": "GHSA-gqj9-g6j7-jf68",
"modified": "2026-04-28T21:35:17Z",
"published": "2024-12-09T15:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29173"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/product-category-tree/vulnerability/wordpress-product-category-tree-plugin-2-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:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-GQM2-2GCX-P88W
Vulnerability from github – Published: 2022-01-13 00:01 – Updated: 2024-07-03 14:13Jenkins Credentials Binding Plugin prior to 1.27.1 and 1.24.1 does not perform a permission check in a method implementing form validation.
This allows attackers with Overall/Read access to validate if a credential ID refers to a secret file credential and whether it’s a zip file.
Credentials Binding Plugin 1.27.1 and 1.24.1 performs permission checks when validating secret file credentials IDs.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:credentials-binding"
},
"ranges": [
{
"events": [
{
"introduced": "1.25"
},
{
"fixed": "1.27.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:credentials-binding"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.24.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-20616"
],
"database_specific": {
"cwe_ids": [
"CWE-732",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-20T22:49:42Z",
"nvd_published_at": "2022-01-12T20:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins Credentials Binding Plugin prior to 1.27.1 and 1.24.1 does not perform a permission check in a method implementing form validation.\n\nThis allows attackers with Overall/Read access to validate if a credential ID refers to a secret file credential and whether it\u2019s a zip file.\n\nCredentials Binding Plugin 1.27.1 and 1.24.1 performs permission checks when validating secret file credentials IDs.",
"id": "GHSA-gqm2-2gcx-p88w",
"modified": "2024-07-03T14:13:06Z",
"published": "2022-01-13T00:01:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20616"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/credentials-binding-plugin/commit/2dd5eda721e52d9a5bf6748405adf965ba517d8a"
},
{
"type": "WEB",
"url": "https://github.com/CVEProject/cvelist/blob/2d78eb36f4d084db7fb35f1535d8d84fdcb7d859/2022/20xxx/CVE-2022-20616.json"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/credentials-binding-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-01-12/#SECURITY-2342"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/01/12/6"
}
],
"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": "Incorrect Permission Assignment for Critical Resource in Jenkins Credentials Binding Plugin"
}
GHSA-GQMF-Q62P-Q4Q6
Vulnerability from github – Published: 2026-05-12 03:31 – Updated: 2026-05-12 03:31Due to missing authorization check in SAP S/4HANA Condition Maintenance, an authenticated attacker could gain unauthorized access to view and modify condition table records, resulting in low impact on the confidentiality and integrity of the data. Additionally, this vulnerability may prevent the legitimate user from accessing the records, causing low impact on application availability.
{
"affected": [],
"aliases": [
"CVE-2026-40133"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T03:16:12Z",
"severity": "MODERATE"
},
"details": "Due to missing authorization check in SAP S/4HANA Condition Maintenance, an authenticated attacker could gain unauthorized access to view and modify condition table records, resulting in low impact on the confidentiality and integrity of the data. Additionally, this vulnerability may prevent the legitimate user from accessing the records, causing low impact on application availability.",
"id": "GHSA-gqmf-q62p-q4q6",
"modified": "2026-05-12T03:31:27Z",
"published": "2026-05-12T03:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40133"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3718083"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-GQMR-QCG4-H6W5
Vulnerability from github – Published: 2023-03-10 21:30 – Updated: 2023-03-15 18:30In telephony service, there is a missing permission check. This could lead to local information disclosure with no additional execution privileges needed.
{
"affected": [],
"aliases": [
"CVE-2022-47473"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-10T21:15:00Z",
"severity": "MODERATE"
},
"details": "In telephony service, there is a missing permission check. This could lead to local information disclosure with no additional execution privileges needed.",
"id": "GHSA-gqmr-qcg4-h6w5",
"modified": "2023-03-15T18:30:26Z",
"published": "2023-03-10T21:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47473"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/1632612109718192129"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/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.