CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
6591 vulnerabilities reference this CWE, most recent first.
GHSA-XW47-6HP2-VX5F
Vulnerability from github – Published: 2023-01-31 18:30 – Updated: 2023-02-08 21:30Westbrookadmin portfolioCMS v1.05 allows attackers to bypass password validation and access sensitive information via session fixation.
{
"affected": [],
"aliases": [
"CVE-2020-20402"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-31T16:15:00Z",
"severity": "HIGH"
},
"details": "Westbrookadmin portfolioCMS v1.05 allows attackers to bypass password validation and access sensitive information via session fixation.",
"id": "GHSA-xw47-6hp2-vx5f",
"modified": "2023-02-08T21:30:22Z",
"published": "2023-01-31T18:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20402"
},
{
"type": "WEB",
"url": "https://github.com/Westbrookadmin/portfolioCMS/issues/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XW48-X32W-4M9R
Vulnerability from github – Published: 2022-05-02 03:29 – Updated: 2022-05-02 03:29Mozilla Firefox before 3.0.11, Thunderbird before 2.0.0.22, and SeaMonkey before 1.1.17 use the HTTP Host header to determine the context of a document provided in a non-200 CONNECT response from a proxy server, which allows man-in-the-middle attackers to execute arbitrary web script by modifying this CONNECT response, aka an "SSL tampering" attack.
{
"affected": [],
"aliases": [
"CVE-2009-1836"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-06-12T21:30:00Z",
"severity": "MODERATE"
},
"details": "Mozilla Firefox before 3.0.11, Thunderbird before 2.0.0.22, and SeaMonkey before 1.1.17 use the HTTP Host header to determine the context of a document provided in a non-200 CONNECT response from a proxy server, which allows man-in-the-middle attackers to execute arbitrary web script by modifying this CONNECT response, aka an \"SSL tampering\" attack.",
"id": "GHSA-xw48-x32w-4m9r",
"modified": "2022-05-02T03:29:08Z",
"published": "2022-05-02T03:29:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-1836"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=479880"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=503578"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11764"
},
{
"type": "WEB",
"url": "https://rhn.redhat.com/errata/RHSA-2009-1095.html"
},
{
"type": "WEB",
"url": "https://www.redhat.com/archives/fedora-package-announce/2009-July/msg00444.html"
},
{
"type": "WEB",
"url": "https://www.redhat.com/archives/fedora-package-announce/2009-July/msg00504.html"
},
{
"type": "WEB",
"url": "https://www.redhat.com/archives/fedora-package-announce/2009-June/msg00574.html"
},
{
"type": "WEB",
"url": "https://www.redhat.com/archives/fedora-package-announce/2009-June/msg00657.html"
},
{
"type": "WEB",
"url": "http://osvdb.org/55160"
},
{
"type": "WEB",
"url": "http://research.microsoft.com/apps/pubs/default.aspx?id=79323"
},
{
"type": "WEB",
"url": "http://research.microsoft.com/pubs/79323/pbp-final-with-update.pdf"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35331"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35415"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35431"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35439"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35440"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35468"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35536"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35561"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35602"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/35882"
},
{
"type": "WEB",
"url": "http://slackware.com/security/viewer.php?l=slackware-security\u0026y=2009\u0026m=slackware-security.372468"
},
{
"type": "WEB",
"url": "http://slackware.com/security/viewer.php?l=slackware-security\u0026y=2009\u0026m=slackware-security.425408"
},
{
"type": "WEB",
"url": "http://sunsolve.sun.com/search/document.do?assetkey=1-66-264308-1"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2009/dsa-1820"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2009/dsa-1830"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDVSA-2009:141"
},
{
"type": "WEB",
"url": "http://www.mozilla.org/security/announce/2009/mfsa2009-27.html"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2009-1126.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/35326"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/35380"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id?1022396"
},
{
"type": "WEB",
"url": "http://www.slackware.com/security/viewer.php?l=slackware-security\u0026y=2009\u0026m=slackware-security.454275"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-782-1"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/1572"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XW5G-644P-8357
Vulnerability from github – Published: 2026-08-19 00:31 – Updated: 2026-09-04 18:31Tapo C200 v5 contains an improper authentication vulnerability within the login authentication verification module. An attacker on the local network can exploit weaknesses in challenge parameter validation to bypass normal authentication controls and obtain administrative session tokens.
Successful exploitation may allow an attacker to subsequently execute privileged management actions, enable unauthorized administrative access and temporary disruption of device services, resulting in a denial-of-service (DoS) condition.
{
"affected": [],
"aliases": [
"CVE-2026-15315"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-18T22:16:49Z",
"severity": "HIGH"
},
"details": "Tapo C200 v5\ncontains an improper authentication vulnerability within the login\nauthentication verification module. An attacker on the local network can\nexploit weaknesses in challenge parameter validation to bypass normal\nauthentication controls and obtain administrative session tokens. \n\n\n\n\n\n\n\n\n\nSuccessful\nexploitation may allow an attacker to subsequently execute privileged\nmanagement actions, enable unauthorized administrative access and temporary\ndisruption of device services, resulting in a denial-of-service (DoS)\ncondition.",
"id": "GHSA-xw5g-644p-8357",
"modified": "2026-09-04T18:31:13Z",
"published": "2026-08-19T00:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-15315"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/tapo-c120/v1.26/#Firmware-Release-Notes"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/tapo-c200/v5"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/download/tapo-c120/v1.26/#Firmware-Release-Notes"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/download/tapo-c200/v5"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/faq/5248"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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-XWCG-44XM-88H2
Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2024-04-04 02:54The BIOS onboard MiR's Computer is not protected by password, therefore, it allows a Bad Operator to modify settings such as boot order. This can be leveraged by a Malicious operator to boot from a Live Image.
{
"affected": [],
"aliases": [
"CVE-2020-10278"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-24T05:15:00Z",
"severity": "MODERATE"
},
"details": "The BIOS onboard MiR\u0027s Computer is not protected by password, therefore, it allows a Bad Operator to modify settings such as boot order. This can be leveraged by a Malicious operator to boot from a Live Image.",
"id": "GHSA-xwcg-44xm-88h2",
"modified": "2024-04-04T02:54:29Z",
"published": "2022-05-24T17:21:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10278"
},
{
"type": "WEB",
"url": "https://github.com/aliasrobotics/RVD/issues/2561"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XWCP-6G2Q-65GM
Vulnerability from github – Published: 2025-05-21 21:31 – Updated: 2025-05-22 21:30An issue in D-Link DI-8100 16.07.26A1 allows a remote attacker to bypass administrator login authentication
{
"affected": [],
"aliases": [
"CVE-2025-44083"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-21T19:16:08Z",
"severity": "CRITICAL"
},
"details": "An issue in D-Link DI-8100 16.07.26A1 allows a remote attacker to bypass administrator login authentication",
"id": "GHSA-xwcp-6g2q-65gm",
"modified": "2025-05-22T21:30:45Z",
"published": "2025-05-21T21:31:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-44083"
},
{
"type": "WEB",
"url": "https://github.com/piposy/IOTsec/blob/main/Dlink/DI8100/DI8100-A1-1.md"
}
],
"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-XWFF-JWF7-FMHQ
Vulnerability from github – Published: 2025-06-06 09:30 – Updated: 2025-06-06 09:30Bypass vulnerability in the device management channel Impact: Successful exploitation of this vulnerability may affect service confidentiality.
{
"affected": [],
"aliases": [
"CVE-2025-48909"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-06T07:15:26Z",
"severity": "HIGH"
},
"details": "Bypass vulnerability in the device management channel\nImpact: Successful exploitation of this vulnerability may affect service confidentiality.",
"id": "GHSA-xwff-jwf7-fmhq",
"modified": "2025-06-06T09:30:24Z",
"published": "2025-06-06T09:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48909"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-XWH3-6M65-FMMJ
Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2022-05-24 17:35SAP HANA Database, version - 2.0, does not correctly validate the username when performing SAML bearer token-based user authentication. It is possible to manipulate a valid existing SAML bearer token to authenticate as a user whose name is identical to the truncated username for whom the SAML bearer token was issued.
{
"affected": [],
"aliases": [
"CVE-2020-26834"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-09T17:15:00Z",
"severity": "MODERATE"
},
"details": "SAP HANA Database, version - 2.0, does not correctly validate the username when performing SAML bearer token-based user authentication. It is possible to manipulate a valid existing SAML bearer token to authenticate as a user whose name is identical to the truncated username for whom the SAML bearer token was issued.",
"id": "GHSA-xwh3-6m65-fmmj",
"modified": "2022-05-24T17:35:35Z",
"published": "2022-05-24T17:35:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26834"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/2978768"
},
{
"type": "WEB",
"url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=564757079"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XWJM-QJ7J-73QW
Vulnerability from github – Published: 2022-05-01 23:36 – Updated: 2022-05-01 23:36OMEGA (aka Omegasoft) INterneSErvicesLosungen (INSEL) 7 supports authentication with a cookie that lacks a shared secret, which allows remote attackers to login as an arbitrary user via a modified cookie.
{
"affected": [],
"aliases": [
"CVE-2008-1134"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-03-04T19:44:00Z",
"severity": "MODERATE"
},
"details": "OMEGA (aka Omegasoft) INterneSErvicesLosungen (INSEL) 7 supports authentication with a cookie that lacks a shared secret, which allows remote attackers to login as an arbitrary user via a modified cookie.",
"id": "GHSA-xwjm-qj7j-73qw",
"modified": "2022-05-01T23:36:51Z",
"published": "2022-05-01T23:36:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1134"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/39575"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/28410"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/486009/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/27210"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XWWR-4H3P-R22C
Vulnerability from github – Published: 2026-09-10 22:49 – Updated: 2026-09-10 22:49Summary
rclone serve s3's handler chain, when --auth-proxy is configured, is (outermost first): authPairMiddleware -> proxyAuthMiddleware -> gofakes3's own SigV4-verifying handler.
authPairMiddleware parses the accessKeyID straight out of the incoming request's own Authorization header (entirely client-controlled) and registers {accessKey: ws.s3Secret} into gofakes3's shared credential store via AddAuthKeys, for EVERY access key any client presents - not just ones previously known to the server. ws.s3Secret defaults to "" whenever --auth-key is not set, which the --auth-proxy documentation (and the reference bin/test_proxy.py) presents as a complete, standalone authentication mechanism requiring no other flag - matching how it's used for serve webdav/ftp/sftp.
gofakes3's SigV4 verification then checks the request's signature against exactly the secret authPairMiddleware just registered for that same client-chosen key. An empty string is a valid HMAC key, so a caller can trivially compute a correct SigV4 signature for ANY access key ID of their choosing using an empty secret, and verification passes.
Crucially, the auth-proxy script never receives a real secret to verify against, for S3 specifically: Server.auth() calls w.proxy.Call(md5(accessKeyID), accessKeyID, false, r.RemoteAddr) - passing the access key ID itself as BOTH the hashed "user" and the raw "auth"/password fields. Contrast with serve webdav/ftp/sftp, whose proxy integration passes the client's actual typed password (see bin/test_proxy.py, which forwards it into a backing SFTP login for real verification). For S3, no independent secret is ever transmitted to the proxy script at all, so no script - however carefully written - can distinguish a legitimate holder of an access key ID from an attacker who merely picked the same string.
Net effect: with --auth-proxy configured and --auth-key not also set (the configuration the feature is documented to support standalone), SigV4 signature verification authenticates nobody.
Details
Vulnerable code (before fix):
func authPairMiddleware(next http.Handler, ws *Server) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
accessKey, _ := parseAccessKeyID(r)
authPair := map[string]string{accessKey: ws.s3Secret}
ws.faker.AddAuthKeys(authPair)
next.ServeHTTP(w, r)
})
}
PoC
Built and signed a request by hand (via the vendored github.com/aws/aws-sdk-go-v2/aws/signer/v4) using a freshly-random access key ID never configured or returned by anything, with SecretAccessKey: "", against a real rclone serve s3 --auth-proxy <script> instance with no --auth-key set:
status=200
<ListAllMyBucketsResult>...<Bucket><Name>mybucket</Name>...
A fully authenticated, successful bucket listing, with zero prior credential knowledge.
Impact
Any network-reachable, unauthenticated attacker who knows (or discovers) that a target is running rclone serve s3 --auth-proxy without --auth-key can choose an arbitrary access key ID, sign a request against an empty secret, and be treated as an authenticated user by the auth-proxy script - reaching whatever backend that script resolves the chosen identity to. No credentials, prior access, or user interaction of any kind are required.
Fix
Refuse to start rclone serve s3 when --auth-proxy is set without --auth-key, rather than silently falling back to a signature check that authenticates nobody:
if proxyOpt.AuthProxy != "" && len(opt.AuthKey) == 0 {
return nil, errors.New("serve s3: --auth-proxy requires --auth-key to also be set (SigV4 has no other way to verify a signature for a dynamically-proxied identity)")
}
Note this is a minimal fix for the zero-knowledge bypass; once --auth-key is also set, every access key ID still shares that one static secret for signature-verification purposes (a caller who knows it can request any identity from the proxy script) - a narrower, pre-existing limitation flagged for awareness but not changed here, since a complete fix needs the auth-proxy wire protocol to carry a per-identity secret for S3 specifically (a larger design change).
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rclone/rclone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.75.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-88018"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:49:07Z",
"nvd_published_at": "2026-09-10T16:18:08Z",
"severity": "CRITICAL"
},
"details": "### Summary\n`rclone serve s3`\u0027s handler chain, when `--auth-proxy` is configured, is (outermost first): `authPairMiddleware` -\u003e `proxyAuthMiddleware` -\u003e gofakes3\u0027s own SigV4-verifying handler.\n\n`authPairMiddleware` parses the accessKeyID straight out of the incoming request\u0027s own `Authorization` header (entirely client-controlled) and registers `{accessKey: ws.s3Secret}` into gofakes3\u0027s shared credential store via `AddAuthKeys`, for EVERY access key any client presents - not just ones previously known to the server. `ws.s3Secret` defaults to `\"\"` whenever `--auth-key` is not set, which the `--auth-proxy` documentation (and the reference `bin/test_proxy.py`) presents as a complete, standalone authentication mechanism requiring no other flag - matching how it\u0027s used for `serve webdav`/`ftp`/`sftp`.\n\ngofakes3\u0027s SigV4 verification then checks the request\u0027s signature against exactly the secret `authPairMiddleware` just registered for that same client-chosen key. An empty string is a valid HMAC key, so a caller can trivially compute a correct SigV4 signature for ANY access key ID of their choosing using an empty secret, and verification passes.\n\nCrucially, the auth-proxy script never receives a real secret to verify against, for S3 specifically: `Server.auth()` calls `w.proxy.Call(md5(accessKeyID), accessKeyID, false, r.RemoteAddr)` - passing the access key ID itself as BOTH the hashed \"user\" and the raw \"auth\"/password fields. Contrast with `serve webdav`/`ftp`/`sftp`, whose proxy integration passes the client\u0027s actual typed password (see `bin/test_proxy.py`, which forwards it into a backing SFTP login for real verification). For S3, no independent secret is ever transmitted to the proxy script at all, so no script - however carefully written - can distinguish a legitimate holder of an access key ID from an attacker who merely picked the same string.\n\nNet effect: with `--auth-proxy` configured and `--auth-key` not also set (the configuration the feature is documented to support standalone), SigV4 signature verification authenticates nobody.\n\n### Details\nVulnerable code (before fix):\n```go\nfunc authPairMiddleware(next http.Handler, ws *Server) http.Handler {\n\treturn http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n\t\taccessKey, _ := parseAccessKeyID(r)\n\t\tauthPair := map[string]string{accessKey: ws.s3Secret}\n\t\tws.faker.AddAuthKeys(authPair)\n\t\tnext.ServeHTTP(w, r)\n\t})\n}\n```\n\n### PoC\nBuilt and signed a request by hand (via the vendored `github.com/aws/aws-sdk-go-v2/aws/signer/v4`) using a freshly-random access key ID never configured or returned by anything, with `SecretAccessKey: \"\"`, against a real `rclone serve s3 --auth-proxy \u003cscript\u003e` instance with no `--auth-key` set:\n```\nstatus=200\n\u003cListAllMyBucketsResult\u003e...\u003cBucket\u003e\u003cName\u003emybucket\u003c/Name\u003e...\n```\nA fully authenticated, successful bucket listing, with zero prior credential knowledge.\n\n### Impact\nAny network-reachable, unauthenticated attacker who knows (or discovers) that a target is running `rclone serve s3 --auth-proxy` without `--auth-key` can choose an arbitrary access key ID, sign a request against an empty secret, and be treated as an authenticated user by the auth-proxy script - reaching whatever backend that script resolves the chosen identity to. No credentials, prior access, or user interaction of any kind are required.\n\n### Fix\nRefuse to start `rclone serve s3` when `--auth-proxy` is set without `--auth-key`, rather than silently falling back to a signature check that authenticates nobody:\n```go\nif proxyOpt.AuthProxy != \"\" \u0026\u0026 len(opt.AuthKey) == 0 {\n\treturn nil, errors.New(\"serve s3: --auth-proxy requires --auth-key to also be set (SigV4 has no other way to verify a signature for a dynamically-proxied identity)\")\n}\n```\nNote this is a minimal fix for the zero-knowledge bypass; once `--auth-key` is also set, every access key ID still shares that one static secret for signature-verification purposes (a caller who knows it can request any identity from the proxy script) - a narrower, pre-existing limitation flagged for awareness but not changed here, since a complete fix needs the auth-proxy wire protocol to carry a per-identity secret for S3 specifically (a larger design change).",
"id": "GHSA-xwwr-4h3p-r22c",
"modified": "2026-09-10T22:49:07Z",
"published": "2026-09-10T22:49:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/security/advisories/GHSA-xwwr-4h3p-r22c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88018"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/commit/90595f34f27f569be6b27c57fe5ab65057d323bd"
},
{
"type": "PACKAGE",
"url": "https://github.com/rclone/rclone"
},
{
"type": "WEB",
"url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
}
],
"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"
}
],
"summary": "rclone serve s3: --auth-proxy without --auth-key authenticates nobody - full SigV4 signature bypass"
}
GHSA-XX2R-X7VM-XJJJ
Vulnerability from github – Published: 2022-04-05 00:00 – Updated: 2022-04-14 00:00A local authentication restriction bypass vulnerability was discovered in HPE OneView version(s): Prior to 6.6. HPE has provided a software update to resolve this vulnerability in HPE OneView.
{
"affected": [],
"aliases": [
"CVE-2022-23699"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-04T20:15:00Z",
"severity": "HIGH"
},
"details": "A local authentication restriction bypass vulnerability was discovered in HPE OneView version(s): Prior to 6.6. HPE has provided a software update to resolve this vulnerability in HPE OneView.",
"id": "GHSA-xx2r-x7vm-xjjj",
"modified": "2022-04-14T00:00:42Z",
"published": "2022-04-05T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23699"
},
{
"type": "WEB",
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbgn04252en_us"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.