Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14816 vulnerabilities reference this CWE, most recent first.

GHSA-PQPW-CVM4-8MV9

Vulnerability from github – Published: 2026-07-09 20:54 – Updated: 2026-07-09 20:54

Summary

Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy

Details

Summary

Avo's direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as upload_{FIELD_ID}?.

An authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both update? and upload_<field>? policies deny the operation.

This primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies.

Details

Avo exposes a direct attachment upload endpoint:

POST /<avo-root>/avo_api/resources/:resource_name/:id/attachments/

The vulnerable code path is Avo::AttachmentsController#create:

app/controllers/avo/attachments_controller.rb:9-24

Current behavior:

def create
  blob = ActiveStorage::Blob.create_and_upload! io: params[:file].to_io, filename: params[:filename]
  association_name = BaseResource.valid_attachment_name(@record, params[:attachment_key])

  if association_name
    @record.send(association_name).attach blob
  elsif params[:key].blank?
    raise ActionController::BadRequest.new(...)
  end

  render json: {
    url: main_app.url_for(blob),
    href: main_app.url_for(blob)
  }
end

This endpoint creates an ActiveStorage::Blob before validating the requested attachment association and before any upload authorization could be enforced. If attachment_key resolves to an association, the blob is attached to the target record. If the request uses the key-based/Trix path, the endpoint can still persist the blob and return url/href even when no attachment association is resolved on the target record.

The controller never calls:

@resource.authorization.authorize_action("upload_<field>?", record: @record, ...)
@resource.authorization.authorize_action("update?", record: @record, ...)

This is inconsistent with the rest of Avo's file authorization implementation. The field-level file authorization concern defines upload authorization as:

lib/avo/fields/concerns/file_authorization.rb:11-12
lib/avo/fields/concerns/file_authorization.rb:25-27

def can_upload_file?
  authorize_file_action(:upload)
end

def authorize_file_action(action)
  authorize_action("#{action}_#{id}?", record: record, raise_exception: false)
end

That upload policy is used by UI components to decide whether to render upload controls, but the server-side upload endpoint does not enforce the same policy. A user can therefore bypass the policy by directly POSTing to the endpoint.

By contrast, attachment deletion does call attachment-specific authorization:

app/controllers/avo/attachments_controller.rb:27-65

def destroy
  if authorized_to :delete
    ...
  end
end

def authorized_to(action)
  @resource.authorization.authorize_action("#{action}_#{params[:attachment_name]}?", record: @record, raise_exception: false)
end

The asymmetry is:

destroy: calls delete_<attachment_name>?
create: does not call upload_<attachment_key>? or update?

The field-level upload authorization intent is also documented by Avo:

Issue #1624 requested the "Ability to police each file upload/download/delete". https://github.com/avo-hq/avo/issues/1624
PR #1625 introduced upload_cover_photo? as an example upload policy method. https://github.com/avo-hq/avo/pull/1625
PR #1667 clarified the policy semantics: "From now on, only field level authorization will be considered. If it is defined and returns true, the action will be granted; otherwise, it will not." https://github.com/avo-hq/avo/pull/1667
The current Avo authorization documentation lists upload_{FIELD_ID}? as the policy method controlling whether a user can upload an attachment, stating: "Controls whether the user can upload the attachment." https://docs.avohq.io/4.0/authorization.html
The same documentation says the same upload_file? policy method will be used to "authorize the file upload" in action file fields. https://docs.avohq.io/4.0/authorization.html

Affected versions observed:

PoC-confirmed: Avo 3.31.2, commit 46aa6b3bc9e3283110c39e58cfec8bb95adc1897
Same vulnerable code path by source inspection: origin/main HEAD as of 2026-05-29, 9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73
Same vulnerable code path by source inspection: Avo v4.0.0.beta.26, 6d339595a27f8779cb99b4aa38ddc97cb702b30f
Same vulnerable code path by source inspection: origin/4-dev at version 4.0.0.beta.40, 7ab9794f8b044b11b9677cdc57547d99cf96c3f3

