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.
5504 vulnerabilities reference this CWE, most recent first.
GHSA-J732-2X82-535H
Vulnerability from github – Published: 2024-06-11 06:31 – Updated: 2024-08-23 03:30Incorrect authorization vulnerability in Cybozu Garoon 5.0.0 to 5.15.2 allows a remote authenticated attacker to delete the data of Shared To-Dos.
{
"affected": [],
"aliases": [
"CVE-2024-31402"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-11T06:15:10Z",
"severity": "MODERATE"
},
"details": "Incorrect authorization vulnerability in Cybozu Garoon 5.0.0 to 5.15.2 allows a remote authenticated attacker to delete the data of Shared To-Dos.",
"id": "GHSA-j732-2x82-535h",
"modified": "2024-08-23T03:30:58Z",
"published": "2024-06-11T06:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31402"
},
{
"type": "WEB",
"url": "https://cs.cybozu.co.jp/2024/007901.html"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN28869536"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J748-H363-WQJ8
Vulnerability from github – Published: 2026-06-26 22:32 – Updated: 2026-06-26 22:32Impact
CVSSv4 Baseline Score: Low 2.4
CVSSv4 Weighted Score: Low 1.3
The full CVSSv4 Vector for this vulnerability is:
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber
CVSSv3.1 Baseline Score: Low 3.1
CVSSv3.1 Overall Score: Low 3.4
The full CVSSv3.1 Vector equivalent for this vulnerability is:
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N
The weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it's unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.
In addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.
Summary
Due to lack of canonicalization of domains in very specific edge cases an access control rule may be skipped when it should match a request.
Details
This attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.
The specific conditions that could lead to a security issue for vulnerability are as follows:
- The specific target resource of the attack must be using the forwarded authorization integration.
- The requested domain must have two additional segments compared to a session domain i.e.
a.b.example.comis requested, but the session domain isexample.com. - There access control rules must specify two separate rules which both contain inexact domain matches such as
*.b.example.comand*.example.comi.e. wildcards, username matches, group matches. - The rules must be in order of most specific domain to least specific domain.
- The second rule must be more permissive than the first rule.
- The second rule must also match all criteria of the given request.
- The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e.
https://a.B.example.comand no other segment with capitalized letters. - The integration used must not be the Envoy ExtAuthz integration.
- The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint.
The kind of configuration used to produce this issue and result in a bypass rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers.
It should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.
Patches
Upgrade to 4.39.20.
Commit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a
Workarounds
See the below examples for configurations to avoid.
Examples
1FA Downgrade
The following example could result in a 1FA downgrade.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
Bypass Downgrade
The following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern *.example.com should not be configured to forward authorization requests to Authelia in most situations.
Request URL: https://a.B.example.com
Configuration:
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: '*.b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'bypass'
Unaffected Scenario
The following configuration is unaffected regardless of the request.
session:
cookies:
- domain: 'example.com'
authelia_url: 'https://example.com'
access_control:
rules:
- domain: 'b.example.com'
policy: 'two_factor'
- domain: '*.example.com'
policy: 'one_factor'
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.39.19"
},
"package": {
"ecosystem": "Go",
"name": "github.com/authelia/authelia/v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.36.0"
},
{
"fixed": "4.39.20"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48794"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-26T22:32:21Z",
"nvd_published_at": "2026-06-19T21:17:01Z",
"severity": "LOW"
},
"details": "### Impact\n\n**CVSSv4 Baseline Score:** Low 2.4\n\n**CVSSv4 Weighted Score:** Low 1.3\n\nThe full CVSSv4 Vector for this vulnerability is:\n\n\u003e CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:H/IR:L/AR:L/MAV:N/MAC:H/MAT:P/MPR:L/MVC:L/MVI:N/MVA:N/MSC:L/MSI:N/MSA:N/S:N/AU:Y/R:U/V:D/RE:L/U:Amber\n\n**CVSSv3.1 Baseline Score:** Low 3.1\n\n**CVSSv3.1 Overall Score:** Low 3.4\n\nThe full CVSSv3.1 Vector equivalent for this vulnerability is:\n\n\u003e CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N/E:P/RL:O/RC:C/CR:H/IR:L/AR:L/MAV:N/MAC:H/MPR:L/MUI:X/MS:U/MC:L/MI:N/MA:N\n\nThe weighted severity rating is a result of no indication this is currently being exploited being available at the time of the publish date, in addition to the fact it\u0027s unlikely that it is being exploited currently. The vectors have been picked based on the scenario most likely to exist in real configurations.\n\nIn addition to the weighting our assessment considers the fact the configuration scenario required for this vulnerability to be exploited is highly unlikely and an attacker is unlikely in most scenarios to be able to determine if the exploit is available and if it was successful except in rare situations. Though the visibility to the attacker was not reflected in our assessment.\n\n### Summary\n\nDue to lack of canonicalization of domains in very specific edge cases an access control rule may be skipped when it should match a request.\n\n### Details\n\nThis attack vector must be executed in a highly specific scenario which we do not believe any user would find themselves in. In an abundance of caution we are issuing this advisory and would appreciate any users who find this configuration report it to us with both the access control section, and sessions section so that we can best advise the community of the actual impact.\n\nThe specific conditions that could lead to a security issue for vulnerability are as follows:\n\n1. The specific target resource of the attack must be using the forwarded authorization integration.\n2. The requested domain must have two additional segments compared to a session domain i.e. `a.b.example.com` is requested, but the session domain is `example.com`.\n3. There access control rules must specify two separate rules which both contain inexact domain matches such as `*.b.example.com` and `*.example.com` i.e. wildcards, username matches, group matches.\n4. The rules must be in order of most specific domain to least specific domain.\n5. The second rule must be **more permissive** than the first rule.\n6. The second rule must also **match all criteria** of the given request.\n7. The attacker must specifically request a URL for the more specific domain, with the second part containing one or more capitalized letters i.e. `https://a.B.example.com` and no other segment with capitalized letters.\n8. The integration used must not be the Envoy ExtAuthz integration.\n9. The proxy must not canonicalize the requested host name in the relevant header before sending it to the relevant authorization endpoint.\n\nThe kind of configuration used to produce this issue and result in a `bypass` rule being matched has long been highly discouraged. Essentially hosts which should be bypassed entirely should not be secured by having the proxy check them with the authorization handlers.\n\nIt should also be noted this has been heavily mitigated due to another bug where the session domain would not match if any part of the configured session domain was capitalized (fixed in https://github.com/authelia/authelia/commit/368631ecc5a9c6bcf2ff5f892ad443b890dd945e, it should be expressly noted this commit does not contain a fix for a CVE). This bug would prevent the request from succeeding in any way. This bug will also be fixed after this vulnerability is fixed, and the bug where session domains would not match has no security impact other than heavily mitigating the access control vulnerability.\n\n### Patches\n\nUpgrade to 4.39.20.\n\nCommit: https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a\n\n### Workarounds\n\nSee the below examples for configurations to avoid.\n\n#### Examples\n\n##### 1FA Downgrade\n\nThe following example could result in a 1FA downgrade.\n\n**Request URL:** `https://a.B.example.com`\n\n**Configuration:**\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027*.b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027one_factor\u0027\n```\n\n##### Bypass Downgrade\n\nThe following example could result in a bypass downgrade. It should be noted that configurations like this have long been discouraged. The domains matching the pattern `*.example.com` should not be configured to forward authorization requests to Authelia in most situations.\n\n**Request URL:** `https://a.B.example.com`\n\n**Configuration:**\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027*.b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027bypass\u0027\n```\n\n##### Unaffected Scenario\n\nThe following configuration is unaffected regardless of the request.\n\n```yaml\nsession:\n cookies:\n - domain: \u0027example.com\u0027\n authelia_url: \u0027https://example.com\u0027\naccess_control:\n rules:\n - domain: \u0027b.example.com\u0027\n policy: \u0027two_factor\u0027\n - domain: \u0027*.example.com\u0027\n policy: \u0027one_factor\u0027\n```",
"id": "GHSA-j748-h363-wqj8",
"modified": "2026-06-26T22:32:21Z",
"published": "2026-06-26T22:32:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/security/advisories/GHSA-j748-h363-wqj8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48794"
},
{
"type": "WEB",
"url": "https://github.com/authelia/authelia/commit/b6d1d60baa02f216fdb19f5dfeaf2e805829508a"
},
{
"type": "PACKAGE",
"url": "https://github.com/authelia/authelia"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Authelia has an Edge Case Access Control Rule Mismatch"
}
GHSA-J74X-6RH4-F7Q2
Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2022-07-15 00:00An improper authorization vulnerability in the Palo Alto Networks Cortex XSOAR server enables an authenticated network-based attacker with investigation read permissions to download files from incident investigations of which they are aware but are not a part of. This issue impacts: All Cortex XSOAR 5.5.0 builds; Cortex XSOAR 6.1.0 builds earlier than 12099345. This issue does not impact Cortex XSOAR 6.2.0 versions.
{
"affected": [],
"aliases": [
"CVE-2021-3049"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-08T17:15:00Z",
"severity": "LOW"
},
"details": "An improper authorization vulnerability in the Palo Alto Networks Cortex XSOAR server enables an authenticated network-based attacker with investigation read permissions to download files from incident investigations of which they are aware but are not a part of. This issue impacts: All Cortex XSOAR 5.5.0 builds; Cortex XSOAR 6.1.0 builds earlier than 12099345. This issue does not impact Cortex XSOAR 6.2.0 versions.",
"id": "GHSA-j74x-6rh4-f7q2",
"modified": "2022-07-15T00:00:17Z",
"published": "2022-05-24T19:13:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3049"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2021-3049"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J756-F273-XHP4
Vulnerability from github – Published: 2021-05-21 16:22 – Updated: 2024-05-21 15:22(This advisory is canonically https://advisories.nats.io/CVE/CVE-2021-3127.txt)
Problem Description
The NATS server provides for Subjects which are namespaced by Account; all Subjects are supposed to be private to an account, with an Export/Import system used to grant cross-account access to some Subjects. Some Exports are public, such that anyone can import the relevant subjects, and some Exports are private, such that the Import requires a token JWT to prove permission.
The JWT library's validation of the bindings in the Import Token incorrectly warned on mismatches, instead of outright rejecting the token.
As a result, any account can take an Import token used by any other account and re-use it for themselves because the binding to the importing account is not rejected, and use it to import any Subject from the Exporting account, not just the Subject referenced in the Import Token.
The NATS account-server system treats account JWTs as semi-public information, such that an attacker can easily enumerate all account JWTs and retrieve all Import Tokens from those account JWTs.
The CVE identifier should cover the JWT library repair and the nats-server containing the fixed JWT library, and any other application depending upon the fixed JWT library.
Affected versions
JWT library
- all versions prior to 2.0.1
- fixed after nats-io/jwt#149 landed (2021-03-14)
NATS Server
- Version 2 prior to 2.2.0
- 2.0.0 through and including 2.1.9 are vulnerable
- fixed with nats-io/nats-server@423b79440c (2021-03-14)
Impact
In deployments with untrusted accounts able to update the Account Server with imports, a malicious account can access any Subject from an account which provides Exported Subjects.
Abuse of this facility requires the malicious actor to upload their tampered Account JWT to the Account Server, providing the service operator with a data-store which can be scanned for signs of abuse.
Workaround
Deny access to clients to update their account JWT in the account server.
Solution
Upgrade the JWT dependency in any application using it.
Upgrade the NATS server if using NATS Accounts (with private Exports; Account owners can create those at any time though).
Audit all accounts JWTs to scan for exploit attempts; a Python script to audit the accounts can be found at https://gist.github.com/philpennock/09d49524ad98043ff11d8a40c2bb0d5a.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nats-io/nats-server/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-755",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2021-05-20T21:01:49Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "(This advisory is canonically \u003chttps://advisories.nats.io/CVE/CVE-2021-3127.txt\u003e)\n\n## Problem Description\n\nThe NATS server provides for Subjects which are namespaced by Account; all Subjects are supposed to be private to an account, with an Export/Import system used to grant cross-account access to some Subjects. Some Exports are public, such that anyone can import the relevant subjects, and some Exports are private, such that the Import requires a token JWT to prove permission.\n\nThe JWT library\u0027s validation of the bindings in the Import Token incorrectly warned on mismatches, instead of outright rejecting the token.\n\nAs a result, any account can take an Import token used by any other account and re-use it for themselves because the binding to the importing account is not rejected, and use it to import *any* Subject from the Exporting account, not just the Subject referenced in the Import Token.\n\nThe NATS account-server system treats account JWTs as semi-public information, such that an attacker can easily enumerate all account JWTs and retrieve all Import Tokens from those account JWTs.\n\nThe CVE identifier should cover the JWT library repair and the nats-server containing the fixed JWT library, and any other application depending upon the fixed JWT library.\n\n\n## Affected versions\n\n#### JWT library\n\n * all versions prior to 2.0.1\n * fixed after nats-io/jwt#149 landed (2021-03-14)\n\n#### NATS Server\n\n * Version 2 prior to 2.2.0\n + 2.0.0 through and including 2.1.9 are vulnerable\n * fixed with nats-io/nats-server@423b79440c (2021-03-14)\n\n\n## Impact\n\nIn deployments with untrusted accounts able to update the Account Server with imports, a malicious account can access any Subject from an account which provides Exported Subjects.\n\nAbuse of this facility requires the malicious actor to upload their tampered Account JWT to the Account Server, providing the service operator with a data-store which can be scanned for signs of abuse.\n\n\n## Workaround\n\nDeny access to clients to update their account JWT in the account server.\n\n\n## Solution\n\nUpgrade the JWT dependency in any application using it.\n\nUpgrade the NATS server if using NATS Accounts (with private Exports; Account owners can create those at any time though).\n\nAudit all accounts JWTs to scan for exploit attempts; a Python script to audit the accounts can be found at \u003chttps://gist.github.com/philpennock/09d49524ad98043ff11d8a40c2bb0d5a\u003e.",
"id": "GHSA-j756-f273-xhp4",
"modified": "2024-05-21T15:22:51Z",
"published": "2021-05-21T16:22:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nats-io/jwt/security/advisories/GHSA-62mh-w5cv-p88c"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/nats-server/security/advisories/GHSA-j756-f273-xhp4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3127"
},
{
"type": "WEB",
"url": "https://github.com/nats-io/nats-server/commit/423b79440c80c863de9f4e20548504e6c5d5e403"
},
{
"type": "WEB",
"url": "https://advisories.nats.io/CVE/CVE-2021-3127.txt"
},
{
"type": "PACKAGE",
"url": "https://github.com/nats-io/nats-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "github.com/nats-io/nats-server Import token permissions checking not enforced"
}
GHSA-J79M-7C8R-83MC
Vulnerability from github – Published: 2022-02-17 00:00 – Updated: 2022-02-26 00:01VMware ESXi contains an unauthorized access vulnerability due to VMX having access to settingsd authorization tickets. A malicious actor with privileges within the VMX process only, may be able to access settingsd service running as a high privileged user.
{
"affected": [],
"aliases": [
"CVE-2021-22042"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-16T17:15:00Z",
"severity": "HIGH"
},
"details": "VMware ESXi contains an unauthorized access vulnerability due to VMX having access to settingsd authorization tickets. A malicious actor with privileges within the VMX process only, may be able to access settingsd service running as a high privileged user.",
"id": "GHSA-j79m-7c8r-83mc",
"modified": "2022-02-26T00:01:05Z",
"published": "2022-02-17T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22042"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2022-0004.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J7C9-79X7-8HPR
Vulnerability from github – Published: 2025-12-03 16:27 – Updated: 2025-12-20 02:28Summary
An authorized attacker can bypass authorization checks and revoke any SSH certificate issued by Step CA by using a valid revocation token.
Details
Step CA users can obtain SSH certificates from a few provisioners. The SSHPOP provisioner allows revocation of the SSH certificate (preventing future certificate renewals) using a token. Due to a missing validity check, this token could be used to revoke any SSH certificate issued by the CA.
To create a token, an attacker must have access to the CA endpoint and a valid SSH certificate, meaning they were already authorized to obtain an SSH certificate. The attacker must also know the serial number of the certificate they want to revoke.
Impact
There is no way to mitigate this attack. It is recommended to update to v0.29.0 or newer.
Fix
In v0.29.0, the token validation logic was strengthened to bind each token to a specific SSH certificate serial number.
Acknowledgements
This issue was identified and reported by Gabriel Departout and Andy Russon, from AMOSSYS. This audit was sponsored by ANSSI (French Cybersecurity Agency) based on their Open-Source security audit program.
Embargo List
If your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.
Stay safe, and thank you for helping us keep the ecosystem secure.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.28.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/smallstep/certificates"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.29.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66406"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-03T16:27:59Z",
"nvd_published_at": "2025-12-03T20:16:26Z",
"severity": "MODERATE"
},
"details": "## Summary\nAn authorized attacker can bypass authorization checks and revoke any SSH certificate issued by Step CA by using a valid revocation token.\n\n## Details\nStep CA users can obtain SSH certificates from a few provisioners. The SSHPOP provisioner allows revocation of the SSH certificate (preventing future certificate renewals) using a token. Due to a missing validity check, this token could be used to revoke any SSH certificate issued by the CA.\n\nTo create a token, an attacker must have access to the CA endpoint and a valid SSH certificate, meaning they were already authorized to obtain an SSH certificate. The attacker must also know the serial number of the certificate they want to revoke.\n\n## Impact\nThere is no way to mitigate this attack. It is recommended to update to v0.29.0 or newer.\n\n## Fix\nIn v0.29.0, the token validation logic was strengthened to bind each token to a specific SSH certificate serial number.\n\n## Acknowledgements\nThis issue was identified and reported by Gabriel Departout and Andy Russon, from [AMOSSYS](http://amossys.fr/). This audit was sponsored by [ANSSI](https://cyber.gouv.fr/) (French Cybersecurity Agency) based on [their Open-Source security audit program](https://cyber.gouv.fr/open-source-lanssi#:~:text=Financement%20d%27%C3%A9valuations%20de%20s%C3%A9curit%C3%A9%20de%20logiciels%20libres).\n\n## Embargo List\n\nIf your organization runs Step CA in production and would like advance, embargoed notification of future security updates, visit https://u.step.sm/disclosure to request inclusion on our embargo list.\n\nStay safe, and thank you for helping us keep the ecosystem secure.",
"id": "GHSA-j7c9-79x7-8hpr",
"modified": "2025-12-20T02:28:23Z",
"published": "2025-12-03T16:27:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/smallstep/certificates/security/advisories/GHSA-j7c9-79x7-8hpr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66406"
},
{
"type": "PACKAGE",
"url": "https://github.com/smallstep/certificates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "step-ca Has Improper Authorization Check for SSH Certificate Revocation"
}
GHSA-J7CG-X2C3-V6HF
Vulnerability from github – Published: 2025-01-09 21:31 – Updated: 2025-01-10 21:31Incorrect Authorization vulnerability in Drupal Basic HTTP Authentication allows Forceful Browsing.This issue affects Basic HTTP Authentication: from 7.X-1.0 before 7.X-1.4.
{
"affected": [],
"aliases": [
"CVE-2024-13291"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-09T21:15:26Z",
"severity": "HIGH"
},
"details": "Incorrect Authorization vulnerability in Drupal Basic HTTP Authentication allows Forceful Browsing.This issue affects Basic HTTP Authentication: from 7.X-1.0 before 7.X-1.4.",
"id": "GHSA-j7cg-x2c3-v6hf",
"modified": "2025-01-10T21:31:27Z",
"published": "2025-01-09T21:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13291"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2024-057"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-J7G9-PJ98-M5M7
Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2022-05-24 17:45The Windows Installation component of TIBCO Software Inc.'s TIBCO Enterprise Message Service, TIBCO Enterprise Message Service - Community Edition, and TIBCO Enterprise Message Service - Developer Edition contains a vulnerability that theoretically allows a low privileged attacker with local access on some versions of the Windows operating system to insert malicious software. The affected component can be abused to execute the malicious software inserted by the attacker with the elevated privileges of the component. This vulnerability results from a lack of access restrictions on certain files and/or folders in the installation. Affected releases are TIBCO Software Inc.'s TIBCO Enterprise Message Service: versions 8.5.1 and below, TIBCO Enterprise Message Service - Community Edition: versions 8.5.1 and below, and TIBCO Enterprise Message Service - Developer Edition: versions 8.5.1 and below.
{
"affected": [],
"aliases": [
"CVE-2021-28821"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-23T21:15:00Z",
"severity": "HIGH"
},
"details": "The Windows Installation component of TIBCO Software Inc.\u0027s TIBCO Enterprise Message Service, TIBCO Enterprise Message Service - Community Edition, and TIBCO Enterprise Message Service - Developer Edition contains a vulnerability that theoretically allows a low privileged attacker with local access on some versions of the Windows operating system to insert malicious software. The affected component can be abused to execute the malicious software inserted by the attacker with the elevated privileges of the component. This vulnerability results from a lack of access restrictions on certain files and/or folders in the installation. Affected releases are TIBCO Software Inc.\u0027s TIBCO Enterprise Message Service: versions 8.5.1 and below, TIBCO Enterprise Message Service - Community Edition: versions 8.5.1 and below, and TIBCO Enterprise Message Service - Developer Edition: versions 8.5.1 and below.",
"id": "GHSA-j7g9-pj98-m5m7",
"modified": "2022-05-24T17:45:06Z",
"published": "2022-05-24T17:45:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28821"
},
{
"type": "WEB",
"url": "http://www.tibco.com/services/support/advisories"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J7M5-Q9G3-5Q68
Vulnerability from github – Published: 2025-07-11 18:30 – Updated: 2025-07-11 18:30An Incorrect Authorization vulnerability in the web server of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to reach the
Juniper Web Device Manager
(J-Web).
When Juniper Secure connect (JSC) is enabled on specific interfaces, or multiple interfaces are configured for J-Web, the J-Web UI is reachable over more than the intended interfaces. This issue affects Junos OS:
- all versions before 21.4R3-S9,
- 22.2 versions before 22.2R3-S5,
- 22.4 versions before 22.4R3-S5,
- 23.2 versions before 23.2R2-S3,
- 23.4 versions before 23.4R2-S5,
- 24.2 versions before 24.2R2.
{
"affected": [],
"aliases": [
"CVE-2025-6549"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-11T16:15:26Z",
"severity": "MODERATE"
},
"details": "An Incorrect Authorization vulnerability in the web server of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to reach the \n\nJuniper Web Device Manager\n\n (J-Web).\n\nWhen Juniper Secure connect (JSC) is enabled on specific interfaces, or multiple interfaces are configured for J-Web, the J-Web UI is reachable over more than the intended interfaces.\nThis issue affects Junos OS:\n\n\n\n * all versions before 21.4R3-S9,\n * 22.2 versions before 22.2R3-S5,\n * 22.4 versions before 22.4R3-S5,\n * 23.2 versions before 23.2R2-S3,\n * 23.4 versions before 23.4R2-S5,\n * 24.2 versions before 24.2R2.",
"id": "GHSA-j7m5-q9g3-5q68",
"modified": "2025-07-11T18:30:34Z",
"published": "2025-07-11T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6549"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA100098"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/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:Y/R:U/V:X/RE:M/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-J7VQ-GW7G-J543
Vulnerability from github – Published: 2021-12-15 00:00 – Updated: 2022-07-13 00:01The Spotfire Server component of TIBCO Software Inc.'s TIBCO Spotfire Server, TIBCO Spotfire Server, and TIBCO Spotfire Server contains a difficult to exploit vulnerability that allows malicious custom API clients with network access to execute internal API operations outside of the scope of those granted to it. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.'s TIBCO Spotfire Server: versions 10.10.6 and below, TIBCO Spotfire Server: versions 11.0.0, 11.1.0, 11.2.0, 11.3.0, 11.4.0, and 11.4.1, and TIBCO Spotfire Server: versions 11.5.0 and 11.6.0.
{
"affected": [],
"aliases": [
"CVE-2021-43051"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-14T20:15:00Z",
"severity": "HIGH"
},
"details": "The Spotfire Server component of TIBCO Software Inc.\u0027s TIBCO Spotfire Server, TIBCO Spotfire Server, and TIBCO Spotfire Server contains a difficult to exploit vulnerability that allows malicious custom API clients with network access to execute internal API operations outside of the scope of those granted to it. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.\u0027s TIBCO Spotfire Server: versions 10.10.6 and below, TIBCO Spotfire Server: versions 11.0.0, 11.1.0, 11.2.0, 11.3.0, 11.4.0, and 11.4.1, and TIBCO Spotfire Server: versions 11.5.0 and 11.6.0.",
"id": "GHSA-j7vq-gw7g-j543",
"modified": "2022-07-13T00:01:43Z",
"published": "2021-12-15T00:00:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43051"
},
{
"type": "WEB",
"url": "https://www.tibco.com/services/support/advisories"
},
{
"type": "WEB",
"url": "https://www.tibco.com/support/advisories/2021/12/tibco-security-advisory-december-14-2021-tibco-spotfire-server-2021-43051"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
No CAPEC attack patterns related to this CWE.