Directory traversal with remote code execution can occur in /upload in ONLYOFFICE Document Server before 5.6.3, when JWT is used, via a /.. sequence in an image upload parameter.

Every login in tangro Business Workflow before 1.18.1 generates the same JWT token, which allows an attacker to reuse the token when a session is active. The JWT token does not contain an expiration timestamp.

This affects all versions of package react-adal. It is possible for a specially crafted JWT token and request URL can cause the nonce, session and refresh values to be incorrectly validated, causing the application to treat an attacker-generated JWT token as authentic. The logical defect is caused by how the nonce, session and refresh values are stored in the browser local storage or session storage. Each key is automatically appended by ||. When the received nonce and session keys are generated, the list of values is stored in the browser storage, separated by ||, with || always appended to the end of the list. Since || will always be the last 2 characters of the stored values, an empty string ("") will always be in the list of the valid values. Therefore, if an empty session parameter is provided in the callback URL, and a specially-crafted JWT token contains an nonce value of "" (empty string), then adal.js will consider the JWT token as authentic.

InfluxDB before 1.7.6 has an authentication bypass vulnerability in the authenticate function in services/httpd/handler.go because a JWT token may have an empty SharedSecret (aka shared secret).

The JWT library in NATS nats-server before 2.1.9 has Incorrect Access Control because of how expired credentials are handled.

The JWT library in NATS nats-server before 2.1.9 allows a denial of service (a nil dereference in Go code).

ServiceStack before 5.9.2 mishandles JWT signature verification unless an application has a custom ValidateToken function that establishes a valid minimum length for a signature.

omniauth-auth0 (rubygems) versions >= 2.3.0 and < 2.4.1 improperly validate the JWT token signature when using the `jwt_validator.verify` method. Improper validation of the JWT token signature can allow an attacker to bypass authentication and authorization. You are affected by this vulnerability if all of the following conditions apply: 1. You are using `omniauth-auth0`. 2. You are using `JWTValidator.verify` method directly OR you are not authenticating using the SDK’s default Authorization Code Flow. The issue is patched in version 2.4.1.

The wpo365-login plugin before v11.7 for WordPress allows use of a symmetric algorithm to decrypt a JWT token. This leads to authentication bypass.

jwt-go before 4.0.0-preview1 allows attackers to bypass intended access restrictions in situations with []string{} for m["aud"] (which is allowed by the specification). Because the type assertion fails, "" is the value of aud. This is a security problem if the JWT token is presented to a service that lacks its own audience check.

An issue was discovered in DP3T-Backend-SDK before 1.1.1 for Decentralised Privacy-Preserving Proximity Tracing (DP3T). When it is configured to check JWT before uploading/publishing keys, it is possible to skip the signature check by providing a JWT token with alg=none.

In generator-jhipster-kotlin version 1.6.0 log entries are created for invalid password reset attempts. As the email is provided by a user and the api is public this can be used by an attacker to forge log entries. This is vulnerable to https://cwe.mitre.org/data/definitions/117.html This problem affects only application generated with jwt or session authentication. Applications using oauth are not vulnerable. This issue has been fixed in version 1.7.0.

An insufficient JWT validation vulnerability was found in Kiali versions 0.4.0 to 1.15.0 and was fixed in Kiali version 1.15.1, wherein a remote attacker could abuse this flaw by stealing a valid JWT cookie and using that to spoof a user session, possibly gaining privileges to view and alter the Istio configuration.

In Hydra (an OAuth2 Server and OpenID Certified™ OpenID Connect Provider written in Go), before version 1.4.0+oryOS.17, when using client authentication method 'private_key_jwt' [1], OpenId specification says the following about assertion `jti`: "A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties". Hydra does not check the uniqueness of this `jti` value. Exploiting this vulnerability is somewhat difficult because: - TLS protects against MITM which makes it difficult to intercept valid tokens for replay attacks - The expiry time of the JWT gives only a short window of opportunity where it could be replayed This has been patched in version v1.4.0+oryOS.17

A flaw was found in the Eclipse Che up to version 7.8.x, where it did not properly restrict access to workspace pods. An authenticated user can exploit this flaw to bypass JWT proxy and gain access to the workspace pods of another user. Successful exploitation requires knowledge of the service name and namespace of the target pod.

A hard-coded cryptographic key vulnerability in the default configuration file was found in Kiali, all versions prior to 1.15.1. A remote attacker could abuse this flaw by creating their own JWT signed tokens and bypass Kiali authentication mechanisms, possibly gaining privileges to view and alter the Istio configuration.

Xmidt cjwt through 1.0.1 before 2019-11-25 maps unsupported algorithms to alg=none, which sometimes leads to untrusted accidental JWT acceptance.

In NETGEAR Nighthawk X10-R9000 prior to 1.0.4.26, an attacker may execute arbitrary system commands as root by sending a specially-crafted MAC address to the "NETGEAR Genie" SOAP endpoint at AdvancedQoS:GetCurrentBandwidthByMAC. Although this requires QoS being enabled, advanced QoS being enabled, and a valid authentication JWT, additional vulnerabilities (CVE-2019-12510) allow an attacker to interact with the entire SOAP API without authentication. Additionally, DNS rebinding techniques may be used to exploit this vulnerability remotely. Exploiting this vulnerability is somewhat involved. The following limitations apply to the payload and must be overcome for successful exploitation: - No more than 17 characters may be used. - At least one colon must be included to prevent mangling. - A single-quote and meta-character must be used to break out of the existing command. - Parent command remnants after the injection point must be dealt with. - The payload must be in all-caps. Despite these limitations, it is still possible to gain access to an interactive root shell via this vulnerability. Since the web server assigns certain HTTP headers to environment variables with all-caps names, it is possible to insert a payload into one such header and reference the subsequent environment variable in the injection point.

Istio versions 1.2.10 (End of Life) and prior, 1.3 through 1.3.7, and 1.4 through 1.4.3 allows authentication bypass. The Authentication Policy exact-path matching logic can allow unauthorized access to HTTP paths even if they are configured to be only accessed after presenting a valid JWT token. For example, an attacker can add a ? or # character to a URI that would otherwise satisfy an exact-path match.

Connect2id Nimbus JOSE+JWT before v7.9 can throw various uncaught exceptions while parsing a JWT, which could result in an application crash (potential information disclosure) or a potential authentication bypass.