Suggested affected range for the GitHub Security Advisory form:

>= 2.28.0

Rationale:

The direct attachment upload endpoint exists without upload authorization from commit ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858 (feature: trix attachments, 2021-04-24), first included in tag v1.4.0.
The documented field-level upload policy bypass is confirmed from commit 667049ceeda838394214489693d088708d9da77d (feature: field level file authorization, 2023-03-12), first included in tag v2.28.0.
PR #1667 later clarified the field-level-only grant/deny semantics in commit 31b6ef94f8cc4c340a2a75eec36c838cda933ce7, first included in tag v2.30.1.

From a narrow missing-authorization perspective, the issue exists from v1.4.0; the >= 2.28.0 range is a conservative submission range anchored to the documented field-level upload policy boundary.

Fixed version: to be determined by maintainers.

PoC

A local request spec was used to reproduce the issue. The PoC adds pundit to the test group and replaces Avo::Services::AuthorizationService with a test double. The test double records every authorize_action invocation and, when invoked, delegates the decision to a PostPolicy resolved via Pundit.policy!.

The policy setup is:

PostPolicy#update? returns false
PostPolicy#upload_attachments? returns false
PostPolicy#upload_cover_photo? returns false
PostPolicy#method_missing returns true for all other policy methods ending in ?, simulating a user with general read access but explicit update/upload denial
the replacement authorization service records all authorize_action calls

The open-source repository does not include Avo Pro's authorization client. The critical observation is independent of which client is plugged in: the vulnerable endpoint never invokes authorize_action at all, so the call list remains empty.

The PoC user has roles: {admin: true}, which is required only to pass the dummy app's coarse route-level guard:

authenticate :user, ->(user) { user.is_admin? }

The vulnerability under test is one layer below that guard: the fine-grained record/field authorization that Avo Pro/Pundit deployments would normally enforce. The dummy route gate is not part of Avo's upload policy decision. In a deployment where non-admin operators reach Avo through a different authentication rule, AttachmentsController#create would still skip authorize_action for the upload.

Policy scoping is orthogonal to this finding. Even if apply_policy filtered the record set during lookup, AttachmentsController#create would still not authorize the upload action itself for records that survive the scope.

The spec demonstrates:

Normal record update is denied by policy and does not persist changes.
Direct upload with attachment_key=cover_photo succeeds even though PostPolicy#upload_cover_photo? returns false, replacing the existing has_one_attached cover_photo blob.
Direct upload with attachment_key=attachments succeeds even though PostPolicy#upload_attachments? returns false, adding to a has_many_attached association.
Direct upload with params[:key] and no attachment association succeeds, creates an ActiveStorage::Blob, and returns url/href without attaching the blob to the record.
The direct upload requests do not invoke the replacement authorization service at all.

The full request-spec patch can be provided in this advisory thread if useful.

Verification environment:

Ruby 3.3.1
Avo 3.31.2
Commit 46aa6b3bc9e3283110c39e58cfec8bb95adc1897

Impact

This is a missing server-side authorization vulnerability in Avo's direct attachment upload endpoint.

The primary affected deployments are Avo Pro/Advanced-style multi-role deployments where non-administrator or restricted operator users can reach Avo, and per-record/per-field operations are expected to be enforced by policies.

In such deployments, an authenticated Avo user can add or replace attachment content on a resolved record even when the host application policy denies both:

record update, for example update?
field-level upload, for example upload_cover_photo? or upload_attachments?

For has_one_attached fields, the demonstrated impact is replacement of a protected attachment field with attacker-controlled content. The attacker controls the uploaded binary content, filename, and content-type metadata for the reachable field.

For key-based/Trix upload flows, the endpoint can persist a blob and return a URL even when no attachment association is resolved. This means the endpoint should not be left as an unauthenticated blob creation and URL return path for authenticated Avo users.

In admin-only deployments following the Avo Community pattern, practical exposure is much lower because the only users who can reach the endpoint are already trusted to perform record updates through the normal CRUD path.

