CWE-284
DiscouragedImproper Access Control
Abstraction: Pillar · Status: Incomplete
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
8562 vulnerabilities reference this CWE, most recent first.
GHSA-8P98-HXH2-CFPV
Vulnerability from github – Published: 2026-05-26 18:31 – Updated: 2026-05-26 21:31An improper access check allows privilege escalation through the com_users batch task.
{
"affected": [],
"aliases": [
"CVE-2026-48898"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-26T17:16:54Z",
"severity": "HIGH"
},
"details": "An improper access check allows privilege escalation through the com_users batch task.",
"id": "GHSA-8p98-hxh2-cfpv",
"modified": "2026-05-26T21:31:57Z",
"published": "2026-05-26T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48898"
},
{
"type": "WEB",
"url": "https://developer.joomla.org/security-centre/1045-20260513-core-privilege-escalation-through-com-users-batch-task.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/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-8P9H-49RC-QGXJ
Vulnerability from github – Published: 2026-07-21 21:02 – Updated: 2026-07-21 21:02Repository Visibility Manipulation via Git Push Options
| Field | Value |
|---|---|
| Affected File | routers/private/hook_post_receive.go |
| Affected Function | HookPostReceive() |
| Affected Lines | 173–225 |
| Prerequisite | Attacker must have owner-level or admin collaborator access to the target repository |
Description
Gitea's post-receive git hook handler processes git push options — key-value pairs transmitted by a client during git push using the -o flag. Two undocumented push options, repo.private and repo.template, allow any user with repository owner or admin-collaborator access to toggle the visibility (private/public) and template status of a repository as a side effect of a normal git push.
This capability was originally intended solely for the "push-to-create" feature (automatically creating a repo on first push). However, the options are processed without restriction on already-existing repositories, and — critically — the visibility change bypasses every control that a proper settings change would trigger:
- No entry written to the repository's audit/activity log
- No webhook event fired (
repositoryevent withvisibility_changedaction) - No org-level notification to owners
- No team permission re-calculation
- No email alert to watchers
- The database update uses
UpdateRepositoryColsNoAutoTime, which also suppresses theupdated_attimestamp change
Vulnerable Code
routers/private/hook_post_receive.go:173–225
isPrivate := opts.GitPushOptions.Bool(private.GitPushOptionRepoPrivate) // "repo.private"
isTemplate := opts.GitPushOptions.Bool(private.GitPushOptionRepoTemplate) // "repo.template"
if isPrivate.Has() || isTemplate.Has() {
// ... loads repo and verifies pusher is owner or admin ...
if !perm.IsOwner() && !perm.IsAdmin() {
ctx.JSON(http.StatusNotFound, ...)
return
}
// FIXME: these options are not quite right, for example: changing visibility
// should do more works than just setting the is_private flag
// These options should only be used for "push-to-create"
if isPrivate.Has() && repo.IsPrivate != isPrivate.Value() {
// TODO: it needs to do more work
repo.IsPrivate = isPrivate.Value()
repo_model.UpdateRepositoryColsNoAutoTime(ctx, repo, "is_private")
// ^^^ bypasses updated_at timestamp, audit trail suppressed
}
if isTemplate.Has() && repo.IsTemplate != isTemplate.Value() {
repo.IsTemplate = isTemplate.Value()
repo_model.UpdateRepositoryColsNoAutoTime(ctx, repo, "is_template")
}
}
The push option constants are defined in modules/private/pushoptions.go:18–19:
GitPushOptionRepoPrivate = "repo.private"
GitPushOptionRepoTemplate = "repo.template"
Attack Scenario
Scenario A — Insider threat / rogue admin collaborator
An organization grants a contractor repo admin access to contribute to a private repository containing proprietary source code. The contractor, before their access is revoked, makes a private repo public for several minutes — long enough to clone, archive, or index the content — then makes it private again. The action leaves no audit trail distinguishable from a normal git push.
Scenario B — Supply-chain template poisoning
A repository marked as a template is used by CI/CD pipelines to generate new project repositories. An admin collaborator uses repo.template=false to silently remove the template designation, then makes changes to the repo's content, re-marks it as a template with repo.template=true, and waits for downstream consumers to regenerate projects from the now-backdoored template. The updated_at timestamp is unchanged due to UpdateRepositoryColsNoAutoTime, making diff-detection harder.
Step-by-Step Reproduction
Prerequisites:
- A Gitea user account with either owner or admin-collaborator access to a private repository
- git client with push access to the repository
Step 1 — Confirm the target repository is private
Step 2 — Clone the repository
git clone http://USER:PASSWORD@<gitea-host>/OWNER/REPO.git /tmp/target-repo
cd /tmp/target-repo
Step 3 — Make any commit (the push option rides on a real push)
echo "$(date)" >> .gitkeep
git add .gitkeep
git commit -m "routine update"
Step 4 — Execute the exploit push
# Make the repository public
git push http://USER:PASSWORD@<gitea-host>/OWNER/REPO.git main \
-o repo.private=false
# The push completes with a normal success message:
# remote: Processed 1 references in total
# To http://<gitea-host>/OWNER/REPO.git
# abc1234..def5678 main -> main
Step 5 — Verify the repository is now public
Step 6 — Restore and cover tracks
Re-make it private in the same session, leaving no visible audit trail
The repository activity feed shows only two normal push events. The visibility change is invisible.
Verification: confirm no activity log entry
Impact Details
| Impact | Description |
|---|---|
| Data exfiltration | Private source code, CI/CD secrets in plain-text files, environment configs become publicly cloneable for the window the repo is public |
| No audit trail | UpdateRepositoryColsNoAutoTime suppresses the updated_at change; no activity log entry; no webhook; no notification |
| Supply chain | Combined with repo.template=true/false, an attacker can silently rotate repository template status, affecting all downstream repositories that generate from this template |
| Scope | Affects all repos where the attacker has admin-collaborator access — not only repos they own |
Recommended Fix
Option 1 (preferred) — Remove the options from post-receive hook entirely. The repo.private and repo.template push options were designed for the push-to-create flow and have no legitimate use on existing repositories. They should be gated with:
// routers/private/hook_post_receive.go
if isPrivate.Has() || isTemplate.Has() {
if !wasEmpty {
// repo already existed — refuse these options on established repos
log.Warn("Repo push options repo.private/repo.template ignored for existing repo %s", repoName)
// do not process
} else {
// original push-to-create path only
...
}
}
Option 2 — Route through the full visibility-change service so that audit events, webhooks, and team re-syncs are triggered:
// Instead of the raw UpdateRepositoryColsNoAutoTime call:
if err := repo_service.UpdateRepositoryVisibility(ctx, repo, isPrivate.Value()); err != nil {
...
}
Where UpdateRepositoryVisibility fires the repository webhook event and writes an activity log entry.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.gitea.io/gitea"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.27.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58437"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T21:02:44Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Repository Visibility Manipulation via Git Push Options\n\n| Field | Value |\n|-------|-------|\n| **Affected File** | `routers/private/hook_post_receive.go` |\n| **Affected Function** | `HookPostReceive()` |\n| **Affected Lines** | 173\u2013225 |\n| **Prerequisite** | Attacker must have owner-level or admin collaborator access to the target repository |\n\n---\n\n#### Description\n\nGitea\u0027s post-receive git hook handler processes git push options \u2014 key-value pairs transmitted by a client during `git push` using the `-o` flag. Two undocumented push options, `repo.private` and `repo.template`, allow any user with repository owner or admin-collaborator access to toggle the visibility (`private/public`) and template status of a repository as a side effect of a normal git push.\n\nThis capability was originally intended solely for the \"push-to-create\" feature (automatically creating a repo on first push). However, the options are processed without restriction on already-existing repositories, and \u2014 critically \u2014 the visibility change bypasses every control that a proper settings change would trigger:\n\n- No entry written to the repository\u0027s audit/activity log\n- No webhook event fired (`repository` event with `visibility_changed` action)\n- No org-level notification to owners\n- No team permission re-calculation\n- No email alert to watchers\n- The database update uses `UpdateRepositoryColsNoAutoTime`, which also suppresses the `updated_at` timestamp change\n\n\n---\n\n#### Vulnerable Code\n\n**`routers/private/hook_post_receive.go:173\u2013225`**\n\n```go\nisPrivate := opts.GitPushOptions.Bool(private.GitPushOptionRepoPrivate) // \"repo.private\"\nisTemplate := opts.GitPushOptions.Bool(private.GitPushOptionRepoTemplate) // \"repo.template\"\n\nif isPrivate.Has() || isTemplate.Has() {\n // ... loads repo and verifies pusher is owner or admin ...\n if !perm.IsOwner() \u0026\u0026 !perm.IsAdmin() {\n ctx.JSON(http.StatusNotFound, ...)\n return\n }\n\n // FIXME: these options are not quite right, for example: changing visibility\n // should do more works than just setting the is_private flag\n // These options should only be used for \"push-to-create\"\n if isPrivate.Has() \u0026\u0026 repo.IsPrivate != isPrivate.Value() {\n // TODO: it needs to do more work\n repo.IsPrivate = isPrivate.Value()\n repo_model.UpdateRepositoryColsNoAutoTime(ctx, repo, \"is_private\")\n // ^^^ bypasses updated_at timestamp, audit trail suppressed\n }\n if isTemplate.Has() \u0026\u0026 repo.IsTemplate != isTemplate.Value() {\n repo.IsTemplate = isTemplate.Value()\n repo_model.UpdateRepositoryColsNoAutoTime(ctx, repo, \"is_template\")\n }\n}\n```\n\nThe push option constants are defined in `modules/private/pushoptions.go:18\u201319`:\n\n```go\nGitPushOptionRepoPrivate = \"repo.private\"\nGitPushOptionRepoTemplate = \"repo.template\"\n```\n\n---\n\n#### Attack Scenario\n\n**Scenario A \u2014 Insider threat / rogue admin collaborator**\n\nAn organization grants a contractor repo admin access to contribute to a private repository containing proprietary source code. The contractor, before their access is revoked, makes a private repo public for several minutes \u2014 long enough to clone, archive, or index the content \u2014 then makes it private again. The action leaves no audit trail distinguishable from a normal git push.\n\n**Scenario B \u2014 Supply-chain template poisoning**\n\nA repository marked as a template is used by CI/CD pipelines to generate new project repositories. An admin collaborator uses `repo.template=false` to silently remove the template designation, then makes changes to the repo\u0027s content, re-marks it as a template with `repo.template=true`, and waits for downstream consumers to regenerate projects from the now-backdoored template. The `updated_at` timestamp is unchanged due to `UpdateRepositoryColsNoAutoTime`, making diff-detection harder.\n\n---\n\n#### Step-by-Step Reproduction\n\n**Prerequisites:**\n- A Gitea user account with either owner or admin-collaborator access to a private repository\n- `git` client with push access to the repository\n\n---\n\n**Step 1 \u2014 Confirm the target repository is private**\n\n---\n\n**Step 2 \u2014 Clone the repository**\n\n```bash\ngit clone http://USER:PASSWORD@\u003cgitea-host\u003e/OWNER/REPO.git /tmp/target-repo\ncd /tmp/target-repo\n```\n\n---\n\n**Step 3 \u2014 Make any commit** *(the push option rides on a real push)*\n\n```bash\necho \"$(date)\" \u003e\u003e .gitkeep\ngit add .gitkeep\ngit commit -m \"routine update\"\n```\n\n---\n\n**Step 4 \u2014 Execute the exploit push**\n\n```bash\n# Make the repository public\ngit push http://USER:PASSWORD@\u003cgitea-host\u003e/OWNER/REPO.git main \\\n -o repo.private=false\n\n# The push completes with a normal success message:\n# remote: Processed 1 references in total\n# To http://\u003cgitea-host\u003e/OWNER/REPO.git\n# abc1234..def5678 main -\u003e main\n```\n\n---\n\n**Step 5 \u2014 Verify the repository is now public**\n\n\n---\n\n**Step 6 \u2014 Restore and cover tracks**\n\nRe-make it private in the same session, leaving no visible audit trail\n\nThe repository activity feed shows only two normal push events. The visibility change is invisible.\n\n**Verification: confirm no activity log entry**\n\n\n---\n\n#### Impact Details\n\n| Impact | Description |\n|--------|-------------|\n| **Data exfiltration** | Private source code, CI/CD secrets in plain-text files, environment configs become publicly cloneable for the window the repo is public |\n| **No audit trail** | `UpdateRepositoryColsNoAutoTime` suppresses the `updated_at` change; no activity log entry; no webhook; no notification |\n| **Supply chain** | Combined with `repo.template=true/false`, an attacker can silently rotate repository template status, affecting all downstream repositories that generate from this template |\n| **Scope** | Affects all repos where the attacker has admin-collaborator access \u2014 not only repos they own |\n\n---\n\n#### Recommended Fix\n\n**Option 1 (preferred) \u2014 Remove the options from post-receive hook entirely.** The `repo.private` and `repo.template` push options were designed for the push-to-create flow and have no legitimate use on existing repositories. They should be gated with:\n\n```go\n// routers/private/hook_post_receive.go\nif isPrivate.Has() || isTemplate.Has() {\n if !wasEmpty {\n // repo already existed \u2014 refuse these options on established repos\n log.Warn(\"Repo push options repo.private/repo.template ignored for existing repo %s\", repoName)\n // do not process\n } else {\n // original push-to-create path only\n ...\n }\n}\n```\n\n**Option 2 \u2014 Route through the full visibility-change service** so that audit events, webhooks, and team re-syncs are triggered:\n\n```go\n// Instead of the raw UpdateRepositoryColsNoAutoTime call:\nif err := repo_service.UpdateRepositoryVisibility(ctx, repo, isPrivate.Value()); err != nil {\n ...\n}\n```\n\nWhere `UpdateRepositoryVisibility` fires the `repository` webhook event and writes an activity log entry.",
"id": "GHSA-8p9h-49rc-qgxj",
"modified": "2026-07-21T21:02:44Z",
"published": "2026-07-21T21:02:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-8p9h-49rc-qgxj"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-gitea/gitea"
},
{
"type": "WEB",
"url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gitea: Repository Visibility Manipulation via Git Push Options"
}
GHSA-8P9J-879P-799J
Vulnerability from github – Published: 2025-05-19 15:30 – Updated: 2025-05-19 18:30EnGenius ENH500 AP 2T2R V3.0 FW3.7.22 is vulnerable to Incorrect Access Control via the password change function. The device fails to validate the current password, allowing an attacker to submit a password change request with an invalid current password and set a new password.
{
"affected": [],
"aliases": [
"CVE-2025-28371"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-19T14:15:23Z",
"severity": "MODERATE"
},
"details": "EnGenius ENH500 AP 2T2R V3.0 FW3.7.22 is vulnerable to Incorrect Access Control via the password change function. The device fails to validate the current password, allowing an attacker to submit a password change request with an invalid current password and set a new password.",
"id": "GHSA-8p9j-879p-799j",
"modified": "2025-05-19T18:30:45Z",
"published": "2025-05-19T15:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28371"
},
{
"type": "WEB",
"url": "https://drive.google.com/file/d/1kQFOyFQYycKynIBjbU8bMx2gYTG3Bxi2/view?usp=sharing"
},
{
"type": "WEB",
"url": "https://pastebin.com/raw/EnL1XT2n"
},
{
"type": "WEB",
"url": "https://pastebin.com/raw/hziq1nGH"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-8PC4-5WHG-XJ4V
Vulnerability from github – Published: 2022-10-24 19:00 – Updated: 2022-10-24 19:00A broken access control vulnerability in the First_network_func function of spx_restservice allows an attacker to arbitrarily change the network configuration of the BMC. This issue affects: Lanner Inc IAC-AST2500A standard firmware version 1.10.0.
{
"affected": [],
"aliases": [
"CVE-2021-26732"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-24T14:15:00Z",
"severity": "MODERATE"
},
"details": "A broken access control vulnerability in the First_network_func function of spx_restservice allows an attacker to arbitrarily change the network configuration of the BMC. This issue affects: Lanner Inc IAC-AST2500A standard firmware version 1.10.0.",
"id": "GHSA-8pc4-5whg-xj4v",
"modified": "2022-10-24T19:00:17Z",
"published": "2022-10-24T19:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26732"
},
{
"type": "WEB",
"url": "https://github.com/CVEProject/cvelist/blob/master/2021/26xxx/CVE-2021-26732.json"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/blog/vulnerabilities-in-bmc-firmware-affect-ot-iot-device-security-part-1"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories/CVE-2021-26732"
}
],
"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-8PFQ-J8FP-2Q5M
Vulnerability from github – Published: 2024-10-08 18:33 – Updated: 2024-10-08 21:31Insecure permissions in the Bluetooth Low Energy (BLE) component of Fire-Boltt Artillery Smart Watch NJ-R6E-10.3 allow attackers to cause a Denial of Service (DoS).
{
"affected": [],
"aliases": [
"CVE-2024-46539"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-08T18:15:30Z",
"severity": "HIGH"
},
"details": "Insecure permissions in the Bluetooth Low Energy (BLE) component of Fire-Boltt Artillery Smart Watch NJ-R6E-10.3 allow attackers to cause a Denial of Service (DoS).",
"id": "GHSA-8pfq-j8fp-2q5m",
"modified": "2024-10-08T21:31:09Z",
"published": "2024-10-08T18:33:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32368"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46539"
},
{
"type": "WEB",
"url": "https://github.com/harishmanam/-Fireboltt-Artillery-Smartwatch/blob/main/FB_Artillerysmart_watch_Security_Assessment_report.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-8PFW-FJHM-QGCF
Vulnerability from github – Published: 2025-11-13 21:31 – Updated: 2025-12-17 21:30Keyfactor SignServer before 7.3.1 has Incorrect Access Control, issue 1 of 3.
{
"affected": [],
"aliases": [
"CVE-2025-47220"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-13T21:15:49Z",
"severity": "MODERATE"
},
"details": "Keyfactor SignServer before 7.3.1 has Incorrect Access Control, issue 1 of 3.",
"id": "GHSA-8pfw-fjhm-qgcf",
"modified": "2025-12-17T21:30:40Z",
"published": "2025-11-13T21:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47220"
},
{
"type": "WEB",
"url": "https://docs.keyfactor.com/signserver/latest/signserver-7-3-release-notes"
},
{
"type": "WEB",
"url": "https://support.keyfactor.com"
},
{
"type": "WEB",
"url": "https://support.keyfactor.com/hc/en-us/articles/37638761131035-SignServer-CVE-2025-47220-Local-file-enumeration"
}
],
"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"
}
]
}
GHSA-8PHC-JHVP-25CW
Vulnerability from github – Published: 2023-01-10 06:30 – Updated: 2023-01-13 18:30An unauthenticated attacker in SAP NetWeaver AS for Java - version 7.50, due to improper access control, can attach to an open interface and make use of an open naming and directory API to access services which can be used to perform unauthorized operations affecting users and data on the current system. This could allow the attacker to have full read access to user data, make modifications to user data, and make services within the system unavailable.
{
"affected": [],
"aliases": [
"CVE-2023-0017"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-10T04:15:00Z",
"severity": "CRITICAL"
},
"details": "An unauthenticated attacker in SAP NetWeaver AS for Java - version 7.50, due to improper access control, can attach to an open interface and make use of an open naming and directory API to access services which can be used to perform unauthorized operations affecting users and data on the current system. This could allow the attacker to have full read access to user data, make modifications to user data, and make services within the system unavailable.",
"id": "GHSA-8phc-jhvp-25cw",
"modified": "2023-01-13T18:30:18Z",
"published": "2023-01-10T06:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0017"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3268093"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"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-8PMQ-59WH-8QF5
Vulnerability from github – Published: 2025-06-01 21:30 – Updated: 2025-06-01 21:30A vulnerability, which was classified as critical, was found in chaitak-gorai Blogbook up to 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Affected is an unknown function of the file /admin/posts.php?source=add_post. The manipulation of the argument image leads to unrestricted upload. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-5406"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-01T19:15:20Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as critical, was found in chaitak-gorai Blogbook up to 92f5cf90f8a7e6566b576fe0952e14e1c6736513. Affected is an unknown function of the file /admin/posts.php?source=add_post. The manipulation of the argument image leads to unrestricted upload. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. Continious delivery with rolling releases is used by this product. Therefore, no version details of affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-8pmq-59wh-8qf5",
"modified": "2025-06-01T21:30:28Z",
"published": "2025-06-01T21:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5406"
},
{
"type": "WEB",
"url": "https://github.com/rllvusgnzm98/Report/blob/main/blogbook/BlogBook%20posts.php%20add_post%20post_image%20Parameter%20Unrestricted%20Upload.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.310746"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.310746"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.583427"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/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-8PPW-2J69-MVRJ
Vulnerability from github – Published: 2026-06-09 03:31 – Updated: 2026-06-09 03:31A weakness has been identified in Dcat-Admin up to 2.2.3-beta. This impacts the function editorMDUpload of the file /admin/dcat-api/editor-md/upload of the component User Setting Page. This manipulation of the argument editormd-image-file causes unrestricted upload. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks.
{
"affected": [],
"aliases": [
"CVE-2026-11621"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T03:16:26Z",
"severity": "LOW"
},
"details": "A weakness has been identified in Dcat-Admin up to 2.2.3-beta. This impacts the function editorMDUpload of the file /admin/dcat-api/editor-md/upload of the component User Setting Page. This manipulation of the argument editormd-image-file causes unrestricted upload. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks.",
"id": "GHSA-8ppw-2j69-mvrj",
"modified": "2026-06-09T03:31:40Z",
"published": "2026-06-09T03:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11621"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-11621"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/834849"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/369302"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/369302/cti"
},
{
"type": "WEB",
"url": "https://www.yuque.com/u25169484/wroc9b/co6eg4x23xkfesng"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-8PQC-R2RX-5HHC
Vulnerability from github – Published: 2024-06-10 21:30 – Updated: 2026-04-02 21:31This issue was addressed by adding an additional prompt for user consent. This issue is fixed in macOS Sonoma 14.4. An app may be able to access user-sensitive data.
{
"affected": [],
"aliases": [
"CVE-2024-27792"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-10T20:15:13Z",
"severity": "MODERATE"
},
"details": "This issue was addressed by adding an additional prompt for user consent. This issue is fixed in macOS Sonoma 14.4. An app may be able to access user-sensitive data.",
"id": "GHSA-8pqc-r2rx-5hhc",
"modified": "2026-04-02T21:31:43Z",
"published": "2024-06-10T21:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27792"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/120895"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT214084"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT214084"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-19: Embedding Scripts within Scripts
An adversary leverages the capability to execute their own script by embedding it within other scripts that the target software is likely to execute due to programs' vulnerabilities that are brought on by allowing remote hosts to execute scripts.
CAPEC-441: Malicious Logic Insertion
An adversary installs or adds malicious logic (also known as malware) into a seemingly benign component of a fielded system. This logic is often hidden from the user of the system and works behind the scenes to achieve negative impacts. With the proliferation of mass digital storage and inexpensive multimedia devices, Bluetooth and 802.11 support, new attack vectors for spreading malware are emerging for things we once thought of as innocuous greeting cards, picture frames, or digital projectors. This pattern of attack focuses on systems already fielded and used in operation as opposed to systems and their components that are still under development and part of the supply chain.
CAPEC-478: Modification of Windows Service Configuration
An adversary exploits a weakness in access control to modify the execution parameters of a Windows service. The goal of this attack is to execute a malicious binary in place of an existing service.
CAPEC-479: Malicious Root Certificate
An adversary exploits a weakness in authorization and installs a new root certificate on a compromised system. Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.
CAPEC-502: Intent Spoof
An adversary, through a previously installed malicious application, issues an intent directed toward a specific trusted application's component in an attempt to achieve a variety of different objectives including modification of data, information disclosure, and data injection. Components that have been unintentionally exported and made public are subject to this type of an attack. If the component trusts the intent's action without verififcation, then the target application performs the functionality at the adversary's request, helping the adversary achieve the desired negative technical impact.
CAPEC-503: WebView Exposure
An adversary, through a malicious web page, accesses application specific functionality by leveraging interfaces registered through WebView's addJavascriptInterface API. Once an interface is registered to WebView through addJavascriptInterface, it becomes global and all pages loaded in the WebView can call this interface.
CAPEC-536: Data Injected During Configuration
An attacker with access to data files and processes on a victim's system injects malicious data into critical operational data during configuration or recalibration, causing the victim's system to perform in a suboptimal manner that benefits the adversary.
CAPEC-546: Incomplete Data Deletion in a Multi-Tenant Environment
An adversary obtains unauthorized information due to insecure or incomplete data deletion in a multi-tenant environment. If a cloud provider fails to completely delete storage and data from former cloud tenants' systems/resources, once these resources are allocated to new, potentially malicious tenants, the latter can probe the provided resources for sensitive information still there.
CAPEC-550: Install New Service
When an operating system starts, it also starts programs called services or daemons. Adversaries may install a new service which will be executed at startup (on a Windows system, by modifying the registry). The service name may be disguised by using a name from a related operating system or benign software. Services are usually run with elevated privileges.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-552: Install Rootkit
An adversary exploits a weakness in authentication to install malware that alters the functionality and information provide by targeted operating system API calls. Often referred to as rootkits, it is often used to hide the presence of programs, files, network connections, services, drivers, and other system components.
CAPEC-556: Replace File Extension Handlers
When a file is opened, its file handler is checked to determine which program opens the file. File handlers are configuration properties of many operating systems. Applications can modify the file handler for a given file extension to call an arbitrary program when a file with the given extension is opened.
CAPEC-558: Replace Trusted Executable
An adversary exploits weaknesses in privilege management or access control to replace a trusted executable with a malicious version and enable the execution of malware when that trusted executable is called.
CAPEC-562: Modify Shared File
An adversary manipulates the files in a shared location by adding malicious programs, scripts, or exploit code to valid content. Once a user opens the shared content, the tainted content is executed.
CAPEC-563: Add Malicious File to Shared Webroot
An adversaries may add malicious content to a website through the open file share and then browse to that content with a web browser to cause the server to execute the content. The malicious content will typically run under the context and permissions of the web server process, often resulting in local system or administrative privileges depending on how the web server is configured.
CAPEC-564: Run Software at Logon
Operating system allows logon scripts to be run whenever a specific user or users logon to a system. If adversaries can access these scripts, they may insert additional code into the logon script. This code can allow them to maintain persistence or move laterally within an enclave because it is executed every time the affected user or users logon to a computer. Modifying logon scripts can effectively bypass workstation and enclave firewalls. Depending on the access configuration of the logon scripts, either local credentials or a remote administrative account may be necessary.
CAPEC-578: Disable Security Software
An adversary exploits a weakness in access control to disable security tools so that detection does not occur. This can take the form of killing processes, deleting registry keys so that tools do not start at run time, deleting log files, or other methods.