| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in the OIDC logout endpoint of the keycloak-services component, which handles user session termination in Red Hat Build of Keycloak. The issue occurs because the system sets a session cookie based on an unvalidated token hint before completing security checks. An attacker can use this flaw to fix a session ID in a victim's browser, allowing them to hijack the victim's subsequent login and gain full control over their account. |
| Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows requests authenticated using HTTP Basic authentication, including with an API token, to obtain a "remember me" cookie, allowing attackers who have obtained a user's API token to retain access to Jenkins using a "remember me" cookie after the API token is revoked or expires. |
| Vulnerability in the Advanced Networking Option component of Oracle Database Server. Supported versions that are affected are 12.1.0.2, 12.2.0.1 and 19c. Difficult to exploit vulnerability allows unauthenticated attacker with network access via Oracle Net to compromise Advanced Networking Option. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Advanced Networking Option, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Advanced Networking Option. Note: The July 2021 Critical Patch Update introduces a number of Native Network Encryption changes to deal with vulnerability CVE-2021-2351 and prevent the use of weaker ciphers. Customers should review: "Changes in Native Network Encryption with the July 2021 Critical Patch Update" (Doc ID 2791571.1). CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H). |
| Session fixation in Apache Wicket.
org.apache.wicket.authroles.authentication.AuthenticatedWebSession is the authentication base class of Wicket's role-based security module, and its signIn(String, String) method is the entry point through which an application authenticates a session. Renewing the container session id at that point is the standard defence against an attacker who has fixed a session id in a victim's browser, and Wicket provides that renewal as org.apache.wicket.Session#changeSessionId(), whose documentation directs callers to invoke it on login for exactly that reason.
AuthenticatedWebSession#signIn(String, String) calls it inside a guard that succeeds only on the first transition of the session's signed-in flag. The session id is therefore renewed when a session first signs in, and is not renewed when a session that is already signed in authenticates again. signIn(String, String) returns true either way, so neither the caller nor the application can tell that the renewal did not happen.
An application is affected where it authenticates through AuthenticatedWebSession, which AuthenticatedWebApplication requires and which the shipped UsernamePasswordPanel uses, and where a session that is already signed in can authenticate again: a step-up prompt before a sensitive action, an account switch, or simply a sign-in form that stays reachable once the user is signed in. Nothing in the module hides that form from a signed-in session. Reaching the defect also requires an attacker to place a session id of their choosing in the victim's browser. JSESSIONID is set by the servlet container rather than by Wicket, so that needs a position Wicket does not grant, such as control of a host under the same registrable domain or a container configured to carry the session id in the URL, and the planted session has to be one the attacker has already signed in on, because a session that is not yet signed in does have its id renewed by the victim's authentication. An authentication attempt that fails signs the session out and closes the window. Applications that renew the session id in their own code after a successful authentication are not affected.
As a workaround, renew the session id from the application's own code on every successful authentication, by calling Session#changeSessionId() at the end of the authenticate(String, String) implementation.
This issue affects Apache Wicket: from 8.18.0 through 8.19.0, from 9.23.0 through 9.24.0, from 10.9.0 through 10.11.0.
Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. |
| java/org/apache/catalina/authenticator/FormAuthenticator.java in the form authentication feature in Apache Tomcat 6.0.21 through 6.0.36 and 7.x before 7.0.33 does not properly handle the relationships between authentication requirements and sessions, which allows remote attackers to inject a request into a session by sending this request during completion of the login form, a variant of a session fixation attack. |
| When using FORM authentication with Apache Tomcat 9.0.0.M1 to 9.0.29, 8.5.0 to 8.5.49 and 7.0.0 to 7.0.98 there was a narrow window where an attacker could perform a session fixation attack. The window was considered too narrow for an exploit to be practical but, erring on the side of caution, this issue has been treated as a security vulnerability. |
| An issue was discovered in Quest KACE Systems Deployment Appliance (SMA) 11.0.273. Certain API endpoints contain a rate-limiting feature to minimize a brute-force attack. This protection can be bypassed by removing the kboxid cookie. |
| Catalyst::Plugin::Authentication versions before 0.10_027 for Perl is susceptible to session fixation attacks.
Catalyst::Plugin::Authentication does not automatically change the session id after authentication. An attacker that obtains a session id cookie can use this to impersonate the victim. |
| Session fixation vulnerability in Drupal 5.x before 5.9 and 6.x before 6.3, when contributed modules "terminate the current request during a login event," allows remote attackers to hijack web sessions via unknown vectors. |
| Session fixation vulnerability in Joomla! before 1.0.13 (aka Sunglow) allows remote attackers to hijack administrative web sessions via unspecified vectors. |
| Session fixation vulnerability in SquirrelMail before 1.4.18 allows remote attackers to hijack web sessions via a crafted cookie. |
| mod_usertrack in Apache 1.3.11 through 1.3.20 generates session ID's using predictable information including host IP address, system time and server process ID, which allows local users to obtain session ID's and bypass authentication when these session ID's are used for authentication. |
| OpenSSL and SSLeay allow remote attackers to reuse SSL sessions and bypass access controls. |
| An improper session validation allows an unauthenticated attacker to cause certain request notifications to be executed in the context of an incorrect user by spoofing the client IP address. |
| A malicious actor can fix the session of a PAM user by tricking the user to click on a specially crafted link to the PAM server. |
| All-Dynamics Software enlogic:show 2.0.2 contains a session fixation vulnerability that allows attackers to set a predefined PHP session identifier during the login process. Attackers can forge HTTP GET requests to welcome.php with a manipulated session token to bypass authentication and potentially execute cross-site request forgery attacks. |
| The Itel DAB Gateway (IDGat build c041640a) is vulnerable to Authentication Bypass due to improper JWT validation across devices. Attackers can reuse a valid JWT token obtained from one device to authenticate and gain administrative access to any other device running the same firmware, even if the passwords and networks are different. This allows full compromise of affected devices. |
| The Itel DAB Encoder (IDEnc build 25aec8d) is vulnerable to Authentication Bypass due to improper JWT validation across devices. Attackers can reuse a valid JWT token obtained from one device to authenticate and gain administrative access to any other device running the same firmware, even if the passwords and networks are different. This allows full compromise of affected devices. |
| Cross-Site Request Forgery (CSRF) vulnerability in the OAuth implementation of the Tuya SDK 6.5.0 for Android and iOS, affects the Tuya Smart and Smartlife mobile applications, as well as other third-party applications that integrate the SDK, allows an attacker to link their own Amazon Alexa account to a victim's Tuya account. The applications fail to validate the OAuth state parameter during the account linking flow, enabling a cross-site request forgery (CSRF)-like attack. By tricking the victim into clicking a crafted authorization link, an attacker can complete the OAuth flow on the victim's behalf, resulting in unauthorized Alexa access to the victim's Tuya-connected devices. This affects users regardless of prior Alexa linkage and does not require the Tuya application to be active at the time. Successful exploitation may allow remote control of devices such as cameras, doorbells, door locks, or alarms. |
| Session Fixation vulnerability in Apache Tomcat via rewrite valve.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.7, from 10.1.0-M1 through 10.1.41, from 9.0.0.M1 through 9.0.105.
Older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.8, 10.1.42 or 9.0.106, which fix the issue. |