Suggested fix direction:

validate the requested attachment_key before any blob is stored
perform upload authorization before ActiveStorage::Blob.create_and_upload!
derive the policy method from the validated association name rather than raw request input
apply an equivalent authorization decision to supported params[:key] / Trix upload flows before blob creation or URL return
return a JSON-compatible 403 Forbidden response when upload authorization is denied

The default Avo::Services::AuthorizationService#authorize_action returns true in lib/avo/services/authorization_service.rb:34-35, so applications without a custom authorization client should not see a behavior change from adding an authorization call. Deployments with custom/Pro authorization clients that explicitly deny upload would gain enforcement at this endpoint.

No official Avo-level workaround was confirmed in this review. Until a fix is available, applications can reduce exposure by ensuring only fully trusted administrators can access Avo routes.

Applications needing an immediate mitigation may override or monkey-patch Avo::AttachmentsController#create to authorize uploads before blob creation. Any mitigation should be tested against the application's Avo authorization client and upload UI, because the endpoint is used by Trix/file upload flows. If a mitigation falls back to update? for key-based/Trix uploads, that is a conservative behavior change for applications that currently allow read-only operators to use those uploads; those deployments should replace the fallback with an explicit rich-text upload policy.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "avo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.28.0"
            },
            {
              "fixed": "3.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:54:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAvo\u0027s direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as `upload_{FIELD_ID}?`.\n\nAn authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both `update?` and `upload_\u003cfield\u003e?` policies deny the operation.\n\nThis primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies.\n\n### Details\n\nAvo exposes a direct attachment upload endpoint:\n\n```text\nPOST /\u003cavo-root\u003e/avo_api/resources/:resource_name/:id/attachments/\n```\n\nThe vulnerable code path is `Avo::AttachmentsController#create`:\n\n- `app/controllers/avo/attachments_controller.rb:9-24`\n\nCurrent behavior:\n\n```ruby\ndef create\n  blob = ActiveStorage::Blob.create_and_upload! io: params[:file].to_io, filename: params[:filename]\n  association_name = BaseResource.valid_attachment_name(@record, params[:attachment_key])\n\n  if association_name\n    @record.send(association_name).attach blob\n  elsif params[:key].blank?\n    raise ActionController::BadRequest.new(...)\n  end\n\n  render json: {\n    url: main_app.url_for(blob),\n    href: main_app.url_for(blob)\n  }\nend\n```\n\nThis endpoint creates an `ActiveStorage::Blob` before validating the requested attachment association and before any upload authorization could be enforced. If `attachment_key` resolves to an association, the blob is attached to the target record. If the request uses the key-based/Trix path, the endpoint can still persist the blob and return `url`/`href` even when no attachment association is resolved on the target record.\n\nThe controller never calls:\n\n- `@resource.authorization.authorize_action(\"upload_\u003cfield\u003e?\", record: @record, ...)`\n- `@resource.authorization.authorize_action(\"update?\", record: @record, ...)`\n\nThis is inconsistent with the rest of Avo\u0027s file authorization implementation. The field-level file authorization concern defines upload authorization as:\n\n- `lib/avo/fields/concerns/file_authorization.rb:11-12`\n- `lib/avo/fields/concerns/file_authorization.rb:25-27`\n\n```ruby\ndef can_upload_file?\n  authorize_file_action(:upload)\nend\n\ndef authorize_file_action(action)\n  authorize_action(\"#{action}_#{id}?\", record: record, raise_exception: false)\nend\n```\n\nThat upload policy is used by UI components to decide whether to render upload controls, but the server-side upload endpoint does not enforce the same policy. A user can therefore bypass the policy by directly POSTing to the endpoint.\n\nBy contrast, attachment deletion does call attachment-specific authorization:\n\n- `app/controllers/avo/attachments_controller.rb:27-65`\n\n```ruby\ndef destroy\n  if authorized_to :delete\n    ...\n  end\nend\n\ndef authorized_to(action)\n  @resource.authorization.authorize_action(\"#{action}_#{params[:attachment_name]}?\", record: @record, raise_exception: false)\nend\n```\n\nThe asymmetry is:\n\n- `destroy`: calls `delete_\u003cattachment_name\u003e?`\n- `create`: does not call `upload_\u003cattachment_key\u003e?` or `update?`\n\nThe field-level upload authorization intent is also documented by Avo:\n\n- Issue #1624 requested the \"Ability to police each file upload/download/delete\".\n  https://github.com/avo-hq/avo/issues/1624\n- PR #1625 introduced `upload_cover_photo?` as an example upload policy method.\n  https://github.com/avo-hq/avo/pull/1625\n- PR #1667 clarified the policy semantics: \"From now on, only field level\n  authorization will be considered. If it is defined and returns true, the\n  action will be granted; otherwise, it will not.\"\n  https://github.com/avo-hq/avo/pull/1667\n- The current Avo authorization documentation lists `upload_{FIELD_ID}?` as the\n  policy method controlling whether a user can upload an attachment, stating:\n  \"Controls whether the user can upload the attachment.\"\n  https://docs.avohq.io/4.0/authorization.html\n- The same documentation says the same `upload_file?` policy method will be used\n  to \"authorize the file upload\" in action file fields.\n  https://docs.avohq.io/4.0/authorization.html\n\nAffected versions observed:\n\n- PoC-confirmed: Avo `3.31.2`, commit\n  `46aa6b3bc9e3283110c39e58cfec8bb95adc1897`\n- Same vulnerable code path by source inspection: `origin/main` HEAD as of\n  2026-05-29,\n  `9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73`\n- Same vulnerable code path by source inspection: Avo `v4.0.0.beta.26`,\n  `6d339595a27f8779cb99b4aa38ddc97cb702b30f`\n- Same vulnerable code path by source inspection: `origin/4-dev` at version\n  `4.0.0.beta.40`,\n  `7ab9794f8b044b11b9677cdc57547d99cf96c3f3`\n\nSuggested affected range for the GitHub Security Advisory form:\n\n```text\n\u003e= 2.28.0\n```\n\nRationale:\n\n- The direct attachment upload endpoint exists without upload authorization from\n  commit `ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858` (`feature: trix\n  attachments`, 2021-04-24), first included in tag `v1.4.0`.\n- The documented field-level upload policy bypass is confirmed from commit\n  `667049ceeda838394214489693d088708d9da77d` (`feature: field level file\n  authorization`, 2023-03-12), first included in tag `v2.28.0`.\n- PR #1667 later clarified the field-level-only grant/deny semantics in commit\n  `31b6ef94f8cc4c340a2a75eec36c838cda933ce7`, first included in tag\n  `v2.30.1`.\n\nFrom a narrow missing-authorization perspective, the issue exists from\n`v1.4.0`; the `\u003e= 2.28.0` range is a conservative submission range anchored to\nthe documented field-level upload policy boundary.\n\nFixed version: to be determined by maintainers.\n\n### PoC\n\nA local request spec was used to reproduce the issue. The PoC adds `pundit` to\nthe test group and replaces\n`Avo::Services::AuthorizationService` with a test double. The test double\nrecords every `authorize_action` invocation and, when invoked, delegates the\ndecision to a `PostPolicy` resolved via `Pundit.policy!`.\n\nThe policy setup is:\n\n- `PostPolicy#update?` returns `false`\n- `PostPolicy#upload_attachments?` returns `false`\n- `PostPolicy#upload_cover_photo?` returns `false`\n- `PostPolicy#method_missing` returns `true` for all other policy methods ending\n  in `?`, simulating a user with general read access but explicit update/upload\n  denial\n- the replacement authorization service records all `authorize_action` calls\n\nThe open-source repository does not include Avo Pro\u0027s authorization client. The\ncritical observation is independent of which client is plugged in: the vulnerable\nendpoint never invokes `authorize_action` at all, so the call list remains empty.\n\nThe PoC user has `roles: {admin: true}`, which is required only to pass the\ndummy app\u0027s coarse route-level guard:\n\n```ruby\nauthenticate :user, -\u003e(user) { user.is_admin? }\n```\n\nThe vulnerability under test is one layer below that guard: the fine-grained\nrecord/field authorization that Avo Pro/Pundit deployments would normally\nenforce. The dummy route gate is not part of Avo\u0027s upload policy decision. In a\ndeployment where non-admin operators reach Avo through a different\nauthentication rule, `AttachmentsController#create` would still skip\n`authorize_action` for the upload.\n\nPolicy scoping is orthogonal to this finding. Even if `apply_policy` filtered\nthe record set during lookup, `AttachmentsController#create` would still not\nauthorize the upload action itself for records that survive the scope.\n\nThe spec demonstrates:\n\n1. Normal record update is denied by policy and does not persist changes.\n2. Direct upload with `attachment_key=cover_photo` succeeds even though\n   `PostPolicy#upload_cover_photo?` returns `false`, replacing the existing\n   `has_one_attached` `cover_photo` blob.\n3. Direct upload with `attachment_key=attachments` succeeds even though\n   `PostPolicy#upload_attachments?` returns `false`, adding to a\n   `has_many_attached` association.\n4. Direct upload with `params[:key]` and no attachment association succeeds,\n   creates an `ActiveStorage::Blob`, and returns `url`/`href` without attaching\n   the blob to the record.\n5. The direct upload requests do not invoke the replacement authorization\n   service at all.\n\nThe full request-spec patch can be provided in this advisory thread if useful.\n\nVerification environment:\n\n- Ruby `3.3.1`\n- Avo `3.31.2`\n- Commit `46aa6b3bc9e3283110c39e58cfec8bb95adc1897`\n\n### Impact\n\nThis is a missing server-side authorization vulnerability in Avo\u0027s direct\nattachment upload endpoint.\n\nThe primary affected deployments are Avo Pro/Advanced-style multi-role\ndeployments where non-administrator or restricted operator users can reach Avo,\nand per-record/per-field operations are expected to be enforced by policies.\n\nIn such deployments, an authenticated Avo user can add or replace attachment\ncontent on a resolved record even when the host application policy denies both:\n\n- record update, for example `update?`\n- field-level upload, for example `upload_cover_photo?` or\n  `upload_attachments?`\n\nFor `has_one_attached` fields, the demonstrated impact is replacement of a\nprotected attachment field with attacker-controlled content. The attacker\ncontrols the uploaded binary content, filename, and content-type metadata for\nthe reachable field.\n\nFor key-based/Trix upload flows, the endpoint can persist a blob and return a\nURL even when no attachment association is resolved. This means the endpoint\nshould not be left as an unauthenticated blob creation and URL return path for\nauthenticated Avo users.\n\nIn admin-only deployments following the Avo Community pattern, practical\nexposure is much lower because the only users who can reach the endpoint are\nalready trusted to perform record updates through the normal CRUD path.\n\nSuggested fix direction:\n\n- validate the requested `attachment_key` before any blob is stored\n- perform upload authorization before `ActiveStorage::Blob.create_and_upload!`\n- derive the policy method from the validated association name rather than raw\n  request input\n- apply an equivalent authorization decision to supported `params[:key]` / Trix\n  upload flows before blob creation or URL return\n- return a JSON-compatible `403 Forbidden` response when upload authorization is\n  denied\n\nThe default `Avo::Services::AuthorizationService#authorize_action` returns\n`true` in `lib/avo/services/authorization_service.rb:34-35`, so applications\nwithout a custom authorization client should not see a behavior change from\nadding an authorization call. Deployments with custom/Pro authorization clients\nthat explicitly deny upload would gain enforcement at this endpoint.\n\nNo official Avo-level workaround was confirmed in this review. Until a fix is\navailable, applications can reduce exposure by ensuring only fully trusted\nadministrators can access Avo routes.\n\nApplications needing an immediate mitigation may override or monkey-patch\n`Avo::AttachmentsController#create` to authorize uploads before blob creation.\nAny mitigation should be tested against the application\u0027s Avo authorization\nclient and upload UI, because the endpoint is used by Trix/file upload flows.\nIf a mitigation falls back to `update?` for key-based/Trix uploads, that is a\nconservative behavior change for applications that currently allow read-only\noperators to use those uploads; those deployments should replace the fallback\nwith an explicit rich-text upload policy.",
  "id": "GHSA-pqpw-cvm4-8mv9",
  "modified": "2026-07-09T20:54:10Z",
  "published": "2026-07-09T20:54:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/avo-hq/avo/security/advisories/GHSA-pqpw-cvm4-8mv9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/avo-hq/avo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/avo-hq/avo/releases/tag/v3.32.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy"
}

GHSA-PQQ3-VH29-3H6Q

Vulnerability from github – Published: 2024-08-19 03:30 – Updated: 2024-10-30 00:31

Details

Pi-hole before 6 allows unauthenticated admin/api.php?setTempUnit= calls to change the temperature units of the web dashboard. NOTE: the supplier reportedly does "not consider the bug a security issue" but the specific motivation for letting arbitrary persons change the value (Celsius, Fahrenheit, or Kelvin), seen by the device owner, is unclear.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-44069"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-19T02:15:04Z",
    "severity": "HIGH"
  },
  "details": "Pi-hole before 6 allows unauthenticated admin/api.php?setTempUnit= calls to change the temperature units of the web dashboard. NOTE: the supplier reportedly does \"not consider the bug a security issue\" but the specific motivation for letting arbitrary persons change the value (Celsius, Fahrenheit, or Kelvin), seen by the device owner, is unclear.",
  "id": "GHSA-pqq3-vh29-3h6q",
  "modified": "2024-10-30T00:31:04Z",
  "published": "2024-08-19T03:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44069"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pi-hole/web/pull/3077"
    },
    {
      "type": "WEB",
      "url": "https://www.kiyell.com/The-Harmless-Pihole-Bug"
    }
  ],
  "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-PQQP-3627-C6R6

Vulnerability from github – Published: 2025-04-16 00:31 – Updated: 2026-04-23 15:37

Details

Missing Authorization vulnerability in NotFound Unlimited Timeline allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Unlimited Timeline: from n/a through n/a.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-27008"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-15T22:15:19Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in NotFound Unlimited Timeline allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Unlimited Timeline: from n/a through n/a.",
  "id": "GHSA-pqqp-3627-c6r6",
  "modified": "2026-04-23T15:37:11Z",
  "published": "2025-04-16T00:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27008"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/unlimited-timeline/vulnerability/wordpress-unlimited-timeline-1-6-1-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:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQRM-V5F6-J44F

Vulnerability from github – Published: 2026-05-29 21:31 – Updated: 2026-05-29 21:31

Details

In JetBrains TeamCity before 2026.1 improper permission checks exposed build configuration parameters

Severity

7.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-49374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-29T19:16:27Z",
    "severity": "HIGH"
  },
  "details": "In JetBrains TeamCity before 2026.1 improper permission checks exposed build configuration parameters",
  "id": "GHSA-pqrm-v5f6-j44f",
  "modified": "2026-05-29T21:31:22Z",
  "published": "2026-05-29T21:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49374"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQVJ-X396-97JJ

Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2024-04-04 00:07

Details

The Leagoo P1 Android device with a build fingerprint of sp7731c_1h10_32v4_bird:6.0/MRA58K/android.20170629.214736:user/release-keys contains the android framework (i.e., system_server) with a package name of android that has been modified by Leagoo or another entity in the supply chain. The system_server process in the core Android package has an exported broadcast receiver that allows any app co-located on the device to programmatically initiate the taking of a screenshot and have the resulting screenshot be written to external storage. The taking of a screenshot is not transparent to the user; the device has a screen animation as the screenshot is taken and there is a notification indicating that a screenshot occurred. If the attacking app also requests the EXPAND_STATUS_BAR permission, it can wake the device up using certain techniques and expand the status bar to take a screenshot of the user's notifications even if the device has an active screen lock. The notifications may contain sensitive data such as text messages used in two-factor authentication. The system_server process that provides this capability cannot be disabled, as it is part of the Android framework. The notification can be removed by a local Denial of Service (DoS) attack to reboot the device.

Severity

5.5 (Medium)


                  
                    CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-14997"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-25T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The Leagoo P1 Android device with a build fingerprint of sp7731c_1h10_32v4_bird:6.0/MRA58K/android.20170629.214736:user/release-keys contains the android framework (i.e., system_server) with a package name of android that has been modified by Leagoo or another entity in the supply chain. The system_server process in the core Android package has an exported broadcast receiver that allows any app co-located on the device to programmatically initiate the taking of a screenshot and have the resulting screenshot be written to external storage. The taking of a screenshot is not transparent to the user; the device has a screen animation as the screenshot is taken and there is a notification indicating that a screenshot occurred. If the attacking app also requests the EXPAND_STATUS_BAR permission, it can wake the device up using certain techniques and expand the status bar to take a screenshot of the user\u0027s notifications even if the device has an active screen lock. The notifications may contain sensitive data such as text messages used in two-factor authentication. The system_server process that provides this capability cannot be disabled, as it is part of the Android framework. The notification can be removed by a local Denial of Service (DoS) attack to reboot the device.",
  "id": "GHSA-pqvj-x396-97jj",
  "modified": "2024-04-04T00:07:40Z",
  "published": "2022-05-24T16:44:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14997"
    },
    {
      "type": "WEB",
      "url": "https://www.kryptowire.com"
    },
    {
      "type": "WEB",
      "url": "https://www.kryptowire.com/portal/android-firmware-defcon-2018"
    },
    {
      "type": "WEB",
      "url": "https://www.kryptowire.com/portal/wp-content/uploads/2018/12/DEFCON-26-Johnson-and-Stavrou-Vulnerable-Out-of-the-Box-An-Eval-of-Android-Carrier-Devices-WP-Updated.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQWM-G232-G69G

Vulnerability from github – Published: 2023-07-12 09:30 – Updated: 2024-04-04 06:02

Details

In DMService, there is a possible missing permission check. This could lead to local escalation of privilege with no additional execution privileges.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-30917"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-12T09:15:10Z",
    "severity": "HIGH"
  },
  "details": "In DMService, there is a possible missing permission check. This could lead to local escalation of privilege with no additional execution privileges.",
  "id": "GHSA-pqwm-g232-g69g",
  "modified": "2024-04-04T06:02:25Z",
  "published": "2023-07-12T09:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30917"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/1676902764208259073"
    }
  ],
  "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-PQX2-8Q56-3F8F

Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-04-01 18:36

Details

Missing Authorization vulnerability in oggix Ongkoskirim.id allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Ongkoskirim.id: from n/a through 1.0.6.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-57949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-22T19:15:53Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in oggix Ongkoskirim.id allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Ongkoskirim.id: from n/a through 1.0.6.",
  "id": "GHSA-pqx2-8q56-3f8f",
  "modified": "2026-04-01T18:36:11Z",
  "published": "2025-09-22T21:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57949"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/ongkoskirim-id/vulnerability/wordpress-ongkoskirim-id-plugin-1-0-6-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PR27-F9RC-Q4VM

Vulnerability from github – Published: 2024-09-26 18:31 – Updated: 2024-09-26 18:31

Details

The Email Subscribers by Icegram Express – Email Marketing, Newsletters, Automation for WordPress & WooCommerce plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'preview_email_template_design' function in all versions up to, and including, 5.7.34. This makes it possible for authenticated attackers, with Subscriber-level access and above, to extract sensitive data including the content of private, password protected, pending, and draft posts and pages.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-8771"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-26T16:15:09Z",
    "severity": "MODERATE"
  },
  "details": "The Email Subscribers by Icegram Express \u2013 Email Marketing, Newsletters, Automation for WordPress \u0026 WooCommerce plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the \u0027preview_email_template_design\u0027 function in all versions up to, and including, 5.7.34. This makes it possible for authenticated attackers, with Subscriber-level access and above, to extract sensitive data including the content of private, password protected, pending, and draft posts and pages.",
  "id": "GHSA-pr27-f9rc-q4vm",
  "modified": "2024-09-26T18:31:44Z",
  "published": "2024-09-26T18:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8771"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/email-subscribers/trunk/lite/admin/class-email-subscribers-admin.php#L1754"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3157336"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f9d90717-fd48-493b-9293-32976bf2cada?source=cve"
    }
  ],
  "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"
    }
  ]
}

GHSA-PR3J-V5PQ-PFV9

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

Details

Missing Authorization vulnerability in 8theme XStore Core.This issue affects XStore Core: from n/a through 5.3.8.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-33555"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-09T12:15:12Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in 8theme XStore Core.This issue affects XStore Core: from n/a through 5.3.8.",
  "id": "GHSA-pr3j-v5pq-pfv9",
  "modified": "2024-06-09T12:30:52Z",
  "published": "2024-06-09T12:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33555"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/et-core-plugin/wordpress-xstore-core-plugin-5-3-5-multiple-authenticated-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:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PR4R-GMW2-WM5R

Vulnerability from github – Published: 2026-05-28 06:31 – Updated: 2026-05-28 06:31

Details

The Frontend Admin by DynamiApps plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.29.2. 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 overwrite an administrator's user_pass, user_email, first_name, last_name, and other profile fields by supplying an arbitrary ?user_id= value, enabling full administrator account takeover via direct password replacement or email-redirect password reset. Exploitation requires the targeted Edit-User form to have its 'Roles' configuration setting left empty; when a non-empty roles list is configured, load_data() sets the user ID to 'none' for users whose roles fall outside the allowed list, preventing administrators from being targeted through that form.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-7802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-28T05:16:38Z",
    "severity": "HIGH"
  },
  "details": "The Frontend Admin by DynamiApps plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 3.29.2. 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 overwrite an administrator\u0027s user_pass, user_email, first_name, last_name, and other profile fields by supplying an arbitrary ?user_id= value, enabling full administrator account takeover via direct password replacement or email-redirect password reset. Exploitation requires the targeted Edit-User form to have its \u0027Roles\u0027 configuration setting left empty; when a non-empty roles list is configured, load_data() sets the user ID to \u0027none\u0027 for users whose roles fall outside the allowed list, preventing administrators from being targeted through that form.",
  "id": "GHSA-pr4r-gmw2-wm5r",
  "modified": "2026-05-28T06:31:09Z",
  "published": "2026-05-28T06:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7802"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.28.36/main/frontend/forms/actions/user.php#L565"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.28.36/main/frontend/forms/actions/user.php#L636"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.28.36/main/frontend/forms/classes/submit.php#L110"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.28.36/main/frontend/forms/classes/submit.php#L392"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.29.1/main/frontend/forms/actions/user.php#L565"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.29.1/main/frontend/forms/actions/user.php#L636"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.29.1/main/frontend/forms/classes/submit.php#L110"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/tags/3.29.1/main/frontend/forms/classes/submit.php#L392"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/trunk/main/frontend/forms/actions/user.php#L565"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/trunk/main/frontend/forms/actions/user.php#L636"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/trunk/main/frontend/forms/classes/submit.php#L110"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/acf-frontend-form-element/trunk/main/frontend/forms/classes/submit.php#L392"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3525193%40acf-frontend-form-element\u0026new=3525193%40acf-frontend-form-element\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/cd091bd5-6b6a-4964-9249-525bbbec702c?source=cve"
    }
  ],
  "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:H",
      "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.

← Back to the CWE list